続・doiluxの検証生活

メインはQiitaで、こちらはQiitaに掲載するのにそぐわない内容(技術的な要素が比較的薄いもの)のものを掲載。なお、本ブログの内容は個人の意見を反映したものであり、所属組織のスタンスを反映したものではありません。

今のところ、僕の中ではこの見積方法がベスト

※この記事はDDD(ドメイン駆動設計)を採用してて、なおかつスクラム開発をしてる現場にしか役に立たないかも。

1 解決したい課題

「3ptだと思って作業をはじめたら15ptだった!!」みたいな理由でバーンダウンしない。 (教科書通りにやるならば、基準となるストーリーを決めて相対的に見積もるが、それでもずれるとき)

2 パターンの説明

エンティティの数と影響するレイヤーに基づきptを策定する。

3 実装

以下のような表(例です)を作った。

災害レベル エンティティ ポイント
レベル「神」:人類文明の存続が危険視される 契約 8
レベル「竜」:複数の都市の壊滅が危惧される 商品 5
レベル「鬼」:都市全体の機能の壊滅が危惧される 契約者 3
レベル「虎」:不特定多数の生命の危機を齎しかねない 請求書 2
レベル「狼」:危険因子となる生物や集団の出現 支払い 1

あとはストーリー(例:契約者は商品を購入できる)でどのエンティティが関わるかを決めて、一部のレイヤーのみに影響がでるなら半分とかにする(例:契約のチェックの機能を追加するため、データソース層は手を入れない->3ptくらいにする)

4 構造

5 利点

6 注意

そもそも神エンティティがいる時点でやばい。分割したほうがいい。

理想を言えば、「ちゃんと設計」してから見積もればそもそもptはブレないはず。なので、設計と実装とでストーリー自体を分けてるけど、「このスプリントで設計と実装両方に取り掛かりたい!!」ってことがあったりするので、ざっくり設計でも見積もれるように、この算定方法を考えた。

7 その他

参考:怪人(ワンパンマン) (かいじん)とは【ピクシブ百科事典】

8 寄贈したアーキテクト