アジャイル開発におけるプロジェクトの進め方
アジャイル開発において、色々悪い意味で誤解をしている方々が沢山いるので、
アジャイル開発をした事が無い方々の指針になればと思い書いております。
その1については下記を参照の事
アジャイル開発時におけるプロジェクトの進め方（その1）
その2については下記を参照の事
アジャイル開発時におけるプロジェクトの進め方（その2）
仕様変更について
アジャイルでは、何時でもどこでも仕様変更はщ(ﾟдﾟщ)ｶﾓｰﾝって話になっていますが、
実際問題、そんなことはありえません。
いや普通に考えれば分かるんですが、例えばですが、車つくってたのが、納期直前にバイクに作り直してくれとか言われても、何言ってんだこいつ？って開発者は思うわけです。
仕様変更は何時でもщ(ﾟдﾟщ)ｶﾓｰﾝではなく、アジャイルでは、常に物を見せ続けているのですから、
アプリケーションの方向性はいずれ収束していき、仕様変更の範囲も収束していく前提があり、
その範囲内での仕様変更は何時でもщ(ﾟдﾟщ)ｶﾓｰﾝって話です。
この辺をPMやPLと言われる方々がよく勘違いをしている事があります。
この手の勘違いをしているPMやPLたちに多いのが、仕様作成等の難しい事は、アジャイルでは特にすぐに決めないから、後回しにできるから、なんとかなんべーって感覚でいたりするのが多いです。
そんなことは無いですから・・・
終了しないスプリントバックログについて
実際にスプリントを開始し始めると、どれほど実際に同じチームでやっても終わらないものというのが出てきます。
この終わらないものをどういう扱いにするかについての説明です。
終了か否か微妙なTODO
プロジェクトでは、わけの分からない担当別に70%終わってるだの、色々と%で出て来るパターンもありますが、基本的にそんな事はしません。
本などでは、ユーザーストーリーを実装できているかをみて、終了か否か等かいてありますが、
こんなあやふやな事でも意味が無いです。
簡単な終了か否かの説明は以下に尽きると思います。
それを本番環境に乗せて責任が取れるか否か
これだけです。
テスト完了までをTODOの終了条件とした場合は、これだけを考えれば問題ありません。
ユーザーが実装されているとか考えなくて良いのです。
逆に実装されていようが、テストが終わっていない状態で、少なくとも担当者がめんどう見れないレベルならもう終わってないのです。
終了しなかったプロダクトバックログとスプリントバックログの扱い
実際問題、どの程度終わってないかによります。
あと1時間とかいうなら、もはや残業でどうにかしろとかいうレベルになるので、
そういったものは除外します。
まずスプリントバックログについては、スプリントバックログのタスクから全て退避します。
（ここでいうスプリントバックログは、スプリント内で消化する必要があるログです。）
スプリントを行うために作業分割した、スプリントバックログの作業待ち行列（次回以降のスプリント等のTODOリスト）にそのまま退避してしまいます。
さて、着手しているプロダクトバックログはどうしたら良いでしょうか？
このまま続けるか、一旦退避するか、それともそもそも必要がなくなったかは、プロダクトオーナーが判定します。
そのまま続けるなら、プロダクトオーナーは、その旨をチームに伝えればスムーズに見積もりを取ってくれるでしょうし、
一旦止めたいのであれば、それをチームに伝えれば、スプリントバックログの状況に応じて適宜ソースやその他の物をブランチ等に退避しておいたりするでしょう。
やらないなら、変更分を含めてざっくり削除されるだけです。
一番行ってはいけないのは、プロダクトオーナーが、チームに対して、終了しなかった事にたいして
説教混じりに問い詰めたりし始めると最悪の状況下になります。
プロダクトオーナーの役目は、1つのスプリント内の作業が終わらなかったら、ネチネチ細かい事をチームに対して突き回すのが役目ではありません。
たいていプロダクトオーナーはPMやPLとかがやられるでしょうが、今までと同じようにガントチャートで線表を引いて、遅れる遅れてないに一喜一憂するのではないのです。
全体として機能実装がどの程度終了するかしないのかだけ把握しておけば良いのです。
今回のスプリント内で終わらなかった機能が実装されてなくても、最終的な機能実装を担保している範囲の実装が終わりそうなのであれば、黙ってみてれば良いのです。
また、チームメンバーは、終わらなかった事に対して、何を見落としていたのか、
何が原因なのかは分析する必要はあります。
それが次にはいってくるKPTです。
終わらなかったことに対して、プロダクトオーナーに責めるなとはいいますが、
チームメンバーに対して、なぜそうなったか分析は行えとは言います。
振り返りについて
振り返りの前提条件として、個人に対して生産性が低いだの、個人に対しての攻撃は振り返りではありえません。
説教をする場所ではありません。
今後チームとしてより良い方向性に発展していくために、どういった事を続けられるとよいか、
いま現状チームで起こっている問題について、どういった改善方法があるか。
これらを打合せる場であって、PMやPLがなにやらわけのわからんスケジュール表を全員に配り、
プロジェクトの遅延がうんたらとか、もっと残業をうんちゃらとか話す場では絶対ありません。
この辺を絶対勘違いしないでほしいです。
っというか振り返りにはプロダクトオーナーも参加しなくてもいいと思う・・・
PMやPLの立場がから自分自身を外して制御できない人たちは・・・
（プロジェクトマネジメントする前に、自分をマネジメントしとけと・・・黒い愚痴が思わず溢れしまいます。）
さて、振り返りの手法として今一番多いのがKPTでしょう。
それ以外にも手法や、使える方法は色々あるのですが、一旦KPTで話をしましょう。
ただし、KPTで話をしますが、個人的にはKPTについても手法の一つであり、一番大事なのは振り返りの準備だと思います。
KPTの由来については、多くの方がご存知の通り、Keep/Problem/Tryとなりますが、
日本語的にもっと砕けて書くと、今後も続けたいこと/問題点/やってみたいこと
みたいに考えたほうがしっくり来るかもしれません。
んでは、KPTって意味があるの？
っと思いますが、ちゃんと準備を個々にしているKPTは意味があります。
けど、ちゃんと準備ができてないKPTには意味がありません。
準備と聞くと (・・?
っとなる方々も多いかもしれませんが、そもそも人間忘れる生き物です。
ちょっと忙しかったりすると、今週何あったっけか？？？っとなります。
それだと、KeepもProblemもTryも頭の中から飛んでいってる状態です。
何を改善したかったんだっけか？っと思い返しても後の祭りです。
たいてい、各スプリントで振り返りをして、(´ε｀；)ｳｰﾝ…効果がいまいちと感じる場合は、
そもそも、各個人がその振り返りの準備の為に、日々何があって、問題が何があったのか、どうしたかったのかを忘れている可能性が多々あります。
私も忘れてた事が多々ありました。
KPTを改善しようにも、それでは意味が無いのです。
KPTを改善するなら、わけの分からないものををKPTに追加するよりも、まずは、日々の習慣から変えるべきです。
何かあったら、すぐにメモして、どうしたかったのかを自分なりに考えて、メモをとっておくとか。
このメモは、PCで取ろうが、手書きでとろうが、各個人の自由ですが、KPTに向けての準備です。
これらを基に、チームとして改善した方がいいものを振り返るのがKPTです。
何処のHPを見てもKPTのやり方は書いてあるのに、この辺の日々の問題について書いてないのが疑問でなりません。
これはとても大事ですから、皆さん頑張ってください。
そして、個人的には、チームとしての改善のみではなく、自分自身の振り返りも大切だと思います。
個人での振り返りは、KPT以外にワールドカフェのようなスタイルで、各自振り返りについて、
他者から意見や提案を貰えるような場を作ったほうが良いと思います。
チームとしての振り返りはスプリントやイテレーション単位で。
各個人の振り返りは、月や3ヶ月や半年単位で見つめ直すばがあるべきでしょう。
そしてプロジェクトが終わったら、両方の振り返りを行うべきでしょう。
チームとしての振り返りと、個人としての振り返り、両方ができる環境を用意して、日々何かあればそれを振り返る事ができるように、情報を記録する事こそが大切です。