ぷららのブログサービス(Broach)終了に伴い
ぷららのブログサービス(Broach)上に置いていた過去のブログ記事をこちらにインポートしました。
Blog引っ越しました The Blog has been moved.
アジャイルやリーンのパイロットプロジェクトに関する考察
Business ValueとCustomer Value
"Business value" is NOT what people want..
— Bob Marshallさん (@flowchainsensei) 2月 9, 2012
彼がどういう意図をもってこのtweetをしたのか私にはわかりません。でも確かに私自身をふりかえってみても、ビジネス価値の実現のために仕事や生活をしているかというとそうでもないような気がします。
そんな中で、考えるヒントとなりそうな資料がありましたので、ここで共有しておきたいと思います。ここで埋め込んでいるプレゼンテーション2つは、Dennis Stevens氏による"What to Build"を考えるにあたってのBusiness Analysisの手法に関するものです。重複する部分もありますが、それぞれに重要な要素が含まれていますので両方ともご覧になることをおすすめします。
BABOKのAgile Extensionが生む(かもしれない)誤解
1. 世の中にはアジャイルかウォーターフォールしかない、つまりアジャイルを採用しなければ、全て計画駆動で要求フェーズが1回きりのモデルに従わなければならない、という誤解。 2. 要求をJust-in-Timeで定義することが他の全てのモデルよりすぐれているという誤解。 3. ドキュメンテーションは、直近のチームのニーズを満たす最小限のものを自動化しておけばよいという誤解。確かに、そういう風に読もうと思えば読めなくもないですね。そして、その部分に対して読者が誤解をしないように警鐘を鳴らしてくれるのはありがたい話でもあります。(特に、BABOKのAgile Extensionが、主に従来型のトラディショナルなやり方を得意とし、アジャイル開発への理解が乏しい場合には、そういう誤解を生んでしまうおそれは十分にあると思います。) でもね、それこそこの前のエントリに書いたように「自分の頭で考えようよ」という話ですよ。できるだけ誤解を避けるような書き方をすることの重要性を否定するわけではないですが、同時に、コンテキストを理解して自分の頭で考えるということがアジャイルな開発にとって重要であるということにフォーカスを当てた方がいいのではないかというのが、元記事を読んだ私の率直な感想です。「BABOKにこう書いてあるからこうしなければいけない」と妄信・固執する人には、そもそもアジャイルは向いてないよ、とか言っちゃうと問題ありそうだからそこまでは言わないですけど。 元記事の筆者が、記事で主張している内容についてIIBAに直接伝えたかどうかわかりませんが、このあたりの内容については、現在のAgile Extensionのドラフト版が今後どのように変わっていくかは注目したいところです。 併せて読みたいBABOK/Agile Extension関連の過去エントリ: BABOK(アジャイル拡張)の歩き方 Business Analysis in Agile Life-Cycles
仕事のやり方を考える時に心がけたいこと
「貴様が何を信じていようがかまわん。キリストだろうがマホメットだろうがイワシの頭だろうが、勝手に信じるがいい。もし本当に自分の頭で考え抜いたすえに、それを信じているのならな」
「何かにとらわれて生きることは容易だ。だが、それは自分の目で世界を見る責任を放棄することだ。自分自身であることを放棄することだ」
アジャイルの成功確率はウォーターフォールの3倍?
Mike Cohn氏が今週月曜日(2月13日)のブログで、Standishグループのレポートからアジャイルとウォーターフォールの成功確率に関する部分を引用・報告しています。 Mike Cohn's Blog - Succeeding with Agile "AGILE SUCCEEDS THREE TIMES OFTEN THAN WATERFALL" まず、そこで引用されているグラフをここにも転載させていただきます。
(Source URL: http://blog.mountaingoatsoftware.com/agile-succeeds-three-times-more-often-than-waterfall ) 確かにこのグラフを見ると、SUCCESSFULの割合がウォーターフォールで14%に対してアジャイルでは42%と3倍になっています。但し、この結果についてはそのまま鵜呑みにするわけにはいきません。いくつかの疑問や懸念点についてはブログ記事のコメント欄で読者とMike Cohn氏の間でも活発に議論されている通り、いわゆる「突っ込みどころ満載」状態です。 まず、統計の元データの詳細が明らかにされていないためわからないことが多く残されています。"SUCCESSFUL"の定義をどう捉えるかというのも大きなポイントですし、ウォーターフォールと称しているものが、元々のRoyce論文にあるようなものを指すのか、その後DoDでスタンダードとして採択された際に曲げられてしまった以降のものを指すのか、そもそもウォーターフォールとは名ばかりの「なんちゃってウォーターフォール」をも含んでいるのかというあたりにも疑問はあります。 それから、レポートの中で"Agile Process"という呼び方がされていますが、そもそもアジャイルってプロセスだっけ?というのもありますね。前述の"SUCCESSFUL"の定義についても記事の中では、"The Standish Group defines project success as on time, on budget, and with all planned features. "と書かれていますが、"all planned features"というくだりは、そもそもアジャイルな考え方と相反するものでは?という気がしないでもありません。 というわけで、このレポートについては話題としては面白いけど、これだけでどうこう言えるものではないし、方法論やプロセスの優劣というよりは、組織やプロジェクトのコンテキストに応じて最適なやり方を自分たちでちゃんと考えることの方が大事だということには変わりはないということだと思います。 ちなみに似たようなテーマの調査としては、Scott W. Ambler氏の 2011 IT Project Success Rates Survey Results というものもあります。 対比してみると面白い(かもしれない)ので、結果のグラフのみ、転載しておきます。
(Source URL: http://www.ambysoft.com/surveys/success2011.html ))