明確にするために編集する
スクラムは、開発をいくつかのスプリントに分割することを提案しています。各スプリントは固定期間です。各スプリントの終わりに、ソフトウェアをリリースするかどうかクライアントに尋ねます。彼らが「はい」と答えた場合は、リリース スプリントを実行します。この間に、外部ユーザー テスト、パフォーマンス負荷テスト、サインオフ、CD の書き込み (関連する場合) など、継続的に実行したいが費用がかかりすぎるすべてのタスクを実行します。 、ユーザー中心のドキュメントの作成など
私の現在のプロジェクトでは、最初のリリース スプリントを実行したところです。バーンダウンなどのスクラムの多くの利点を失っていることがわかりました (多くのことがマイナーな調整を修正したり、負荷テストを実行できるようにサイトから一時的にセキュリティを削除したりしていたため)、どのくらいの作業が必要かという明確な目標基本的に、リリース タスクは消防に近すぎて、通常のスクラム ツールで簡単に追跡できませんでした。
リリーススプリント中に他の人が使用した方法と、回避すべき落とし穴は何ですか?
実際、私はこのツールの方が好きです。タスクの追跡、バーンダウン、バーンアップを行い、プロジェクトのメモに役立ちます。
しかし、質問に答えるために、バーンダウンの残り時間の追跡は引き続き機能するはずです。リリースに間に合うようにすべてのリリース スプリント タスク (バグ/調整) を完了できるかどうかは引き続きわかります。答えが「すべてではない」場合は、プロダクト オーナーに優先順位を付けてもらい、いくつかのタスクをスプリントから除外するときです。
スクラム付きかんばんボードを使用しています。各製品アイテムは、ホワイトボードの付箋で表されます。誰もがそれぞれのタスクを実行している毎日のスタンドアップでは、それは本当に明白です。ボードの「保留中」の領域に、もう一方の端の「完了」領域と比較して、キューに入れられたチケットの数を確認できます。
あなたの目標は、本番環境にデプロイするためにリリース スプリントを必要としないポイントに到達することです:) とはいえ、そうは言っても、リリース スプリントで何をしていますか? やるべきタスクはまだありますが、それらはコードを開発するよりも予測可能です。通常、オペレーションからチームに人を追加する以外に、バーンダウン/計画がどのように機能するかの違いは見たことがありません。もちろん、それはそれ自体の問題になる可能性があります。組織でのリリース スプリントの概要を簡単に説明できるかもしれません。