共同作業（小規模チーム）-ベストプラクティス
私は現在、プログラマーの非常に小さなチーム（2〜3人）で作業しており、作業の編成方法に関するアドバイス/ベストプラクティスを探しています。私たちは全員、PHPを使用して同じアプリケーションに取り組んでいます。今日、私たちはすべての方法で取り組んでいます。
今日の状況：
- 各開発者1 /週で作業する必要があるリスト項目。やらなければならないことは、高機能レベルで定義されます（例：この製品の検索エンジンを作成します。）
- 毎週、次のミーティングの前に、個々のブランチ（git）をコミット/マージします
- 実際の開発ルールなし、コードレビューなし
- テストは書かれていません（aouutch）
直面する問題：
- コードの品質の問題：他の誰かを見つけるのは難しい場合があります（インライン、変数+関数+クラス名、スペース、コメントなど）。
- 既存のクラスの変更（誰か他の人への影響）
- 各開発者の責任は不明：他の誰かのコードを入手した後
そして厄介なものを発見しました、変更を加えるべきですか？彼は
変更を加えますか？それらを計画する方法、...
私が探しているもの：
基本的には、フラストレーションを回避して全体的な品質を向上させるために、私たちが開発する方法を構造化することを検討しています。
- コーディング標準を定義する方法（命名規則、コード規則...）？コミットする前にコードが有効であることを確認する検証スクリプトはありますか？
- チームでアーキテクトの役割を定義する必要があると思いますか？次のフェーズで開発する必要があるものを実際に定義する人。記述する必要のあるインターフェースまたはクラスの説明を定義する。 （このような小さなチームでは理にかなっていますか？）
今日、私たちは他の人が何をしたか、何をしようとしたかを理解するのに時間を費やしています。また、「あなたはそのようにそれをやるべきだったのです。なぜこのクラスがそれをやっているのでしょうか？。このデータのセットではなく、埋め込みクラスがあります...」.
私は、パフォーマンスを改善するために、おそらくより明確な責任とプロセスを備えた作業プロセスを調査しています。経験、アドバイス、ベストプラクティスなど、私たちが共有できるメリットがある場合は、ぜひお知らせください。
あなたの時間をどうもありがとう！
小規模なチームの場合、おそらく、大規模なチームが経験する厳格なプロセスのタイプにあまり焦点を合わせる必要はありませんが、実際に役立ついくつかの低ぶら下がり果物があります。
デイリースタンドアップ
毎日の最初に立ち上がるシンプルなスタンドアップ。全員が昨日何をしたのか、今日何をするのかを簡単に説明し、進行を妨げている何かを提起します。
コーディング標準
ほとんどの言語には、1つまたはいくつかの標準があります。重要なことは、どちらを選ぶかではなく、どれを選ぶかです。そうすれば、例外なく、誰もがそれに慣れることができます。
ドキュメント
「この製品の検索エンジンを構築する」タイプのプロジェクトを始める前に、その検索エンジンの機能仕様をまとめる必要があります。これは、実装の詳細にあまり深く入り込まずにシステムがどのように機能するかを明確な言葉で説明します。ドキュメントは完成している必要があり、チームはコーディングを開始する前にドキュメントを確認する必要があります。チームの全員が開発者として妥当なレベルであると想定すれば、おそらくそれは十分なアーキテクチャの監視です。これらの仕様は、ユーザーに渡す将来のドキュメントの基礎として、または古い作業を再検討するときの参照資料としても使用できます。
コードレビュー
少なくとも1人の他のチームメンバーによってレビューされるまで、誰のコードもプロジェクトのマスターブランチにマージされません。コーディング標準を満たさないコードは含まれず、文書化されていないコードは含まれません。これにより、後で多くの問題が回避され、上記のコーディング標準と組み合わせると、はるかに読みやすくなります。コード。
また、順番にコードの例を選んで共有することもできます CodeReview.se -これにより、チームの全員が他の開発者の幅広い経験から学び、支援する機会が与えられますみんなから良いコーディングを奨励する。
テスト
自分の機能に対して機能テストを実行する人はいません。他の誰かにあなたのためにテストしてもらう必要があります。
また、ユニットテストが実行されてユニットテストに合格するまで、コードは完成しません。ユニットテストはビルドプロセスの一部であり、失敗した場合、ビルドは失敗します。
早期にマージし、頻繁にマージします
毎週のマージを行っていて、開発者間で衝突が発生している場合は、分岐戦略を検討する必要があるかもしれません。他の開発者に何かがノックオン効果をもたらす場合は、できるだけ早くマージして、誰もができるようにする必要があります。新しいバージョンを使用できます。これは優先順位の問題であり、みんなの生活を楽にします。
小さなチームの最大の利点の1つは、あなたが小さなチームであることです。誰もが簡単に他の人に自分の状況を伝え、他の人にアドバイスを求めることができます。私がここで行っている提案の多くは、コミュニケーションを促進するための単なる方法であり、小さなチームでは大きなチームよりもはるかに簡単なはずです。
コードレビューと毎日のスタンドアップの重要性に関する他の回答に完全に同意します。
アーキテクトの役割
これは難しい問題です。それはあなたのチームの開発者の経験に依存すると思います。チームであなたの規模が大きいほど、開発者の経験が豊富であればあるほど、アーキテクトは必要ありません。アーキテクトを追加する前に、経験の浅い開発者のペアプログラミングとメンタリングを増やすことをお勧めします。
ビジネスアナリスト
チームに人を追加する場合は、アジャイルスタイルの要件/ストーリーを非常に適切に記述できる有能なビジネスアナリストを追加することを強くお勧めします。長い目で見れば、ビジネスニーズを適切に定義し、簡単にテストできる要件/ストーリーを作成できる人物がいると、最終製品にとってより価値があることがわかりました。
コーディング標準
承認された基準に従っていない場合に警告を発するツールを使用すると、良い出発点になります。誰もが認められた形式を使用する必要があります。
通常のコードレビューランチ
私が所属していた1つのチームも同様の状況にありました。私たちは毎週のランチを設け、全員が自分のランチを持ち込んで会議室で会い、チームの1人がコードや機能について話し合ってもらいました。彼らはコードの簡単なプレゼンテーションを行い、それから私たちはそれのさまざまな側面について話します。
ベビーステップ
加えた変更をゆっくりと行います。一度にすべてを実行しても、チームのバランスが崩れるだけです。チームをどこに連れて行きたいかについての長期計画を作成し、チームと共有します。一度に1つのステップを選択し、チームがそれを受け入れてワークフローに統合するまで、そのステップに集中します。次に、次のものに進みます。
つま先を踏まないでください
チームマネージャーでない場合は、チームマネージャーと一緒に座ってチームの目標を提示し、どのように変更できるかを提案します。あなたがマネージャーである場合は、各チームメンバーの地位を尊重するようにしてください。加えられた変更はすでに存在するバランスを混乱させ、人々が本当に含まれるべきであったときに誰かがプロセスから除外されたので、あなたは人々が去ることを望まないでしょう。