スポンサードリンク
要求開発アライアンス
以前から興味がありました
毎月定例会を開いてるようで今回初参加
エンタープライズアジャイルにおける要求探索の勘所
鈴木雄介さんより
エンタープライズアジャイル
明確な定義はないが、
すでに完成されているウォーターフォール型開発プロセスがある上でのアジャイル導入
あるある
稟議決済、既存のルール、部署は縦割
ウォーターフォールが出来ている故に、、、
開発の外側で起きていること
SoRとSoE
売上としてのITへ
SoRは無くならないがSoEを重視する
SoEは社内だけでは仕様を決められない
市場環境の変化を受けやすい
ウォーターフォール
フェーズごとの中間成果物で段階的に品質を確認する
↓
期間が長いので欲しい成果物が変化してしまう
中間成果物では品質確認ができない
調整が後手後手になりやすい
アジャイル
リソースを決めて短期に計画と評価を繰り返す
動くソフトウェアを確認
↓
今欲しいものを得られる
定期的に評価できる
プロセスではなくチーム
計画主導と調整主導
SoEでは誰も正しい要求がわからないからアジャイル
継続的に要求探索していく必要がある
エンタープライズアジャイルの実践の勘所
１．スコープを管理する
２．リードタイムを管理する
３．プロセスを共有する
１．スコープを管理する
稟議内容を守って欲しい
全部大事、全部必要
と言いつつ、要件がすぐ決まるものはあまり価値がない
ウォーターフォールはS→QCD
何を作るかを決めてから
アジャイルはQCD→S
チームとリズムが先にある
チームを決めた方が効率的
日付を固定するとリズムが安定
優先度よりもMVP（実用最小限の製品) #redajp
— 門屋浩文＠redmineエバンジェリストの会主宰 (@MadoWindahead) July 23, 2018
実用に耐えうるものを段階的に
MVPを決める 難しい
何のための機能なのか、何を達成したいのか
具体的にどういった操作をするのか
どのレベルでどこまでできていればいいかを決める
使われ方を考える
エレベーターピッチ
カスタマージャーニー
感情 フェーズとタッチポイント 具体的な行動
ネガティブをどう対応するか
ユーザーストーリー
なぜしたいか 機能レベルで合意する
リリースして一刻も早くフィードバックを得る
稟議書通りに実行することも大事だし、価値あるのもを作るのも大事 この戦いを真剣にやれるかどうか
２．リードタイムを管理する
開発中に急ぎの案件が持ち込まれる
技術的にできないことがわかる
開発したものの変更が入る
バックログの精度を明確にする
見積可能なものしか入れない 候補を管理する箱を作る
リリースサイクルとリードタイムの一致
一致しないとチームを増やさないとできない
リードタイムは調整の多さに依存する
調整が多くなるほど長くなる
複数のリリーストレインを走らせる
近距離、中距離、長距離、臨時
稟議が通ったらバックログへ
企画してから学びを得るまでがリードタイム
３．プロセスを共有する
複数の部門から個別に相談がくる
複数チーム間で不整合や重複が起きる
企画から配送までの流れを共有する
VSM 価値な流れを表現する
タスク単位にリードタイムを明確にする
成果物を明記 ムリムダムラを排除しプロセスとして定義
プロセスに対する厳密さは重要課題
厳密さを組織全体で共有し実践することが大事
縦割りのままでは難しい
今までと違うことができるワクワク感
組織内全ての人がアジャイルプロセスに参加する
体感してないでイメージでしかないのは悲しいところだが
組織内の全ての人がアジャイルプロセスに参加すれば組織力が高まるのは感覚的に納得
ご本人のブロクはこちら
