アジャイル開発、スクラム開発における問題点、疑問点を話す会に参加したので、知見の共有。
前提条件
アジャイル開発、スクラム開発の体制を前提としています。
スクラムをざっくり説明するときのスライドが特に参考になりました。
- PO プロジェクト価値を最大化することが使命
- PM/SM チームが上手く回ることが使命
- developer(dev) 機能を実装することが使命
- ストーリー/プロダクトバックログアイテム(PBI) 「〇〇は〇〇したい、なぜなら〇〇だから」
ケース1: 「価値」と「画面イメージ」と「ロジック」について
POは価値を最大化するためにストーリーを作るが、そこは価値のみが書かれてるケースが多く、dev側では完成画面イメージが提供されていないため、どう作成すればいいのか悩むケース
問題点
POが「価値」を描く
devは「価値」と「画面イメージ」と「ロジック」を書く
画面イメージは誰が？？
POは「なんでもいいよ/うまくやってよ」
devは「やる前にワイヤー欲しいなぁ」
解決策
このようなケースではデザイナーが居ないことが多く、画面デザインにはこだわってないことが多い
もちろん、POが納得するワイヤーをスプリントバックログを作成する、ブレイクダウンのタイミングでササッと書き、okをもらうのが良い
webの場合、最低限を担保するbootstrapを使うというのを事前に伝えておくのが良い
ケース2: 本当のPOについて
POを任された人が居るが、実はもっと強い鶴の一声を持っている人がいるケース
問題点
差し戻しが多くなったりする事が予期される
鶴の一声さんは忙しくてスプリントプランニング/レビューには出てこない
決定権/仕様の決定は誰が？？
解決策
現状のPOがメッセンジャー的な役割ならば、POは鶴の一声さんの意図を汲み取った上でストーリーを作成することをdev側から求める。できてないと感じるならば、POの差し替えを要求する
ケース3: デザイナーが入ってる場合(リリース前)
デザイナーが画面イメージを作るが、ストーリーはどう作るのがいいのか
最良案
リリース前なら、画面モック(ワイヤー)を作成してもらい、POがストーリーを作成する
デザイナーより開発者が早い場合
バランスが悪いので、タイミングをずらすか、スポットでデザインを手伝ってあげる
デザイナーより早く作らない方が良い
ケース3: デザイナーが入ってる場合(リリース後)
リリース後の追加機能に関してのストーリーはどう作るのがいいのか
現実
画面のストーリーと、ロジックのストーリーを分けてあげるのが良い
ケース4: 開発メンバーの実力/理解度の差に関して
スプリントプランニングのタイミングで、対象ストーリーに対しての開発メンバーの実力/理解度の差があるケース
問題点
プランニングの時間が伸びる
時間、もったいない？？
解決策
時間、もったいなくない。
スプリントプランニングのタイミングでキャッチアップが足りないならば、PM/SMがギャップを埋める時間を個別に作成してあげる。
- 前提知識をインプットするミーティング
- ペアプロ
- モブプロ
が役に立つ。
むしろプランニングの段階で理解度にギャップがあることがわかることは良いこと。
参考
- アジャイルとスクラムを継承した、新しい開発、モジャイル開発を発明した会社、株式会社mofmofのミーティング
- スクラムをざっくり説明するときのスライド
あとがき
アジャイル開発初心者なので、間違ったこと/間違った前提/偏った前提を元に記事を作成している可能性があります、ご容赦ください。