アジャイル手法を使用したソフトウェアの書き換え
アジャイル方法論を使用してアプリケーション全体を書き換えなければならない場合、どうすればよいでしょうか？
現在のシステムの動作に基づいて、大量のユーザーストーリーを作成できると思います。そして、小さな反復でそれらを実装します。しかし、これは要件があることを意味するわけではありませんP FRONT ??
また、いつリリースを開始しますか？アジャイルは、私たちは早期にそして頻繁にリリースすべきだと言っていますが、完全な書き換えが完了する前にリリースすることはあまり意味がありません。
高レベルの叙事詩に分解します。アプリケーションの各機能領域を一度に1ステップずつ実行します。
1つの叙事詩をストーリーのグループ（使用可能なチャンク-アプリケーションを改善するもの）に分割し、既存のアプリケーションがない場合と同じようにそれらを管理します。ただし、例外が1つあります。可能であれば、その1つの機能を元のアプリケーションの一部として、または元のアプリケーションと一緒に実装できます。
アジリストが「頻繁かつ早期にリリースする」と言ったとき、それは必ずしも生産を意味するものではありません。既存のアプリケーションを置き換える場合は、ステージング領域を使用して頻繁にリリースし、ユーザーがそこでシステムをテストしていることを確認してください。これにより、次の作業に優先順位を付け、製品にリリースするものが製品の価値を低下させないようにするための余地が与えられます。
1つのコンポーネントを製品版にリリースしたら、次のコンポーネントに移ります。
私たちはそのような経験（スクラム製品の所有者としての私）を経験しました。解放可能なものになるまでに2年かかりました。しかし、それでも、アジャイルには多くのメリットがあります。
最初：完全な書き換えは本質的にまったくアジャイルではありません。代わりに、既存の製品を少しずつリファクタリングすることを検討する必要があります。それは別の質問で議論されました。だから、それが書き換えである必要があると仮定しましょう。
次に、実際に、既存の製品の関連するすべてのユースケースをカバーするバックログから始めます。ただし、仕様を書いているように近づかないでください。細かすぎます。完全である必要があります（そうしないと、リリース計画を実行できません）。また、複雑すぎないようにしてください（そうしないと、仕様を事前に記述します）。これが私たちがそれに取り組んだ方法です：
古い製品のユーザーを分類します。古い製品のほんの一部しか必要としないユーザーを特定し、それでもそれから何か役に立つものを得る。彼らはあなたの最初の叙事詩を定義します。
次に、別のカテゴリのユーザーが新製品に移行できるようにするエピックを追加します。すべてのユーザーをカバーするバックログが得られるまでなど。
ほとんどの場合、これらのエピックはさらに分割する必要があります。可能な場合は、分割して各部分にまだ値があるようにしてください。それが不可能な場合は、少なくとも各部分を実証できることを確認してください。
20〜50のエピックがある場合は、チームに推定してもらいます。
最高のエピックを、チームがスプリント内で実行可能であると信じているユーザーストーリーに分割します。まだすべての叙事詩についてそれを行わないでください。一番上のものだけです。残りを分割する時間は十分あります。
いつ外部にリリースするか！それはビジネス上の決定です。少なくともこのアプローチでは、特定のユーザーカテゴリに早期にリリースする機会が与えられます。これは、一見終わることのないこのプロジェクトについて経営陣が緊張した場合に便利です。
可能であれば今すぐリリース
コードのリリースをいつ開始するかについてのあなたの質問は素晴らしいものです。 2つの条件が適用されると思います。 1つは、「十分な品質」であり、2つ目は、MVP（実行可能な最低限の製品）の要件を満たしていることです。
ローマ（およびアジャイル）は1日で構築されませんでした
多分あなたはターンキーアジャイルチームが初日に引き継ぐ準備ができています。ほとんどの組織では、チームを構築するためのトレーニング、ツールの変更、および通常のフォーミング、ストーミング、規範、パフォーマンスのサイクルの作業と費用があります。リスクとコストについて前向きになり、現実的な期待を設定するように注意し、前向きになり、アプローチを支持する準備をします。
再利用のブートストラップになる
フュージョンパワーと同様に、コードの再利用は、経済問題のfutureソリューションであり、常にそうです。開発者は再利用を信じているとよく言われますが、誰かがすでに行ったことに基づいて構築するのではなく、新しいフレームワークを構築した後に始まる種類の再利用のみです。誰かが他の誰かの土台の上に築くことをいとわないまで、それはどのように機能しますか？せいぜい、チームのリーダーシップが変わるときに数年ごとに書き直すことを意味します。
なぜ早期かつ頻繁にリリースするのですか？
多くの理由から、早期にリリースすることはしばしばマントラです。それは、製品がどうあるべきかについての議論に活気を与え、私たちがどこにいるのかを現実にし、反復的/増分的な変化の基盤を与えます。リリースのペースは、アジャイルにとってはほとんど不変で、違いはリリースを受け取る人（顧客の代理またはエンドユーザー）です。アジャイル以前は、保守はソフトウェアシステムのコストの60％を占めると推定されていました。これは、マネージャや他の人々にとって多くの驚きの源であり、製品のリリースはソフトウェアが死ぬところだと感じる人もいます。彼らにとって、リリース後のすべての作業はやり直しであり、彼らがすでに支払った製品を修正するために支払っています。
プレリリースは不自然です
ケントベックは、プレリリースはソフトウェア製品にとって不自然な状態であると書いています。それはあなたが顧客を持たず、あなたがあなたのために支払う製品ではなく、あなたがその製品の代金を払っている時であるので、それは確かに不便な時間です。
前のチームを批判しないでください
書き換えを引き継ぐ開発者をプロジェクトのヒーローと救済としてセットアップするかもしれませんが、以前のチームの成果を批判するにはコストがかかると思います。
- まず、前のチームについて人々が自分で決心するようにすると、あなたの本当の使命のためにより多くの時間とエネルギーが与えられます。
- 以前のチームのメンバー、つまり開発者だけでなく、製品マネージャー、プロジェクトマネージャー、顧客などの利害関係者とも協力する必要がある場合は、厄介です。
- それを機能させることができれば、前のチームがやったことの功績を受け取る（またはさらに悪いことに）自分に気付くかもしれません。
- 平均して、前のチームはおそらく平均的でした。平均して、あなたは平均的かもしれません。プロジェクトに加えて導入する新しい方法論があるため、前のチームよりも多くの作業が必要になります。
- 古いチームがひどいものだった場合、あなたもひどいものでない限り、最終的にはひどいものよりも優れていると認められます。それらが恐ろしいよりも優れていて、あなたがそれほど良くない場合、彼らが恐ろしいと言ったのは不愉快な比較を招くかもしれません。
- 古いチームがあなたが思っていたよりも優れていて、組織が壊れていたり、問題が明確に定義されていなかったり、非常に困難だったりして問題が発生した場合、期待を大幅に上げていなければ、状況は改善されます。
- 彼らは彼らが得ていたものを期待しているが、あなたがもっとうまくやれば、それはあなたにとっての勝利です。
- 批判を控えることは両方とも良いマナーであり、あなたがクラスを持っていることを示しています。
@Chuckによるコメントと、本質的には書き直さないと言っているNetscapeへの言及と、OPが彼がすべきかどうか尋ねていないことを主張する有効な応答によって促されます。 -真に俊敏なソフトウェア開発サイクルにより、書き換えができなくなります。ほとんどの場合、書き換えはアジャイルの背後にある原則の多くを破ります。現在のソフトウェアをベースラインとして使用すると、これらのアジャイルの原則（ Agile Manifesto から）を書き換えで満たすことはできません。
- 貴重なソフトウェアの早期かつ継続的な配信。 -顧客がすでに持っているものに対して測定された場合、顧客は早期の価値を得られません
- 稼働中のソフトウェアを頻繁に提供します-数週間から数か月-プロジェクトの規模はどれくらいか、正直に言って、顧客がいつでももっと役立つものを手に入れられると思いますか。
- 作業中のソフトウェアは進行状況の主要な指標です-ベースラインと比較した作業は急いでは起こりません
- アジャイルプロセスは持続可能な開発を促進します。-顧客が実用的なベースラインを持っていることを考えると、改善された機能を提供するように圧力がかかります。これは持続可能なペースで行われる可能性は低いです
- シンプルさ-行われない作業量を最大化する技術-は不可欠です。これは本当にすべてを言います...
「アジャイル手法を使用してアプリケーション全体を書き直さなければならない場合、どうすればよいでしょうか？」
質問は誤った前提に基づいています-書き換えはアジャイルと見なすことができます。
書き換えられたアプリケーションを一度に1つずつリリースし、古いアプリケーションと並行して本稼働できるかどうかを検討します。
特にWebアプリケーションの場合、アプリケーションの単一の部分を新しいプラットフォームに移動し、ロードバランサーにリクエストを適切なシステムにルーティングさせるのはかなり簡単です。次に、最初のページを本番環境に導入し、俊敏な方法で配信できるようにするストーリーを作成します。
デスクトップアプリケーションはより複雑になる可能性がありますが、多くの場合可能です。
あなたは継ぎ目を探しています–完全な書き直しを必要とせずに、古いシステムがその責任を新しいシステムに引き継ぐことが可能な場所。
おそらく、新しいWebサービスまたはフレームワークに移動できる自己完結型のビジネスロジックがあり、古いコードの代わりにそれを使用して古いアプリを変更できます。残ったものがすべて一口で管理できるようになるまで、継ぎ目でチャンクを切り分けてください。
継ぎ目が見つからない場合は、他のいくつかの回答で提案されている種類のビッグバンアプローチを探す必要があります。しかし、特に古いシステムを並行して開発し続けることが予想される場合は、目的地に到着する前に長い行進に備えてください。
アジャイルは、私たちは早期にそして頻繁にリリースすべきだと言っていますが、完全な書き直しが完了する前にリリースすることはあまり意味がありません。
実際、これが重要なポイントです。書き換えられたアプリケーションの一部を本番環境で入手する（そして理想的には古いシステムの機能を置き換える）ほど、プロジェクトが成功する可能性が高くなります。これがあまり意味がないと思うなら、もっと考えてください。ほとんどの場合、パーツをリリースする可能性があります。
それはおそらく、誰かが古いアプリケーションの何かを変更する必要があることを意味します。たとえば、書き換えが完了していない間に、書き換えられたアプリケーションとやり取りする新しいインターフェイスをいくつか追加します。しかし、私の経験では、そのような追加の作業は常にそれ自体の利益になります。
新しいアプリケーションの最初の部分が本番環境に入ると、アジャイルで反復的なアプローチが明らかになります。要件が変化し、ユーザーストーリーが変化するか、新しい優先順位が付けられます。うまくいけば、古いシステムの機能を少しずつ置き換えることができます。