web-dev-qa-db-ja.com

スプリントの最後に潜在的な出荷可能製品（PSP）を作成するにはどうすればよいですか？

私は4人の開発者と2人のテスターのチームを運営しており、すべてのスプリントでPSPを作成するというスクラムの原則を順守しようとしています。つまり、完了したすべてのユーザーストーリーを使用して潜在的なリリースを作成し、POが自由に処理できるように公開サーバーに保存する必要があります。

私の問題は、スプリントの最後に一部のストーリーが完了していないときに、技術的にビルドを作成する方法です。コードはチェックインされていますが、テストに完全には合格していません。

完了したコードのみをチェックインする場合、つまりコードが完全にレビューされ、テストされている場合、コードベースとマージが異なる可能性があり、悲惨な結果になる可能性があります。たとえば、開発者Aと開発者Bは、アセンブリXを変更するさまざまな機能に取り組んでいます。開発者Aはコーディングを終了し、アセンブリXをテストにプッシュします。翌日、Dev Bはコーディングを終了し、AssemblyXをプッシュしてテストします。機能Aにはバグがあり、機能Bは完璧です。おっと、スプリントは終わりました。では、Aではなく機能Bを使用してPSPを作成するにはどうすればよいですか？

scrumrelease-managementsprint
3
Ninjarabbi

重要なのは：

  • クリーンでよく整理されたコード
  • 分岐と自動マージをサポートする優れたソース管理（おそらく分散）
  • 自動テストスイート
  • 継続的デリバリーに成長できる継続的インテグレーション

次のいずれかを実行できます。

  • トランク内にすべてを作成し、トランクから（分岐後の）すべての不完全なストーリーを元に戻します。これは、特にストーリーで共有コードに大きな変更が必要な場合に、コードベースに大きな影響を与える可能性があります。
  • 新しいストーリーごとにブランチを使用し、ストーリーが完了したときにのみマージします。それには1つの重大な問題があります。ストーリーは個別にテストされ、フィードバックはゆっくりと収集されますが、これが最も簡単な方法です。ビッグヘルパーは、優れたツールと優れたコード/テストです。
  • トランクですべてのユーザーストーリーを作成し、出荷可能な製品をブランチに保管します。分離の問題は解決しますが、共有コードが変更された場合に非常に困難になる可能性があるマージ戦略に対する要求が高くなります。
  • 組み合わせ。出荷可能な製品をトランクに保管し、ストーリーの開発をブランチに保管します。ブランチとトランク間のすべてのコミットをマージします（すべてのブランチには、常に他のブランチからの最新のコミットされたコードが必要です）。ストーリー全体が完了した後にのみ、トランクの新機能がエンドユーザーに利用可能になることを確認してください。

最後のオプションでは、不完全なストーリーを出荷しますが、ユーザーはそれらを利用できません。コードベースにはコードのみが存在します。要件は、他のすべてのユーザーストーリーが機能している必要があることです。

私もはるかに単純なものを使用しました（ただし、スクラムのようなソリューションではありません）。完成したストーリーを壊さなければ、不完全なストーリーは削除しませんでした。レビューミーティングで、これらのストーリーを完成させることができず、機能しないため使用すべきではないと述べました。このオプションは、エンドユーザーが完成したストーリーを検証するだけで、スプリントの直後に実際の作業に製品を使用しない内部リリースの場合にのみ可能です。

2
Ladislav Mrnka

ここでの根本的な問題は、スプリントの最後に行われていないストーリーです。それはあなたが解決しようとすべき問題です。

言い換えれば、「スプリントの終わりまでにすべてのストーリーをどのように終わらせることができるか」とチームに尋ねます。 「半分完成したストーリーを管理するためにプロセスをどのように適応させることができるか」ではありません。

4
Martin Wickman

重要なのは、コードが「ビルドを壊す」ことを許可しないことです。つまり、テストに合格しないコードはチェックインしないでください。毎晩自動化されたビルド/テストサイクルを実行する場合、これはすべて自動化されているはずです。

失敗したコードは引き続きリポジトリにブランチとして保存され、PSPの一部にはなりません。

特に、継続的インテグレーションの実践と、これをサポートするように設計されたMercurial（ [〜＃〜] kiln [〜＃〜] ）のようなソースコード管理システムを利用する必要があります。

3
JonnyBoats

Dev Aはコーディングを終了し、AssemblyXをプッシュしてテストします。翌日、Dev Bはコーディングを終了し、AssemblyXをプッシュしてテストします。長編Aにはバグがありますが、

フィーチャーAのストーリーには、ユニット/受け入れ/統合テストがあると仮定します。

開発者Bは、ステージング領域で自分のコードをチェックインします。機能Aのテストを含むすべてのテストに合格すると、機能Bのコードが自動的に本番環境にマージされます。

分散バージョン管理で上記を行うことができます

0
Asim Ghaffar