web-dev-qa-db-ja.com

プログラミングプロジェクトを他の開発者のタスクに分割する方法は？

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

問題は、しかし、私がこれを行う方法の手がかりがないことです。私は週末に鉛筆と紙でそれを理解しようと費やしましたが、並行してではなく順次処理するタスクのリストを思いついています。多分それを機能に分割することを考えましたが、同じファイルを編集する必要があるタスクが発生します。開発の初期段階のため、タスク全体を完全に書き換える必要があるかもしれません。プログラムがもう少し完成してタスクを作成するのが簡単になるまで、一部の開発者を待つこともできますが、その後、何週間か知っている人に手を貸してもらいます。

私はこれを行うための資格について上司と話しましたが、私にはその選択の余地がありませんでした。私は自分が何をしているのかわからないので、正しい方向に向けたヒントや微調整をいただければ幸いです。

team-leadertask-organization
168
khm

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

  1. 基本

    • 一人で行かないでください。チームメイトをできるだけ関与させるようにしてください。
    • 軽量トラベル。
    • 民主主義、しかし多すぎない。時には、最大の人数を満足させるものではなく、最小の人数を傷つけるものについてです。
    • 何を保持する（実行する必要がある）およびどのように（実行する）個別。
    • Scrum（ "what"）、[〜＃〜] xp [〜＃〜]（Extreme Programming、 "how"）、Kanbanについて学ぶ=（「どのくらい」）、リーン（「何ではない」）およびDevOps（「誰と」）。
    • Leanも同様ですflow：全体的な効率では、通常、個々の効率よりもflowefficientが重要です。
    • Software Craftsmanship、Clean CodeおよびPragmatic Programmingについて学習します。
    • 優れたアーキテクチャとは、約行われない決定の数を最大にするです。
    • スクラム/ XP /リーン/アジャイルは約行われていない作業量の最大化：[〜＃〜] yagni [〜＃〜] =。
    • ソフトウェアの主な価値は簡単に変更できることです。それがすべきことを実行することは重要ですが、それは二次的な価値にすぎません。
    • iterativeおよびincrementalのアプローチを優先しますtime boxを使用しますホフスタッターの法則が適用されるので、ほとんどすべて、特に会議はパーキンソンの法則を友達にします。
    • コンウェイの法則およびタックマンのチーム開発の段階を理解して、チーム構造のバランスを取ります。
    • プログラミングは四元論であり、それはscience、engineering、artとcraftのすべてが同時に、そしてそれらです。バランスを取る必要があります。
    • スクラム/[〜＃〜] xp [〜＃〜]/XYZが誰か（私を含む）に適しているからといって、必ずしもあなたに適しているとは限りません/スーツあなたの環境。誇大広告を盲目的に実行するのではなく、まず理解してください。
    • Inspect and Adapt！（スクラムマントラ）
    • 重複を避ける-一度だけ！（XP Mantra）別名DRY-自分を繰り返さない別名SPOT-単一ポイント真実

  2. 「What world」の作業分解プロセス

    • 要件をユーザーストーリー/ジョブストーリーとして製品バックログに収集します。
    • ユーザー（ユーザーストーリーの）俳優（UMLの場合）ペルソナのような役割。
    • ユーザーストーリーの絞り込み彼らがチームのチームに会うまで準備の定義に基づいて[〜＃〜]投資[〜＃〜]（独立、交渉可能、価値があり、推定可能で、小さく、テスト可能です。 （スクラム会議：Backlog Refinement）
    • Product BacklogをBusiness Valueでソートします。
    • Ready Ready（readyの定義に従って準備ができている）になる前に、ストーリーの作業を開始しないでください。
    • Planning Pokerを使用してStory Pointsのストーリーの効果を見積もります。 Triangulation Comparisonを使用して、推定の一貫性を確保します。
    • 昨日の天気が最善の見積もりです。
    • Split Storiesそれらが大きすぎる場合。
    • Definition of Doneを使用して、配信文化を向上させます。
    • Done Done（Doneの定義に従って行われる）になる前に、ユーザーストーリーの実装を受け入れないでください。
    • 同じコードベースの複数のチームは、同意して同じDefinition of Done（特にCoding Standards）を共有する必要があります。
    • バーンダウンチャートで進捗状況を確認します。
    • チームが提供するものが本当に必要なものであるかどうか、関係者に定期的に確認してください。 （スクラムミーティング：スプリントレビュー）

  3. ストーリーの内訳

  4. 「どのように世界」を実現するか

上記のリストは確かに不完全であり、一部は疑わしいかもしれません！

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

関連項目

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

さらに読む（本）

  • Robert C. Martinによるクリーンコード
  • アジャイルソフトウェア開発：ロバートC.マーティンによる原則、パターン、および実践
  • 実用的なプログラマー-アンドリューハントとデビッドトーマスによるジャーニーマンからマスターへ
  • Michael Feathersによるレガシーコードの効果的な使用
  • リファクタリング-Martin Fowlerによる既存のコードのデザインの改善
  • Joshua Kerievskyによるパターンへのリファクタリング
  • スティーブンシルビガーによる10日間のMBA（sic！）
  • Eric Evansによるドメイン駆動設計
  • Mike Cohnによって適用されたユーザーストーリー
  • オブジェクト指向の分析とアプリケーション、Gray Boochらによる設計
  • 4人のギャングによるデザインパターン
  • ケントベックによるテスト駆動開発
  • ケントベックによるエクストリームプログラミング
  • [Javaの場合]有効Java Joshua Bloch作
217
Christian Hujer

アジャイルに

私は以下を提案します：

同じファイルを編集する

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

Gitなしでマルチ開発者プロジェクトを管理しようとすることは、プリンボウルなしでプリンを作成しようとすることに似ています。それは可能ですが、かなり乱雑にかなり速くなります。

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

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

次に、プロジェクトをユーザーに表示される機能に分割します。たとえば、「ユーザーがサインアップすると、メールが届きます」または「ユーザーはアイテムを追加できます」などです。ここにすべての利害関係者を巻き込みます。みんなを部屋に入れて、みんなに自分の特徴を叫んでもらいます。

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

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

必要な追加のカードを追加します。アプリケーションがSMSテキストアラートを送信するとします。その方法がわからない可能性があるため、質問があります。 "= Investigate SMS portals"と入力してください他の大きな未知のものについても同様です。これらは後で開梱する必要があります。これらの機能はおそらく最初のスプリントにはなりません。

カードをグループに分類し、シャッフルして、feelを取得します。これがプロジェクトのスコープです。

ポーカーの計画

ポーカーの計画に取り掛かります。それでも、全員で一緒に、「1ポイント」、「2ポイント」などのすべてのデベロッパーカードに「4ポイント」まで与えます。 「もっと」カードも。ポイントはおよそ1時間に相当します。

機能リストを1つずつ確認します。機能を読み上げると、誰もがカードをプレイする必要があります。 1人が1をプレイし、別の人が4をプレイする場合、そこには通信の問題があります。一人は他の人とは異なる何かを意味する機能を理解しています。話し合いをして、実際に何が意味されているのかを調べ、カードに書き留めます。

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

同意を得たら、カードの番号を別の色のペンで書きます。

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

時間の代わりにポイントを使用すると、私たちの開発者が頻繁に従事するマッチョな「コードをどれだけ高速にコーディングできるか」を取り除きます。これは微妙な違いですが、かなりうまくいくことがわかりました。

今スプリントを作成します

スプリントはゴールに向けての急なバーストです。スプリントの長さを決定します。おそらく5日か10日です。日数に1日あたりのポイント数を掛けた開発者数を掛けます。

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

収まる範囲を超えて絞ろうとしないでください。将来性がありすぎると、あなたを含め、長期的には誰もが傷つきます。

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

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

エクストラを絞るように誘惑されることはありません。見込みが高すぎると、約1日分の幸せなクライアントが得られ、続いて4日間のチームストレスが続きます。最終的には、チームが時間どおりに提供できない場合は、最終的にはいくつかの不幸なクライアントが発生します。

それに行きます。

カードを配り、誰が何をしたいのか尋ねます。あなたは何が行われているのかを完全に可視化し、ゼロに近づいていくポイントを数えることができます。誰もが何に取り組んでいるのか、そして何が行われたのかを誰もが知ることができるように、毎日の初めに立ち上がる。

明確に定義された管理可能な目標を1つのユニットとして一緒に取り組む5人または6人のやる気のある開発者は、5日間のスプリントでかなりの量を達成できます。

可視性を維持

誰もがプロジェクトのステータスを確認できるようにしてください。すべてのカードを壁にBluetackします。左側はまだ処理されていないカードです。右側はカードです。

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

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

可能であれば、プロジェクトの期間中、全員が同じ部屋にいるようにします。利害関係者をできるだけ多く、理想的には毎日配置します。

全焼

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

失敗するつもりなら、早く失敗してください。

ソフトウェアを使用してバーンダウンを作成できますが、私は壁に大きな紙を置くことを好みます。描画し、その上に書き込みます。

自動テスト

複数の開発者が同じものに同時に取り組んでいる場合、おそらくお互いのコードが壊れることがあります。コミュニケーションと可視性はこれに役立ちますが、問題の発見に役立ついくつかのテクノロジーを導入したいと思うでしょう。

単体テストは、コードベースの個々の部分（理想的には各メソッド）のテストを作成するプロセスです。単体テストは頻繁に実行する必要があり、可能であればすべて保存します。 KarmaやRspecなど、これに役立つツールはたくさんあります。

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

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

技術的負債を回避し、やり遂げる

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

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

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

35
superluminary

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

モジュールがすべて個別に機能することを保証するために、開発者にTDDを適用するようにしてください。

私が意味することの例を示すために：

開発者の1人がSQLロガーを構築するとします。

インターフェースを定義し、開発者の1人に（または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に大きく依存します。

10
z0mbi3

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

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

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

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

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

また、ケントベックの「Extreme Programming」を読むことをお勧めします。私がプロジェクトマネージャーになろうとしていたときに私を助けてくれた素晴らしい本。

10
Erez Eshkol

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

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

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

ペンと紙に関しては、すでに多くのことを行っているようですが、ガントチャートを実際に確認することは常に役に立ちます。順番に並んだタスクを見ると、「ちょっと、タスクXをタスクYの前に実行する必要がありますか？（これまでの私の経験では、答えが実際に「いいえ」である頻度に驚きました）」

2
Shaz

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

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

1
Scott Pavetti