私は小さなチームで働くことを好みます：最大10人。 チームメンバー全員を個人的に知っています。ほとんどの場合、何かを話し合って決定するために「時間を予約する」必要はありません。



しかし、大規模なプロジェクトに取り組むこともあります。 「大」によって、私は次の要因の構成を理解します。

1. ソリューション内の50以上のプロジェクト。 すべてを知っているわけではない
2. ビルドと計算は5分以上続きます
3. 数十または数百人がさまざまなオフィス（おそらく国）でコードに取り組んでいます
4. 各チームには明確な分業と責任範囲があります
5. 厳格な規制があり、コード設計の基準があり、レビューに合格することがタスクを完了するための必須基準です。
6. 作業時間の計算はタスクごとに実行され、見積もりと実際の人件費の不一致の理由が分析されます

この場合の官僚制は、それでも必要な悪であり、神経に作用します。 貴重な細胞の損失を避けるため、通常のワークフローを変更する必要があるという事実にすぐに備えることをお勧めします。 良いニュースは、再訓練されたので、あなたが小さなプロジェクトに取り組むことも難しくないということです。 ほとんどの場合、あなたの同僚はそのようなペダントリーにうれしい驚きを感じるでしょう。

1.機能文字列とアトミックコミットを使用する

キャプテンのカテゴリーからのアドバイスですが、誰もがこの規則を順守していれば、このような記事はそれほど多くの利点を得られなかったでしょう。 私はこのテクニックをわざと習得しませんでした。ある時点で、作業をサブタスクに明確に分割し、それぞれの最後にコミットするようになりました。 この場合、開発自体が反復的であるため、TDDではアトミックコミットを使用する方が簡単です。 あなたにとっての追加のボーナスは、あなたが自分のスレッドで自分でやるなら、git reset --hardを実行するだけです。 複雑なコンピューターゲームでは必須の保存と考えてください。



別のブランチの同僚がまだ完成していないコードを必要とする場合、彼はマージを拾わずにチェリーピックを行い、あなたの「意識の流れ」全体ではなく、彼に関心のある変更のみを拾うことができます。

この慣行に対して私が聞く主な議論は、「フローの状態が失われる」ことです。 「フローの状態」を測定したり、触ったり、評価したりできないため、コメントできません。

2.コミット命名形式を使用する

コミットの命名は、トラッカーのタスクIDで開始する必要があります。 最新のプロジェクト管理システムはすべて、ビルドサーバーおよびVCSと同期できます。 さらに、リポジトリ内の履歴を追跡するのが簡単です。

3. gitでエイリアスを取得してプルリクエストを準備する

master / devブランチに対処するために、アップストリームですべてのローカルコミットを実行することが常に必要です。 これらは単純なアクションですが、難しいタスクの作業を終えた後、注意が不足している可能性があります。 これを自動化に請求する方が良いです。

4.毎日のチェックリストを取得する

たとえば、これ：

1. プールリクエストを確認し、すべて合格しましたが、拒否されたリクエストはありますか？
2. プールリクエストが拒否されたタスクを「開発」ステータスに移行し、レビューアがそこに残っているかフィールドが空の場合は、自分に担当者を割り当てます。
3. 拒否されたプルリクエストを修正し、タスクをレビューに変換し、プールリクエストを再度開きます
4. 今日作業することに同意したタスクを取り、それを開発ステータスに変換します
5. 終了したら、マスター/開発者をサポートします
6. 競合を修正
7. 煙テストを実施する
8. タスクをレビューに変換し、PRを開きます
9. 次のタスクに進む

一部の組織には強力なdev-opがあり、最初のコミットをアップストリームにプッシュするだけで十分であるため、カードは自動的に目的のステータスに切り替わります。 このようなメカニズムをあらゆる方法で歓迎しますが、そのような自動化を構成するすべての場所ではありません。

5.事前に手配する

一般的にすべてについて。 大規模な組織のプロセスは規制されており、意思決定を行う主要な従業員の仕事は常に屋根よりも高くなっています。 明日の午後に必死にレビューが必要な場合は、今夜手配してください。 夕方に到達する複雑なコードの助けが必要です。 朝助けが必要な人に確認してください。 彼は彼自身の問題を抱えているかもしれません。 他の部門/クライアントの従業員との要件を明確にする必要がある場合は、1週間でこれを開始します。

6.プランBについて考える

たとえすべてに同意しても、必要な従業員は病気になる可能性があり、予期しないファカップに引っ張られる可能性があります。 何でも起こります。 可能であれば、ブロッキングの場合に別のタスクを提供してください。

7. RTFM

真剣に、それを読んでください。 これはあなたとあなたの同僚に時間と神経を節約します。 ただ... 100％のドキュメントを信用しないでください。 ドキュメントは最新ではありません:)

8.同僚とのパートナーシップを構築する

誰とやり取りする必要があるかを学びます。 誰があなたをブロックできますか？ 誰の命令に従うべきですか？ 何かが起こったら誰があなたを助けることができますか？ あなたはすべての同僚を愛する必要はなく、ただ人間として振る舞います。 意地悪ではなく、失礼ではありません。 他の従業員との甘やかされた関係は、最も予期しない方法で戻ってくる可能性があります。

9.理解できない状況では、正式に行動する

いいえ、私はイタリアのストライキを求めていません。 会社が大きくなればなるほど、発生した問題の詳細を掘り下げて管理する時間が少なくなります。 おそらく、あなたは勇敢に自分自身を示し、状況を修正するために最善を尽くしたのでしょう。 これが頭でうまくいかなかった場合、彼らはあなたをstrokeでません。 そして、賞品は授与されません。 一般的に、あなたは極端なままです。 あなた次第ですが、ルールの範囲内ですべてを行ってください。 ほとんどの場合、あなたがどのように考えても、彼らは合理的です。 ルールが合理的でない場合-ジョブを変更します。

9¾。 いつもより慎重かつ慎重に

これは良いアドバイスではないので、私は自分を4分の3に制限しました。 プロジェクトに参加する人が多くなればなるほど、ダウンタイムとミスが「コスト」になり始めます。 開発者がプールリクエストを送信しました。 ティムリッドは忙しく、レビューを実施せず、コードを保持していませんでした。 翌日、彼のチームメイトは、マージされていないリクエストからのコードを必要としていました。 プールリクエストはバックデッキされ、2つの機能が遅延し、QAにはテストする時間がありませんでした。 全社規模では、これは莫大なコスト超過につながります。 したがって、すべてがタイムリーに行われるようにあらゆる努力をすることが非常に重要です。 いくつかのタスクがプロジェクトのクリティカルパスに沿って「移動」される場合、合理的な準備金は耐えられません。



「血なまぐさい企業」の目に見えない前線のすべての従業員に、コメントで彼らの前向きな（またはそうでない）経験を共有することを勧めます 。