これは！？
プロジェクトのキャンバスを拾ったけど、アジャイルな使い方にもうちょっとアレンジ出来ないか？
いや、使いやすくしたい気持ちになったから魔改造してみた話
- Timebound Project Canvas の視点を理解してみる（自己流）
- XP、スクラムの視点 で要素別に整理してみる
- １，２から考察＋マージして、魔改造版を作る
１、Timebound Project Canvas の視点を理解してみる（自己流）
見つけたキャンバスは以下の内容ぽいです。
（ちゃんと読んでないので、詳細をしっかりしたい人は、下部のLINKから対象のページを参照ください）
- Foundation
- Hypothesis, MVP, Goals : 上位概念的で、背景・前提や要素とサマリが収まりそう
- Assets
- Team, Budget, Resoures ： 実行する現場状況
- Enablers
- catalyst,parthers,tools ： PL、パートーなー、ツールとか成立させる責任ある要素
- Fascination
- Value, Revenue, Concept, Resrictions ： コンセプト、魅力とか定性・定量的なもの
2. XP、スクラムの視点 で要素別に整理してみる
PMBOKから要素出しして、その要素で整理をしてみる。
- PMBOK要素
- Schedule, Scope : 何をいつまでに
- Execute： 実行しないと進まない
- Quality： 品質をお大事に
- Monitor,Control ： 計測してから最適化
- Risk ： リスクを放置しちゃうと
- Communication ： テレパシーって無いんです。空気読めないっす
- Integration/Closing ： リリースしないとね
- Value Evaluation ： 結局どうなの？
XP,Scrumの要素整理
| Items | XP | Scrum |
|---|---|---|
| Schedule,Scope | Planning Game | Backlog, Product Owner |
| Execute | Pair programming | Developer, Scrum Master |
| Monitor,Control | Whole team,Collabolative OwnerShip | Scrum Master, Burndown chart |
| Quality | Spike, Refactor, Acceptance Test | N/A |
| Risk | Spike, UnitTest, Pair Programing | Spring Review, Retrospective |
| Communication | Standup Meeting, Open Sapce | Daily Scrum, Retrospective |
| Integration/Closing | Small Release | Increment |
| Value Evaluation | Customer Tests | Spring Review |
雑なそれぞれのフロー
extreme programing
scrum
３、魔改造版
前提として、xp, scrumでも利用できるが、プラクティスに依存せずに利用したいものとしたいので、進行中の時に利用可能なものを目指す。 （water fall でも短期間で利用するイメージ）
- 考察
- 始まりのプランニング、終わりの成果物評価 時点での canvas は要らない。
- Execute 面は開発力依存な所があるので、どこまでケアするか？をわかるようにしたい
- Monitor,Control, Quality, Risk はバラつきがちなのでそこは落ち着けたい
- canvas の用途・効果
- Communication のツール と 意思決定の高速化と変更速度向上する
- Execute,Monitor,Control, Quality, Risk の均質化
- Quality, Risk の課題発見の均質化
- 除外するもの
- Schedule, Scope はありきで canvas を書くので、その用途の要素は入れない
- Value Evaluation はリリース後のタスクなので、終わった後の事のためその要素は入れない。利用したりとかはいいとは思う
- 長期期間で利用することは想定しない
- 使い方
- 始まる前に書き起こす。確認のタイミングもあらかじめ設定する。
- 確認時
- Points, Progress Steps, Spike
- 進捗を記入する
- 内容に変更があれば更新をする
- 課題があればどうするか？を別途対策などを決める
- Points, Progress Steps, Spike
魔改造して出来たもの
- 魔改造要素
- Foundation は ステークホルダーの枠を追加
- Enablers,Assets は 短い期間で利用するものなので、小さく規模感になるように Points と Teams に換える
- より詳細にするためにProgress Stepを追加
- Fascination は Goal と MVP にて表現する
- Quality, Risk 面を Spike にて対応する
- 項目
- Hypothesis ： 前提・制約・期日とかを書く
- Audience/Stakesholder ： 成果物の提供先を書く
- MVP ： ユーザーストーリーとか、ゴール・価値の内訳を書く
- Goal ： 成果物、価値、ゴールなどを書く
- Points Sum / Progress Points ： 初期見積と実績を書く
- Teams ： 参画者と役割を書く（状況の変化に応じて修正する）
- Progress Steps ： Goalまでの道筋をステップのリストで書く、進捗の確認にも利用する。変更があれば更新して認識合わせをする
- Spike： 設計、品質、関係者など重要なこと、リスクとなりそうな事を最初に書く。状況に応じて更新をする。
Checkpoints
上部・下部を見比べてチェックをする
- そもそもの妥当性
- 詳細の妥当性
- 品質・リスク面の考慮の妥当性
現実的な計画か？
価値創出に適切なアクションをとれているか？
品質・リスクなど障害点に対して対応できているか？
あとで書くかも
とりま、使ってみてうまくいったらそのままで、ダメなら項目を更新する
Links
