スクラム/アジャイル：内部改善をどのように計画していますか？ [閉まっている]

Question

私はここ2年でアジャイル/スクラムアプローチを使用する2つの異なるチームに取り組んでおり、両チームはソフトウェア開発へのアプローチ方法の改善に熱心でした。最初のチームでは、ビルドシステムの改善、統合テストのセットアップ、リリース戦略の改善など、社内の時間を確保するようにプロダクトオーナーに簡単に納得させることができました。現在、POも喜んで時間を与えてくれますが、彼はもっと押し戻そうとしているが、それは彼が自分のことを成し遂げなければならないので合理的である。

とにかく私の質問は、他のチームがこれをどのように処理するのですか？改善ストーリーを作成して計画中にテーブルに配置するか、「バケット」を保持しますか。そのようなことのための周りの時間の？プロダクトオーナーに改善のための時間を確保するよう説得することは、あなたの経験上どれほど難しいですか？これらすべての改善はチームに利益をもたらしますが、直接またはすぐに製品の所有者/ビジネスに利益をもたらすことはありません。

Answer 1

すばらしい質問。 「アクションアイテム」にはいくつかのフレーバーがあると思います。さまざまなアプローチに値する回顧展から。

1）技術的な負債やインフラストラクチャの改善などに対処するための技術タスク-＆quot;アプリケーションのビューレイヤーにデータベース呼び出しがないことを確認する必要があります。誰かがコードを検索して、他の場所で実行されていないことを確認する必要があります。＆quot;

2）プロセスの改善（例：「人々は時間通りにスタンドアップに来ていません...誰かが遅れるたびにチャリティー寄付のために1ドルを始めましょう」）

最初のカテゴリは重要な作業になる場合もあれば、簡単な場合もあります。私が示した例は非常に簡単でした...しかし、スケジュールする必要がある他のタスクを生成するかもしれません（例えば、それらが発見された5つの場所でデータベース呼び出しを削除する）。

2番目のカテゴリは、イテレーションマネージャー、プロジェクトマネージャー、スクラムマネージャーなどによって処理/駆動される必要があります。私は通常（スクラムマスターまたはプロジェクトマネージャーとして）プロジェクトWikiにリストし、振り返ってそれらについて話し、チェックします対処されたらオフにし、ステータスについてチームに報告します。火をつけ続けます。

最初のカテゴリ-技術的なタスク-の間違いは、受け入れ基準を定義していないことです。例には、「ビルドシステムの改善、統合テストのセットアップ、リリース戦略の改善」などがあります。これらは非決定的であり、鮮明な用語で列挙する必要があります（必要に応じてスパイクを使用）。そのため、ビルドシステムの改善は、技術的なタスクまたはオプションを評価するためのスパイクから始まる場合があります。

また、技術的なタスクを分類して優先順位を付ける必要があります（たとえば、「より良い統合テスト」は、現在の統合カバレッジの定義、または統合の失敗に起因する可能性のあるバグの割合を評価する技術タスクから開始できます）そこで投資のケースを作成します。

優先度を設定したら、優先度の高いアイテムの価値を伝え、製品所有者と時間をかけて交渉することができます。私は何かに使う定義済みバケットの大ファンではありません...しかし、明確な要件、ROI、受け入れ基準について製品所有者と話し合うことが重要です。

Answer 2

改善は、新機能と同様にスプリントの一部である必要があります。これらの改善が今後のスプリントに必要であることをプロダクトオーナーに示すのはチーム次第です。これにより、新しい機能が生成される速度が低下する可能性がありますが、最終的には製品に役立ちます。

一方で、改善のみを含むスプリントには問題があります。すべてのスプリントは、プロダクトオーナーに示すことができる出力を生成する必要があります。

Answer 3

クリスタルメソッドには、リフレクションワークショップという概念があります。開発プロセスを調整します。チームは定期的に（おそらく開発サイクルよりも少ない頻度で）会議を行い、プロセスの改善とステータスについて話し合います。今回試した0から3の機能があり、機能し続けていること、1から3の機能していないこと、1から3の機能を次に試します。アイデアは、製品だけでなくプロセスも段階的に改善することです。

Answer 4

昨年、私は非常に初期のアジャイル（xp）アダプター/コンサルタント/トレーナーの1人で働いていました。彼は私が思うに良いアプローチを持っていた。

私たちは毎週金曜日に会い、何がうまくいったのか、何がうまくいかなかったのかを話し合いました。私たちはそれらを2枚の大きな紙に書きます（彼はホワイトボードの代わりに紙とイーゼルに夢中でした。なぜなら、それはより永続的で、より簡単に再配置できるからです。）

機能するものは非常に単純な場合があります。チームとしてうまくやり取りし、ペアリングがスムーズに進みました。

機能しなかったものは、単純でランダムでした。一部の人々は、ペアリングに抵抗しているかもしれませんし、「上司は約束どおりに私たちをボートに連れて行ってくれませんでした」。

毎週、「機能しなかった」過去を再確認します。修正したかどうかを確認します。修正した場合は、今週中に常に「仕事をしました」と表示されます。列。

具体的な解決策について説明しますが、問題を公開するだけで非常に良い効果が得られる傾向がありました。彼らが「うまくいかなかった」に留まった場合3週間または4週間のリストを作成し、異なる/より良いソリューションについて議論し、それらを実装するための意図的な試みを行います。

「Worked well」で1週間か2週間費やしたアイテムコラム、それは多かれ少なかれ期待されていたので、それをドロップします（改善し続けない限り）。

また、金曜日の午後は、誰もが参加できるかなり楽しい会議であったため、もう少し面白くなりました。

Answer 5

このようなことには「スパイク」を使用します。内部/プロセスの改善はユーザーストーリーではありませんが、完璧なスパイクになります。

Answer 6

ここに追加することはあまりありませんが、これらの環境改善に関連する問題専用のリソースが必要であり、タスクをバーンダウンチャートに含めるべきではないと感じています。このプロジェクトに追加のハードウェアが必要な場合は、追加して予算を追加する必要があります。したがって、最終的にこれらはスクラムの時間配分に影響を与えるべきではありませんが、これらの問題の結果として影響を受ける作業は正当化されるべきです。

Answer 7

いいえ、技術的なユーザーストーリーを作成することはできません。 ：理論的には、顧客に直接的な価値をもたらさないため、反復で選択される機会はほとんどありません。プロダクトオーナーを納得させることはこれを軽減するオプションですが、ここで使用できる別のツールがあります：スラック。

Slackは、これらの改善タスクのために用意された反復時間の小さな部分です。反復中にすべてがうまくいった場合、その時間をそれらの改善に使用することができます。一方、チームがイテレーションに過剰にコミットした場合（または、タスクが過小評価された場合、予想どおりに困難になった場合...）

スラックを使用するもう1つの利点は、残業に頼らずにコミットメントをより頻繁に満たす可能性が高いため、速度の変動が小さくなることです。

Tom DeMarcoを参照スラック：過去のバーンアウト、ビジーワーク、トータルの神話を取得効率（Amazonリンク）-ISBN 0767907698。