PDCAのサイクルとWFとかTDDとかコミニュケーションとか

今頃？だが、よくPDCAという言葉が使われる。身近で。

PDCAってサイクル短いほうがフィードバック早くてよいはず。

でもWFとはそうならない。

だって、基本設計ビシッ！と固めて、変更あるならお金くださいってんだから。

１タスクでみたら、予定工数のなかでPDCA的なことは行われるだろう。

ただし、それはフェーズが変わると、サイクルのスピードがストップするに等しい。

タスクをこなすスピードとしても、PDCAのサイクルが早いほうが正解にたどりつくのが早いという実体験としての例がある。

FizzBuzzをTDDでやった。

テストケースがざっくりとしていて、ケースを洗い出すことに時間を掛け、それを完全に満たす実装を行った人と（完璧な設計で、動くものに時間がかかる）

テストケースを細かくし、設計はそこそこに動かしながら、バグをつぶしていく人（きたなくても動くものを作っていく）の場合では

後者が圧倒的に早く実装が完了した。

（前者が30分掛けても実装・テストが終わらなかったところ、後者は10分ほどで実装・テストが完了した。）

つまり、フィードバックがないなか、頭の中で検討するより、

実際に動かした結果から改善するほうが早い場合もあるということ。

正解はその中間なんだろうけども。

で、こういうのは、個人差があるけども、経験で埋められる。

で、経験が無いから無駄に悩むってこともある。

経験が無くても、ゴールさえわかっていれば、そこに突き進むこともできる。

ただし、ゴールがわかってないと、どこに進んでるかわからん。

早くできても正解じゃないかもしれないしね。