アジャイルサムライ読書会 – 8章前半のふり返り
By 管理人
昨日22日のアジャイルサムライ読書会のふり返りです。
今回は8章の途中まででした。
前回参加できなかったこともあって、久しぶりの参加でうっかり予習を忘れてしまいました。流し読みでもいいから、読んでいかないといけませんね。反省。せっかくの勉強会。皆さんの時間を無駄にしないように。他にもいろいろ勉強したいこともありますし。
さて、8章はアジャイルな計画作りです。
プロジェクトの途中で主力のメンバーが何らかの都合で外れてしまうとか、まぁありそうなお話ですね。そうでなくても多少のマージンを見ていたとしても、現実には全員がほぼフル稼働状態で期日が迫るに連れて残業が慢性化していて休日も…。何とか間に合わせようと、安易にコードをペタペタと膨らませて、どうにもならなくて他のところから人をかき集めて…。それで何とかなったとしても、その後の運用・保守を考えるとぞっとします。いや、ぞっとしないかも。慣れてるから。（汗
（コラム記事には「プロジェクトをクビに…」という最悪のお話も書かれていて “逆に” 安心できます。）
このあたりを読んでディスカッションしたこと。
リリースの期日に間に合いそうにない場合に、期日を調整するのかスコープを調整するのか。経験上、心苦しい会議をして期日を延ばすことが多かった。じゃあそれでその後うまく行くのか。結局、そのような状況になる時点ですでに無理やりのコーディングになっていたり、超過勤務の日々を過ごしていて期日が延びたからといって
特にモチベーションがあがるわけでもなく。
それよりは、スコープを調整して期日にリリースすべき。そうすれば新たなモチベーションの元に次のリリースに向けて開発を進めることができるはず。
5章でも出てきたけど「スコープを柔軟に」することがポイント。じゃあなんでも削れるのかというともちろんそんなはずはないですよね。そこで出てきた言葉がMMF(Minimal Marketable Feature Set)。リリース単位のことをこのように表現されています。要するに価値のある機能を厳選して最初のリリースに含めるということです。そうすることで、期日が迫ったときにスコープを調整しやすい状態にできるわけです。
それともうひとつディスカッションしたこと。それは個人の成果物に対する評価について。例えばある程度の規模のコーディングをすれば一定の割合のバグが発生するはず。言い換えれば、バグがなければ上司にとっては都合が悪かったりするわけです。これは何が問題かというと、個人の生産性を測っていること。すなわち生産性の高い人と低い人が同じ割合でバグを発生しないといけないのか、というまぁナンセンスなお話です。そうじゃなくてチームの生産性、この本ではチームのベロシティという表現がされていますが、このベロシティを評価して維持あるいは良くすることが重要です。どうしてもベロシティがあがらない場合、それは開発環境に問題があるのか、チーム内のコーディングの仕方に問題があるのか。そこの見通しがないと期日とかスコープの調整もできません。
だいたいこのあたりまで。
ということで、次回は少し先まで読んでから参加しようと思います。
さて、この読書会のほかに、今年はいろいろな新しいセミナー・イベントに参加することができました。その大半は無料で参加できるもので、有志の方々が自主的に企画して開催されています。来年にはさらに新しいセミナーの計画もされています。そういう状況の中で考えてほしいこと。それは、無料で気軽に参加できるからといって甘えてばかりではいけないということ。開催する側は日常の仕事をしながら、身の回りの人も含めて少しでも良い仕事をしたいと思って努力をしていると思います。もちろん自分自身の勉強目的があります。なので、自分の都合だけで参加するとかしないとか、そういうことではなくて、なんとか時間を調整して積極的に参加するとか、参加できなくても周りの人への告知を協力するとか、何かできることがあると思います。もちろん強制されることではありませんが、これからの各種勉強会の益々の充実に期待するとともに、小さなことでも何かできることがあれば協力していきたいですね。