バッファとゆとりとスモールリリースとFRT

 CCPMのバッファだけを監視する

という考え方はシンプルで誰でも状況把握可能かと思います。

しかし、バッファという言葉が、どうもしっくりきません。

言葉というより「バッファを入れる、付加する」というアプローチがしっくりこない感じ。

自然に入るものであるべきというか…

ゆとりの法則も、何度も読んでいますが、

必要なのは納得なのですが、”ゆとり”という言葉がどうもしっくりきません。

こちらも、言葉というより「ゆとりを取り入れる」というような

敢えて、組み込むような感じがしっくりこない感じです。

こちらも、敢えてではなく、普通に”ある”ものであるべきな気がするのです。

そして、アジャイルのスモールリリースは、”ゆとり”やバッファとは対局のようですが、

同じ考え方だと思うのです。

価値を小さく短い期間で提供していく事が、”ゆとり“やバッファを作り出す。

これでは分かり難いですね。

”ゆとり”もバッファも価値定義の曖昧さに含まれると思うのです。

最初のリリースの価値定義、リリースするモノ（仕様）は、多少なりとも曖昧さがあり、

「まずは、ここまで作ってみましょう。」

というようなスタートになる事が多い気がします。

お互いの認識合わせをしながら形にしていくようなケースが多いかと。

そうなると、いい意味で探り合いしながら進めるので、

最初は曖昧となるが、リリースを重ねる事で、認識も、価値定義も合ってくる。

そして、この曖昧さが”ゆとり“であり、バッファと言えると思うのです。

当然、後半は”ゆとり”もバッファも、少なくなりますが、

後半は何が重要であるかという認識も、作業スペースも掴めている状況なのですし、

全ての認識合わせが出来ている状況で、たとえ、短期間で一気に作り上げるといような

いわゆる“ゆとり”が無い状況だとしても、

士気は最高潮、集中力も高くなるのでミスも少なくなります。

予算の関係から、何回のリリースで完成するのかが明確でないと受け入れられない！

という事も言われますが、

これも、完成品が見えてくれば、その後の回数は分かります。

完成品が見えるまでを試作評価期間と考えるなど、対応方法はいろいろあるかと。

そうそう。こういう時こそ、曖昧な価値定義や仕様を仮説検証FRTですね！

2つのFRT（曖昧なFRTと検証した結果を書き込むFRT）

にする事で、おおよその計画となります！

仮説検証FRTについては、改めて紹介したいと思います。

と、いう事で、

スモールリリースとバッファ監視。

対局のようで、実は同じでは！？

そして、スモールリリースはしっくりきます。