小さなチームのプログラミングを計画する最良の方法は？[閉まっている]

私は小さなスタートアップ組織のディレクターです。現在、Webアプリケーションプラットフォームを構築している2人のプログラマ（1人は経験豊富、もう1人は経験不足）がいます。

これまでの最大の課題の1つは、計画プロセスです。プログラマーは通常、自分の仕事の計画を担当しますが、私たちは自分で決めた期限を超過し続けます。たとえば、彼らが見積もったタスクは2日かかり、8日かかります。

特定のタスクがどれくらい続くかを正確に推定するための技術的なノウハウが不足しているため、私にとって計画を支援することは困難です。

あなたは何か考えがありますか：

1. これの理由は何ですか、これはプログラマーに一般的ですか？
2. 計画を立てるために私ができることは何ですか？小さなチームのプログラマーに役立つ方法やツールはありますか？

一般的なテクニックはやや常識的であり、知っておくべき重要なことは、技術的な専門知識をあまり必要としないということです。

計画の出発点は、解決する必要がある正確な問題を特定し、明確で明確な要件を持つことです。それがない場合、見積もりは不正確になります。誰かがコードの記述を開始する前に、何らかの機能仕様でこれを文書化するということは、コーディングを開始する前に、尋ねる必要がある質問はすべて尋ねられることを意味します。これは驚くほど効果的な時間節約です。前に戻って要件を明確にすると、プログラマーとしての流れが崩れ、応答を待つと進行がブロックされる可能性があります。

要件を特定したら、その解決に関係する作業タスクを特定する必要があります。これは古典的な分割統治演習です。さらに分解できるタスクは、さらに分解する必要があります。

大規模なチームでは、推定ポーカーを使用して、関係者全員の経験に基づいて推定値を取得できます。小規模なチームではうまくいきませんが、開発者と開発者の両方から独立した見積もりを取得し、自分自身からの見積もりを含めることも有用です。ここでは、特定の専門知識の欠如が、タスクには彼らの観点から関係するので、開発チームはおそらく問題をよりよく把握するでしょう。

小規模なチームでは、各タスクのベスト/予想/最悪のケースの推定値を取得するのに役立ちます。これにより、さまざまな値が得られますが、オーバーランの推定値を多く取得している場合は、開発者まで最悪のケースに向かって傾斜させることができますより正確に推定することを学ぶ。

小さなショップでは、開発者はしばしばシステム管理者、サポートチーム、さらにはテスター（彼らができることはすべてですが、テストはあなたがすべてのコストで回避しようとするべきものです）を兼ね備えることになります。開発者が実際に新機能の開発に費やす時間を把握し、それを見積もりに反映します。タスクが2日と見積もられているが、開発者が60％の時間しか新しい開発に取り組むことができない場合、そのタスクを完了するには4日が必要になります。緊急の管理タスクまたはサポートタスクをアドホックベースで処理するのではなく、ある程度まとめてバッチ処理できるように、処理する必要がある他のタスクのパイプラインを制御することで、これを支援できる場合があります。多くのプログラマー（確かに私自身もこれに参加しています）は素晴らしい時間管理者ではありません。その点で手を貸すためにできることは何でも役立ちます。シングルタスクは、マルチタスクよりもプログラマにとって常に簡単です。日中の時間をブロックすることもこれに役立ちます。

記録を残す -計画セッションがあるたびに、推定値と実績値を記録します。次に、これをa）計画中に見積もりをどれだけ膨らませるかのガイドとして使用し、b）見積もりスキルを磨くのに役立ちます。各反復の終了時（または同等のもの）に、チーム全体が行った作業をレビューし、予想よりも長くかかった理由を把握して、将来の見積もりに組み込むことができるようにする必要があります。これは非難されない仕事である必要があります-あなたはここで正しい態度を持っているようですが、この答えはしばらくの間であるかもしれないので、私は観察をします。誰かが「ここで間違えた」と言うと、それを「もっとうまくできたはず」に変えることができます。

この種の問題に特効薬はないことは承知していますが、最大の要因はコミュニケーションです。これは実際には小規模なチームで簡単になり、フィードバックを使用して集合的なスキルを磨くことができます。

[2日間で8日間かかると見積もられている]理由は何ですか、これはプログラマーによくあることですか？

次の場合：

• 実際に彼らが何をすべきか明確ではないので、彼らはそれを正しくするためにより多くの時間をかけます
• 彼らは目の前のタスクに慣れていない（それから彼らはそれについて言及し、見積もりに研究を含めるべきである）
• 完了したタスクと大きな製品との統合に、予想よりも長い時間がかかります（製品のアーキテクチャが劣ることを意味する場合があります）
• 開発者は車輪を再発明するのが好きです、そして、そうすることは他の人によって解決された問題でつまずきます。そして、それはライブラリで自由に利用可能です
• タスクの実装中に製品所有者によって変更が導入され、異なるアプローチと作業のやり直しが必要になります
• 開発者は生産的な環境で作業しません（したがって、自宅では2日かかると思いますが、作業中はすべての注意散漫を補うために8つ必要です）

いくつかのことを挙げます。

おそらく、開発者に見積もりがまちがっていると思う理由を尋ねるのが最善でしょう。:-)

開発時間を計画するための最良の方法を見つけようとするのは、長い目で見れば最初ではありません。これは、一部に起因して、あなたが実際に建設されて見ることができない何かを定量化することは困難であるという事実に一部である人月の神話直感的な考え方は正反対である、あなたは2人のプログラマーを持っている場合、あなたがすべきことプログラマが1人いる場合の2倍の速さで開発できます。

おそらくすでに気付いているように、それはそれよりもはるかに複雑です。開発時間を見積もるための1つのアプローチは、ソフトウェア開発に関係する有能な個人のグループをまとめ、プロジェクトを完了するのにかかる時間を見積もるように依頼します（可能な限り詳細に説明します）。すべての推定値の中で最も高い値を取り、それを2倍にします。はい、正しく読みます。あなたダブル最も高い見積もりであり、合理的に正確な見積もりが必要です。時間が経つにつれて、これが私が上司に何かをするのにどれくらい時間がかかるかを正確に伝えることができた方法だからです。私は仲間のプログラマーと私自身の意見を集め、最高の見積もりを倍にします。これが高すぎると思われる場合は、新しい機能をテストすることが重要であることを考慮し、その後の潜在的なバグ修正を検討してください。

プログラマーとしての私個人の経験では、プロジェクトをマイルストーンに分解するのに役立つと言えます。マイルストーン1に到達し、マイルストーン1からマイルストーン2に到達し、マイルストーン2からマイルストン3に到達するまでにどのくらい時間がかかりますか？このように分類すると、答えは通常、プロジェクト全体を全体的に推定しようとするよりもはるかに正確です。奇妙なことに、これらのすべてのマイルストーンの推定値を合計すると、通常はプロジェクト全体の元の推定値よりも大きくなります（プログラマーがとにかく自分自身に正直である場合）。ここに。

おそらく技術的なノウハウが不足しているかもしれませんが、より一般的なレベルでフォローするようにしてください。プログラマは繰り返しに問題はありません。プログラムの開発で常に占めるのは、twist余曲折です。そのため、含める機能が多ければ多いほど、プログラムはより複雑になり、この新しい機能が以前に実装されたコードのセクションに影響を与えないと仮定すると、開発は作業量に応じて線形になります。終わり。おそらく、新しい機能は以前に実装されたセクションに大きな影響を与えるため、開発には新しい機能の実装だけでなく、古いコードの修正が含まれ、開発時間が指数関数的になります。

あなたに私のアドバイスは、プログラマーに仕事のやり方を教えることなく、プログラムが一般的なレベルでどのように動作するかを把握しようとすることです。すぐに新しい機能がその動作を変更し、したがって提供する方法を見ることができるはずですそれにかかる時間の合理的な見積もり。これと見積もり（最高の2倍）を組み合わせると、開発時間を見積もる方法についてより良いアイデアを得ることができます。

それがお役に立てば幸いです！

見積もりが実際にはかなり遅れる理由の1つは、見積もりが実際には非常に難しく、変更するシステムに関する経験と知識が必要なためです。多くの場合、大きなステップを小さなステップに分割すると役立ちます。

今、あなたはそれらの多くの可能性を持っています。

• プランニングポーカー
• PERT（プログラム評価およびレビュー手法）

プランニングポーカー

これは小さなアジャイルチームで非常にうまく機能します。

ウィキペディアからの抜粋：

• プレーしないモデレーターが会議の議長を務めます。
• プロダクトマネージャーは、簡単な概要を提供します。チームには、質問をしたり、話し合いを行って仮定やリスクを明確にする機会が与えられます。ディスカッションの概要はプロジェクトマネージャーによって記録されます。
• 各個人は、自分の見積もりを表すカードを伏せて置きます。使用される単位は異なります-期間は日数、理想的な日数、またはストーリーポイントです。議論中、アンカーを回避するために、フィーチャーのサイズに関連して数値をまったく言及してはなりません。
• カードを裏返すことで、全員が同時にカードを呼び出します。
• 見積もりが高い人と見積もりが低い人には、見積もりの​​正当性を示すために石鹸箱が渡され、その後議論が続けられます。
• 合意に達するまで推定プロセスを繰り返します。モデレーターがコンセンサスを交渉することはできますが、成果物を所有する可能性が高い開発者は、「コンセンサス投票」の大部分を持ちます。
• エッグタイマーを使用して、ディスカッションが構造化されていることを確認します。モデレーターまたはプロジェクトマネージャーは、いつでもエッグタイマーを引き継ぐことができます。エッグタイマーがなくなると、すべてのディスカッションが終了し、ポーカーの別のラウンドがプレイされます。会話の構造は、石鹸箱によって再導入されます。

ここでの重要な部分は、明確化、議論、バイアスを導入しないための推定値の同時呼び出し、およびコンセンサスです。

パート

1つの正確な見積もりを出すのは難しい場合がよくあります。より簡単なのは、可能性を与えることです。PERTは推定に3つの値を使用します。

• 終了までの最も楽観的な時間（予想よりも問題が少ない場合）
• 終了までの最も悲観的な時間（すべてがうまくいかない場合-大災害を除く）
• 終了する可能性が最も高い時間（すべてが予想どおりに進む場合）<-これは、開発者が現時点で推定する可能性が最も高い時間です

これらの3つの推定値に重みを付けると、より信頼性の高い推定値が得られます。

t_expected = (t_opt + 4 * t_likely + t_pes) / 6

そして/または、これら3つの値を使用して、現実世界の不確実性をさらに反映する確率分布を構築することができます。ベータ分布と三角分布は顕著な選択肢です。これを使用して、「現在の推定値が与えられた日付xで終了する可能性」または「95％の確実性が必要な場合、どの時点で終了するか」などの統計を適用できます。

実際には、PERTはここで説明したこれらの側面よりも多く構成されているため、簡潔にするために省略しました。

履歴メトリックを保持していない場合、合理的な精度で合理的な推定値を提供することさえできないという事実です。そして、他の会社/人にどれくらいかかるかを尋ねても、助けにはなりません。問題は、各企業と開発者が独自の方法を持っていることです。したがって、すべての企業は、まったく同じタスクを実行するための時間の長さが異なります。開発者ごとに、まったく同じタスクを実行するための時間の長さが異なります。

あなたの最善の行動は、時間の追跡を開始し、何らかの方法でタスクの難易度を分類する方法を見つけ出すことです。コード行を使用している会社もあれば、機能を使用している会社もあります。さらに、これが開発者がすでに構築したものや、新しい技術、チームが以前に構築したことのない新機能などに似ている場合も考慮する必要があります。時間システムは一般的にかなり複雑になります。

実際のデータを収集しない限り、開発者が何回見積もっても、実際にあなたが尋ねるたびに彼らは後ろから数字を引いているだけです。はい、実際のデータの収集は苦痛であり、最初は多くの有用な情報を提供しませんが、時間が経つにつれて、かなり正確な推定値を提供し始めます。

また、概算は一般的に全体像に対してのみ有効であり、短期間の測定には適していないことを指摘したいと思います。たとえば、開発者は2日と見積もっていますが、8日かかります。まあ、開発者はテスト環境をセットアップしてシミュレーターを開発しなければならないことや、習得しなければならないまったく新しい技術やバグで立ち往生したことを考慮していませんでした彼らは理解できなかったか、機能が既存のシステムのリファクタリングを必要としていました。小規模なタスクについて、こうした種類のことを常に予測できるとは限りません。ただし、プロジェクト全体を通して、6日間は他のタスクによって6日間短縮されるため、余分な6日間は洗い流される可能性があります。

私はいくつかの小さなプロジェクトで独力で開発者として働いており、大規模なチームで働いた経験があります。大企業が使用している手法は、小さなチームには必ずしも機能しないことに気付きました。ある時点で、コードを書くのではなく、より多くの計画とドキュメントを作成していました。さまざまなテクニック（他の回答からも優れた洞察が得られます）やツールを試して、最初に適切な作業方法を見つけようとすることをお勧めします。これにより、時間と労力がかかりますが、後でそれを活用できます。便利だとわかったツール/テクニックは次のとおりです。

-Pivotal Tracker-ストーリーを追跡し、ブレークダウンを促進するための優れたプログラム-ストーリーの入力を迅速に軽減し、速度を自動的に推測します。https://www.pivotaltracker.com/。

-ドキュメントのGdocs。複数のユーザーが同時に編集および議論するのは簡単です。

-私が以前働いていた会社で、私たちが始めたすべてのストーリーについてミーティングを開催していましたが、このミーティングには上級プログラマーが含まれていなければなりませんでした。彼はまた、タスクで難しい部分が何であるかを判断するのに優れています。

要約すると、小規模なチームで働くための鍵は、迅速で流動的な堅実な計画体制を持つことだと思います。また、タスクの計画がそのことを念頭に置いておくために、ストーリーの問題を早期に特定することができます（これにより、何か異なる構築が行われる可能性があります）。

お役に立てれば