ソフトウェアの方法論を研究していると、 「この方法論には成熟した開発チームが必要です」という免責事項がよく見られます。
未熟な開発チームを特に対象とした開発方法論はどれですか? これがほとんどのチームが始めるべきところだと思います。
未熟なチームを、メンバーがこれまで一緒に作業したことがなく、未知の環境(つまり、新しい会社)で作業していて、プロセスと制御をまだ定義していないチームとして定義しましょう。
ソフトウェアの方法論を研究していると、 「この方法論には成熟した開発チームが必要です」という免責事項がよく見られます。
未熟な開発チームを特に対象とした開発方法論はどれですか? これがほとんどのチームが始めるべきところだと思います。
未熟なチームを、メンバーがこれまで一緒に作業したことがなく、未知の環境(つまり、新しい会社)で作業していて、プロセスと制御をまだ定義していないチームとして定義しましょう。
私の$0.02
方法論が未成熟な開発チーム自体に特に向けられているわけではありません。ただし、経験の浅い開発者にとって有益な方法論の特性がある場合、それは「明確に定義されたプロセス」になります。
免責事項(「成熟した開発チームが必要」)の理由は、ほとんどの場合、アジャイル手法に適用されます。これは、プロジェクトに取り組み、間違いから学ぶことによってのみ得られる規律と経験が必要であるためです。適切な手順を実行し、適切な選択を行います。成熟した(読む:経験豊富な)開発者は、経験の浅い開発者がとにかく毎回無謀に行う可能性のあるコーナーを切り取ることが安全である(そして安全ではない)場合を知っています。また、経験豊富な開発者は、より良い直感とより良い最初の選択を行い、必要に応じて設計とコードを適切にリファクタリングする方法を知っています。
Bjarne Stroustrupからの有名な引用を、(経験の浅い)チームに一致する方法論に書き直すには、次のようになります。同じ方法論で、彼らはおそらく彼らの足を吹き飛ばすでしょう。」(Bjarne、および下肢の怪我の考えに腹を立てた人にはお詫びします:)
方法論に精通していて、いつ何を追加するかを選択できる人がいると役立ちます。経験の浅いチームで本格的な方法論を試してみると、チームを圧倒する可能性があります。プロセスを所有するために上級者を割り当てることは良い考えです。
まず、バージョン管理とcontinuosビルドプロセスから始めます。これらは、他の変更がコードを壊しているかどうかを識別するのに役立ちます。ビルドプロセスに関連付けられた自動テストは、すぐに実行されます。何をいつ構築するかを選択することも重要です。
何が機能していて何が機能していないかについてのこのコミュニケーションのすべてを通して、発生するはずです。動作しないものを変更し、追加を続けます。
難しいのは、これが起こっている間にものを作ることです。
維持するコードがある場合は、新しいコードに取り組んでいる小さなチームから始めて、方法論を開発し、それをチームに広めることができます。
方法論は、必要なときに適切な人に適切な情報を提供することを促進する必要があります。方法論が機能するコードの生成を妨げている場合は、問題に対処してください。
考慮する必要があるもののウォーターフォールの方法論を確認します。適切なタイミングで物事を検討する方法について、アジャイル手法を確認します。
私はあなたに環境を設定し、働き始めることだけをアドバイスすることができます、そしてあなたのチームは選ばれた方法論に順応します。小さなリリースサイクルを作成し、すべての新しいリリースサイクルの開始時に選択した方法を調整します。
コード/設計レビューの導入は、非常に価値のある最初のステップになる可能性があります。(正しく導入された場合)チームボンディングを開発できます。「エゴレス」プログラミングにつながる可能性があります。知識と学習の共有につながります。そして、熱意が大きな落とし穴につながる可能性があるプロセスの早い段階でエラーを拾い上げます。@BillThorのように、バージョン管理は価値があると思いますが、チームが心からそれを採用する前に、一般的にその必要性を経験する必要があり、これはバージョン管理が問題を引き起こした後にのみ発生することを示唆します。私の答えに役立つ要素である@Billと@Peterは、メンタリングを利用できるようにする能力です。これは(理想的には)開発経験のあるマネージャー、または上級開発者の役割になります。