最近、「アジャイルを採用したい。しかし、どの方法論を採用して、
どのようにやっていけば、開発が最初から最後まで通るのか、
想像できないので教えてくれ」といわれたことがあった。
そのときの答えたのを、まとめてみる
まず、開発の場合、実際の開発と、マネージメント部分がある。
マネージメント部分に【スクラム】を持ってくると、考えやすい。
「スクラム」の場合、プロダクトバックログを作らないといけない。
これを作るまでの方法として
・【インセプション・デッキ】を作成して、顧客や製品・サービス、
業務に関係する人を考える
・業務に関係する人が判ったら、その人たちの【ユーザーストーリー
マッピング】(byジェフ・パットン）を作成して、そこから、
要求と(作れるものであれば）【ペーパープロトタイプ】を作成する。
ライブラリなどは、プロトタイプではなく、ユースケースシナリオ
やシーケンスフローになることもある。
・少なくとも要求は出てくるので、その要求を”プロダクトバックログ”
にまとめる。あとは、「スクラム」の手順
・スプリント計画ミーティング
・デイリースクラム
・スプリントレビュー
・スプリントレトロスペクティブ
を行うわけだが、（
内容はここの下のほうに書いた）
これはマネージメント的な視点であり、
スプリント計画ミーティングで、見積もりと設計(＝スプリントバックログへの記入）を
行うことになる。
実装を実際にやる上では【TDD】を採用しないと、
ライブラリ開発などのときは、スプリントレビューで見せるものが無い
（デモできない）
「TDD」で、ユースケースシナリオの事前条件をセットして、現スプリントで
作成するものを呼び出し、事後条件に一致していたら緑色になる（つまり、
JUNITなどの、一般に言うユニットテスト）ようにしておけば、スプリント
レビューで緑色になるところが見せられる。
コーディングなどの実装は【XP】を採用することになる。
・・・と書くと、”ペアプログラミング”のとき、２人必要なので、
人件費が高騰する・・・とまずいので、
ペアのうちの一人は、プロジェクトマネージャー（PM)とし、ずーっと
ペアプロしているのではなく、時間を区切って、PMが担当者を回る
というようにするしかない。
つまり、担当者とPMがペアを組む（時間を１日のうち数時間、組む）。
PMは、スクラムマスターもやるとなれば、人件費は高騰しないし、
毎日その場で、進捗状況がわかる。
ただ、そのためには、PMは嫌われるといけないので、とりあえず、
うさみみをつけてペアプログラミングする（とは、言わなかった）。
この方法だと、単体テストまでは完了し、結合も一部行っているが、
システムができたとき、結合の一部と総合がのこる。
そこで、この部分を手分けしてやると同時に、操作マニュアルを
作成する。
【】が、アジャイルの手法に相当する。
まとめると、手始めに
PMが(ペアプログラミングするため）うさみみを付けて
みんなで円陣(スクラム）を組めばよさそうだ・・・
・・・そうなのか（この部分は、言ってない）
ウィリアムのいたずら @xmldtp
アクセス
トータル
ランキング
