読者です 読者をやめる 読者になる 読者になる

Natural Software

KinectなどのDepthセンサーを中心に活動しています

アジャイル(scrum)とオブジェクト指向、UML

雑記

特徴(Feature)、粗筋(Story)、脚本(Scenario)とチケットの関係: プログラマの思索
あきぴーさんの記事を読んで、あーなるほどーと思ったので。

分析の話

オブジェクト指向分析(OOA)なら、ユースケース記述書のフォーマットに従って、システム要件や要求、フローを書いて、そこからモデリングしていく。

そういえば最近プロセスを勉強し始めて、分析・設計手法との絡みをあまり考えていなかったなーと思った。


で、これを読んでいくと、オブジェクト指向のもともとってウォーターフォール?と感じる。
僕の場合、ユースケース記述がうまく書けないので、ユースケース図からロバストネス分析で一気に分析クラス図と分析シーケンス図に落として、あとはダーっと書いていく感じだった。

設計の話

最近設計の話を聞くと、 UML はあくまで道具としてで、ホワイトボードにさっくり書いて、写真撮っておしまいという話を何回か聞いた。
scrum の場合、ソフトウェアは変わっていくものという考え方なので、そもそもコードを書く前の設計書は最終的なソフトウェアの構造とはかけ離れているはず。
と考えると、最初からキッチリとした図を書いても、それをメンテナンスするコストばかり掛かり、最悪メンテナンスされない成果物になるのだろう(実際、自分はいつもこのパターン)。


だったら、最終的なコードからクラス図を生成するなり、シーケンス図を書いたほうが乖離もなくて、お客さんからしたら求めているものができるんじゃないのかな?

で、結局

分析・設計手法もプロセスに当てはめれば、その中に組み込めばいい話で、たとえばウォーターフォールに当てはめれば最初からキッチリ作ればいいし、scrumに当てはめれば各スプリントごとにやってけばいいんじゃないかな?


アウトプット(作成するドキュメント)自体もバックログに入れる、という話も聞いたことがあるので、ドキュメントは

  • 必要のないものは作らない
  • 必要なものは必要になった時点で作る

のが最善なのかな。