既製のソフトウェアはアジャイル開発にどのように適合しますか?[閉まっている]

https://stackoverflow.com/questions/51649

agile

09-06-2019
|

質問

私のアジャイル開発に対する理解は十分ではないかもしれませんが、最終的なシステムがどうあるべきかという要件や知識が十分に整っていない場合に、アジャイル開発者が既製 (OTS) ソフトウェアをどのように使用する可能性があるのか興味があります。私が理解している限りでは、(多くの場合、開発の反復ごとに) 急速に変化しています。

私にとって特に興味深い状況が 2 つあります。

(1) OTS システムは、既存のシステムに統合される可能性を除き、ほとんどまたはまったく変更を加えることなく、初期の一連の要件を満たします。ただし、開発を数回繰り返すうちに、このシステムはコアコードを書き直さないとニーズを満たせなくなります。開発者は、この OTS ソフトウェアの背後にあるコアコードの学習に追加の時間を費やすか、それを捨てて最初から構築するかを選択する必要があります。どちらの場合も、開発時間とプロジェクトのコストに大きな影響を与える可能性があります。

(2) 初期のニーズは既存の OTS システムとは異なりますが、最終的に顧客が製品を受け入れると、要件の追加や削除により、既存のソリューションとほぼ同じになります。開発者がより多くの要件を抱えていて、事前にそれらの作業にもっと多くの時間を費やしていたら、再度構築する代わりにこのソリューションを使用できたかもしれません。プロジェクトは実現しましたが、納期が遅く、必要以上に高いコストがかかりました。

ソフトウェアエンジニアとしての私の責任の 1 つは (私が教えられてきたように)、(とりわけ) 可能な限り低コストで高品質のソフトウェアを期限通りに顧客に提供することです。アジャイル開発では高品質のソフトウェアを実現できますが、場合によっては、手遅れになって多額の費用が費やされるまで、より優れた代替手段があることがわからない場合もあります。

私の質問は次のとおりです。

既製のソフトウェアはアジャイル開発にどのように適合しますか?
アジャイルマネージャーとアジャイル開発者はこれらのケースにどのように対処しますか?
アジャイルパラダイムはこれらのケースについて何を言っているのでしょうか?

解決

シナリオ 1:

これは、コンポーネントの OTS の性質に関係なく発生する可能性があります。アジャイルとは近視眼的な意味ではありません。大きな部分を知る必要があるでしょう。フレームワークの一部を理解し、事前に検討時間を費やします。そうは言っても、自分が知っていることに基づいて構築することしかできません。責任ある最後の瞬間までのみ遅らせてください。その後、選択肢の 1 つを選択して、それを開始する必要があります。(社内での開発コストが不可能でない限り、サードパーティ製アプリケーションは避けたいと思います。しかしそれは私だけです）。複数のソリューションのプロトタイプを作成し、既知の要件のリストを使用して実現可能性を確認します。物事を疎結合 (交換可能) にし、簡単に変更でき、完全にテストできるようにします。ハッキングを続けるか書き換えるかの分岐点に達したら、どちらがビジネスにとってより価値があるかを考えて、そのオプションを選択する必要があります。それは、「ここに来て、今私たちにできる最善のことは何だろう？」ということです。

シナリオ 2:

チームが要件を「最終決定」するために 2 ～ 3 か月を費やした結果、市場のニーズや顧客の考え方が変わって「今はこうしたい」と気づくのに比べれば、このようなことが起こる可能性は低いですが。もう一度言いますが、問題は、行動に移す前に調査と探索の準備がどの時点までにあるのかということです。それまでに得た情報をもとに賢明に判断してください。後から考えると常に 20 対 20 ですが、顧客は永遠に待ちません。要件が統合されて既知の OTS コンポーネントに適合する時点まで待つことはできません :)

アジャイルは意味のあることは何でも実行し、付加価値のないアクティビティを取り除きます :) アジャイルは特効薬ではありません。 私のアジャイルな2セントだけです:)

他のヒント

それ自体は厳密な答えではありませんが、次のような場合には、既製のソフトウェアをソフトウェアソリューションのコンポーネントとして使用することが非常に有益であると考えられます。

データはオープンです。オープンなデータベースまたはそれと対話するための Web サービス
既製のシステムはカスタマイズ可能 簡単に ソリューションの残りの部分に同様のプログラミングパラダイムを使用する
残りのワークフローにシームレスに適応できます

私は車輪の再発明をしないことの大ファンです。開発スキルを利用して既製のソリューション間の「接着剤」を設計することは、大きな成功となる可能性があります。

「オープン」が重要な部分であることを忘れないでください。ベンダーは、実際にはオープンではないにもかかわらず、自社のソリューションをオープンであると宣伝することがよくあります。

どこかで読んだ気がします。イテレーション中に最初に考えていたより 20% 以上多くの作業があることに気付いた場合は、スプリントを放棄し、追加の作業を考慮して新しいスプリントの計画を開始する必要があると思います。

したがって、これは、詳細を把握した上で、企業が元の要件を引き続き進めたいかどうかを確認するために、企業と再計画することを意味します。

当社では、スプリント前にプロトタイピングを利用して、このような状況がスプリントで発生する前に特定できるようにしています。もちろん、それでもあなたが説明しているような状況を特定できないかもしれませんが。

C2 wiki のディスカッション: http://c2.com/cgi/wiki?BuyDontBuild

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow