分からないことが3つある工程が、1つの工程より速く終わりました

アプリを作るとき、工程ごとに見積時間を出して、実績を記録しています。

今日終わった工程で、見積より短く終わりました。 初めてです。

しかもその工程は、初めて触る技術が3つ入っていました。

数字を並べたら、逆でした

未知が1つの工程で4.8倍かかり、3つの工程が0.8倍で終わりました。

違いは、割り方でした

今日の工程は、作業を4段階に割ってありました。

1. 入力チェックのルールだけを書く（画面はまだ無い）
2. 保存する処理だけを書く（フォームはまだ無い）
3. 素のフォームで動かす（ライブラリはまだ入れない）
4. ライブラリを足す

各段階の終わりに、動く状態があります。

前の工程は、そう割っていませんでした。全部つなげてから動かそうとして、
どこが原因か分からない状態で止まりました。

効いたのは3段階目でした

3段階目が終わったところで、一度コミットしてあります。

そこまでで機能はもう動いています。だから4段階目でライブラリを入れて壊れても、
戻れる場所があるという状態でした。

これが精神的にかなり違いました。壊してもいい、と思って触れます。

気づいたこと

問題は未知の数ではありませんでした。

一度に確かめる未知の数でした。

3つ全部を同時に入れて動かそうとすれば原因の候補が3つ残りますが、1つずつ入れれば原因はいつも直前の1つです。

未知が3つあっても、1つずつ確かめれば、未知1つの作業が3回になります。

前にも同じことを言われていました

少し前、教材の章数が多くて止まりそうになったことがあります。

そのとき範囲を6章から2章に狭めたらその日のうちに進んで、自分でも「ゴールを細分化するのは大事だ」と言っていました。

あのとき分かったのは学習の話だと思っていました。 実装でも同じでした。

やっていること

工程に入る前に、どこで一度動く状態にするかを決めるようにしました。

見積を細かくするのとは違います。時間を割るのではなく、動く地点を置くほうです。

4時間の作業を1時間ずつに割っても、4時間目まで動かないなら意味がありません。
1時間目の終わりに動くものがあるかどうかが効いていました。