« 第42回IT勉強宴会「話題のRedmineの魅力を知ろう」の感想 | トップページ | Redmine BacklogsプラグインはScrumプロセスを忠実に実現しようとしている »

2015/07/18

ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか

Redmineを導入したいという話を受けて、Redmineを導入した時、後で気づくのは、ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか、という問題。
ラフなメモ書き。
結論はなし。

【参考】
akipiiさんはTwitterを使っています: "改めて読むとなるほどを思う。「ツールは高速道路だが、その上を時速何キロで走れるのかはチームの成熟度に依存しているのだ。」書評 アジャイルソフトウェアエンジニアリング http://t.co/mwzki9EZGi @ryuzeeさんから"

OjaさんはTwitterを使っています: "管理者受けし易い代わりに、うまく使えるかどうかも管理者次第なので、管理者の実力と評価がそのままRedmineの評価になるんじゃないかという仮説 RT @t_yoshi_tomi 何故、 Redmineを気に入る人と Redmineを毛嫌いする人がいるのだろうか・・・"

よしむさんはTwitterを使っています: "@kawanishi_ameya プロジェクトによって運用具合もバラつきがありますし、管理者次第というところが影響してくるんですね・・・(泣)"

akipiiさんはTwitterを使っています: "同感。RT @n_enot: チームでのソフトウェア開発って本当に難しくて、だからみんなPullRequest駆動やチケット駆動、あるいはもっと単純に相談&告知、最悪な例だと申請&ハンコ承認といった、とにかく協調して作業する方法が探られているわけです。"

みずのり(みずののりゆき)さんはTwitterを使っています: "個人的に。 プロセスとツールの両方を同時に変えるのは難しいので、まずはEXCELな従来ツールで展開ツール活用時に近いプロセスを実装。 そこから”ツールの方が便利ですよ”とやってみると導入しやすい感。 前者のプロセス変更に対応出来ないチームにはツール導入しても使われないっす。"

みずのり(みずののりゆき)さんはTwitterを使っています: "最近やったのはプロセス導入の段階で、かなり苦労して試行錯誤して枠組み作ったけど、そのプロセスの安定した形態はすぐにツールに置き換え可能なものでしたとさ。 チケット駆動の考え方をプロセスにしたので、redmine置き換えがすぐに出来るのは当たり前なのですが^^;"

僕個人の経験では、Redmineというツールを導入した後に、こういうふうにプロセスを回すのだな、と気づきながら運用していた。
だから、ツールを使いながら、あるべきプロセスを導き出したように思う。

でも、実際はそうではなかったかもしれない。
ツールの導入前は、アジャイル開発を実践した経験はほとんど無かったけれど、アジャイル開発の知識は持っていたし、こういうふうに運用したい、という思いはあった。

WF型開発できちんと変更管理するやり方も、色んなSIを渡り歩きながら、学んでいた。
SIer特製の障害管理Webシステムへの障害票の書き方、コミットする時には障害管理番号を記載すること、CVSのコミットログに変更理由を記入すること、などの運用ルールはある程度分かっていた。
だから、Redmineを障害管理からタスク管理へ発展させて使う方法はマッチできた。

実際は、プロセスが確立されたイメージを持ってツールを導入していたのだろう。

ツールは高速道路であり、上手く使えば、ゴールまで速く到達することはできる。
でも、高速道路の走り方も多少はあるし、車のエンジン(=チームの能力)が性能を出し切れなければ、国道を走っている時と変わらないかもしれない。

色々考えてみる。

【追記】
下記の記事が参考になる。

NotesのDB設計ができる人はチケット管理システムのプロジェクトへの適用にアドバンテージを持っている - 室長のひとりごち

(引用開始)
ところで、Notesってあったでしょう。あ、今もあるか。アレのDBの設計を経験したことがある人は、チケット管理システムのビューやフォームの設計のハードル皆無だと思います。

ラベルをもったデータ項目を追加するか、標準のデータ項目を使いまわすことで、システム開発手法で管理したい情報を持たればいいとか、開発プロセスごとで見たい情報をビューで見せることができるとか、そういったことがわりとすんなりイメージできます。
(中略)

そのときのワタシの頭の中にあったことは「問題解決をするためにツールの導入を考えていたのか」と聞かれれば答えは「ノー」です。問題はプロセスにあると見切り、その問題のあるプロセスままだと潜在化したままで進行してしまうので「可視化」が問題解決の決め手と思った、と当時判断したと思います。今でもそうすると思いますが。

そこには、そう判断した根っこにはチケット管理システムはプロセス管理システムとして使える、と思ったんですね。そのおおもとを辿るとNotesもその1つの要素なのかもしれません。

その点から言えば、確立した開発プロセスのイメージを持っているから、適用するプロジェクトの課題解決のための1つの手段としてツールを導入することを判断した、のではないかと思うのです。
(引用終了)

|

« 第42回IT勉強宴会「話題のRedmineの魅力を知ろう」の感想 | トップページ | Redmine BacklogsプラグインはScrumプロセスを忠実に実現しようとしている »

ソフトウェア工学」カテゴリの記事

チケット駆動開発」カテゴリの記事

Ruby」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« 第42回IT勉強宴会「話題のRedmineの魅力を知ろう」の感想 | トップページ | Redmine BacklogsプラグインはScrumプロセスを忠実に実現しようとしている »