記事では秘密を明かしませんし、特効薬もありません。 また、私は開発プロセスについて深くて質の高い知識を持っているふりはしませんが、自分で適用する最も簡単なアプローチの1つを説明します。 ここでは、経験豊富なプロジェクトマネージャーが知っているシンプルで基本的な事項について説明します。 この記事は、主にポーランド共和国の初心者、チームリーダー、およびこれらの投稿を組み合わせる人を対象としています。 ただし、複雑なアクティビティには役立ちます。
自転車
だから、Vasyaは普通のプログラマー、一流のプログラマーとして長い間働いて、ついにヘッドになりました。 彼には2人の
Vasyaが最初の注文を受け取りました-私たちはしなければなりません...自転車。
残念ながら、完成した自転車は高価であるか、いくつかの理由で顧客に適していないかのいずれかです。 ヴァシャは、自転車を作るのが大好きで、自転車を使うことができると考え、開発を喜んで引き受けます。 Vasyaは初心者ですが、すでにリーダーであり、自転車をよりシンプルにする必要があることを理解しています。 条件、契約、予算、および商業組織の意思決定の基礎となる他のすべてについて覚えています。 物思いにふける顔をして、1分間黙っていたので、彼は顧客に少なくとも1か月かかると答えました。 「タスクは複雑で非標準です。」 仕事が2週間そこにあったと自分自身に考えましたが、合理的に2倍になりました。 ヴァシャはまだ用心深い男でした。
彼はチームを集めてタスクを発表します。自転車を作ります。 熱意を持って男たちを立ち上げ、みんなから素晴らしいアイデアを聞き、彼は一般的な精神に触発され、シンプルで論理的な決定を下します。他の添付ファイルを扱います。 私たちはコーヒーを飲み、自転車を顔全体、横顔、セクションごとに描き、マーカーでホワイトボードにコードを書きました。
少し前に進むと、プロジェクトが失敗の危機にonしており、チームの士気が落ちており、自転車がすでに乗っているにもかかわらず、近くにあり、しばしば倒れることがわかります。 そうでなければできませんでした。 どうしたの？
簡単な年表
0日目
スタート。 インスピレーションと創造性とロッド。
3日目
Seryoga：ボブ、車輪の準備はほぼ整いました。マイナーな改善があります。 試着するフレームはいつありますか？
Vasya：私はここで顧客と相談しましたが、今はすくい上げて仕上げます。 そして、あなたが、だまされないように、ゴムなどを選択します。 要するに、何か有用なものに注意してください。
6日目
Petya：Vasya、私はベルとバックミラーを作りました。 しかし、試着するにはハンドルが必要です。
Vasya：ホイールですか？ 地獄 ハンドルについては考えませんでした。 さて、それはただガムのついた棒です、それを切ります。 それから私達はそれをもっとまともにします。
しかし、しばらく待って、忙しくなって...研究に耐えてください！ そして、ペダルでチェーンをやってみましょう、彼らは優先順位です。
10日目
Vasya：Seryoga、これがあなたのフレーム、Petyaのハンドルです。 ふう。
13日目
Seryoga：Vasya、しかし折りたたみ式フレームはどうですか？ そして、なぜマウントが間違った側にあるのですか？ 前輪がフィットし、後部がキャッチします。
Petya：Vasya、もちろんベルを引っ掛けましたが、ハンドル付きのファイルを見る必要があり、ミラーがハングしました。
Vasya：みんな、フレームに収まるようにファイルを提出しますが、すべてがうまくいくように少し仕上げます。
（このプロジェクトで初めてVasyaは真夜中まで起きました）
20日目
デモバイクのデモ。 彼は転倒し、後ろにしか乗らず、サドルを持っていませんが、前輪は後輪よりも大きくなっています。 Vasyaは、問題があることを顧客に納得させますが、すぐにすべてが解決します。
30日目
フレームと前輪の完全な再設計の後、自転車はより良く見えます。 また、緊急モードでは、古いサドルを固定することができました。 しかし、それでも壊滅的に不安定であるため、アタッチメントをチェーンとペダルに減らす必要があり、美しいパッケージング（仕様の最後のアイテム）については誰も考えていませんでした。 Vasyaは、お客様、取締役、およびその他の認定された人物によって容赦なく相談されます。 チームは士気を失っています。
スタート。 インスピレーションと創造性とロッド。
3日目
Seryoga：ボブ、車輪の準備はほぼ整いました。マイナーな改善があります。 試着するフレームはいつありますか？
Vasya：私はここで顧客と相談しましたが、今はすくい上げて仕上げます。 そして、あなたが、だまされないように、ゴムなどを選択します。 要するに、何か有用なものに注意してください。
6日目
Petya：Vasya、私はベルとバックミラーを作りました。 しかし、試着するにはハンドルが必要です。
Vasya：ホイールですか？ 地獄 ハンドルについては考えませんでした。 さて、それはただガムのついた棒です、それを切ります。 それから私達はそれをもっとまともにします。
しかし、しばらく待って、忙しくなって...研究に耐えてください！ そして、ペダルでチェーンをやってみましょう、彼らは優先順位です。
10日目
Vasya：Seryoga、これがあなたのフレーム、Petyaのハンドルです。 ふう。
13日目
Seryoga：Vasya、しかし折りたたみ式フレームはどうですか？ そして、なぜマウントが間違った側にあるのですか？ 前輪がフィットし、後部がキャッチします。
Petya：Vasya、もちろんベルを引っ掛けましたが、ハンドル付きのファイルを見る必要があり、ミラーがハングしました。
Vasya：みんな、フレームに収まるようにファイルを提出しますが、すべてがうまくいくように少し仕上げます。
（このプロジェクトで初めてVasyaは真夜中まで起きました）
20日目
デモバイクのデモ。 彼は転倒し、後ろにしか乗らず、サドルを持っていませんが、前輪は後輪よりも大きくなっています。 Vasyaは、問題があることを顧客に納得させますが、すぐにすべてが解決します。
30日目
フレームと前輪の完全な再設計の後、自転車はより良く見えます。 また、緊急モードでは、古いサドルを固定することができました。 しかし、それでも壊滅的に不安定であるため、アタッチメントをチェーンとペダルに減らす必要があり、美しいパッケージング（仕様の最後のアイテム）については誰も考えていませんでした。 Vasyaは、お客様、取締役、およびその他の認定された人物によって容赦なく相談されます。 チームは士気を失っています。
栄光の開発者をしばらく置いて、彼らに何が起こったのかを横から見てみましょう。 このストーリーでは、多くの明らかな間違いを見ることができますが、それらのほとんどは、開発が始まる前であっても、非常に最初の段階でVasilyが犯した主な間違いの結果です。 彼が主にマネージャーであり、プログラマーではないことを簡単に忘れていました。
どうする？
1.自転車を設計します。
2.作業とリソースを計画します。
3.顧客に日付を伝えます。
4.自転車を作ります。
明らかに、これらの点に秘密はありません。 それらは理解可能で論理的です。 しかし、Vasyaは最初にポイント3を実行し、ポイント2で得点し、結果が判明しました。 この記事では設計については説明しませんが、最も単純なケース（自転車）では、これは問題の通常の分解です。 このVasyaは、パラグラフ2とは異なり、チームとともに実行しました。
作業計画
開発チームとマルチスレッドアプリケーションの類似点を考えてみましょう。開発者は、ソフトウェアスレッドと同様に、他のスレッドと同期する必要がない方がうまく機能します。 そして、彼は始めるために十分な入力を必要とします。 リーダーの仕事は、問題を解決するための最も効果的な一連の段階を構築するために、利用可能なリソースに関する作業を適切に並列化することです。
問題の最も単純な分解を実行します。
ストーリーからわかるように、完成したフレームがないため、チームには常に問題がありました。 したがって、最初にフレームを作成してから、残りを実行する必要がありました。
しかし、Vasyaがフレームを作成する間、SeryogaとPetyaは何をしますか？ 休息は確かに良いですが、この場合はそうではありません。 最初にフレームを描いて、寸法を完全に同意してみませんか？ 必要なサイズがあれば、SergeとPetyaはそれぞれのタスクを実行できます。 ところで、梱包作業があります。 それは他のすべてとあまり結びついておらず、サイズがわかっているのですぐに起動できます。 したがって、私たちではすべてがサイズに反します。 フレームの寸法を設計するタスクを選び出し、何が起こるかを見てみましょう。
ご覧のとおり、タスクは最も困難な段階で最大4つのスレッドを並列化することができました。 自転車の話では、重要なタスクはフレームのサイズ（インタラクションインターフェイスのアナログ）でした。 通常、インターフェイスは最初に解決する必要がある最も重要なタスクですが、常にではありません。 問題を慎重に分析し、この重要なポイントを特定することが重要です。 これが5分間の最も単純なタスクであることがあります。
リソースとタイムライン
利用可能なリソースに結果の開発計画を課してみましょう：
よく知られた人気のある計画ツールであるネットワークダイアグラムのオプションの1つを入手しました。
誰がいつ何をするかが明確になりました。 Vasyaの開発負荷は最も小さく、これは偶然ではありません。 他のリーダーと同様に、彼には多くの管理作業があり、十分な時間を残すべきです。
この例では、最も単純な分解のみが実行されます。 ソリューションを意図的に簡素化することにより、興味のある読者であれば誰でも自転車の開発をより良く計画できると期待しています。 タスクをより小さなステージに拡張することにより、利用可能なリソースをより効率的に使用できるようになり、次に期限の推定の精度が向上します。 自転車をどれだけ作るかを言うのは難しいです。 しかし、タイヤにホイールを引っ張るなど、どれくらいの時間がかかるかを答えるのははるかに簡単です-煙の休憩で10分。 自転車全体の作成期間を見積もると、桁違いに簡単に間違えられる可能性があります。 単純で明白なステップの推定値を持っているので、2倍以上間違っている可能性は低いです。 したがって、2つを乗算する必要があります。
一方で、これに数日間座っていないように、ステージへの分割をより深く掘り下げることも必要です。 入力条件が明確に定義されている場合、各ステージが1つの実行ユニット（開発者）によって実行される個別のタスクになるまで、タスクを分解する必要があります。 ダウンタイムを回避するために多数のパフォーマーがいる場合は、さらに深く分割することは理にかなっています。
チームリーダーまたはプロジェクトマネージャーになって、主なタスクが開発プロセスの管理であることを忘れないでください。 コードの作成に直接参加できますが、チームが失敗した場合は、フックに取り組んで穴を塞ぐ、残りのベースで。 または、エグゼキュータによるプロセスの分離が始まる最も重要な段階を迅速かつ定性的に実行します。
管理は魔法、直観、または神の贈り物ではありません。 これは、体系化と最適化に関する骨の折れる体系的な作業です。
PS： 図を含む記事は、実験のために完全にGoogleドキュメントで作成されています。 それが判明したように、便利なこと！