分散SCRUMチームの問題：作業環境

今日、私にとって興味深い問題が1つ現れました。分散SCRUMチームで、コード形式、IDEプラグイン（checkstyle＆co）、VCS、CIの観点から単一の作業環境の実施をいつ開始しますか？チームは探索段階にあり、目標は本番品質のコードではなく、概念実証です。チームメンバーが将来の作業に本当に関連するものを決定する前に、いくつかの一般的なコーディングルールを「アプリオリ」に実施するのはオーバーヘッドではありませんか？この種のツールは、技術的な負債を最小限に抑えるヒューリスティックとして機能するため、確かに大きなメリットですが、Jenkinsビルドを実際に破壊する「後続スペースなし」としてルールを強制することは、私にとっては、焦点を絞るべきフェーズのやり過ぎに思えます量産コードを作成するよりも氷をくじくように。

注意1：作成したプロトタイプは破棄されます

メンション2：最初からすべてが正しく行われることを望みますが、100％可能ではないことは完全に承知しています。

この問題には3つの部分があると思います。

1. 良いルールを今すぐ施行することで、技術的な負債/頭痛の種を節約したいと考えています。
2. 不必要なルールで全員を行き詰まらせてチームの速度を殺したくはありません。
3. プロジェクトは探索段階にあるため、実装するのに最適なルールを正確に把握していません。

私は両方の極端な方法を試しました（ルールなしから、同じソース管理を使用して、20ページのコーディングスタイルガイドラインと他の多くのプロセスまで）。

一貫して機能している唯一のことは、私が必要としていることがわかっていて、今すぐ必要であることを証明できる絶対的な最小値を採用し、プロセスを定期的に改訂することです。（振り返りのすべてのスプリントは、それを行うのに適したタイミングです）これには、痕跡のルールの削除も含まれます。

これは本当にチームに依存していると思います。私はいくつかの不必要なバグを防ぐためにある種のルールを持つべきであることに同意します。しかし、いくつかのルールは生産的というよりも迷惑です。チーム内で必要なルールと不要なルールについて同意する必要があると思います。

Jenkinsのジョブをcheckstyleやfirebugに設定するのも良い方法ですが、ここでも、どれほど厳格にしたいかについて同意する必要があります。私は誰かがチェックスタイルのルールを破って、誰もコミットできないようにしている状況にあります。長い目で見れば、人々を困らせるだけです。繰り返しますが、人々があまり注意を払う必要がないと言った場合、彼らはそれらを無視し始めるでしょう。ですから、私のチームでは、質の高い仕事がひどく壊れていない限り、ある程度同意します。スプリントが終了する前に青でなければなりません。

したがって、私の提案は、会議のタイムボックスを作成して、ルールの作成やルールの議論に多くの時間を費やさないようにすることです。

いくつかの考えでは、最近のIDEにはチェックスタイルプラグインがあり、いくつかのルールが破られた場合に、チームはコミットする前にコードレビュー中にチェックすることだけに同意することができます。それは私のチームにも役立ちます。

• 開発を高速化しないIDEはツールではなく、ボートのアンカーです。それを船外に投げて、決して振り返らないでください。
• すでにCIインフラストラクチャがある場合は、1日目からそれを使用してください。プロトタイプコードの破棄に本当に成功したとしても、後で感謝します。
• 逆に、CIシステムがない場合でも、CIシステムをセットアップする時間を無駄にしないでください。コストが高すぎるため、最初からやり直すことを望んでいます。
• 1日目のVCSから開始します。期間。

チームの速度が安定し始めたら、単一の作業環境の概念の実装を開始することをお勧めします。これにより、プロジェクトの開始時に技術部門が発生する可能性がありますが、プロジェクトの開始時には常に技術部門が存在します。:)

私は通常、チームの自己組織化の側面から、チームとその要件に適したものを考え出すことに成功しています。基本的には、Jenkin Buildsの失敗などの問題の説明をチームに提示し、それらに「修正」する機会を提供します。

これは通常、ザッカリーイェーツが彼の回答で述べたように、ソリューションの最小限の実装をもたらします。

上級の技術スキルレベル/ポジションの誰かが微妙なガイダンスを提供している場合、チームが彼らが一緒に行くことに決めたことに変わらないようにするのを助けるために、それはあなたに有利に働くと思います。:)