PMがうさみみ付けて円陣組む？−アジャイルの方法論のまぜまぜの仕方

最近、「アジャイルを採用したい。しかし、どの方法論を採用して、
どのようにやっていけば、開発が最初から最後まで通るのか、
想像できないので教えてくれ」といわれたことがあった。

そのときの答えたのを、まとめてみる



まず、開発の場合、実際の開発と、マネージメント部分がある。
マネージメント部分に【スクラム】を持ってくると、考えやすい。

「スクラム」の場合、プロダクトバックログを作らないといけない。
これを作るまでの方法として

・【インセプション・デッキ】を作成して、顧客や製品・サービス、
　業務に関係する人を考える

・業務に関係する人が判ったら、その人たちの【ユーザーストーリー
　マッピング】(byジェフ・パットン）を作成して、そこから、
　要求と(作れるものであれば）【ペーパープロトタイプ】を作成する。
　ライブラリなどは、プロトタイプではなく、ユースケースシナリオ
　やシーケンスフローになることもある。

・少なくとも要求は出てくるので、その要求を”プロダクトバックログ”
　にまとめる。あとは、「スクラム」の手順
　　・スプリント計画ミーティング
　　・デイリースクラム
　　・スプリントレビュー
　　・スプリントレトロスペクティブ
　を行うわけだが、（内容はここの下のほうに書いた）
　これはマネージメント的な視点であり、

　スプリント計画ミーティングで、見積もりと設計(＝スプリントバックログへの記入）を
行うことになる。

　実装を実際にやる上では【TDD】を採用しないと、
　ライブラリ開発などのときは、スプリントレビューで見せるものが無い
　（デモできない）

　「TDD」で、ユースケースシナリオの事前条件をセットして、現スプリントで
　作成するものを呼び出し、事後条件に一致していたら緑色になる（つまり、
　JUNITなどの、一般に言うユニットテスト）ようにしておけば、スプリント
　レビューで緑色になるところが見せられる。

　コーディングなどの実装は【XP】を採用することになる。
　・・・と書くと、”ペアプログラミング”のとき、２人必要なので、
　人件費が高騰する・・・とまずいので、
　ペアのうちの一人は、プロジェクトマネージャー（PM)とし、ずーっと
ペアプロしているのではなく、時間を区切って、PMが担当者を回る
というようにするしかない。
　つまり、担当者とPMがペアを組む（時間を１日のうち数時間、組む）。
　PMは、スクラムマスターもやるとなれば、人件費は高騰しないし、
毎日その場で、進捗状況がわかる。
　ただ、そのためには、PMは嫌われるといけないので、とりあえず、
うさみみをつけてペアプログラミングする（とは、言わなかった）。

　この方法だと、単体テストまでは完了し、結合も一部行っているが、
　システムができたとき、結合の一部と総合がのこる。
　そこで、この部分を手分けしてやると同時に、操作マニュアルを
作成する。



【】が、アジャイルの手法に相当する。　

　まとめると、手始めに
PMが(ペアプログラミングするため）うさみみを付けて
みんなで円陣(スクラム）を組めばよさそうだ・・・

・・・そうなのか（この部分は、言ってない）