shipping - ソフトウェアを時間どおりに出荷するためのベストプラクティス

Question

フィーチャークリープの問題がなく、意欲的で安定したチームがあり、解決すべき明確に定義された問題があり、プロジェクトに関連するドメイン/言語/ツールを知っていると想像してください。

どのようにスケジュールを守り、その1.0マイルストーンを達成しますか？反復出荷
へのあなたのアプローチは何ですか？

特に、コミュニケーションの問題がほとんどまたはほとんどない小規模なチーム向けの推奨事項があります。

score 19 · Accepted Answer

実装タスクではなく機能に焦点を合わせます。
反復して作業します（毎週または隔週など）。
優先順位の高い順に、作業機能をステージング環境にリリースします。
コードを単体テストするときに、リリース日に近づくにつれて幾何学的に増加するバグリストによって速度が低下することはありません。
重要度の低い機能からスコープを切り取る準備をしてください。スタッフはいつもあなたが思っているよりも時間がかかります。
必ず事前にUIをスケッチして（UIがある場合）、潜在的なユーザーに見せてください。
テスト、テスト、そしてさらにテストします。これは直感に反しているように見えますが、時間がかかるよりも多くの時間を節約できます。

score 5 · Accepted Answer

それはおそらくユートピアのシナリオです;-)。とにかく、機能のクリープがなく、非常に優れたチームがあり、明確に定義された要件があり、コミュニケーションの問題がまったくない場合、おそらく製品を予定どおりに提供する最善の方法は

現在のステータスを評価するためのチームとの毎週のミーティング (PM がある場合は、チームとの PM)
チームリーダーは、チームメンバーと毎日小規模なミーティングを行い、委任された問題/要件に関するステータスを評価することができます。問題がある場合は、問題を解決するために必要な措置を講じる必要があります。
プロジェクト計画の追跡と作業の委任 (チームリーダーは、作業を適切に委任するために、各チームメンバーの個々の強みを知る必要があります)。
テストは、テクノロジーが許す範囲で自動化できます。
各チームメンバーによる作業の所有権。

結局のところ、それは人が自分の仕事に対してどれほど情熱的であるかにかかっています。

ちょうど私の 2 パイズ;-)

score 4 · Accepted Answer

質問: 大規模なソフトウェアプロジェクトが 1 年遅れるのはなぜですか? 答え: 一日ずつ！

それはあなたの質問に対する答えにはなりませんが、スケジュールに固執する必要があることを示していると思います.1日でも遅れたら、どうにかして追いつく必要があります. (残念ながら、The Mythical Man Month の残りの部分は、ほとんどのプロジェクトで「何とか」がないことについてです...)

また、FogBugzなどの製品のエビデンスベースのスケジューリングもご覧ください。これにより、製品が出荷される可能性が高い時期の最新の見積もりが得られます。実際には、日付ごとの確率とともに、日付の範囲が示されます。予定されているリリース日が期限を過ぎている場合は、それについて何かをする必要があることを知らせてくれます。うまくいけば、効果が現れるまで十分な時間が必要です。

score 3 · Accepted Answer

このスレッドにはたくさんの良いアドバイスがあります。私が追加しなければならない唯一のことは、リリースの定期的なスケジュールを採用することです。私の会社は数年前にこれに切り替えて、最初は苦痛でしたが、多くの利点があります。最大の利点は、機能を簡単に延期できることです。

機能が次のリリースに組み込まれる可能性があり、そのリリースがいつになるかがわかっているため、機能を延期しても問題ありません。これは、土壇場で中途半端な機能を急いで導入するのではなく、もう少し長く費やして、次のリリースの開始時に導入できることを意味します。

score 3 · Accepted Answer

販売/マーケティング/管理からの不合理なタイムラインを除けば、プロジェクトが予定どおりに出荷されない理由はほとんど除外されています。ソフトウェア開発方法論の歴史は、回避する方法、影響を軽減する方法、および/または回避する方法のコレクションです。

スコープの定義が不十分
特徴クリープ
ドメイン知識の欠如
コミュニケーションに問題がある大規模なチーム
やる気のない/無能な開発者

score 3 · Accepted Answer

以前のポスターで見逃していた小さな点が 1 つあります。締め切りに間に合わせるには、まず現実的なスケジュールを定義する必要があります。プロジェクトは、プロジェクトのサイズにもよりますが、小さなタスクに分割する必要がありますが、私の世界では、プロジェクトに 3 ～ 4 か月かかるため、最大 2 ～ 3 日のタスクに分割しようとしています。このようにして、時間の見積もりはほとんど現実的になり、リスクは事前に計算され、提案されたスケジュールに追加されます。

score 2 · Accepted Answer

クライアントにとってミッションクリティカルな機能とは何かを理解します。それらの進行状況を保護します。多くの場合、成功の 80% は 20% の作業からもたらされるというのは非常に真実です。

score 1 · Accepted Answer

製品チームのために、現在承認されているビルドを使用して、定期的 (毎月? 毎週?) に製品のウォークスルーを行います。できるだけ早くこれらを開始してください。現在の使いやすさに関係なく、すべての機能をデモします。遅れているものをスキップしないでください。

重要なのは、プロジェクトの過程で、利害関係者に製品の現在の状態を明確に伝えることです。このようにして、意思決定者は、出荷日を危険にさらすのではなく、スケジュールのリスクに迅速に取り組む可能性が高くなります。

score 1 · Accepted Answer

機能セットまたは出荷日のいずれかを選択できますが、両方を選択することはできません。

- 楽観的にならないでください - 最初に難しい部分を実行してください - スケジュールを遅らせることなく機能を追加しないでください - スケジュールに間に合うようにドロップできるような方法で機能を記述してください

http://shipcamp.com

shipping - ソフトウェアを時間どおりに出荷するためのベストプラクティス

9 に答える 9

Related

Reference