プロジェクト参加者の目的
顧客の目標は、割り当てられたリソース（一時的、財務的、人的）内でプロジェクトを完了することです。 時間給制では、監視対象のリソースの数は1つ（工数）に削減され、制御のためのパラメーターが少なくなり、制御が向上します。
開発者の目標は、収益を増やしてプロフェッショナリズムを向上させることです（費やす時間と結果として、より多くのお金を稼ぐ）。 開発者には、より多く稼ぐための2つの方法があります-より多くの仕事（より多くの時間）とより良い仕事（より効率的で、1時間あたりの賃金が高い）。 時間を無限に増やすことはできませんが、無駄に費やす時間を減らすことはできます。 そして、これを行う最も簡単な方法は、そもそも時間を費やすために必要なもの、つまり顧客リソースを節約する方法を学ぶことです。
これらの目標は、さまざまな主題分野（ソフトウェアから建設まで）でプロジェクトを実施するプロセスで私たちがやってきたアルゴリズムに従うなら、簡単に満たされます。 このアルゴリズムで優れた結果を得るための唯一の条件は、プロジェクトマネージャー（この場合、彼が顧客である）が開発者より悪くない主題分野を理解しなければならないことです。
方法「これをどのように行いますか？」
メソッドのキーポイント：
- 請負業者自身が問題を解決するための行動を説明し、自分で評価します。
- 顧客はこの評価に同意するか、独自の実装方法を提案します。
1.問題の声明。
マネージャーは、必要な機能から取得したい結果を記述することにより、タスクを設定します。
2.開発者は、機能に応じてタスクをステージに分割します。
開発者は、マネージャーにニュアンスについて質問することで、このタスクをどのように実装するのかを人間の言葉で説明します：どのアルゴリズム、これのためにどの機能が作成されるか、どのファイルが移動/変更されるか、どのモジュールが使用されるか。 タスクを機能に分割しようとしています。
一部の開発者は、TK（誰も書くのが好きではない）のようなものが必要であることを期待して、このステップを恐れています-現実から逃れるためのTK、形式主義、グラフ、UMLおよびその他の素晴らしい技術は必要ありません、実装をそのまま記述してください、開発者にどのように見えるか。 例：
- 他の人がこのタスクを実行したようなサイトを見ていきます。
- データベースに変更を加えます
- データベースに、id、from_id、to_id、message、time、is_readedの各フィールドを持つ「メッセージ」テーブルを作成します。
- テーブル「users」にフィールド「new_messages」を追加します
- モデルを補完します
- ユーザーモデルにメソッドを追加します：send_message（user_id、message）、read_message（id）、get_all_messages（）
- send_messageメソッドは、メッセージをメッセージテーブルに保存し、送信ユーザーのnew_messagesフィールドをインクリメントします
- アラート
- jqueryライブラリをダウンロードして接続する
- 通知ウィンドウの入力機能を書いています
- 通知コードをテンプレートに挿入します
- テストとデバッグ
これはかなり重要な調査作業であり、開発者自身が実際にこの機能をどのように実装するかを理解するための非常に優れた演習です。 そうすれば、彼は自分の行動をより正確に計画し、行動の完了のタイミングをより正確に決定できるようになります。
それは重要です-人が何かをどのように行おうとしているのかを明確に説明できない場合、彼はそれを合理的な時間内にまったく行うことができません。
3.開発者がタイミングを決定します
開発者は、彼がどのように何をするかを知ったので、各ステージの実装にかかる時間を計算します。 最初に、タイミングを考えずにすべての機能を説明し（ステージ2）、それを評価することが重要です。
例：
- サイトでソリューションを見つける-20分。
- データベースの変更-15分。
- モデルへの追加-30分。
- アラート-90分
- テストとデバッグ-30分
合計：3時間05分。
タイミングをすぐに正しく評価することはほとんど不可能です。 しかし、2-3-4-5の反復の後、正確に計画および評価するスキルと能力が現れます。
4.マネージャーは、実装の方法と条件を評価します。
開発者が設定した機能および用語の説明を見て、マネージャーはそれらをそのまま受け入れるかどうかを決定します。
マネージャーが特定の段階をより早く完了することができると考えている場合、タイミングと実装方法の両方に同意するまで、開発者にその方法を説明します（実際、2番目の段階に戻ります）。 例：
マネージャー：NotifyBarプラグインを使用すると、通知は15分で完了できると思います。
開発者：プラグインはニーズに合わせて調整する必要があるため、15分では不十分です。約30分かかります（別のJSライブラリを使用します）
マネージャー：OK、30分で警告します。
ステージの計画が難しい場合は、ステージをいくつかの小さなステージに分割し、それらを最初に説明して評価できます。
5.マネージャーは機能に優先順位を付けます。
マネージャーと開発者はすべての条件に同意した後、実装の期間に応じて機能を優先します。 一般的に、各項目の実装に割り当てられる時間と、プロジェクトのこの段階でそのようなリソース（時間+支払い）を費やすことの正当性を調べます。 これが意味をなさない場合、そのような機能は現在のタスクから削除され、より良い時間までバックログに転送されます。
たとえば、プロジェクトには「アラート」タスクを完了するために90分が与えられました。 この段階では無駄が多いため、プロファイルにメールボックスアイコンを表示します。90分ではなく5分かかります。
6.実装。
現在、開発者が作成した明確な機能、タスクを完了するための計画および期限があります。 マネージャーが不要な機能を削除し、先手を打った後、開発者は実装に進みます。
予期しない遅延
それでも開発者がスケジュールから外れており、何が起こっているのか心配する必要がないと判断した場合、最初の計画で何かを予測していなかったことを意味し（調査部分を完了しなかった）、すぐにマネージャーに通知します。 マネージャーと開発者は、この段階（ポイント2）を完了する方法について再度話し合い、時間通りに完了するように変更する必要があるものを見つけます。
期限が変更されると、マネージャーは優先順位付けを再評価し（段落5）、このステージをタスクから除外するか、それをより小さなものに分割するか、新しい期限を受け入れます。
7.支払いの準備ができました。
遅延
開発者が自分で設定した期限に間に合わなかった場合、実際に費やした時間について、交渉した金額の1時間の費用を受け取ります。 これが頻繁に発生する場合、つまり、開発者が時間を推定することを学べない場合（ポイント2をフォロー）、この瞬間に特別な注意を払ってトレーニングします。この場合、結果がない場合は、そのような従業員に迷子にならなければなりません。
予定より早く完了
開発者が期限に間に合い、タスクをより早く完了することさえできた場合、彼はすでにそれをより早く渡し、別のタスクに進むか、拒否された機能で埋めるか（バックログを参照）、または散歩に行くことを決定します。 いずれにせよ、彼の仕事は計画期間 （1時間のコスト*ボーナス係数*計画期間）の金額で支払われます。つまり、実際に彼はボーナスと休日を獲得しました。
再開
したがって、説明されている手法を使用して：
- 真に機能するスケジュールが確立されており、開発者はそれをより速く行うことに関心があり、顧客は自分のタスクをより正確に記述することでリソースを節約できます。
- 明確に定義された計画を持つタスクがあります：実装の段階、方法、条件。 課されていませんが、開発者と一緒に生まれています（ほとんどの場合、自分で）。
- 開発者は、神話上の「一度必要な機能」を掘り下げるのではなく、必要なことだけを行うため、自分と他の人の時間を節約できます。
- 機能に優先順位を付けることで、期限内に保ちます。