ソフトウェア開発のアジャイルで異なる側面
かんばんの手法はソフトウェアの保守やサポートの分野に適しているのに対し、スクラムは新製品の開発に適していると言われています。プロセスやメソッドは完了していません。適切なものを使用すると成功に役立ちますが、成功を保証するものではありません。
基本的にあるテクノロジーから別のテクノロジーへの再プラットフォーム化であるプロジェクトに最適なアジャイルアプローチはどれですか（たとえば、Javaから.NETへ）。
かんばん手法はソフトウェア保守やサポート分野に適しているのに対し、新製品開発にはスクラムが適していると言われています。
アジャイルコミュニティのほとんどの人は同意しないと思います。かんばんとスクラムはどちらも新製品の開発に適しています（私はかんばんと一緒にグリーンフィールドプロジェクトに取り組んできました）。
確かに、長所と短所が異なり、迅速な対応が最優先の場合、元の形式のスクラムはソフトウェアメンテナンスには適していませんが、ほとんどのチームは「純粋な」方法論を使用せず、ニーズに合わせて調整します。
基本的にあるテクノロジーから別のテクノロジーへのプラットフォームの再構築であるプロジェクトに最適なアジャイルアプローチはどれですか（たとえば、Java to .net）。
アジャイルの答えは次のようになります：しないでください。完全な書き直しが良いアイデアになることはめったになく、最も重要なことは、アジャイル開発の基本的なアイデアの1つに反することです。つまり、価値を迅速に提供することに焦点を当てる：完全に書き直した場合、完了するまでany値を提供しない可能性があります（失敗した場合は、おそらく決して提供しません）。たとえば、次を参照してください： 書き換えるかどうか 、および Joel on Software-絶対にすべきでないこと、パートI 。通常、最も苦痛を引き起こす部分を修正することをお勧めします。おそらく、ビットごとに（モジュールごとに）別のテクノロジーに移行します。最初はもっと難しいように見えるかもしれませんが、結果がはるかに速くなり、リスクが軽減されます。
とはいえ、書き直さなければならないと感じた場合、方法論はそれが書き直しであるという事実に依存しません。むしろ、チームの構成方法、チームの働き方、利害関係者とのコミュニケーション方法などに依存する必要があります。かんばんとスクラムの両方が適しています。