19

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

4

6 に答える 6

11

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

次に、気に入ったアイデアをプロジェクトに適用します。名前や流行語について心配する必要はありません。いずれにせよ、来年はすべて「時代遅れ」になります。最初はシンプルに保ち、より理にかなっていて費用対効果が最も高いアイデアを採用し、まだ存在しない問題を解決しようとしないでください。とても良いスタートになります。

于 2008-11-27T15:04:47.840 に答える
5

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

小規模なチームの良い点の 1 つは、内部でのコミュニケーションに多くのサポート システムを必要としないことです(バグトラッカーは多かれ少なかれ自分の ToDo リストになりますが、とにかく持っていると便利です)。チーム全体とのミーティングで、チャリを振り向いて「ねえ、ボブとカール、これを見て!」と言うだけの場合は、方法論のすべての正式なルールは実際には必要ありません。一般に、アジャイル手法は中小規模のチームに非常に適していますが、自発的なチーム メンバーが必要です。

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

于 2008-11-27T15:15:15.883 に答える
2

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

于 2008-11-27T19:14:41.907 に答える
0

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

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

于 2008-11-27T15:50:01.693 に答える
0

答えは、ことわざですが、場合によって異なります...

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

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

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

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

于 2008-11-27T16:32:19.067 に答える