アジャイルサムライを読み進めながら、自分の業務と照らし合わせながら、落とし込み方を考えていきます。
チケット管理システム（RedmineやBacklog、tracなど）やCIツールとしてJenkinsを使っているので、その使い方と合わせながら考えて行きたいと思います。
まずは最初に気になったところから。
アジャイルに取り組むために6つの大事なことがあるようです。
- 大きな問題は小さくする
- 本当に大事なことに集中して、それ以外のことは忘れる。
- ちゃんと動くソフトウェアを届ける
- フィードバックを求める
- 必要とあらば進路を変える
- 成果責任を果たす
1.大きな問題は小さくする
アジャイルでは定期的に価値あるものをリリースすることが大事とされています。
そのためには1サイクルで終わるレベルに問題を小さくシンプルにする必要があります。
具体的には・・・
チケットの単位を最大数時間単位として、その粒度でチケットを作成する。
大規模プロジェクトだと難しいかもしれませんが、一定のサイクルでリリース可能なものを作り上げるには、なんとしてもその日のうちに終わる分量のチケットにする必要があると考えています。
そのためにはチケット作成時の粒度として最大で◯時間と決めてチケットを作る必要があります。
もちろん1機能が大きい（ように見える）場合もありますが、その場合は機能の中で満たすべき要件を洗い出して、処理の中身をステップに分けてそれに応じてチケットを分割します。
そうすることで、1機能丸々作り終えてから実は仕様と違ったと言った際のさし戻りが小さく出来ますし、少しずつレビューができるので、チェックする側も楽になりますし、開発する側も直ぐに修正ができるようになります。
2.本当に大事なことに集中して、それ以外のことは忘れる。
本当に大事なのは、動くソフトウェアを提供することであり、ドキュメントはあくまでもその補佐的な役割になります。
具体的には・・・
ソフトウェアをリリースできる状態にしておくことを一番に考える。
ドキュメントだけでなく、ムダを省く必要があります。ソフトウェアにバグが有ることがわかっているのであれば、新しい機能の開発はやめて、そのバグの修正に全力を尽くさなければいけません。
3.ちゃんと動くソフトウェアを届ける
お客さんに価値を届けるということは、常にテストされて動くことが担保された状態にしておく必要があります。テストだけは疎かにしてはいけません。
具体的には・・・
開発が終わったらすぐテストを行う。
プログラマの言う「開発がほぼ終わった」やチケットの進捗90%、は何も終わっていません。
プロジェクトマネージャーの視点で言えば、いや、プロダクトとして言えば、何も終わっていません。テストを行なってリリースできる状態になればようやく完了となります。
ここがプログラマとプロマネの意識の違いになるので、プログラマからプロマネになる時の難しい点でもあります。
チケット管理システムをプロダクトのためのツールとして使うのであれば、進捗は0か100かだけで事足ります。
リリースできるか出来ないか、それだけです。
Redmineには進捗のパーセンテージを登録できる機能がありますが、消しました。
開発が終わったらすぐにテストに入るのも重要です。あとでためてからやると、テストも大変になりますし、バグが出た時にどれが原因か分かりにくくなるので大変です。
開発が終わってテストまで終えてチケットを完了にしてから帰るのがベストですね。
テストが終わってないのは何も終わってないのと同じ！
4.フィードバックを求める
狙い通りに進んでいるのを確認するためにも定期的にお客さんにフィードバックを得よう。
具体的には・・・
見せられる状態になったらすぐに見せる。
せっかく定期的にお客さんに価値を届けているはずなのに 、全部が完成するまでフィードバックを得られない。それは定期的に価値を届けてないということになってしまうので、せっかく見せられる環境があるんだったらどんどん見せて意見をもらいましょう。
意見を全部吸い上げていたらスケジュールに間に合わない、というのであれば、やるもの・やらないものを決める交渉を行うことが必要です。
どちらかと言うと最後にまとめてフィードバックをもらって、DB構造から作り直しだよ・・・。デスマ確定。というケースのほうが多いんじゃないだろうか。このようにならないように、定期的に実際に動いているものを触ってみてもらって確認してもらう必要があります。
頑張ってモック作っても「これってエラーの処理とかは実際の画面遷移じゃないんでしょ？」と言われて結局触られないことが多いので、動くものを見せましょう。
5.必要とあらば進路を変える
計画を変える。現実を変えるんじゃない。
具体的には・・・
計画は変わるものだと認識する。
例えばYahoo APIを使った連携をする計画を立てていたとするが、開発中に有料APIになるアナウンスがあったにもかかわらず、そのまま何も考えずに突き進む前に、本当にそのAPIを使うのか、別に乗り換えるのかを考える必要があります。
計画はあくまでもその計画を立てた当時の計画であり、流動的に対応をしていく必要があります。
6.成果責任を果たす
質・スケジュール・期待・資金のコントロールを行う。
具体的には・・・
決められたスケジュール内でお客さんの期待するものをリリースする。
