第13章より効果的なアジャイル:要求の作成
要求を推敲しないという過ちを犯しているアジャイルプロジェクトもあるが、それはアジャイルというよりもコード&フィックス開発の特徴である。
昔?の話を思い出した年長者が「昔もそうやってフィードバックループ回してたし、アジャイル的なことやっていたよね」とかいうんだけど、こういう要求の取り扱いとかが違うので、いつも「あなたみたいな考えがなんちゃってアジャイルを産むんですよ」って思っている。
わらわらわら
うちはコレですわ・・・
チームのほとんどの作業がCynefinの複雑系で行われる場合は、プランニングの見通し期間が短いほうが現実的かもしれない。
ディスカバリーとかPoCとかはこういうのになりそうだ。
https://scrapbox.io/files/621381bc242895001d29eee2.png
この図がこの前のryuzeeさんとちょっと違っていて面白い。ryuzeeさんのやつはしたで、MMM or LMSSがいいって話だった。上だとMMMかSSSSSSSSSSになりそう。SSSSSSSSSは避けたいから、上の図はあんまり良いメタファーじゃないのかも。
https://scrapbox.io/files/621382894c5c780023b2bf4f.png
バックログアイテムが作業を進めるのに十分なほど細かく定義されていないため、チームが間違った方向に進んでしまう。
これは最近とても多い・・・。この章を読んでいると、うちのチームの要求の作成は全然うまく行っていないことに気付かされる。
わかりみのかたまり - shin_semiya
バックログの優先順位が正しく設定されていないため、チームが価値の低いアイテムに取り組み、価値の高いアイテムの作業が遅れてしまう。
これも多いな・・・バックログリファインメント全くできてないな〜。
推奨リーダーシップアクション
■事前のレンズとジャストインタイムのレンズを通して、要求に対するチームのアプローチを見直す。「要求の仕損率」としてどの程度の数字が見込まれるだろうか(要求の仕損率は、定義してから実装するまでの間に古くなっている、あるいは再定義が必要となる要求の割合)。
これはやったアウトプットを変更する必要がある割合って意味でいえば、事前は7割くらい、ジャストインタイムだと3割くらいな記憶。
■チームは要求獲得のアプローチとしてトップダウン方式とボトムアップ方式のどちらを採用しているだろうか。それぞれの手法に関して本章で説明した一般的な課題はどの程度見られるだろうか。チームがそれらの課題に対処する準備はできているだろうか。
基本はトップダウン。詳細が発見されないという課題は数としては年々少なくなっている(経験によってトップダウン思考だけどレビュー時にボトムアップ思考を素早く大量にシミュレーションできるため少なくなっている)が、制約や前提の変更に対してはまだ嗅覚がよわい。
開発初期はトップダウンがほとんどで、あとの方からボトムアップが徐々に増えていく。
■チームのバックログの状態を理解することを目的としてバックログリファインメントセッションに参加する。効率的なスプリントプランニングと、スプリントでの効率的な開発作業を後押しするのに十分な要求が定義されているだろうか。
バックログアイテムがReadyかどうかは結構杓子定規に一旦考えているのと、自身がエンジニアやQAだった経験から不足していることがすくない。
■チームが準備完了の定義(DoR)を文書化し、実際に活用しているかどうかを調べる。
初期はできているが、数スプリントまわすとバラバラになっていることがあるのでそこでもう一度使うように促すことがある。
明確に定義したことはない。チームでどういう実装で実現できそうかという確認を取るくらい。
DoR自体はPdMがそもそも「なにがOKなら始めていいのか?」を理解していないと定義できない問題
普通は定義できるんですかね?PdMが定義できない問題が結構ボトルネック&手戻りのタネに・・・
まずそもそも定義できるPdMが少ない=チーム構成の問題点に・・・。
わかりみのかたまり = Pdmのスキルが足りない -shin_semiya
そもそも十分なすきるのPdMがいない
きょんくん「チーム全員でやる作業。分業じゃなくね?」
ぼく「なるほど」 - shin_semiya
■過去のスプリントレビューとスプリントレトロスペクティブを再調査し、バックログリファインメントが不十分だったために完了できなかったバックログアイテムを洗い出す。チームは将来そのようなことが起きないようにする対策を取っているだろうか。
ここでPOがリソース効率を求めるタイプだと、リリースできる状態にもっていくことよりもなんとなく作業を着手していることを優先してしまうため、うまくいかないことがあるということを思い出した。あと、チームが仕事に追われるような感じに慣れていると、作業を先行着手して余裕をつくりたいという一心で、Readyではないバックログアイテムであることに目を瞑って作業をはじめてしまうことがある。そのときには「軽く触ってどうなるのか情報量を増やす」ということを名目にするので、周りも止めづらかったりする。が、私は基本的に反対している。
なんとなく作業着手するの、わかる・・・。空回りする
適応
■準備完了の定義(DoR)を作成するための措置を講じる。
これはまぢでよくいっている。
ぐぅのねもでない
まずそもそもReadyにならない問題 > こいつが一番難しい
■プロダクトバックログリファインメントが適切なタイミングで行われるようにするための措置を講じる。
少なくても週2時間を定期的にとるのと、レビュー後には1度とるようにしている。
これまでリファインメントのイベントの時間を取らずに、今やっていることに関連しそうなPBIを見直すことはやってた。まとめてやった方が良さそうな気がしている。