カイゼンにっき。

@hyokota です。主にtwitterに呟いていますが、twitterに書ききれない事をここに綴って行こうかと。

アジャイルな計画の有効性を伝えるための障壁とは 〜アジャイルサムライ新宿道場#04に参加しました！〜

agile 勉強会

アジャイルサムライ新宿道場#04に参加してきました。
下記、参加して私が感じたことのまとめです。
※例によって、勉強会のまとめではないことにご注意を。

他のアジャイルサムライ新宿道場#04の記事

アジャイルな計画の有効性を伝えるための障壁

主要な（そして回答が難しい）批判

  1. 最初に全体を見通せないので、適当でないアーキテクチャになったり、局所最適化に陥らないのか？
  2. 最初に全体を見通せないので、契約や予算どりをどうするのか？

この辺りの問いはよく聞かれるが、（少なくとも私は）答えるのが難しい。
常に向き合っていくべき問いなのかもしれない。

下記は勉強会で学んだこと。

最初に全体を見通せないので、適当でないアーキテクチャになったり、局所最適化に陥らないのか？

陥る。
これは認識されており、アーキテクチャの大々的な変更は「アーキテクチャジャンプ」と呼ばれている。
※ニュアンスとして、「避けられればもちろんよいが、避けられない」もののように書かれている。

ただ、アジャイルなソフトウェア開発（主にXP）では、従来の常識と異なり、
変更コストは「時とともに急激に上昇」しない、という仮定を置いている。
※この仮定は、UT, CI, リファクタリング, DRY, YAGNI などのプラクティスからもたらされる。

よって、アーキテクチャジャンプのコストは、それほど大きくはならない。

でも、最初に全体を見通していれば効率よく出来たのに。

答えは二つ。

・変更は常に起こるし、最初から完璧なものは出来ない、とされている。
最初に全体を見通すためにいくら努力しても、結局それは正しくない、変更する必要が出てくる、よって無駄だ、という理念がある。

・インフラを構築するために、顧客に価値を提供しない時期が長時間あってはいけない、という理念がある。

では、アーキテクチャはどうすればよいのか？

アーキテクチャの創発を「自然に起こる」のを待つ とのこと。
何となくわかるものの、これでは説明できない。

私にはまだ答えが出せていない。ただ、下記が参考になりそう。

また Jim Coplien は、

開発は２つのレベルで進行する。
(1) アーキテクチャ
(2) 実装
２つは同時進行し、かつ、お互いに強い相互作用がある。
新しい実装はアーキテクチャの変更を示唆する。アーキテクチャの変更は、ふつう大幅な実装の変更を強制する。

と示唆。

アーキテクチャとは？ Grady Booch によると。。。：An Agile Way：ITmedia オルタナティブ・ブログ

また、RUPではアーキテクチャを初期に構築している。こちらの考え方も学ぶ価値があるかもしれない。この辺り、もっと勉強したい。

アーキテクチャジャンプは顧客に価値を生まない。どう説明する？

下記の事を、誠実に顧客にそのまま伝えるしかないと思う。

  • 実施しないと、以後の作業コストは増大していく
  • 実施すると、最悪1イテレーション程度、新しいストーリーを実現できない

最初に全体を見通せないので、契約や予算どりをどうするのか？

個人的な見解としては、アジャイルなプロジェクトが誠実なだけではないか、と思っている。
WF（ウォーターフォール）型では、本当に最初に全体が見通せているのか？

そもそも、WF型は全てが予測可能で変化しないことを、アジャイルでは全てが変化することをそれぞれ前提にしている。
両者とも上手くいく、という仮定をおけば、より都合のよい前提を置いているWF型の方が有利なことは当然である。

問題は、その前提が成り立つかどうかだ。私は（そしてアジャイルを推奨する方々も）その前提は成り立たないと確信している。
そして、WF型はこの前提が崩れると弱い。

アジャイルでは、最初に全体が見通ず、確実なコミットメントができないことを真摯に伝えている。

とはいえ、契約が難しいことに変わりないよね？

おっしゃる通り。私も答えは出せていません。
IPAでレポートが出ていたります（私は、実はまだ読んでません）。

参考になる！

なお、海外では、日本よりもずっと、委託側の個人や部門の権限が強いらしいので、
アジャイルなソフトウェア開発における契約形態は、日本ほど問題にならない、とのことです。

この辺りも、もっと勉強したい。

その他学んだこと

私のtwitter上のまとめメモを掲載します。

チーム運用島



宇宙チーム



ワールドカフェ外