特徴(Feature)、粗筋(Story)、脚本(Scenario)とチケットの関係: プログラマの思索
あきぴーさんの記事を読んで、あーなるほどーと思ったので。
分析の話
オブジェクト指向分析(OOA)なら、ユースケース記述書のフォーマットに従って、システム要件や要求、フローを書いて、そこからモデリングしていく。
そういえば最近プロセスを勉強し始めて、分析・設計手法との絡みをあまり考えていなかったなーと思った。
で、これを読んでいくと、オブジェクト指向のもともとってウォーターフォール？と感じる。
僕の場合、ユースケース記述がうまく書けないので、ユースケース図からロバストネス分析で一気に分析クラス図と分析シーケンス図に落として、あとはダーっと書いていく感じだった。
設計の話
最近設計の話を聞くと、 UML はあくまで道具としてで、ホワイトボードにさっくり書いて、写真撮っておしまいという話を何回か聞いた。
scrum の場合、ソフトウェアは変わっていくものという考え方なので、そもそもコードを書く前の設計書は最終的なソフトウェアの構造とはかけ離れているはず。
と考えると、最初からキッチリとした図を書いても、それをメンテナンスするコストばかり掛かり、最悪メンテナンスされない成果物になるのだろう（実際、自分はいつもこのパターン）。
だったら、最終的なコードからクラス図を生成するなり、シーケンス図を書いたほうが乖離もなくて、お客さんからしたら求めているものができるんじゃないのかな？
