project-management - チームの規模とプロジェクトの反復期間

Question

プロジェクトのイテレーションの長さは、プロジェクト チームの規模に関係していると思いますか? もしそうなら、どのように？さまざまなプロジェクトの正しいイテレーションの長さを認識するために、他にどのような重要な要素を使用していますか?

Answer 1

イテレーションの長さは、主に、ソフトウェアの作業バージョンを伝達して完成させるチームの能力に関連しています。チーム メンバーが増えると、コミュニケーション チャネルが増えることになり (ブルックスの法則)、イテレーション時間が長くなる可能性があります。

クライアントに提供するかどうかにかかわらず、2 週間のイテレーションは良い目標だと思います。これにより、非常に優れたヘルス チェックが可能になります。

最終的に、イテレーションの長さは、次のイテレーションで実装したい機能によって異なります。初期段階では、チームとテクノロジー スタックに慣れるにつれて、イテレーションは 1 週間から 1 か月に跳ね返る可能性があります。

Answer 2

クライアントに提供するかどうかに関係なく、2週間の反復は、非常に優れたヘルスチェックを可能にするため、良い目標だと思います。

2週間の反復は、私と私が通常行う種類のプロジェクトにとって最も快適ですが、提供しないことが良い結果であることに同意しません。焦点は、物事の「ソフトウェアオーバープロセス」側にとどまる必要があります。

プロダクトオーナー/ユーザーが利用できない場合は、数週間ごとのショーケースの場合でも、イテレーションを長くすることを検討します。これは、技術面で高速イテレーションが許可するのと同じヘルスチェックを、エンゲージメント側で行う必要があるためです。ビジネス。

Answer 3

反復の長さは多くの要因で決定する必要があります...そしてチームのサイズは、実際には「反復のオーバーヘッド」について行われた考慮事項の一部にすぎません。

この記事ではそれらの多くについて説明します。

重要なものIMO：

1. 全体のリリース長
2. 優先順位を変更せずに維持できる期間
3. 反復のオーバーヘッド

Answer 4

どれだけの作業を完了できるかという点では関係がありますが、ここには他にもいくつかの重要な要素があります。たとえば、Windows アプリケーション、コンソール アプリケーション、Web アプリケーションなどのプロジェクトの種類や、コードベースの開発方法などです。現在のチームのスタイルと比較したサイズ、複雑さ、スタイルの観点から、チームが方法論と彼らが行っている作業の両方でどのような専門知識を持っているかは、全員がプロセスに習熟するという点でコストがかかる可能性があるためです。

Answer 5

短いイテレーションの主な要因の 1 つは、モジュール/機能/プログラマ間の統合を容易にすることです。明らかに、チームが大きくなればなるほど、統合が進みます。これはトレードオフです。反復が短いということは、頻繁に統合することを意味します。これは良いことですが、大きなチームの場合、新しいコードがなくても、統合のオーバーヘッドに多くのチームを費やすことになります。より長い反復は明らかに、毎回より多くの統合を意味し、めったに行われず、リスクがはるかに高くなります。

チームが非常に大きい場合は、分岐統合を試すことができます。つまり、小規模なサブチームを頻繁に統合し、チーム間の統合をそれほど頻繁に行うことはありません...しかし、そうすると、ブランチ間で矛盾が生じ、その利点の多くが失われます。

考慮すべきもう 1 つの重要な要素は複雑さです。明らかに複雑で、バックエンド システムは統合のリスクが高く、単純な Web-UI ページはリスクが低くなります。

（私は明確な答えをあなたに与えていないことを認識しています.何もありません.それは常にトレードオフです.私はあなたに考えの糧を与えることを願っています.）

Answer 6

私の経験では、イテレーションの長さはチームの規模に多少依存します。

反復ベースの開発サイクル (ウォーターフォールを参照) を使用していない社内システムと統合する必要がある場合など、外部の依存関係が観察されました。

私たちのチームは、反復開発に関しては本当に初心者だったので、最初は反復が非常に長かった (12 週間)。しかし、後で心配する必要がないことがわかり、イテレーションは大幅に短縮されました (4 ～ 6 週間)。

したがって、反復にかかる時間のもう 1 つの要因は、反復開発の概念にどれだけ精通しているかです。