WF型開発はなくならないけど幸せになる方法はあると思う
プログラマの思索様の言葉から
WF型開発であっても、成功プロジェクトの現場では、無意識のうちに並行開発という形で、アジャイル開発のアイデアを相当な部分で実施している場合が多い。
アーキテクチャの構築・検証作業をプロトタイピングという名前で、アジャイル開発に近いことを行なっているのだ。
WF型開発でもアジャイル開発に近いことを部分的に自然にやっているし、アジャイルに向かうのは自然な流れなんだと思う。
開発と単体テスト、部分的な結合と組み合わせの疎通確認、開発の並列化といった感じで、プロジェクトの中の異なる工程と領域のなかでそれぞれアジャイル開発に近いことがあった。
今日は、１点目に少し前にふと気づいてたことがあったので、メモ兼ねて残しておこうと思う。気が向いたら２点目と３点目もメモしておこう。
１．WFの開発と単体テスト
WF型開発でテスト駆動も知らない時期の話だが、品質が高い人とそうでもない人という話題が雑談ででたことがある（ここでいう品質は、単に単体テストの不具合の件数。はっきりした評価軸の話ではない）。品質の高い人は開発工程のスケジュールがやや遅れがちで、それをよく残業でカバーしていた。一方品質の低い人は開発工程のスケジュールは守れているが、予定以上に不具合がでるのでテスト工程で遅れがちであった。
その時の現場では先に第一版として動くものが見えるので、品質がそれほど高くない方が重宝されていたように思う。
品質の高いと言われている方は、IDEでのステップ実行を常にしていたと思う。新調に、コードレベルの目視確認を常にしていて、何かあれば気づいて直していて、いつの間にかC0C1をチェックしている。という感じだった。
WF型の開発では開発工程の後に必ず単体テストの工程があるため、確認済みの事柄についてもチェックリストを作成して消化しなければならない。
この作業はテスト工程としてプロジェクト計画通りだし、品質を保証してくれるかもしれないが、工数としては無駄もあったと思う。開発者にはテスト済みのことをもう一度テストすることの煩わしさと、徒労感があったと思う。
開発時に検証しておくべきこと、チェックリストを作成してテストすべきことを切り分けておけば、彼は残業せずにタスクを終えられたのではないか、と思う。
TDDではテストを軽く再実行できることが必要とされている。現状のWF型開発ではテスト済みのケースに対する再テストのコストがとても高いので、どちらの方法でも再テストは苦痛な作業だ。
テストファースト的な開発として、テストケースやチェックリストを作成してからの開発が実施されるなど、徐々にアジャイルからの文化流入がSIerの開発プロジェクトに見られるようになってきた。それでも、手戻りに悩まされることは変わらない。
現状の最大の問題は手戻りのコストを残業で消化する、ブラックWF開発が染み付いていることだろうと思う。
