小さなチームのプログラミングを計画する最良の方法は？
私は小さなスタートアップ組織のディレクターです。現在、Webアプリケーションプラットフォームを構築している2人のプログラマー（経験者1人、経験者1人）がいます。
これまでの最大の課題の1つは、計画プロセスです。プログラマーは通常、自分の作業の計画を担当しますが、私たちは自分で課した期限を超え続けます。たとえば、彼らが見積もるタスクには2日かかり、最終的に8日かかります。
特定のタスクの継続時間を正確に予測するための技術的なノウハウが不足しているため、私にとっては、計画を立てるのが難しいです。
何か考えはありますか：
- これの理由は何ですか、これはプログラマーにとって一般的ですか？
- それらを計画でサポートするために私は何ができますか？小さなチームのプログラマーに役立つメソッドやツールはありますか？
一般的な手法はいくぶん常識的なものですが、知っておくべき重要なことは技術的な専門知識はあまり必要ありません
計画の出発点は、解決する必要がある正確な問題を特定し、明確で明確な要件があることです。それがない場合、見積もりは不正確になります。誰かがコードを書き始める前にこれをある種の機能仕様に文書化しておくと、コーディングを開始する前に、尋ねる必要がある質問がすべて尋ねられることになります。これは驚くほど効果的な時間節約です。戻って要件を明確にすることは、プログラマーとしての流れを分断し、応答を待つことが進行を妨げることがあります。
要件を特定したら、それを解決するために必要な作業タスクを特定する必要があります。これは、古典的な分割統治の演習です。さらに分解できるタスクは、さらに分解する必要があります。
より大きなチームでは、推定ポーカーを使用して、関係する全員の経験に基づいて推定を取得できます。これは小規模なチームではうまく機能しませんが、開発者と開発者の両方から独立した見積もりを取得し、おそらく自分自身からも見積もりを含めることは有用です。具体的な専門知識の欠如は、ここで役立ちます。タスクには彼らの視点が含まれ、開発チームはおそらく問題をよりよく理解するでしょう。
小規模なチームでは、各タスクの最良/予想/最悪のケースの見積もりを取得するのに役立ち、さまざまな値が得られますが、オーバーランの見積もりが多い場合は、開発者まで最悪のケースに傾くことができますより正確に推定することを学びます。
小さな店では、開発者はしばしばシステム管理者、サポートチーム、さらにはテスターを兼任することになります（実行できることは何でも、テストはすべてのコストで回避すべきものです）。そのことを考慮する必要があります。開発者が実際に新機能の開発に費やしている時間を把握し、それを見積もりに組み込みます。タスクが2日と見積もられているが、開発者が60％の時間で新しい開発に取り組むことができる場合、タスクが完了するまでに4日必要になります。非緊急の管理タスクやサポートタスクをアドホックベースで処理するのではなく、いくらかまとめてバッチ処理できるように、処理する必要がある他のタスクのパイプラインを制御することによっても、これを支援できる場合があります。多くのプログラマー（確かに私も含めて）はすばらしいタイムマネージャーではないので、その点で手を貸すためにできることは何でも役立ちます。プログラマにとって、シングルタスクはマルチタスクよりも常に簡単です。日中の時間を遮断することもこれに役立ちます。
記録を残す-計画セッションを行うたびに、見積もりと実績を記録します。次に、これをa）計画時にどれだけ見積りを膨らませるかのガイドとして使用し、b）見積りスキルを磨くのに役立ちます。各イテレーションの終わり（または同等のもの）に、チーム全体で実行された作業を確認し、予想よりも時間がかかった理由を理解して、将来の見積もりに組み込むことができるようにする必要があります。これは非の打ちどころのない仕事である必要があります-ここでは正しい態度を持っているようですが、この答えはしばらくあるかもしれないので、観察します。誰かが「ここで間違えた」と言った場合、それを「あなたはもっと上手くできましたか」に変えることができますが、遅すぎる、または問題が発生したことを人々に伝えることは、問題を悪化させるだけです。
この種の問題に特効薬はないことは承知していますが、最大の要因はコミュニケーションです。これは実際にはチームが小さいほど簡単です。フィードバックを使用して集団スキルを磨くことができます。
[2日で8日かかると見積もられている]理由は何ですか、これはプログラマーにとって一般的ですか？
それは、
- 実際に何をすべきか明確ではないため、正しく理解するのにより多くの時間がかかります（そして、どのくらいの時間がかかるかを推測するのではなく、そう言う必要があります）。
- 彼らは目前の課題に慣れていない（そして、彼らはそれについて言及し、見積もりに調査を含める必要がある）
- 完成したタスクとより大きな製品の統合には、予想よりも時間がかかります（製品のアーキテクチャが劣っている可能性があります）。
- 開発者はホイールを再発明することを好み、そうすることで、ライブラリで自由に利用できる、他の人が解決した問題につまずきます
- タスクの実装中に製品の所有者が変更を導入するため、別のアプローチが必要で、作業をやり直す必要がある
- 開発者は生産的な環境で作業しません（したがって、自宅にいると2日かかると思いますが、仕事ではすべての注意散漫を補うために8日必要です）
いくつか例を挙げると。
おそらく、開発者に彼らの見積もりがずれていると思う理由を尋ねるのが最善でしょう。 :-)
あなたは、開発時間を計画するための最良の方法を理解しようとするロングショットの最初のものではありません。これは、一部は実際に構築されているとは見えないものを数量化することが難しいという事実と、一部は mythical man-month によるものです。プログラマーが2人いる場合は、プログラマーが1人いる場合よりも2倍速く開発できるはずです。
おそらくすでにお気づきのように、それはそれよりもはるかに複雑です。ソフトウェア開発に関連する高度な資格を持つ個人のグループを四捨五入して開発時間を見積もり、プロジェクトを完了するのにかかる時間を見積もるよう依頼します（可能な限り詳細に説明します）。あなたはすべての見積もりの中で最も高いものを取り、あなたはdoubleそれを見積もります。はい、あなたは正しく読みました。あなたdoubleが最も高い見積もりであり、合理的に正確な見積もりを行うものとします。時間が経つにつれ、私が何かをするのにどれくらい時間がかかるかを上司に正確に伝えることができたので、私は知っています。私は仲間のプログラマーと私自身のプログラマーの意見を集め、最高の見積もりを2倍にします。これが高すぎると思われる場合は、新しい機能をテストすることが重要であり、後で潜在的なバグ修正を検討することを検討してください。
プログラマーとしての私自身の個人的な経験では、プロジェクトをマイルストーンに分解するのに役立つと言えます。マイルストーン1、次にマイルストーン1からマイルストーン2、次にマイルストーン2からマイルストーン3に到達するまでにどのくらいかかりますか？このように分解すると、通常、プロジェクト全体を推定するよりもはるかに正確な答えが得られます。不思議なことに、これらすべてのマイルストーンの見積もりを合計すると、通常はプロジェクト全体の元の見積もりよりも大きくなります（とにかくプログラマーが自分に正直である場合）。ここに。
技術的なノウハウが不足している可能性がありますが、それでも、より一般的なレベルでフォローするようにしてください。プログラマーは繰り返しの問題はありません。プログラムの開発において常に占めるのは、ねじれと回転です。そのため、含める機能が多ければ多いほど、プログラムはより複雑になり、この新しい機能が以前に実装されたコードのセクションに影響を与えないと仮定すると、開発は作業量に応じて線形になります終わり。ほとんどの場合、新しい機能は大きく以前に実装されたセクションに影響を与えるため、開発には新しい機能の実装だけでなく、古いコードの修正も含まれ、開発時間は指数関数的になります。
あなたへの私のアドバイスは、プログラマーに彼らの仕事をする方法を告げることなく、プログラムが一般的なレベルでどのように機能するかを理解しようとすることです、そしてあなたはすぐに新しい機能がその振る舞いをどのように変更し、こうして提供するかを見ることができるはずですそれを行うのにかかる時間の合理的な見積もり。これを見積もり（最高の2倍）と組み合わせると、開発時間を見積もる方法についてより良いアイデアが得られます。
お役に立てば幸いです。
概算がずれることが多い理由の1つは、概算が実際には非常に困難であり、システムについての経験と知識を変更する必要があるためです。ほとんどの場合、大きなステップを小さなステップに分割すると役立ちます。
今あなたは私が2つ言及するそれらの多くの可能性を持っています：
ポーカーの計画
これは小さなアジャイルチームで非常にうまく機能します。
ウィキペディアからの抜粋：
- プレーしないモデレーターが会議の議長を務めます。
- プロダクトマネージャーは短い概要を提供します。チームは、質問をしたり、仮定やリスクを明確にするために議論したりする機会が与えられます。ディスカッションの概要はプロジェクトマネージャーによって記録されます。
- 一人一人が自分の見積もりを表すカードを裏向きに置きます。使用される単位は異なります-それらは、日数の期間、理想的な日、またはストーリーポイントです。話し合いの際、アンカーを回避するために、フィーチャのサイズに関連して数字をまったく言及しないでください。
- 誰もがそれらをひっくり返して同時にカードを呼び出す。
- 見積もりが高い人や見積もりが低い人には石けん箱が渡され、見積もりの正当性が示されます。その後、議論が続けられます。
- コンセンサスに達するまで推定プロセスを繰り返します。成果物を所有する可能性が高い開発者は、「コンセンサス投票」の大部分を占めますが、モデレーターはコンセンサスを交渉できます。
- 卵のタイマーは、議論が構造化されていることを確認するために使用されます。モデレーターまたはプロジェクトマネージャーはいつでも卵のタイマーを入れ替えることができ、時間切れになるとすべてのディスカッションが終了し、別のポーカーラウンドがプレイされます。会話の構造は、石鹸箱によって再導入されています。
ここで重要なのは、明確化、議論、同時に見積もりを呼び出すことで、バイアスが導入されないため、コンセンサスです。
PERT
1つの正確な見積もりを出すことはしばしば困難です。簡単なのは可能性を与えることです。 PERTは、推定に3つの値を使用します。
- 終了までの最も楽観的な時間（予想よりも問題が少ない場合）
- 終了するまでの最も悲観的な時間（すべてがうまくいかない場合-大災害を除く）
- 終了する可能性が最も高い（すべてが期待どおりに進んだ場合）<-これは、開発者が現時点で推定する可能性が最も高いものです
これらの3つの見積もりに重みを付けることで、より信頼できる見積もりが得られます。
t_expected = (t_opt + 4 * t_likely + t_pes) / 6
また、これらの3つの値を使用して、現実世界の不確実性をさらに反映する可能性のある確率分布を構築できます。 ベータ分布 と 三角分布 が目立つ選択肢です。これを使用して、「現在の推定値を与えられた日付xに終了する可能性」または「95％の確実性が必要な場合、どの時点で終了するか」などの統計を適用できます。
実際、PERTはここで説明した以上の側面で構成されていますが、簡潔にするために省略しました。
履歴メトリックを保持していない場合、妥当な精度で妥当な見積もりを出すことすらできません。また、他の会社/人にどれくらいの時間がかかるか尋ねても、助けにはなりません。問題は、各企業と開発者が独自の方法を持っていることです。したがって、まったく同じタスクを実行するために、会社によって時間の長さが異なります。まったく同じタスクを実行するために、開発者ごとに時間の長さが異なります。
あなたの最善の行動は、時間の追跡を開始し、どういうわけかタスクの難易度を分類する方法を理解することです。一部の企業はコード行を使用し、一部は機能を使用し、一部は直感的に進んでいます。さらに、これが開発者が既に構築したもの、または新しいテクノロジー、チームによってこれまでに構築されたことのない新しい機能などの何か新しいものに類似している場合も考慮する必要があります。時間システムの場合、一般に複雑さがかなり高くなります。
実際のデータを収集しない限り、開発者が何回見積もっても、あなたが尋ねるたびに実際に背後から数値を引き出しているだけです。はい、実際のデータを収集するのは面倒であり、最初は多くの有用な情報を提供しませんが、時間の経過とともに、かなり正確な見積もりを提供し始めます。
また、概算は概して全体像に対してのみ良好であり、短期的な測定値に対してではないことも指摘しておきます。たとえば、開発者は2日と見積もっていますが、8日かかります。まあ、開発者はテスト環境をセットアップしてシミュレーターを開発する必要がなかったか、まったく新しい技術を習得しなければならないか、バグに悩まされました。彼らは理解できなかったか、機能性が既存のシステムのリファクタリングを必要としました。小さなタスクでは、このようなことを常に予測できるわけではありません。ただし、プロジェクト全体で、これらの余分な6日間は、6日間少ない他のタスクによって洗い流される可能性があります。
私は自分自身のいくつかの小さなプロジェクトの唯一の開発者であり、大規模なチームとの共同作業についてある程度の経験があります。大企業が使用している手法は、必ずしも小さなチームではうまく機能しないことに気づきました。ある時点で、コードを書くのではなく、より多くの計画と文書化を行っていました。さまざまなテクニック（他の回答はいくつかの優れた洞察を提供します）とツールを試すことによって、最初に良い作業方法を見つけようとすることをお勧めします。これは、ある程度の時間と労力を要しますが、後でそれから利益を得ます。私が役立つとわかったいくつかのツール/テクニックは次のとおりです。
-Pivotal Tracker-ストーリーを追跡するための優れたプログラムであり、タスクの分解を促進します-ストーリーの入力が迅速になり、速度を自動的に推定します。 https://www.pivotaltracker.com/ 。
-複数のユーザーが同時に編集およびディスカッションを行うことが容易なため、ドキュメント用のGdocs。
-私が以前働いていた会社では、私たちが開始したすべてのストーリーについてミーティングがありました。このミーティングには、タスクにかかる時間を判断するのが得意なので、上級プログラマーを含める必要がありました。彼はまた、課題の難しい部分を判断するのに優れています。
要約すると、小さなチームで作業するための鍵は、迅速かつ流動的なしっかりとした計画体制を持つことだと思います。また、ストーリーの難しさを早期に特定して、タスクの計画でそれを覚えておくことができます（これにより、何かが異なるものになる可能性があります）。
お役に立てれば