スパゲティコードなので相対見積できません
アジャイル/スクラムの見積の考え方やプラクティスを納得してもらうのは難しい、といつも感じる。
理由の一つは、従来型の開発手法からスクラムにシフトしてきた開発者の多くが「見積とはマネジメントに対するコミットメントであり、ゆえに正確でなければならない」というマインドセットに深く染まっているからだ(僕もまだ完全に抜け切れてはいない)。
このようなケースでは、『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法』を引用しながらアジャイル/スクラムの見積の考え方やプラクティスを繰り返し説明し、実践している。
たとえば、見積はコミットメントではない、不確実性のコーン、計画を立てることは重要だが立てた計画は重要ではない、などなど。
上記の場合よりももっと厄介なのは「スパゲティコードなため、相対見積の考え方が適用できない」というケースだ。
アジャイル/スクラムでの見積の基本的な考え方は、絶対見積ではなく相対見積である。具体的にはフィーチャーA(≒機能)をWBSで分解して見積るのではなく、フィーチャーAとフィーチャーBのサイズを相対的に比較しながら見積をする。
だが、特に既存プロダクト改修でスクラムを実施する際、そのプロダクトがスパゲティコードの場合、相対比較の考え方を当てはめるのが難しい。
なぜならば、相対見積的にはフィーチャーAは3ポイントでフィーチャーBは5ポイントだったとしても、開発を始めたらフィーチャーAはグローバル変数を触るため広範に影響が及ぶことが判明し、結果10ポイントだった、ということが往々にして起きるからである。
こうして開発者が様々な痛い目をあっていくと、ますます開発者は防衛的になり、フィーチャー毎に時間を掛けて絶対見積するようになり、アジャイル/スクラムのメリットが失われてゆく......
さて、このような場合、アジャイルコーチとして何とアドバイスすれば良いか、自問自答してみた。
短期的には、以下のような方法が考えられるかもしれない。
- プロダクトバックログアイテムをより小さく分割する
- 影響調査をプロダクトバックログアイテムとして切り出す(スパイク)
- スプリントでスパゲティコードのために追加されたタスクを記録しておき、記録に基づいてスプリントのバッファとして確保する
ただし、中長期的には、問題を根本から断つために、チームや組織に以下を実施するコストを割いてもらうように働きかける必要がある。
以下は2013年の記事からの引用だ。
コードの構造はなぜ重要なのでしょう？ そのコードが10年後、スパゲティコードのおかげで内容や機能を変更できなければ、変更や追加が可能だというソフトウェアが持つ大事な価値を失ってしまうのです。
約10年後の今、膨大なスパゲティコードをスタート地点に、スクラムを始めたいというチームは沢山いると、思う。
皆さんはどのようにしてこの問題に取り組んでいるのか、聞いてみたい。