アジャイル開発におけるリファクタリング
アプリ開発プロジェクトでは、プロジェクトの全範囲がアプリの設計で考慮されていませんでした。そのため、変更に対応するためにコードを頻繁にリファクタリングすることは、スプリント中に必要になったプロジェクトの納期に悪影響を及ぼします。利害関係者は妥協する気がないので、プロジェクトの納品の合意された日付を超過するリスクを最小限に抑えるために、これをどのように最適に制御できますか？
回答
TL; DR
プロジェクト管理フレームワークの一部ですが、特にスクラムのようなアジャイルフレームワークは、利害関係者の期待を継続的に管理する必要性です。人々は必要なときに必要なものを求めていますが、プロジェクト管理の大部分は、プロジェクトに影響を与えるさまざまな制約の中で実際に何ができるかを人々に説明することです。プロジェクトが進展するにつれて、特に実行可能なものが当初の計画から逸脱した場合に、その時点で現在の制約内で現在実行可能なものを理解する必要があります。
やり直しが期待されます
リファクタリングは、外部の動作を変更せずに実装を変更します。おそらく、実際にはリファクタリングを行っているわけではありません。技術的負債を返済したり、やり直しや統合を行ったりしていますが、これらは本質的に同じものではありません。
スクラムのようなフレームワークは、さまざまなタイプの作業（リファクタリングやリワークを含む）を、経験的な制御と設計の許容可能なトレードオフとして扱います。これは見積もりプロセスで処理され、（正しく）技術的負債、複雑さ、または変化のペースが増すにつれて速度の低下として現れます。これは、反復フレームワークで期待され、望ましいものです。これは、各検査と適応のループが、スコープ、優先順位付け、またはアプローチを変更する機会を提供するためです。
やり直しは、経験的管理のコストです。ソフトウェア開発などの複雑なプロジェクトでは、これを回避することはできません。スクラムは、必要または望ましい変更を行うためのコストとして、チームと利害関係者にリワークを表示するだけです。
修正済み-すべてが不可能
「鉄のトライアングル」は、予算、範囲、またはスケジュールを制御することでプロジェクトを調整でき、品質は他の3つのスライダーの影響を受ける暗黙の4次元であると考えています。次の図はこれを示しています。
スクラムのようなアジャイルフレームワークは、一般的にスコープ、特にプロジェクトスコープを次のように尋ねることでメインスライダーとして扱います。
1つのスプリントのタイムボックスにどのくらいの範囲を収めることができますか、またはアジャイルリリースプランに収めることができますか？
現在、プロジェクトはスコープとスケジュールの両方を修正しようとしています。それはあなたの利用可能なスライダーとして予算を残すだけです。それもロックしようとすると、プロジェクトが失敗するか、品質が低下するか、またはその両方になります。品質を維持しながら、プロジェクトフレームワークで固定価格、固定範囲、固定スケジュールを確実に実行することはできません。スクラムは単にそれをより明白にし、トレードオフをより明確にします。
スクラムのポイントは、魔法のように鉄の三角形を消すことではありません。代わりに、プロジェクト（および利害関係者とスポンサー）が固有のトレードオフに同意するように強制します。スクラムを使用すると、関係者は、各スプリントの最後に出荷するのに「十分」なものがあるかどうかを判断できます。プロダクトオーナーは、バックログの詳細化とスプリントの計画中に範囲と優先順位を調整する機会が得られます。利害関係者は、リリース計画内で実現可能な最大の価値を確実に得る方法として、これらのイベントを活用する必要があります。プロジェクトが100％完了している、または固定された一連のスプリントの終了時に目的に適合しているということは、返金保証ではありません。
埋没費用を削減する
アジャイル開発のもう1つの側面は、「早期に失敗する」機会です。何らかの理由でプロジェクトが失敗する可能性がある場合、スクラムのようなアジャイルフレームワークは、スプリントをキャンセルして変更された期待に基づいて新しいプロジェクトを計画するか、関係者がプロジェクトの残りの部分をキャンセルできるようにすることで、プロダクトオーナーにお金を節約する機会を与えます彼らの目的を果たさないでしょう。後者はプロジェクトを成功させることはありませんが、プロジェクトに関連する埋没費用を削減します。
プロジェクトが成功することを保証できる人は誰もいません。あなたができる最善のことは、それを制御し、成功がもはや選択肢ではなくなったときに、運命のプロジェクトをできるだけ早く殺すことです。
今できること
まず、あなたが死の行進への道を進んでいることを認めてください。あなたがその真実に直面しなければ、あなたがすることは何も重要ではありません。
次に、問題が設計、技術的負債、不当な期待、または他の何かであるかどうかを把握します。根本的な原因が何であるかは関係ありません。チームと利害関係者が協力して対処できるように、それらを表示する必要があります。
最後に、現在の状況を明確に伝えます。当初の予定納期を数サイクル過ぎたフル機能のリリースに向けてペースを上げている場合は、プロジェクトが「時間」の頂点を調整できるかどうかについて話し合ってください。スケジュールを調整できない、または調整しない場合でも、コストを増やすか範囲を縮小することで、固定の期限を守ることができます。利害関係者は、時間のかかる機能の一部を削減するために、時間通りの配信を交換しますか？あなたが尋ねない限りあなたは知りません。
プロジェクトが上記のいずれも実行できない、または実行できない場合は、失敗に備えてください。履歴書をブラッシュアップして、次のプロジェクトや次の仕事で使用できる貴重なレッスンを学んだことを願っています。何よりも、前提条件、課題、フレームワーク要件、トレードオフについて早期に頻繁にコミュニケーションを取り、利害関係者の期待を継続的に管理することの重要性を内面化することを学んだことを願っています。
スプリントごとに展開可能な増分の製品を作成していますか？もしそうなら、合意された納期はすでに満たされています、そしてそれはリスクを最小にしそしてあなたがしていることに顧客に自信を与えるための最良の方法です。利害関係者は（製品の所有者を介して）必要なものと時期を決定する必要があります。したがって、最も重要なことは、あなたが価値を提供していることを引き続き確認し、製品に必要な改善、変更、修正についてフィードバックを得るということです。ここでは、フィードバックを得ることが重要です。タイムラインがありません新しい機能範囲を拡張したが、すぐにあなたが最新の改良を含めて始めると、もしお客様が当然懸念される可能性があります彼らは優先順位として見、彼らは柔軟性の必要性を認める可能性が高くなります。