アジャイルは組込みを救うことができるのか？

日科技連 ソフトウェア品質 第6回特別講義 「アジャイル開発での品質向上への取り組み」まとめを読んだ。

共感した部分はあきぴーさんのブログにしっかり書いて下さっているので、twitter の内容に関しては割愛する。

ひとつだけ。

細谷さん「スクラムには3つの原則があります。まず『透明性』です。スクラムは透明性を大切にしています。傾きかけているプロジェクトでは悪い報告を挙げるタイミングを気にしたり『お客様に言えない』とかいうことが起こります。スクラムでは包み隠さず透明にします。

— akiyama924さん (@akiyama924) 11月 16, 2012

このことは、ビジネスの情勢を見極めながら仕様を決め、何がいつまでにリリースできるのか判断するために、
大変重要で必要なことなのであるが、
このような関係づくりが難しいと思っている。なぜか？

私のやっている仕事は、主に BSP やドライバの開発である。
ということは、いわゆる外部仕様の部分は、最初から完全に決まっているようなものである。
ということは、バックログ ＋ 優先順位 ＋ できるところまで　のやり方は、初めから成立していないのだ。

だからと言って、トラブルがなく全てがスムーズに進むわけではない。
例えば、未経験のプロセッサやデバイスがターゲットで、ノウハウが乏しいこともあれば、
回路の取り回し等、ハードに起因するようなトラブルだってある。
やはり「初めてやることはできるかどうかわからないもの」なのだ。
そしてこのようなリスクによる変動分は読みづらい。

アジャイルは QCD を変えずに、スコープをコントロールするやり方。
しかし、BSP やドライバでは、このスコープを変えることができない（難しい）。
もちろん Q も C も D も変えることはできない。かくしてここにデスマーチの誕生、なのである。

では、本当にスコープを変えることはできないのか？

例えば、BSP で RTC は後回しだとか、ドライバで DMA は後回しだとか、
多少の優先順位をつけて進めることができたとしても、
いずれはフルスペックの完成品が必要となる。
常に「フルラインナップ」であって、機能の「オプション化」が難しいのだ。

もちろん、アジャイルが全くダメなわけではない。
早く失敗する　も、テストファースト　も、ペアで対応　も、みんな間違いなく有効だ。
ただ「顧客への価値」としては、最初に決まったことのまま、何も変わることがない、ということだ。

「アジャイルは組込みを救うことができるのか？」

このテーマについては、これからも何度か取り上げて考えていきたい。