私は最近、開発プロジェクトに参加しましたが、突然主任開発者の仕事を与えられました。私の主な責任は、プロジェクトのプログラミング部分をタスクに分割し、これらのタスクを他の開発者に与えて、それらの部分が連携して動作することを確認することです。

問題は、これを行う方法がわからないことです。私は週末を鉛筆と紙でそれを理解しようとして過ごしましたが、並行してではなく順番に取り組むべきタスクのリストを考え出し続けています。機能に分割することを考えたかもしれませんが、同じファイルを編集する必要があるタスクになります。開発の早い段階のため、タスク全体を完全に書き直す必要があります。プログラムがもう少し完成してタスクを作成しやすくなるまで開発者を待たせることもできましたが、その後、何週間かを知っている人たちに手を貸してもらいました。

私はこれを行う資格について上司と会話しましたが、この問題について選択肢は与えられませんでした。自分が何をしているかわからないので、正しい方向へのヒントやナッジは大歓迎です。

あなたの質問への適切な答えは数冊の本を埋めます。このことについて頭に浮かぶ話題の単語の箇条書きリストを思いつくでしょう。Googleと本があなたのために残りを行います。

1. 基礎

   • 一人で行かないでください。できるだけチームメートを巻き込むようにしてください。
   • 軽量の旅行。
   • 民主主義ですが、多すぎません。時には、それは最大数の人々を満足させるものではなく、最小数の人々を傷つけるものについてのものです。
   • 何（やらなければならない）と、どのように（やらなければならない）を分けておきます。
   • Scrum（ "what"）、XP（Extreme Programming、 "how"）、Kanban（ "how much"）、Lean（ "what not"）、DevOps（ "with who"）について学びます。
   • リーンはフローにも関係します。全体的な効率のために、フロー効率は通常、個々の効率よりも重要です。
   • ソフトウェアクラフツマンシップ、クリーンコード、実用的なプログラミングについて学びます。
   • 優れたアーキテクチャとは、行われない決定の数を最大化することです。
   • スクラム/ XP /リーン/アジャイルは、未完了の作業量を最大化することです：YAGNI。
   • ソフトウェアの主な価値は、簡単に変更できることです。それがすべきことをすることは重要ですが、それは二次的価値に過ぎません。
   • ホフスタッターの法則が適用されるため、反復的 かつ 漸進的なアプローチを好み、ほとんどすべて、特に会議にタイムボックスを使用して、パーキンソンの法則をあなたの友人にします。
   • コンウェイの法則とタックマンのチーム開発の段階を理解して、チーム構造のバランスを取ります。
   • プログラミングは四元性であり、科学、工学、芸術、工芸のすべてが同時に行われるものであり、それらのバランスを取る必要があります。
   • 理由だけでスクラム / XP / XYZが誰かのために良いです（私を含む）、必ずしもそれはあなたのために良いことだという意味ではありません/お使いの環境に適しています。誇大広告を盲目的にたどらないで、最初に理解してください。
   • 検査と適応！（スクラムマントラ）
   • 重複を避ける - 一度だけ！（XP Mantra）別名DRY-繰り返さないでください別名SPOT-Single Point of Truth

2. 「What World」ワークブレイクダウンプロセス

   • などの要件の収集ユーザーストーリー / 求人ストーリーにプロダクトバックログを。
   • ユーザーに類似（ユーザーストーリーの）俳優（UMLで）に似たペルソナに似た役割。
   • INVEST（Independent、Negotiable、Valuable、Estimable、Small、Testable）に基づいて、チームのReadyの定義を満たすまでユーザーストーリーを調整します。（スクラム会議：バックログの改良）
   • 製品バックログをビジネス価値でソートします。
   • Ready Ready（Readyの定義に従って準備完了）になる前にストーリーの作業を開始しないでください。
   • プランニングポーカーを使用して、ストーリーポイントのストーリーの労力を見積もります。使用する三角測量の比較を推定値の一貫性を確保します。
   • 昨日の天気が最良の推定値であり、最悪の事態を願っています。
   • ストーリーが大きすぎる場合は分割します。
   • Doneの定義で配達文化を改善します。
   • Done Done（Doneの定義に従って行われます）が完了する前に、ユーザーストーリーの実装を受け入れないでください。
   • 同じコードベースの複数のチームは、同じDoneの定義（特にコーディング標準）に同意し、共有する必要があります。
   • Burndown Chartsで進捗を確認してください。
   • チームが提供するものが本当に必要なものであるかどうかを定期的に関係者に確認してください。（スクラム会議：スプリントレビュー）

3. ストーリーの内訳

   • ユーザー / ペルソナ / アクター / ロール（製品所有者）のリストと説明
   • Epic-> Stories（ユーザーストーリーまたはジョブストーリー）（プロダクトオーナー）
   • ストーリー->受け入れ基準（製品所有者）
   • ストーリー->サブタスク（開発チーム）
   • 受け入れ基準->受け入れテスト（仕様：製品所有者、実装：開発チーム）
   • 最小限のEnd-to-（Half-End）であるウォーキングスケルトンから始めます。
   • MVP-最小実行可能製品を作成します。
   • SMURFSを使用してMVPを拡張する-特に市場性が高く、有用で、リリース可能な機能セット。

4. 「How world」の実現

   • OOA / D、UML、CRCカードを使用しますが、大きなデザインは事前に避けてください。
   • プログラミング言語に関係なく、オブジェクト指向、構造化、機能を可能な限り同時に実装します。
   • 使用するバージョン管理を（好ましくは分散）。
   • 受け入れテストから始めます。
   • TDDを適用し、TDDの3つの法則に基づいて、Red-Green-Refactor-Cycle、BDDのSingle-Assert-Rule、4 A、GWT（Given When Then）を実行します。
   • 「ユニットテストは、高速で実行されるテストです。」—マイケル・フェザーズ
   • SOLIDとパッケージの原則を適用して、結合と結合を管理します。例：SOLIDのSはSRP =単一責任の原則であり、編集と応答の数を大幅に削減します。チーム内のマージ競合。
   • 知っているデメテルの法則を / 知らせる、聞かないでください。
   • 必要に応じて、継続的インテグレーション（DevOps）でも継続的インテグレーションを使用します。
   • 合意された共通のコーディング標準（完了の定義の一部である必要があります）に基づいて、集合コードの所有権を使用します。
   • 継続的な設計改善（fka継続的リファクタリング）を適用します。
   • ソースコードはDesignです。まだ前もって考えることは不可欠であり、UMLダイアグラムを明確にするいくつかの良い点に反対する人はいません。
   • XPは、1日が建築の日ではないという意味ではなく、毎日が建築の日であることを意味します。デフォーカスではなく、アーキテクチャに焦点を当てており、焦点はコードにあります。
   • あなたキープ技術的負債を 4つのデザインを避けるため、低匂い脆弱、剛性、不動と粘度を。
   • アーキテクチャは、永続性と配信メカニズムではなく、ビジネスロジックに関するものです。
   • 建築はチームスポーツです（建築には「私」はいません）。
   • デザインパターン、リファクタリングおよび変換優先順位前提。
   • プロジェクトコードは、優先度のあるATP-Trinityです。1。自動化コード、2。テストコード、3。生産コード。
   • チームが提供する方法を改善できるかどうか、チームピアと定期的に確認してください。（スクラムミーティング：スプリントレトロスペクティブ）
   • テストは最初に行う必要があります-高速、独立、反復可能、自己検証、タイムリー。

上記のリストは確かに不完全であり、一部の部分は議論の余地があるかもしれません！

このすべてがあなたをおびえさせる場合-それはので、心配しないでなければならないあなたを怖がらせます！チームでソフトウェア開発プロジェクトを成功させることは簡単な作業ではなく、人々がこの技術について適切に訓練され、教育されることはめったにありません。これがあなたを怖がらせるなら、あなたの直観はきちんと働いています、それを聞いてください。あなたは準備したいです。上司と話をして、時間とトレーニングを受けてください。

こちらもご覧ください

• 技術的な「ユーザーストーリー」をスクラムで書いているのは誰ですか

さらに読む（オンライン）

• ウォードカニンガムらによるポートランドパターンリポジトリ
• ロバート「アンクルボブ」C.マーティンによるOODの原則
• 実用的なプログラマーのヒント

さらに読む（書籍）

• ロバートC.マーティンによるクリーンコード
• アジャイルソフトウェア開発：原則、パターン、および実践by Robert C. Martin
• 実用的なプログラマー-ジャーニーマンからマスターへ、アンドリュー・ハントとデビッド・トーマスによる
• マイケルフェザーズによるレガシーコードを効果的に使用する
• リファクタリング-Martin Fowlerによる既存コードの設計の改善
• ジョシュアケリエフスキーによるパターンのリファクタリング
• スティーブンシルビガーによる10日間のMBA（原文）
• Eric Evansによるドメイン駆動設計
• Mike Cohnが適用したユーザーストーリー
• Gray Boochらによるアプリケーションを使用したオブジェクト指向分析および設計
• Gang of Fourによるデザインパターン
• ケントベックによるテスト駆動開発
• ケントベックによるエクストリームプログラミング
• [if Java] Joshua Blochによる効果的なJava

アジャイルを取得

次のことをお勧めします。

同じファイルを編集する

まず、Git（または同様の同時バージョン管理システム）を使用します。同じファイルの異なる部分を編集している限り、競合は発生しません。競合が発生した場合は、競合として明確にマークされます。

Gitを使用せずにマルチ開発者プロジェクトを管理しようとすることは、プリンボウルなしでプリンを作成しようとするようなものです。それは可能ですが、それは非常に速く非常に乱雑になります。

コメントで指摘されているように、Gitは万能薬ではありませんが、自動化されたテストと組み合わせると、確かに大いに役立ちます。

すべての機能をリストする

次に、プロジェクトをユーザーに見える機能に分割します。たとえば、「ユーザーがサインアップすると、メールを受信する必要があります」または「ユーザーはアイテムを追加できます」。ここにすべての利害関係者を参加させます。全員を部屋に連れて行き、みんなに自分の特徴を叫んでもらいます。

これらはユーザーに見える機能である必要があります。実装戦略については後で説明できます。

愚かなものも含めて、インデックスカードにすべての提案を書いてください。リストをすばやく合理化して重複を削除し、すべてのカードを大きなテーブルまたは床に配置します。

必要な追加のカードを追加します。アプリケーションがSMSテキストアラートを送信するとします。あなたはそれを行う方法を知らないかもしれないので、質問があります。カードに「SMSポータルの調査」と書きます。他の大きな未知のものについても同様です。これらは後で解凍する必要があります。これらの機能はおそらく最初のスプリントにはなりません。

次に、カードをグループに分類し、シャッフルし、雰囲気を感じます。これがプロジェクトの範囲です。

計画ポーカー

ポーカーのプランニングに挑戦してください。それでも全員と一緒に、「1ポイント」、「2ポイント」など、「4ポイント」までのすべての開発者カードを与えます。また、「もっと」カード。ポイントはおおよそ1時間に相当します。

機能リストを1つずつ確認します。機能を読み上げると、全員がカードをプレイする必要があります。1人が1をプレーし、別の人が4をプレーする場合、そこにコミュニケーションの問題があります。ある人はこの機能を理解して、他の人とは異なる何かを意味します。話し合いをして、実際に何を意味していたかを考え、カードに書き留めます。

機能が「もっと」であることに同意する場合、その機能は大きすぎます。その機能を分解する必要があります。これを以前と同じ方法で行います。

同意したら、カードに異なる色のペンで数字を書きます。

ポイントは時間よりも優れています

時間の代わりにポイントを使用すると、開発者が頻繁に行う「コード化できる速さ」というマッチョがなくなります。これは微妙な違いですが、かなりうまくいくことがわかりました。

スプリントを作成します

スプリントとは、目標に向かって急に爆発することです。スプリントの長さ、おそらく5または10日を決定します。日数に開発者数を掛け、1日あたりのポイント数を掛けます。

最初は開発者ごとに1日あたり6ポイントを想定します。これは達成可能な数値です。5人の場合、5 * 5 * 6 = 150ポイントです。すべての開発者および管理者と連携して、リストから最大150ポイントの機能を選択します。それがあなたのスプリントです。

収まる範囲を超えて絞らないでください。あなたを含め、長期的に見ると、過度に有望な人は傷つきます。

ここで依存関係を考慮する必要があります。たとえば、環境のセットアップは明らかに最初のスプリントに含める必要があります。これは、全員がいるときに実際に比較的簡単に実行できます。部屋には6つの頭脳があり、すべて「これはこれに依存しています」などと言っています。その後、カードをシャッフルして依存関係を示します。

スプリントを取得したら、何も追加できません。5日間ロックされます。機能クリープは、チームにストレスを与え、士気を傷つけ、全員を遅くします。最終的に、クリープはプロジェクトを停止させます。チームリーダーとして、チームを機能クリープから保護する必要があります。新機能のリクエストが来たら、次のスプリントに追加する必要があります。次のスプリントがすでに満杯の場合は、他のものを取り出す必要があります。

エキストラで絞らないでください。過剰な約束をすると、約1日分の幸せなクライアントが得られ、その後4日間のチームストレスが発生します。

さあ、行きましょう。

カードを配り、誰が何をしたいかを尋ねてください。何が行われているかを完全に把握でき、ゼロに達するポイントをカウントできます。誰が何に取り組んでいるのか、誰が何をしてきたのかを全員が把握できるように、毎日の始めに立ち上がってください。

明確に定義された管理可能な目標の単位として一緒に働く5人または6人の意欲的な開発者は、5日間のスプリントでかなり量の多いものを達成できます。

可視性を維持する

全員がプロジェクトのステータスを確認できるようにしてください。壁にすべてのカードをブルータックします。左側には、まだ作業されていないカードがあります。右側には完成したカードがあります。

開発者がカードに取り組んでいるとき、彼らはそれを壁から取り外して机の上に置きます。これにより、可視性が維持され、人々がお互いのつま先を踏みすぎないようにします。

インデックスカードに代わる技術的な選択肢はありますが、壁にプロジェクトのステータスを大量に紙で表示することに勝るものはありません。

可能であれば、プロジェクトの期間中、全員を同じ部屋に入れます。できる限り、理想的には毎日、利害関係者を囲んでください。

全焼

バーンダウンチャートでゼロに向かって進んでいるポイントをグラフ化できます。制限時間に達する前に最適なラインがゼロを超えた場合、軌道に乗っている可能性があります。そうでない場合、締め切りに近づきすぎる前に、今すぐクライアントに知らせる必要があるかもしれません。

失敗する場合は、早期に失敗します。

ソフトウェアを使用してバーンダウンを作成することもできますが、壁に貼ってある大きな紙だけが好きです。その上に描いて書いてください。

自動テスト

複数の開発者が同時に同じ作業をしている場合、彼らはおそらく互いのコードを時々壊すでしょう。コミュニケーションと可視性はこれに役立ちますが、問題の発見に役立つ技術をいくつか導入したいと思うでしょう。

ユニットテストは、コードベースの個々の部分（理想的には各メソッド）のテストを記述するプロセスです。ユニットテストは頻繁に実行し、可能な場合は保存するたびに実行する必要があります。KarmaやRspecなど、これを支援できるツールが多数あります。

エンドツーエンドのテストでは、プロジェクト全体をテストし、内部をブラックボックスとして扱います。これらのテストは、「ユーザーはサインアップできます」または「ユーザーはアイテムのリストを表示できます」など、高度なビジネス要件に基づいて行います。分度器は、エンドツーエンドのWebベースのテストフレームワークの好例です。

テストについて書かれた本は全部ありますが、少なくともいくつかの受け入れテストを実施しておくと、プロジェクトで作業しているときに何も壊れないことを確認するのに役立ちます。

技術的な負債を回避し、完了させる

技術的負債とは、後でクリーンアップする必要があるものを記述する概念です。借金の一般的な原因は、完了とマークされたが、「完了」されたことのない機能です。完了した機能はGitにチェックインされ、利害関係者によって承認され、テストが行​​われます。

完了するまで機能をチェックしないでください。グラフをマッサージしないでください。繰り返しますが、これはあなたを含む長期的にはすべての人を傷つけます。

これが、開発者ごとに1日あたり6ポイントしか見積もらない理由の1つです。完了は余分な作業を必要としますが、気分が良く、チームを後押しします。

同じファイルを編集すること自体は問題ではありません。同じ関数を編集して2つの異なることを行う場合にのみ問題になります。

基本的に私がやることは、プロジェクトを個別の「機能」に分割することです。1つはネットワークプロトコルの処理に関連するもの、もう1つは構成ファイルに関連するもの、さらにもう1つはDB処理に関連するものです。機能は大きなものです。

次に、これらの機能をタスク（ストーリー）に分割します。これらは、「ユーザーがボタンをクリックすると、プログラムがファイルをロードする」、「プログラムが起動すると、構成ファイルをロードする」などの単純なものでなければなりません。

いくつかのタスクは順番に完了する必要があります（「プログラムは構成ファイルのすべてのフィールドを解析します」は「プログラムが構成ファイルをロードする」後に実行する必要があります）。他の人はできません（DBとネットワークで同時に作業できます）。

しかし、ほとんどの場合、あなたはそれを間違って行うでしょう、そしてそれは経験が適所に来るところです。ほんの少し（または多く）失敗するだけで、時間の見積もりが間違ってしまい、プロジェクトに必要以上の時間がかかります。次回は良くなります。

ケント・ベックによる「極端なプログラミング」を読むこともお勧めします。私がプロジェクトマネージャーになろうとしていたときに助けてくれた素晴らしい本。

結局のところ、アプリケーションを機能モジュールに分割し、異なるモジュール間にコントラクト（インターフェイスとデータコントラクト）を導入する必要があります。その後、各モジュールを異なる開発者に渡すことができます。すべてを元に戻すと、コントラクトはこれらのモジュールが互いに正しく通信することを保証します。

モジュールがすべて個別に動作することを保証するために、開発者にTDDを強制してください。

私の言いたいことの例を挙げましょう：

開発者の1人にSQLロガーを構築させたいとしましょう。

インターフェイスを定義し、開発者の一人に（またはAgileを使用している場合はストーリーを作成して）、次の仕様に従ってSQL固有のロガーを希望することを依頼します。

interface ILogger
{
    void Log(string message, int level);
}

私が開発者に期待するものは次のとおりです。

1. ロガーのSQL固有の実装

   class SqlLogger : ILogger
   {
       private readonly SqlLogRepository _logRepository;
   
       public SqlLogger(SqlLogRepository _logRepository)
       {
           this._logRepository = _logRepository;
       }
   
       public void Log(string message, int level)
       {
           _logRepository.CreateLog(message,level);
       }
   }
   

2. の実装など、依存するコード SqlLogRepository

3. 要求された内容に応じた単体テストまたは模擬テスト。上記の場合（他の外部依存関係がある場合）の模擬テスト、またはのような単純なユーティリティ関数の場合String.ReverseCharacters(string input)、いくつかの異なるシナリオをテストする単体テストを簡単に見たいです。

この意味は：

あなたとあなたのチームは、このインターフェースを使用して開発を続けることができます。例えば

class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}

を配置する前にコードを実行する必要がある場合SqlLoggerは、単純に作成できますNullLogger：

class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}

そして、これはあなたがその間にそれをテストする方法です（依存性注入のためにICOを見ることをお勧めします）

void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}

概要

プロジェクトのサイズについてはわかりませんが、これは非常に困難なタスクになる可能性があります。開発リードをこれまでにしたことがない場合は、このタスクを非常に真剣に受け止めて、数週間を読んでくださいソフトウェアの設計とアーキテクチャができます。そして、あなたの仕事（ソフトウェアの品質など）について非常に透明になります。

また、デザインとオブジェクト指向のパラダイムを読むことを強くお勧めします。このプロジェクトでは、OOPに大きく依存します。

他の回答ではプログラミングの側面について説明しましたが、プログラム管理の側面に言及したかっただけです。免責事項から始めます。私はプログラムマネージャーではありません。プログラム管理のために大学院レベルで1つのコースを受講しました。私の仕事の経験には、通常500時間未満で1000時間を超えない小規模プロジェクトの入札時間が含まれます。

しかし、2〜4か月（パートタイムとフルタイム）の間、2〜3人を忙しくしなければならないラボのタスクの定義を支援する必要がありました。本当に助けになったのは、Microsoft Projectのようなプロジェクト管理ソフトウェアを使用していたことです（フリーウェアバージョンがあるかどうかはわかりませんが、雇用主はおそらくそのようなものを持っているでしょう...どのようなプログラム管理ソフトウェアが使用されているかを監督者に尋ねてくださいあなたの会社で）。特に、Microsoft Projectのデフォルトビューであるガントチャートをかなり使用しています。すべてのタスクとその所要時間を定義することで、視覚化を実行できます。

ガントチャートは、視覚化されているため、最も役立ちます。紙の上でタスクを見るのはあまり役に立ちませんが、きれいな写真やチャートを見ることは確かに役立ちます。Microsoft Projectでは、先行タスクと開始日を設定することもできます。主なアイデアは、「タスクXを開始するために完了する必要のある最小限のタスクを見つける」ことです。少なくとも私の小さなプロジェクトでは、「本当の」先行者の数は非常に少ないです。実際、あるプロジェクトでは、ほとんどすべてを同時に実行できるという問題があり、多少まとまりのある2つの同時パスを合成する必要がありました。たとえば、開発者AがGUIに触れた場合、GUIに近いタスクにも取り組むようにしました。

ペンと紙に関する限り、あなたはすでにこれの多くを行っていたように聞こえますが、ガントチャートを実際に見ることは常に非常に役立ちます。順番に並んでいるタスクを見ると、「待って、タスクYはタスクYの前に実行する必要がありますか？

開発者からソフトウェアエンジニアに卒業したようです。作業の管理は設計の課題ではなく、2つが密接に関係していることを認識してください。行われている作業を管理する必要がありますが、それは会社の開発方法によって異なります。時間とリソースがあれば、アジャイルな方法論を採用することを検討してください。インターネット上には山ほどの資料があります。自分に合ったものを見つけてください。ただし、他のすべてと同様に、無料ではないことに注意してください。テクニックの採用には、成功する前にトレーニング、学習、失敗することが含まれます。より包括的な手法を採用するための帯域幅がない場合は、マイルストーン計画を立てることが答えかもしれません。連続したタスクのリストがある場合、可能なシーケンスが見つからない可能性があります並列化されます。また、テストや実装などのより一般的なタスクに開発を分割したい場合もあります。それだけではレポートの問題は解決しませんが、品質を管理しています。あなたの進行は連続したリストかもしれませんが、あなたの役割は並行しています。ただの提案。人が行った作業にマッピングする設計は、作業分解構造と呼ばれます。

他の人が提案した多くの良い提案がありますが、あなたが仕事を管理していることを忘れないでください。作業コンセプトを設計/アーキテクチャにマッピングできる場合もあれば、そう簡単にマッピングできない場合もあります。追跡可能なように作業を構造化する方法は常にあります。上司に戻って、プロジェクトの状態を伝える際に彼にとって何が重要かを尋ねることをお勧めします。それはあなたがやっていることにアプローチする方法を教え始めます。スケジュールであれば、進捗状況の報告に集中する必要があります。品質が良ければ、あなたが考え出さなければならない一連のメトリックについて報告したいと思うでしょう。コストがかかる場合は、おそらく努力を検討する必要があります。これらのすべては、タスクにマッピングしたり、タスクからマッピングしたりすることもできます。