アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 |
|
 |
木下 史彦
オーム社 2007-12-22 おすすめ平均 |
まさに教科書だアジャイルプラクティスを読んでて、腑に落ちた記事があった。
「設計は指針であって、指図ではない」
これは、設計者にも開発者にも、どちらにとってもいい言葉だと感じた。理由としては、設計者は指針を書くことに注力できること。いい意味で時間の短縮ができる。
詳細仕様書でフローチャートを書いていたときに、やりたいことはわかっているのだがフローチャートにして書こうするとすごく時間がかかった。しかも悲しいことに、この時間のかかったフローチャートは、「わかりにくい」と言われてしまった！！
フローチャートではなく、フローを箇条書き形式で書き直して見てもらったら、「これならわかる」と。
『詳細』なので、詳細にしなければならないという気負いがあるが、指図になるまで詳細にすると、仕様に問題がある場合に後戻りするのが難しい。しかも、詳細設計書を書くのに異常に時間がかかるようになる。これでは本末転倒だし、プログラマの仕事とやる気を奪う事になる。
機能仕様書に載っている機能は具体的にどんな処理をするかを設計する事が詳細設計であり、どのように実装するべきかはプログラマに任せたほうがいいと思う。アジャイルプラクティスに書かれているが、
「実際にその場所を通ってみるまでは、そこがどんな様子なのか確かなことはわからない」
のである。実装を詳細設計に書いたところで、実際に実装しようとするとどうしても無理が生じる場合はありうる。以前に、指針を示さずに指図になっていた詳細設計書を受け取ったのだが、フローとSQLが間違っていたことがあった。何がしたいのかがわかっていれば、間違っている場合は報告できるし、実装も可能なのだが、このときは駄目だった。詳細設計書の修正依頼をかけても修正に時間がかかり過ぎて工数がどんどん減っていき、待ちきれずに意図を判断して実装。そして詳細設計書と実装がどんどん乖離していく…という悪循環だった。
ドキュメントは指針。そして実装方法は、『実際にその場所にいる人』に委譲したほうがいいと思う。指針を共有できれば、プログラマから設計者へのフィードバックでまた素晴らしい設計が生まれる場合もある。
| Manage It! 現場開発者のための達人式プロジェクトマネジメント |
|
 |
でびあんぐる
オーム社 2008-10-18 おすすめ平均 |
プロジェクトマネージャー必見
