1. 最小イテレーションサイズ
イテレーションが短ければ短いほど製品の品質が上がる
イテレーションが短ければ短いほど製品の品質が上がる
例えば:
チームが受けられるフィードバックも、振り返りから得られる教訓も断然bの方が多いに違いない。
イテレーションにはオーバーヘッドが伴う
しかし、ここで考慮しなければいけない事がある。 イテレーションにはオーバーヘッドが伴うということだ。
スプリント計画にもスプリントレビューにも当然時間がかかる。 例えば、3日で1イテレーションを回そうとすると、ものを作っている時間がほとんど無くなってしまうのだ。
そういうわけで、1イテレーションの長さには「これ以上は短くできない」という下限が存在する。 それが最小イテレーションサイズだ。
最小イテレーションサイズを考慮すべき理由
この最小イテレーションサイズは、時として問題になる。 プロダクトへの新しいフィーチャーの追加を非常に短いスパンで行いたい場合だ。
たとえば、架空のブラウザ向けソーシャルゲームの運営を考えてみよう。
- このチームの最小イテレーション単位が1週間だとする。
- しかし、新規イベントのリリースは1週間ごとに行いたいとする。
このような場合、実際に動くプログラムを作成して、スプリントレビューを行い、フィードバックを受けて、軌道を修正するという機会が1回も得られない。
これだと厳しい。
しかし、最小イテレーションサイズの制約があるので、イテレーションをこれ以上短くする事ができない。
このような問題が発生する場合がある。
どうすればいいのか?
このような場合の解決策の1つとして、
「チームを複数に分割してパイプライン化する」という方法が挙げられる。
2つのラインで、交互にリリースを繰り返すようにすれば、
ごく単純に考えた場合では、イテレーションのサイズを変えずに、倍のペースでリリースできる。
※リ = リリース
非常に短いスパンでの開発が必要な場合には検討すべき方法だと思う。
まとめ:
イテレーションのサイズには下限があり、その制約はリリース頻度の制約となる。しかし、チームをパイプライン化することで、その制約を緩和できる場合がある。
ただし、もし短いスパンでリリースを行わなくてもユーザーに価値を届け、収益を上げる事が可能であれば、それがそもそもの根本的解決かもしれない。
2. 最大自己組織化人数
アジャイルがもつ重要な要素として、「自己組織化」というコンセプトが挙げられる。
この自己組織化についても、（メンバーの資質に依存するところも多分にあると思うが、）「これ以上人数が増えると自己組織化できない」という上限があると考えている。
メンバーの人数と仕事量が増えると、コミュニケーションのパスが乗算で増えていくからである。
しかし、ある程度大人数が居ないとできない仕事もあると思う。
この問題については、今このようなアイディアを考えている。
チームを分割する指針として何が適切か - 宇宙は究極のフリーランチ
一言で言うと、「チームを分割してScrum of Scrumをしよう」という感じである。
これについては、今後実践の中でこの考え方が有効かどうか検証していきたいと思う。
