まえがき
多くの場合、開発者はシステムの既存の機能を変更したり、既存の機能を再利用する新しい機能を追加したりする作業に直面します。 この記事では、タスクを正しく計画するために開発者が行う必要がある作業量を決定するためのいくつかのアプローチについて説明します。
計画する理由
柔軟な開発環境（アジャイル）でも、ウォーターフォールなどの従来のアプローチでも、作業環境に関係なく、作業を完了する
技術的なタスクの計画
この記事では、ゼロから作成されるシステムのタスクスケジューリング手法を省略し、既存のアプリケーションで行う必要のある変更に焦点を当てます。
私が説明しようとするすべてのアプローチは、何らかの形で自分自身を使用しました。
だから：
- 仮説的に変更する必要があるコードの検査。
このアプローチは、実装が非常にうまく進んでいる場合に適用でき、ほぼ確実に、システムのどの部分が変更される可能性があるかを知ることができます - システムログの調査。
システムの実装とその動作に関する知識がわからない場合は、ログを参照できます。 まず、ユーザーに入力データを入力して、システムがログに残したトレースを確認するように依頼できます。 その後、特定のビジネスアルゴリズムが実装のどの部分を実行するかを自信を持って言い、新しいロジックを実装するための人件費を評価できます。 - テストを書く
システムの動作を再現するためにアクセスできるユーザーはいません。 そして、もしあれば、毎回連絡することはありがたい仕事であり、すべてを手動で繰り返したくありません。 アルゴリズムを実装する前に自動テストを書いてみませんか？
はい、ATDD（Acceptance Test Driven Development）および問題の機能テストです。
このタイプのテストは、プロジェクトの開始直後に処理する必要があります。 このようなテストを作成および実行するためのフレームワークは、プロジェクトとともに進化する必要があります。 簡単に拡張可能でスケーラブルでなければなりません。 さらに、このようなテストの実行は継続的インテグレーションでサポートされる必要があります。
システムの現在の動作を再現するテストがあり、結果がどうあるべきかがわかっている場合、作業の半分はすでに完了しています。 a）既存のテストが失敗しないように、そしてb）新しいテストも新しい期待される出力で合格するように、実装する必要があるまさにそのデルタを評価することが残っています。
非常に政治的な疑問が生じます。 タスクをスケジュールする前に、そのようなテストを書くことは本当に必要ですか？ 答えは、機能テストフレームワークがこれらの種類のテストをどれほど迅速に作成できるかという事実かもしれません。 これが2、3時間の質問であれば、答えは「はい」です。そうでない場合は、技術部について考え、近い将来状況を修正する必要があります。
反復的な開発手法を使用する場合、次の反復の前に、要件の観点からユーザーストーリーが十分に明確であることを確認してください。 要件は簡単に受け入れテストに変換でき、例による仕様 （SBE）に役立ちます。 ちなみに、SBEは、Fitneesなどのテストツール、Spock、EasybなどのBDD実装とうまく統合されています。
道徳
実装の詳細を掘り下げる前に、すべてをテストする方法について考えてください。 この機能またはその機能を実装するのに十分な要件がない可能性があるため、後で延期する必要があります（スプリント）。 機能テストの作成に時間をかけ、Continious Integrationのリグレッションに注意してください。 グリーン機能テストは、顧客が望んだとおりにあなたが正しく仕事をしたことの証明であり、ソース管理での次のコミットの直後にこれについて知ることができます（初期のフィードバック）。 そして、賢明なログを書きます。
がんばって。