アジャイル/スクラムが答えですか? スクラムはこれをどのように処理しますか?
1 人のプロダクト オーナー、1 つのプロダクト バックログ vs 複数のプロダクト オーナーとプロダクト バックログ?
それはあなたにとってどのように機能していますか？あなたの成功失敗談を教えてください。
私は、インフラストラクチャ プロジェクト、単純な機能拡張、そして 6 ～ 7 人の開発者からなる小規模な開発チームによる大きなプロジェクトに至るまで、複数の作業待ち行列を管理するプロセスをまとめようとしています。
1486 次
6 に答える
2
1 つ欠けているのは、これが技術的に 1 つの製品 (たとえ大規模であっても 1 つのコードベースなど) であるかどうかです。
それらが完全に別個の製品である場合、スクラムを使用して、非常に短いスプリント (1 ～ 2 週間) と一連の開発作業に取り組みます。したがって、2 週間のプロジェクト A、次にプロジェクト B、次に C、そして再び A - おそらく 2 つのスプリント、次に C などです。このような状況では、単一のバックログは意味がなく、A、B、および C に対して個別のバックログを保持する必要があります。このように機能するチームを少なくとも 1 つ知ってください。
より多くの PO が必要かどうかは、むしろ製品に関する知識の関数です。プロジェクトごとに誰かが必要な場合もあれば、A、B、C をよく知っている人が PO になる場合もあります。
異なる製品の場合、異なるバックログから異なるストーリーを取得してそれを実行しようとすると、スプリントごとにチームが分割されます。当然のことながら、人々は特定のプロジェクトに特化し、完了を適切に定義することも非常に難しくなります (このスプリントで A と B の新しいインクリメントを出荷できても、C を出荷できなかったら完了でしょうか?)。短いスプリントでプロジェクトを順序付けできない場合は、これに何らかの組織を入れようとするカンバンに注目します。
これが1 つの製品/1 つのコードベースである場合、作業ははるかに簡単になります。プロジェクトが異なるためにチームがコードベースのさまざまな領域に触れなければならない場合でも、チームは同じ製品に取り組んでいるため、スクラムのすべてのメカニズムがうまく適用されます。1 つのバックログ、1 つの PO。
これの注意すべき欠点の 1 つは、チームのメンバーがコンテキストを切り替えることであり、使用するプロセスに関係なく、これを行うとペナルティが発生することです。どのようなプロセスを選択する場合でも、これをできるだけ長く (ビジネスが維持できる限り) 最小化するように努める必要があります。スクラムの良いところは、コンテキストの切り替えはスプリントの境界でのみ発生する可能性があるという PO との合意が組み込まれていることです。つまり、チームは別のプロジェクトに切り替える前に 1 ～ 2 週間集中することができます。
また、アジャイルのすべての技術的実践を忘れないでください。単体テスト。自動ビルドとテスト。コードレビュー。リポジトリの賢い使い方。高水準の再。品質。このような困難な環境では、これらすべてが必須です。
于 2010-07-08T19:34:29.847 に答える
1
もう少し詳細が役立つかもしれません。彼らの間で多くのプロジェクトを共有しているのは、1 つの大きな制作チームですか? 多くのプロジェクトを抱えた小規模なチーム (5 くらい) ですか?
なぜたくさんのプロジェクトを抱えているのですか？彼らはさまざまな時間枠で作業しており、「実際の作業」と「忙しくない場合はバックグラウンド タスクとしてこれを行う」というものがあります。
ここでの鍵は、プロジェクトと開発者の比率にあると思います。
約 15 の 1 つの部門があり、一度に 3 ～ 4 つのプロジェクトを実行しています。一般に、人はいつでもプロジェクトに所属していますが、プロジェクトがさまざまな段階を経るにつれて、またさまざまなスキルが必要になると、メンバー間を移動できます。特にテストはプロジェクトを頻繁に切り替えるようです。
厳密なプロセスについては...プロセスをニーズに合わせてください。お客様のニーズをよりよく把握できれば、より良いご提案ができるかもしれません。
于 2010-07-08T17:13:57.763 に答える
1
次の 2 つのことができると思います。
- 1 つのプロジェクトの 1 つのリリースを行い、完了したら次のリリースを行う
- 開発チームを分割する
または両方の組み合わせ:)
アジャイル/スクラムは良いバズワードですが、あなたの質問とはあまり関係がないようです。それらはプロジェクトの束ではなく、プロジェクトの範囲に適用されるためです。
私は、開発者よりも多くのプロジェクトが存在するレベルまで、2 番目のオプションの経験がありますが、これはあなたが望むものではありません。しかし、適切なコード レビュー セッションでは、うまくいくようです。
于 2010-07-08T17:17:06.103 に答える
1
重要な点の 1 つは、複数の製品所有者がお互いを認識し、開発の範囲外で協力できるようにする必要があるということです。彼らが自分たちの領地に隔離されていて、それぞれが「彼らの製品」に値する注目を集めるために他の人よりも声を上げようとしている場合、問題が発生するでしょう.
開発作業がチームの前に置かれるまでに、これらのことはすでに解決されているはずです。開発者は、どのタスクがどの所有者やどのプロジェクトのためのものかなどを気にするべきではありません (場合によっては、知りたがることもあります) 。
プロダクト オーナーやその他のさまざまな高レベルの役割は、そのスプリント中にどのストーリーを実行するかを計画して、各スプリントを開始する必要があります。特定のプロジェクトからいくつのストーリーが含まれるかは関係ありません。それを整理することは、それらの利害関係者にとってスケジュール上の懸念事項です。アーキテクトや上級開発者などと協力して、現在/次のスプリントでどのストーリーを実装するかを単純に決定する必要があります。
(ちなみに、私はまさにこの種のことに対する Area 51 の提案を持っています: http://area51.stackexchange.com/proposals/9543/development-methodologies )
于 2010-07-08T17:20:34.263 に答える
0
製品とプロジェクトのコンセプトを組み合わせているようです。
1つのチームと1つの製品バックログで1つの製品開発を管理することをお勧めします。1つのプロジェクトの機能要求に対して個別のプロジェクトを作成しないでください。代わりに、ユーザーストーリーに優先順位を付けて、1つのチームにさまざまな顧客からのさまざまな要求に取り組んでもらいます。
ただし、それらが開発する完全に別個の製品である場合は、チームを分割して、各チームが一度に1つの製品に集中できるようにしてください。
于 2010-07-24T18:05:39.130 に答える
0
私見ですが、スクラムは、4 ～ 6 人の開発者のチームで 2 週間の反復を少なくとも 3 ～ 4 回行うと、より効果的です。したがって、+-400 人/日のプロジェクトの場合
一度に複数のプロジェクトを行うのは悪い考えだと思います。
この以前に回答された質問も確認してください。
于 2010-07-08T18:58:27.780 に答える