アジャイル手法を使用したソフトウェアの書き換え

アジャイル手法を使用してアプリケーション全体を書き直さなければならないとしたら、どうしますか？

現在のシステムの動作に基づいて、多くのユーザーストーリーを作成できると思います。そして、それらを小さな反復で実装します。しかし、これは私たちが前方に要件を持っているという意味ではないでしょうか？

また、いつリリースを開始しますか？アジャイルは、早期かつ頻繁にリリースすべきだと言っていますが、完全な書き換えが完了する前にリリースすることはあまり意味がありません。

高レベルの叙事詩に分けてください。アプリケーションの各機能領域を一度に1ステップずつ実行します。

1つの叙事詩をストーリーのグループ（使用可能なチャンク-アプリケーションを改善するもの）に分割し、既存のアプリケーションがない場合と同じように管理します。ただし、1つの例外があります。可能な場合は、元のアプリケーションの一部として、または一緒に、その1つの機能を実装できます。

アギリストが「早期かつ頻繁にリリースする」と言うとき、それは必ずしも生産を意味するものではありません。既存のアプリケーションを置き換える場合は、ステージング領域を使用して頻繁にリリースし、ユーザーがそこでシステムをテストしていることを確認する必要があります。これにより、次の作業に優先順位を付け、製品にリリースするものが製品を減価しないようにする余地が残ります。

1つのコンポーネントを実稼働環境にリリースしたら、次のコンポーネントに進みます。

私たちはそのような経験をたった今得ました（私はスクラムプロダクトオーナーとして）。リリース可能なものに到達するのに2年かかりました。それでも、アジャイルは多くの利点をもたらしました。

まず、完全な書き換えは本質的にアジャイルではありません。代わりに、既存の製品を1つずつリファクタリングすることを検討する必要があります。それは別の質問で議論されています。それで、それが書き直さなければならないと仮定しましょう。

実際、既存の製品の関連するすべてのユースケースをカバーするバックログから始めます。ただし、仕様を作成するときにアプローチしないでください。それはあまりにも詳細になります。完全でなければなりません（そうでなければ、リリース計画を立てることはできません）。そして、それはあまりにも複雑であってはなりません（そうでなければ、仕様を前もって書いています）。以下がそのアプローチです。

• 古い製品のユーザーを分類します。古い製品のごく一部しか必要としないユーザーを特定し、それでも何か有用なものを入手します。彼らはあなたの最初の叙事詩を定義します。

• 次に、別のカテゴリのユーザーが新しい製品に移行できるようにするエピックを追加します。すべてのユーザーをカバーするバックログが作成されるまで。

• ほとんどの場合、これらのエピックはさらに分割する必要があります。可能であれば、分割して、各パーツにまだ値があるようにします。それが実現可能でない場合は、少なくとも各部分を実証できることを確認してください。

• 20〜50のエピックがある場合は、チームにそれらを見積もってもらいます。

• チームがスプリント内で実行可能であると考えているユーザーストーリーに、最上位の叙事詩を分割します。まだすべての叙事詩に対してそれを行うのではなく、一番上の叙事詩についてのみ行います。残りを分割するのに十分な時間があります。

外部にリリースするタイミング！それはビジネス上の決定です。少なくともこのアプローチでは、特定のユーザーカテゴリに早期にリリースする機会が与えられます。経営陣がこの一見決して終わらないプロジェクトに神経質になった場合に便利です。

できれば今すぐリリース

いつコードをリリースし始めるのかという質問は素晴らしいものです。2つの条件が適用されると思います。まず、「十分な品質」があること、そして次にMVP（最小の実行可能製品）の要件を満たしていること。

ローマ（およびアジャイル）は1日で構築されなかった

たぶん、あなたはターンキーアジャイルチームで初日を引き継ぐ準備ができているかもしれません。ほとんどの組織では、トレーニング、リツール、およびチームを構築する通常のフォーミング、ストーミング、標準化、実行サイクルの作業と費用がかかります。リスクとコストについて前もって考え、現実的な期待値を設定するように注意し、率先してアプローチを支持する準備をしてください。

再利用ブートストラッパーになる

フュージョンパワーのように、コードの再利用は私たちの経済的問題に対する将来の解決策です。私の考えでは、開発者は再利用を信じているとよく言いますが、新しいフレームワークを構築した後に開始する種類の再利用のみであり、他の誰かが既に行ったことに基づいて構築します。誰かが他の誰かの基盤の上に構築することを選択するまで、それはどのように機能しますか？せいぜい、それはチームのリーダーシップが変わるとき、数年ごとに書き直すことを意味します。

なぜ早くリリースされることが多いのですか？

早期にリリースすることは多くの理由からマントラです。それは、製品がどうあるべきかについての議論に活気を与え、私たちがどこにいるのかを現実にし、反復的/漸進的変化の基盤を提供します。リリースのペースはアジャイルにとってほとんど不変ですが、リリースを受け取る人（顧客の代理人またはエンドユーザー）が異なります。アジャイルになる前は、ソフトウェアシステムのコストの60％をメンテナンスが占めると推定されていました。これは管理者や他の人たちにとって大きな驚きの源であり、一部の人たちは製品のリリースはソフトウェアが死ぬ場所だと感じています。彼らにとって、リリース後のすべては手直しであり、かつて一度支払った製品を修正するために支払っています。

プレリリースは不自然です

Kent Beckは、プレリリースはソフトウェア製品にとって不自然な状態だと書いています。それは確かに不便な時間です。なぜならあなたは顧客がいなくて、あなたが製品にお金を払うのではなく、製品にお金を払っている時だからです。

前のチームを批判しないでください

書き直しをプロジェクトのヒーローと救いとして引き継ぐ開発者を設定するかもしれませんが、前のチームの業績を批判することにはコストがかかると思います。

• 第一に、前のチームについて人々に決心させれば、本当の使命のためにより多くの時間とエネルギーが与えられます。
• 前のチームのメンバー、開発者だけでなく、プロダクトマネージャー、プロジェクトマネージャー、顧客などの利害関係者と連携する必要がある場合は、面倒です。
• あなたがそれを機能させることができるなら、あなたはあなた自身が前のチームがやったことの功績を受け取っている（またはさらに悪いことに取っている）ことに気付くかもしれません。
• 平均して、前のチームはおそらく平均でした。平均して、あなたは平均的かもしれません。プロジェクトに加えて導入する新しい方法論があるため、前のチームよりも多くの作業があります。
• 古いチームが恐ろしい場合、あなたも恐ろしい人でない限り、あなたは恐ろしいよりも優れているという信用を最終的に得るでしょう。それらが恐ろしいより優れていて、あなたが顕著に良くないなら、彼らが恐ろしいと言って不快な比較を招くかもしれません。
• 古いチームが思っていたよりも優れていて、組織が壊れているか、問題が明確に定義されていないか非常に難しいために問題が発生した場合、期待を大幅に上げなければ物事はうまくいきます。
• 彼らが彼らが得ていたものを期待しているが、あなたがよりうまくやれば、それはあなたにとって勝利です。
• 批判を控えることは良いマナーであり、あなたに階級があることを示しています。

@Chuckによるコメントと、本質的には書き換えないというNetscapeへの参照と、OPが彼にすべきかどうかを尋ねていないことを反論する有効な応答によって促されます。-本当にアジャイルなソフトウェア開発サイクルは、書き換えを不可能にします。書き換えは、ほとんどの場合、アジャイルの背後にある原則の多くを破ります。現在のソフトウェアをベースラインとして使用すると、これらのアジャイルの原則（アジャイル宣言から）を書き換えることができません。

• 価値のあるソフトウェアの早期かつ継続的な配信。-顧客は、すでに持っているものと比較して早期の価値を得られません
• 稼働中のソフトウェアを頻繁に（数週間から数か月間）提供します。プロジェクトの規模はどれほど大きいでしょうか。
• 稼働中のソフトウェアは進捗の主要な尺度です -ベースラインと比較して動作することは急いで起こりません
• アジャイルプロセスは持続可能な開発を促進します。-顧客が実用的なベースラインを持っていることを考えると、改善された機能を提供する圧力がかかります。これは、持続可能なペースで行われる可能性は低い
• シンプルさ-完了していない作業量を最大化する技術-は不可欠です。これは本当にすべてを言います...

「アジャイル手法を使用してアプリケーション全体を書き直す必要があるとしたら、どうしますか？」

質問は、誤った前提に基づいています-書き換えはアジャイルと見なすことができます。

書き換えたアプリケーションを一度に1つずつリリースし、古いアプリケーションと並行して運用環境で使用できるかどうかを検討してください。

特にWebアプリケーションの場合、アプリケーションの一部を新しいプラットフォームに移動し、ロードバランサーに適切なシステムにリクエストをルーティングさせるのは非常に簡単です。次に、最初のページを本番環境に導入できるストーリーを作成し、それらをアジャイルな方法で配信します。

デスクトップアプリケーションはより複雑になる可能性がありますが、多くの場合可能です。

継ぎ目を探しています。完全に書き直す必要なく、古いシステムが新しいシステムに責任を引き継ぐことができる場所です。

おそらく、新しいWebサービスまたはフレームワークに移動できる自己完結型のビジネスロジックがあり、古いアプリは古いコードの代わりにそれを使用して変更できます。残っているものがすべて一口で管理できるようになるまで、縫い目で塊を切り分けてください。

継ぎ目が見つからない場合は、他の回答のいくつかで提案されている種類のビッグバンアプローチを探す必要があるかもしれません。ただし、特に古いシステムを並行して開発し続けることが予想される場合は、目的地に到着する前に長い行進に備えてください...

アジャイルは、早期かつ頻繁にリリースすべきだと言っていますが、完全な書き換えが完了する前にリリースすることはあまり意味がありません。

実際、これが重要なポイントです-書き換えられたアプリケーションの一部を本番環境で早く取得する（そして理想的には古いシステムの機能を置き換える）ほど、プロジェクトが成功する可能性が大きくなります。これがあまり意味をなさないと思うなら、それについてもっとよく考えてください-パーツをリリースする可能性はほとんど常にあります。

おそらく、誰かが古いアプリケーションで何かを変更しなければならないことを意味します。たとえば、書き換えが完了していない間に書き換えられたアプリケーションとやり取りするためにいくつかの新しいインターフェースを追加します。しかし、私の経験では、このような追加の作業は常にそれ自体に対価をもたらします。

新しいアプリケーションの最初の部分が実稼働されると、アジャイルで反復的なアプローチが明らかになります。要件が変更され、ユーザーストーリーが変更または新しい優先順位が付けられます。古いシステムの機能を小さなステップでますます置き換えることが望まれます。