小規模チーム向けのプロジェクト方法論[終了]

Question

通常、私の会社の各プロジェクトの開発者/アートディレクター/コピーライターは1〜4人ですが、どの方法論を使用することをお勧めしますか？アジャイル？ XP？スクラム？他に何か？ （これらはすべて本質的に同じ概念のバリエーションであることがわかります、はい）

Answer 1

一般的な答えがあるとは思わない。質問が広すぎて、「方法論を採用する」ことはできない。箱から取り出した製品であるかのように、時間の経過とともに進化するものですが、いずれにしても、この本のコピーを入手することを強くお勧めします。 Head First Software Development

次に、好きなアイデアをプロジェクトに取り入れます。名前と流行語について心配する必要はありません。それらはすべて「合格」です。とにかく来年。最初はシンプルにしてください、より理にかなったアイデアを採用し、最大限の価値を生かして、まだ存在しない問題を解決しようとしないでください。良いスタートになります。

Answer 2

ペアプログラミングの場合、少なくとも、偶数人のプログラマーがいるのが最善です;; P

小さなチームの良い点の1つは、内部で通信するために多くのサポートシステムを必要としないことです（バグトラッカーは多かれ少なかれ自分の仕事リストになりますが、とにかく）。チーム全体とミーティングを行うだけで、あなたの慈善団体を振り返り、「ちょっと、ボブとカール、これを見てください！」と言うだけであれば、とにかくメトロジーのすべての正式なルールは必要ありません。ただし、一般的にアジャイル手法は中小規模のチームに非常に適していますが、自発的なチームメンバーが必要です。

さまざまな方法論から好きなアイデアを選んで、とにかく提案と見なすことができます。

Answer 3

このような小さなチームでは、ソフトウェア開発へのアジャイルアプローチを間違いなく検討します。個人的には、XP、Scrum、Leanのブレンドを使用するでしょう。それらを最もよく知っているからです。特に、アジャイルを初めて使用する場合は、XPが適切な開始点となり、そこからプロジェクト固有の適応を見つけることができます。 「The Art of Agile Development」という本を強くお勧めします。

Answer 4

私の3つの開発チームは、単にカンバン+継続的な展開を使用するだけで、急速に動いています。私はスクラムなどを見てきましたが、私たちの小さなチームにはオーバーヘッドが大きすぎます。

Answer 5

これらはビジネス側に非常に近いため、プログラマーは会計、時間管理、リスク管理などの意味をよく理解していないため、悪いことでもあります。彼らは、ビジネスを洗練された技術スキルを向上させるもう1つの魅力的な機会と考えています。会社が小さいため、開発チーム内で複雑な方法論を実装するのはやり過ぎかもしれません。技術的な質問は自分で簡単に処理できます。彼らが処理できないのは、彼らがビジネス環境に近いからといって、もはやプログラマーではないということを理解することです。

いくつかのプログラマーが気に入っている技術的なトピックについて顧客と話すのではなく、規律を確保し、技術的な側面に焦点を当てるいくつかの簡単なポリシーを実装することをお勧めします。

Answer 6

答えは、事実上、状況によって異なります...

各チームは個性と能力の融合であり、各チームメンバーは異なります。 「方法論」を見つけることに集中するのではなく、それ自体は、各チームメンバーが成功するために必要なものに集中し、それをプロジェクトが成功するために必要なものと組み合わせることをお勧めします。これら2つの考慮事項の間に適切な方法論とプロセスの組み合わせが見つかります。

例として、私は過去7か月間、小さなチーム（3人のフルタイム開発者と一部のパートタイムUIデザイナー）を率いてきました。次のプラクティス/手順がうまく機能していることがわかりました...

• 短期間（60〜90日）の明確に定義されたスパイラルを採用することで、チームの集中力とデリバリー指向を維持し、リスクを最小限に抑えます。
• 反復的なライフサイクルを採用します。このライフサイクルでは、スパイラルの過程でクライアントにいくつかの増分配信を行い、何を行ったかを話し合います。そうすることで、私たちとクライアントは、彼らのニーズに確実に対応できるようになります。
• 各チームメンバーの調整タスクと指示。たとえば、あるチームメンバはより若手の開発者であり、他のチームメンバは非常に優れた開発者ですが、オープンエンドのタスクをうまく処理しません。異なるアプローチが必要です。

当然、プロジェクトとチームのニーズに合わせてCMプロセスとテストプラクティスも調整しました。