先日のことです。
まだ経験の浅いプログラマーに実装してもらった箇所をテストしたところ、不具合が沢山出てきました。
不具合が出ること自体、ある意味しょうがないのですが、問題は不具合の質です。
簡単に言うと、単体テストレベルの不具合が多数出てきたのです。
経験を積んでいるプログラマーなら、そもそも漏れないレベルです。
仮に漏れていても実装したあとに確認して、それで解消するレベルのものばかりです。
問題点を指摘して今後は注意しましょうでは解決しない、
できてないことを責めるのはもってのほか、
という点は、PLと意見が一致していました。
で、どうする?
PLのアイデアとして、実装の前に単体テストの仕様書を作成させてから実装しましょうと。
でも、それだけだと作成した日と実装した日の時間的ズレから抜ける恐れがあるので、
単体テスト項目作成⇒実装⇒その場で単体テストを実施
をワンセット(息継ぎなし)でやらせることにしました。
しかも、項目はちゃんと書きなさい。絶対に、頭の中だけでやってはいけないと。
工程の途中で翌日持ち越しを不可にすることで、おのずと自分で粒度も考えるようになります。
非常に複雑な処理系の実装などは、このような手順を踏む場合もあると思います。
しかし、不具合の質を見ると、そこまでしなくても実装し、頭で網羅できるレベルのものばかりです。
とはいえ、1年前は全くの未経験で、未知の世界だったわけです。
自分たちが思っている以上に、我々が普段見ている景色が見えてないのだと痛感しました。
なので、まずは、その景色を見えるように我々もサポート(の工夫を)していくこと。
この工夫が人材育成におけるノウハウになっていくと信じています。
目の前に丘があります。
その丘に登らないと丘の向こうの景色は見えません。
チームのみんなはこの丘の上にいます。
まずは、この丘に早く来て欲しいです。
そして、未だ見えてない景色を皆と一緒に見れるようなって欲しいと思います。
プロジェクトマネジメント雑記(20) どうする? 漏れのないプログラミング指導
![プロジェクトマネジメント雑記(20) どうする? 漏れのないプログラミング指導](https://f-soln.com/wp/wp-content/uploads/2023/09/27712581_s.jpg)