合意しながら期待をマネジメントしながら、企画やデザイナーも含めてチームで開発をするということを書いている。
小さい規模感でアジャイル開発をしたことある人なら馴染みのある内容になっていると思う。
インプションデッキの作成については参考にすべきところが多いと思う。
インプションデッキを作成したことがないなら作ったほうが良いかも。自分も含めて。
- 我々はなぜここにいるのか?何を実現するためにいるのか?
- エレベーターピッチのテンプレ
- 「潜在的なニーズを満たしたり抱えている課題を解決したり」したい
- 「対象顧客」向けの
- 「プロダクト名」というプロダクトは
- 「プロダクトカテゴリー」である。
- これは、「重要な利点、対価に見合う説得力のある理由」が出来、
- 「代替手段の最右翼」とは違って
- 「差別化の決定的な特徴」が備わっている
- パッケージをデザインする
- 機能の利点をアピールしよう。
- 顧客への訴求要素が何かを明らかにすることが目的
- やらないことリストを作る
- 決められないなら後で決めるに入れておく
- ご近所さんを探す
- セキュリティ担当
- 法律
- インフラ
- PR・マーケ
- 解決案(アーキテクチャ)を描く
- 描いて見てリスクを可視化しよう
- 致命的でわかっているリスクを洗い出す
- ざっくりのスケジュール
- 諦めるものを決める
- スケジュール
- スコープ
- 品質
- 予算
- をそれぞれ優先順位付けする。同じ値はありえない
- 何がどのくらいいつようか。ざっくりでも良いので出してみる
- どのくらいの期間
- 何人
- いくら
- 運用ではどのくらい??
ユーザーストーリーについては、Sprintと似ているなーという感じ。この本に書いてある内容としては、テストが可能な内容でユーザーの価値が書いてあるユースケースのことだ。
見積もりはざっくりだ。
大中小で分けて、代表的なものを一つづつ見積もって、相対的に決めても良い。
ポイントを利用してverocityを計測してみよう
計画MTGは受け入れテストができるのか?などをチェック。これから始められるのかを確認する。
実行は作るだけ
ショーケースは、実際にデモして見せることだ。
次のイテレーションを計画する。ベロシティを見て入れられる量を決めたりだ。
最後は振り返り
現場の見える化は大事だ。
自分たちにも大事だけど、偉い人のためでもある。
バーンダウンチャートを作ったり、カンバンを用意したりだ。
最後は、プログラムについてであるが、エンジニアにはこれが最も大事かも。
これを外すといろいろ積む。
ユニットテスト
リファクタリング
テスト駆動開発
CI
良い内容の本なので一読の価値があると思う。
アジャイルサムライ−達人開発者への道− Jonathan Rasmusson https://www.amazon.co.jp/dp/4274068560/ref=cm_sw_r_tw_dp_U_x_ScEnDb6B9CZNV
0 件のコメント:
コメントを投稿