プログラマの思索

ＸＰ祭り関西２０１０のTiDDセッションで小枝さんが講演された資料が公開されたのでメモ。

公開資料だけでは雰囲気が伝わりにくいけれど、小枝さんは物腰が柔らかく、現状のSW開発の問題点を的確に分析されていて、とても興味深かった。

・組込SW開発では、SW開発部隊以外にHW部隊や品質保証部隊など社内の別の部署と連携する必要がある。
　そのために、コミュニケーションがスムーズにいかない場合がある。
　
・「システムテストの手戻りが多い」という問題点を最優先に対処した。
・一部の協力会社の開発者は、製品知識が少ないので間違った理解で実装してしまうため、単体テストで防げない。
・多発する変更要求やバグを正確に開発者へ伝えるために、TiDDを採用した。
・BTSとしてMantisで運用した。
　Mantisは、ステータス別に色分けされるので、ぱっと見ただけで状況が分かる。
　新規(紫)や担当(黄色)が多い場合、チケットが未着手か遅延しているので、早急に対処が必要。
　解決(緑)が多い場合、テストやレビューで止まっているので、早急にリスケが必要。

・チケットにはバグだけでなく、仕様変更なども登録する。
　「仕様変更に対処しなかった」という意思決定の結果も残した方が後で役立つ。
・TiDDには、イテレーションのPDCAサイクルとチケットのPDCAサイクルがある。
　チケットのPDCAサイクルを早く回せば進捗がはかどる。

・チケットの粒度はプロジェクトに応じて変わる。
・細かいチケットになるほどチケットは溢れる。
　だから、ランクを付けて、ランクの順にチケットをこなす。
　例えば、100枚のチケットがある場合、10個ずつランク分けして、10個ずつ作業してリリースしていく。
　そうすれば、作業しやすくなるし、自然にアジャイル開発になる。

・チケットをイテレーションに割り当てて、約1ヶ月のサイクルで小刻みにリリースした。
　すると自然にアジャイル開発になった。
　開発にリズムが出て、開発者のモチベーションも向上した。

・TiDDで解決できない問題点もまだある。
　　システム設計が不十分
　　テスト技術力が低い
　　要求管理が不十分

組込製品開発のように、多数の部署と連携しながら開発する場合、TiDDによって情報共有がスムーズになる利点がある。
しかし、TiDDはいわゆる下流工程では威力を発揮するが、上流工程のコントロールなどではその効果が得られない時もある。
それらは今後の課題と言えるだろう。