彼らは、目標は具体的、測定可能、達成可能、関連性、期限付きであるべきだと彼らは言います。
そして、プログラマーのためにこれを突き出そうとしている驚くべき人々さえいます。
しかし、タスクがあり、タスクがあります。 そして、それらの間には大きな違いがあります！
開発者-生き物のストリーミング、運転。 プロジェクトマネージャー、チームリーダー、および10分ごとに1回フォーカスを変更しなければならない他のすばらしい人々とは異なります。 そして、プロセスが開発者がこのスレッドに参加し、調整や通信エラーのポイントに気を散らすことなくコードを作成できるようにすることは素晴らしいことです。 これにはTOTEモデルがあります。 そして、開発者へのタスクの定式化に基づいて構築する必要があるのはそれからであるという意見があります。 最初にどのようなモデルを説明し、次にそれをどのように適用するかを説明します。
トット
T1-テスト -私たちが目指している望ましい状態、それは何ですか？
-操作 -結果を達成するためにどのような行動をとるべきですか？
T2-Test2-結果に向かって動いたことをどのような兆候で認識しますか？
E-終了 -結果が最終的に達成されたことをどの基準で認識していますか？
このモデルは非常にアルゴリズム的であり、最大20時間までのタスクに適しています（ライン開発者が4..8時間以上タスクを設定する必要がない理由を説明する必要はないでしょうか？）。
これが計画開発中のタスクの設定にどのように当てはまるかの例を示します。 もちろん、このレシピは、研究開発のスタイル、作業の組織、または緊急の穴の塞ぎの作業の場合には適していません。
最初に（ T1 ） 私たちがしていることの簡単な説明があります（タスクのタイトルと混同しないでください！）。 私たちが何をしているのか、そしてその理由をまとめた一文。
一般的に言えば、あなたがそれを定式化できないならば、それはタスクを引き受ける意味がありません。 「ユーザープロファイルの標準REST APIを作成して、アプリケーションフロントエンドが動作するようにする」、「性別パラメーターを受け入れて保存するための鎧の作成方法を教える」、「マージリクエストのスキームに従ってキーを配置する移行を記述する必要があります」 （uml chart charts）。 "
操作およびT2の少しとして、 「結果を達成するために実行するアクション」の章が表示されます。
これは、線形開発者が行う必要がある特定のアクションの番号付きリストです。 おそらく時間の推定値があります。 例：
1.移行を作成します（30分）
2.検証付きのモデルの登録（2時間）
3.コントローラーを処方する（2時間）
番号を付けて、各ステップにかかる時間を理解することが重要です。 これは、ジュニアやミドルで作業している場合に特に重要です。 開発者が「ダグイン」するとすぐに、このリストは、彼が立ち往生していることと、今後のステップをすぐに理解するための良い方法です。
結論として、 「期待される結果」の章は、 Exitと小さなT2のルールとして機能します。 「期待される結果」は、番号のないタスク検証チェックリストです。 実際、QAでタスクのテストスクリプトを作成します。 つまり、理想的にはポジティブなシナリオとネガティブなシナリオの両方を含める必要があり、「書かれたようなクラス」のスタイルのコードへの参照を含めるべきではありません。 機能チェックのみ。
例：
-APIを介してユーザーを作成すると、ユーザーはデータベースに表示されます
-ユーザーを作成するときのAPI応答はドキュメントに対応します
-管理者のみがユーザーを作成できます
-ユーザーを作成しようとしたときに管理者以外のユーザーが403エラーを受信する
ところで、実行されたタスクのバグの割合が高いのは、開発者に求めるものを策定する際に「期待される結果」にもっと注意を払う理由にすぎません。
ブナが多すぎますか？
もちろん、実際には、この方法ですべてのタスクを作成することは費用対効果が低い場合があります。 バランスを見つける必要があり、これについても少し言いたいと思います。
TOTEを介してタスクを設定することは、チームが採用する新しいシステムとアプローチに慣れるまで、新参者、ジュニア、ミドルを接続するときの一時的な手段として役立ちます。
資格のあるプロアクティブな上級従業員によって、タスク設定を安全に簡素化できます。 1人の人があなたから1ブロックの仕事を引き受け、休みなく、休日や病気なしにそれを解決し、保証された結果が得られれば、安全に言葉遣いを減らすことができます。 作業ブロックが「保留」になっている場合、人々と「チェッカー」をプレイし、タスクからタスクに投げ、チーム間でシャッフルする必要がある場合-TOTEが必要です。
他に何を探す
作業ブロックがタスクに分割される量にエラーがある場合があります。 作業単位全体の目標設定、作業単位の要件、社内および社内のプロセス、能力に誤りがある可能性があります。 TOTEアプローチはこれらの問題を解決しません。 そして、これは全く異なる話です。