私は過去2年間、アジャイル/スクラムアプローチを使用する2つの異なるチームで作業してきましたが、どちらのチームもソフトウェア開発へのアプローチ方法を改善することに熱心でした。最初のチームでは、ビルドシステムの改善、より良い統合テストの設定、より良いリリース戦略の設定など、社内の作業に時間を割くようにプロダクトオーナーを簡単に説得できました。現在、POも喜んで時間を与えてくれますが、彼はもっと押し返しています、それは彼も彼のことを成し遂げなければならないので合理的です。
とにかく私の質問は今です、他のチームはこれをどのように処理しますか？改善ストーリーを作成し、計画中にそれをテーブルに置きますか、それともそのようなことのために時間の「バケツ」を保持しますか？改善のための時間を確保するように製品所有者を説得することは、あなたの経験ではどれほど難しいですか？結局のところ、これらの種類の改善はチームに利益をもたらしますが、直接またはすぐに製品の所有者/ビジネスに利益をもたらすことはありません。
素晴らしい質問です。レトロスペクティブの「アクション アイテム」には、さまざまなアプローチに値するいくつかのフレーバーがあると思います。
1) 技術的負債やインフラストラクチャの改善などに対処するための技術的なタスク - 「アプリケーションのビュー レイヤーにデータベース呼び出しがないことを確認する必要があります。なぜなら、この過去のイテレーションで時間を無駄にする原因となったからです...誰かがコードを検索して、他の場所でそれを行っていないことを確認してください。」
2) プロセスの改善 (例: 「人々はスタンドアップに時間通りに来ていない...誰かが遅刻するたびに 1 ドルの慈善寄付を始めましょう」.)
最初のカテゴリは重要な作業である場合もあれば、単純な場合もあります。私が示した例は非常に簡単でした... しかし、スケジュールする必要がある他のタスクを生成する可能性があります (たとえば、発見された 5 つの場所でデータベース呼び出しを削除するなど)。
2 番目のカテゴリは、イテレーション マネージャー、プロジェクト マネージャー、スクラム マネージャーなどによって処理/推進される必要があります。私 (スクラム マスターまたはプロジェクト マネージャーとして) は、通常、それらをプロジェクト wiki にリストし、ふりかえりでそれらについて話します。対処し、状況をチームに報告します。火をつけ続けます。
最初のカテゴリである技術的なタスクの誤りは、受け入れ基準を定義していないことだと思います。あなたの例には、「ビルド システムの改善、より良い統合テストの設定、より良いリリース戦略」が含まれていました。これらは非決定論的であり、明確な用語で列挙する必要があります (必要に応じてスパイクを使用します)。そのため、ビルド システムの改善は、技術的なタスクまたはオプションを評価するスパイクから始まる場合があります。
また、技術的なタスクを分解して優先順位を付ける必要があります (たとえば、「より良い統合テスト」は、現在の統合カバレッジを定義する技術的なタスクから始めるか、統合の失敗に起因する可能性のあるバグの割合を評価してケースを構築することから始めることができます)。そこへの投資。
優先順位を設定したら、優先順位の高いアイテムの価値を伝え、それらに費やす時間をプロダクト オーナーと交渉できます。私は何かに費やす事前定義されたバケツの大ファンではありません...しかし、明確な要件、ROI、および受け入れ基準について製品所有者と会話することが重要です.
改善は、新機能と同じようにスプリントの一部である必要があります。これらの改善が次のスプリントに必要であることをプロダクトオーナーに示すのはチームの責任です。これにより、新しい機能が生成される速度が遅くなる可能性がありますが、最終的には製品に役立ちます。
一方で、改善のみが含まれているスプリントに問題があります。すべてのスプリントは、プロダクトオーナーに示すことができる出力を生成する必要があります。
Crystal Methodsには、開発プロセスを調整する手段としてのReflectionWorkshopの概念があります。チームは定期的に（おそらく開発サイクルよりも少ない頻度で）会合を持ち、プロセスの改善とステータスについて話し合います。今回試した0〜3のことでうまくいき、これからも続けていきます。1〜3のことでうまくいかず、1〜3のことで次回試してみます。アイデアは、プロセスと製品を段階的に改善することです。
昨年、私は非常に初期のアジャイル (xp) 採用者/コンサルタント/トレーナーの 1 つで働きました。彼は良いアプローチをしていたと思います。
私たちは毎週金曜日に会って、何がうまくいき、何がうまくいかなかったかを話し合った. 私たちはそれを 2 枚の大きな紙に書いていました (彼はホワイトボードではなく紙とイーゼルに夢中でした)。
機能したことは非常に単純である可能性があります-チームとしてうまくやり取りした、ペアリングがスムーズに行われたなど.
うまくいかなかったのは、同じように単純でランダムなものでした。一部の人々は、ペアリングに抵抗している可能性があります.
また、毎週、過去の「機能しなかった」を再確認し、修正したかどうかを確認します。修正された場合は、この週の「機能した」列に常にリストされます。
具体的な解決策について話し合いますが、問題をオープンにするだけでも非常に良い効果が得られる傾向がありました。それらが「機能しなかった」リストに 3 ～ 4 週間残っていた場合は、別の/より良い解決策について話し合い、それらを実装するためのより慎重な試みを行います.
項目が「うまく機能した」列で 1 ～ 2 週間過ごした後、多かれ少なかれ期待どおりになったため (改善が続けられない限り)、その項目を削除します。
また、誰もが参加できるかなり楽しいミーティングだったので、金曜日の午後が少し面白くなりました.
私はそのようなことのために「スパイク」を使用します。内部/プロセスの改善はユーザーストーリーではあり得ませんが、それは完璧なスパイクになります。
ここに追加することはあまりありませんが、これらの環境改善関連の問題に専念するリソースが必要であり、タスクをバーンダウン チャートに含めるべきではないと感じています。このプロジェクトに追加のハードウェアが必要な場合は、事前に追加して予算を立てておく必要があります。したがって、最終的にこれらはスクラムの時間配分に影響を与えるべきではありませんが、これらの問題の結果として影響を受ける作業は正当化する必要があります。
いいえ、技術的なユーザー ストーリーを作成してはなりません。理論的には、それらは一般に顧客に直接的な価値をもたらさないため、イテレーションで選択される可能性はほとんどありません。プロダクト オーナーを説得することはこれを軽減するためのオプションですが、ここで使用できる別のツールがあります: Slack です。
Slack は、これらの改善タスクに割り当てられるイテレーション時間のごく一部です。イテレーション中にすべてがうまくいった場合は、その時間をそれらの改善に使用できます。一方で、チームがイテレーションに過度にコミットした場合 (または、タスクが過小評価され、予想どおりに難しくなった場合) には、コミットメントを達成する別の機会が得られます。
スラックを使用するもう 1 つの利点は、残業に頼ることなく、コミットメントをより頻繁に満たす可能性が高いため、ベロシティの変動が小さくなることです。
Tom DeMarco Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency (Amazon リンク) - ISBN 0767907698 を参照してください。