チームでスクラムを実践しようとしました。しかし、私の同僚は私に尋ねます：
私たちのソフトウェアには明確な要件があります。では、なぜスクラムを使用する必要があるのか
どうすれば彼をこの事件から説得できるでしょうか。
2 に答える
3
viや emacs、Tide の洗濯用洗剤、歯ごたえのあるピーナッツ バターを使用するのと同じように、スクラムを使用するべきではありません。スクラムは、チームが協力して作業するための多くの方法の 1 つにすぎません。チームがすでにうまく連携している場合、スクラムに切り替える正当な理由はないかもしれません。
スクラムの利点は、チームが大きな問題を一連の小さな問題に減らし、それらの問題に対する解決策をタイムリーに優先順位に従って提供できるようにすることです。また、間違ったものを作成しているかどうかを後でではなくすぐに確認することが容易になるため、修正を行う時間はまだあります。
ソフトウェア業界が過去数十年にわたって何かを学んできたとすれば、それは要件が常に変化しているということです。スクラムは、それが起こらないことを願うのではなく、その事実を受け入れるように設計されています。
管理の観点から見ると、スクラムにより、プログラム マネージャーは、プロジェクト全体がいつ完了するかをより正確に予測できます。歴史は、タスクが小さければ小さいほど、見積もりが容易であることを示しています。すでに要件を把握して理解しているものの、2 か月かかると見積もられるものを構築している場合、2 か月かかることもありますが、3 か月かかる可能性があります。または4。または8。ストーリーを作成してサイジングするプロセスを経ることで、より正確な見積もりが得られる可能性があります。
以上のことから、チームがスクラムを使用したくない場合は、絶対にスクラムを使用しないでください。スクラムは、個人の集まりではなく、チームによって使用される場合に機能します。グループ全体がスクラムに従うことを望んでいない場合、スクラムは効果がありません。
于 2015-09-06T15:31:52.477 に答える
1
アジャイルが良いことである理由はいくつかあります。要件が 100% 明確であるものの、実行の最も価値のあるシーケンスが不明であり、部分的な成果物を早期に提供することで、早期に価値が得られる可能性があることを前提としています。
一部の機能を早期に提供することで、すでに価値が解き放たれている可能性があります。最初に admin モジュール、次に print モジュール、次に report モジュール、最後に基礎となるビジネス ロジックをリリースすることで、アプリケーションを構築できます。この順序では、ビジネス ロジックが実際に実装されるまで、値は 0 になります。その間ずっと、他のモジュールが埃をかぶっていて、それらの値が遅れていました。ビジネス ロジックと部分的なレポートと管理モジュールを最初にリリースすることで、アプリケーションをより早く運用に移し、より早く価値を引き出すことができる可能性があります。そうすれば、ROI が向上します。
早期納品により、アーキテクチャ、展開、およびインフラストラクチャを証明できます。製品をより小さなビットで提供することで (ユーザーの小さなサブセットが早期に使用できるようになる可能性があります)、アーキテクチャを早期に証明でき (したがってリスクが軽減されます)、デプロイ スクリプトをテストする複数の機会が得られます。アプリケーションが頻繁に使用されている場合、エンド ユーザーへの影響を大幅に抑えながら、はるかに短い時間で修正を展開できます。
早期配信はフィードバックを提供します。あなたは、要件が 100% 明確であると考えています (想定しています)。多くの場合、それらはめったにありません。または、実際のアプリケーションを見て、実際には必要なことを正確に実行していないことに気付く場合があります。動作するソフトウェアを定期的に見せることで、要件を 100% 理解していることを継続的に証明する機会が得られます。より伝統的なウォーターフォールを行う場合は、要件を知っていることに賭けます。アジャイルな方法では、間違っていることが早い段階でわかり、方向を変えるチャンスがあるため、間違っているリスクははるかに低くなります。
多くのアプリケーションの 60% の機能はまったく使用されていません. マイクロソフトのワードを例にとってみましょう。拡張性モデルを実際に使用している人はどれくらいいますか? 埋め込まれた XML? そして、時間の経過とともに製品に忍び込むこれらの機能のかなりの数. 確かに、これらの各機能には市場がありますが、多くの人はワードパッドのもう少し高度なバージョンで十分です。Microsoft のような市場規模を持っていない限り、word のすべての機能をウォーターフォール方式で備えたアプリケーションを構築し、それをリリースするには、非常に非常にコストがかかります。アジャイルに行うことで、必要のない機能を構築することなく、早期に停止することができます。多くのウォーターフォール開発プロジェクトでは、多くの場合、要件は実際に必要な量を超えています。多くの「ビジネス」は、彼らが最終的に得られることを知っている以上のものを求めています。
要件が 100% 既知であるという仮定が正しいことを証明できますか? できないと思います。特に要件は時間の経過とともに変化する傾向があるためです。しかし、小規模なプロジェクトや非常に明確な作業 (法律や何らかの認証によって要求される可能性があります) の場合は、何が必要かを正確に把握して構築するだけで済みます。
あなたは、要件がすでにわかっているとだけ述べています。それは、開発者がそれを構築する方法を正確に知っているということですか? そして、それをテストできるかどうか、またその方法を正確に把握しましたか? そして、最も有用な配達順序を知っていますか? インフラストラクチャはアプリケーションを処理できますか? これらの質問はすべて、実際の製品の小さな部分を構築し、それらを継続的に統合することで簡単に答えることができます.
もちろん、すべての部品がどのように組み合わされるかを紙の上で正確に理解できるかもしれませんが、ドメインを知っていて、実績のあるテクノロジ (通常は少し古いテクノロジ) を使用し、非常によく似たものを既に構築している場合は、非常にまれなケースでうまくいきます。少なくとも3回。古いものを使用して技術的負債を生み出すことを自分自身に許している場合、おそらくアジャイルを一切使用しなくても済むでしょう。
途中で多くのバックログの改良を行う必要がありますか? 多くの要件がすでにわかっている場合は、そうではないかもしれません。他のすべての正当な理由から、特にすべての要件が既知であると想定されている場合、アジャイルな方法で作業することで多くのメリットがあると私は言います。
あなたのチームがこれらの理由を受け入れるのであれば、ぜひアジャイルに行ってください。それがスクラムであろうとなかろうと。少なくとも定期的に配信し、作業が継続的にテストされ、展開されていることを確認してください。チームがそれを受け入れない場合は、上記のポイントを取り入れようとする方法でウォーターフォール プロジェクトを構成してみてください。定期的に配信し、作業が継続的にテストされて展開されていることを確認してください...待ってください...それは、少なくとも反復的で段階的な配信ではないにしても、アジャイルのように聞こえます;)。
于 2015-09-06T15:40:16.203 に答える