概要
タイトル通りですがとりあえず PoC レベルです。
データ保持していないので自由にいじってもらって大丈夫です!
逆にいえば、データ保持していないのでブラウザをリロードするとリセットされます!ご注意ください!
モチベーション1
最近は React をいじっておりまして、「React 楽しい!なにか クソ アプリを作りたい。。!」という思いが高まりして。。
モチベーション2
今の会社では、費用見積もりのベースとして下記のように「設計、実装、試験」の3つの観点から人日工数を算出し上長承認を通しています。
「えーまじ人日!?」
「人日の工数見積もりが許されるのは平成までだよねー」
みたいな幻聴が聞こえてきそうですが。。
今の会社は受託開発をしておりまして、受託開発となるとお客様へ費用見積もりやスケジュール見積もりの根拠として人日工数を提示している方もいらっしゃるのではないでしょうか。
で、「いちいち設計、実装、試験の観点から人日工数を考えるのツライ!」というのが第2のモチベーションです。
基準がなければその日の気分でムラがでることもありますし。
そしてツライ作業は自動化するのがエンジニアの鉄則(?)です。
スクラムだとプランニングポーカーで値を割り振ってベロシティの安定度を評価する感じだと思うので、せめて「プランニングポーカーしたら自動的に各値を算出、あとは項目内容を鑑みて手直しをする」程度まで楽をしたい!
使い方
タイトルの通りで、本ツールは詳細設計以降向けです。
基本設計まで終わっており、ある程度の全体方針および機能が洗い出されていることが前提になります。
ということで Flask のチュートリアルを例に試してみましょう。
(なお、 Flask のチュートリアルでは簡単なブログアプリケーションを作ります)
概要ページに貼られてある成果物のイメージより次のことがわかります。
- ログインの仕組みがある => ということはユーザ管理が必要
- ブログをポストできる => ということはブログ管理(投稿内容の管理) が必要
作業項目を列挙
ということで。ざっくりと作業項目を列挙します。
各項目に重み付け
次に、各項目にプランニングポーカーで重みを付けます。
オレオレ手法
自分はスクラムの方針をもとにフィボナッチ数列を使っています。
そしてオレオレルールとして下記の方針で2回まわします。
- 1回目
- 3,8,21 で重み付け
- 21 はタスク分解が必要なレベル
- 3,8,21 で重み付け
- 2回目
- 1回目で 21 をつけた項目をタスク分解
- 5, 13 を追加して 3,5,8,13 で重み付け
この方針はなんとなくです。深い思いはあったりなかったり。。ご自由にお試しいただければと。。
設計、実装、単体試験の割合
次に設計、実装、単体試験の割合を考えます。
意図としては「お客さまによって納品物が変わるので作業内容が増減する」と思うで、その点を考慮しています。
たとえば。。
- 設計資料の納品を求められるか?(クラス図とかシーケンス図とか?WebAPIを公開するならAPI仕様書とか?)
- 単体試験仕様書や試験成績書の納品を求められているか?など
今回は下記の方針としました。
- 設計資料は不要
- 単体試験はテストコードのみ
といった感じで下記に割り振りました。
(モーダルにテーブルが表示されちゃうんですよね−。。。なぜ?)
頂いたコメントをもとに修正済みになります!
なお、このモーダルは右上の config から開けます。
想定人日を考える
次に、ざっくりと最初に頭に思い浮かんだ全体の作業工数を想定人日欄に入力してみましょう。
仮に「この程度なら三日で終わるぜ!」という思いで入力してみます。
重み付けの小さい値と大きい値を確認します。
例えば「記事管理機能」の「一覧表示機能」は 0.375 人日となっています。
1日8時間とすると 0.125 は1時間なので3時間ですね。
さて、冷静に考えてみましょう。
- 設計
- 設計書は不要なので方針検討のみ
- 実装
- フロントサイド
- HTMLおよびCSSでUIを実装する
- JSで動的な制御を実装する
- バックエンド
- POST に対してバリデーションを実装する
- バリデーションチェックはそれなりの条件を考慮してテストを行う
- SQLを実装する
- ビジネスロジックを実装する
- POST に対してバリデーションを実装する
- フロントサイド
- 単体試験
- 仕様書などは不要
- テスト用に複数の初期投稿データを投入するコードが必要
- ログイン前後の表示出し分け観点が必要
- テストコードとしてログイン状態を作る必要がある
- 複数ユーザーからの投稿を期待通り表示しているか確認が必要
- テスト用に複数の初期ユーザーを投入するコードが必要
- その他
- ゼロベースの開発か?それとも既存実装があり機能追加するのか?
- 作業者は開発言語およびフレームワークに詳しいか?
- SPA で作るのか? MPA で作るのか?
- SPA で作るならフロントのテストコードも必要か?
- 打ち合わせや社用の割り込みなどを考慮すると一日中開発してるわけではない
- セルフチェック時間やレビュー時間など考慮しているか?
- お客さまの要望を満たした設計になっているか?
- お客さまの追加要望を考慮した拡張性を持った設計になっているか?
- お客さまの業務や運用、操作感を考慮したUI/UXになっているか?
- DDDを考慮した工数になっているか?
- バリューオブジェクトなど考慮すると作業時間が増えないか?
- オニオンアーキテクチャやクリーンアーキテクチャを考慮した作業時間になっているか?
とかとか難しそうなキーワードとかを考慮して、その人日で終わりそうか検討します。
「3時間。。。ムリポ」と感じたら、どの程度の時間がほしいか考え、その値になるまで想定人日を増やしましょう。
最終的に「これならイケそう!」と感じた想定人日から算出した算出人日が作業工数になります。
(なお、想定人日と算出人日の値がずれる点については、細かい計算をすべて切り上げているからです)
自分としては下記のようになりました。
体裁を整理
こちらはエクセルにコピーできるので、あとはエクセルで細かい点を修正しましょう。
(Handsontable さまさまですね!)
項目によっては設計に時間がかかったり、試験に時間がかかるものがあるはずです。
使い方は以上です。
技術スタック
こちらの技術スタックは次の通りです。
今後
- テーブルの行追加や行削除がしたい
- 2点見積もりや、PERT法による3点見積もりとかできるようにしたい
- ジュニア、シニア、リードエンジニアなどのレベルで割増できるようする、とか?
- nextjs に移行したい気持ち(SSRにしたところで意味はないですけどね。。nextjs の素振りの意味で)
- wordle みたいにローカルストレージでデータ管理すると、サーバサイドでDB使ってデータ保持とか必要なさそうですね
セルフQ&A
Q. それ、エクセルでできね?
A. できます!そんなわけでGoogleスプシはこちら!DLしてご自由にご使用ください! How many person hour?
Q. config モーダルの表示バグってね?
A. そうなんですよねー。。。Handsontable の z-index まわりがなんかしちゃってるっぽく。。解決策お待ちしております!
頂いたコメントをもとに修正済みになります!
Q. 上の gif で、作業項目が「パッ」とでるのはなに?
A. エクセルからコピペしているだけです!洗い出しは手作業です!
Q. 項目の洗い出しがしんどいんですけど。。。
A. わかる。ガンバるしかない。。!
注意事項
- Handsontable を商用使用する場合はライセンスが必要です!