「来たものに取り組む」と比較したスクラムの利点は何ですか？
アジャイル開発、特にスクラムの利点については多くのことが伝えられていますが、これらの評価のほとんどは、組織がウォーターフォールの非常に厳格な方法論に基づいていると想定しています。しかし、企業がスクラムの助言よりも厳格に組織されていない場合はどうなるでしょうか？
私が働いている組織は以前のスタートアップです。チームは、問題や要件が発生したときにそれに取り組むことに慣れています。組織はスクラムの実装に中途半端な試みを行っていますが、一般的な態度はかなり否定的であり、多くの人々はスクラムを単なる企業のレッドテープと見なしています。より多くの規律を適用することでどのようなメリットがありますか？
開発者側では、チームはセッションの計画のためにコーディング時間を犠牲にすることに消極的です。特にチーム全体が参加することになっている場合：これまでのところ、計画や見積もりはチームリーダーだけで行われていました（開発者の一部から積極的に支援を求めた場合を除く）。
一方、ビジネスは、2週間前から詳細な要件を事前に提供する必要があることに慣れていません。これまでのところ、彼らは当時最も必要なものの一般的なスケッチを提供し、外出先でそれを具体化しました。さて、スプリントの開始時に要件にギャップがある場合、チームは理論的にはアイテムが「準備完了」ではなく、新しい機能が次の2週間は機能しないことを伝える必要があります。最短で1か月で展開されます。この柔軟性の損失をビジネスにどのように受け入れさせますか？
すでに混乱の点まで機敏である企業に、アジャイル開発をどのように販売しますか？
チームが管理者が許容できる速度で適切な品質のコードを作成している場合、スクラムを使用しても何も得られません。ある意味では、スクラムは、チームをこの正確な状態に到達させるためのフレームワークです。
ただし、コードの品質が低い場合、または開発したコードが必ずしもエンドユーザーのニーズを満たしていない場合、または管理者が開発プロセスの透明性の欠如に不満を抱いており、開発スケジュールに関する計画が困難である場合は、スクラムが役立つかもしれません。
スクラムは、予測可能な方法で最終顧客に真の価値を提供する取り組みにチームが集中できるよう支援することで、変化を受け入れることを目的としています。短いフィードバックサイクルを導入することで、チームは顧客が必要とするものを正確に提供していることを確認できます。さらに、経営陣は、チームが現在何をしているのか、今後数週間でチームが何を計画しているのか、機能の準備が整う時期について、より明確に把握できます。
そして最後に、スクラムはチームが継続的な改善を通じてソフトウェアを書くことに上手になるためのフレームワークを提供します。
スクラムを使用するチームの最終結果は、ユーザーのニーズを満たす高品質のコードを予測どおりに提供できるチームです。もしあなたのチームがすでにそれをしているなら、あなたがしていることを変える意味はありません。
スクラムに対する直感に反する利点の1つは、バックログに優先順位を付け、実際の容量を実際に認識し、進行中の作業を制限することを強制することです。私たちがスクラムを始めたときにわかったことは、彼らが来るときに物事に取り組むことによって本当に反応的であると思っていましたが、実際に私たちが取った新しいことはどれも自分をより薄く広げ、すべてを遅らせました。
つまり、優先度の高い3つのタスクを2週間で完了してから、次の2週間で次に優先度の高い3つのタスクを完了するのではなく、6つすべてに一度に同意しますが、いずれかを完了するには1か月かかります。私たちはより薄く広がっていたので、それら。より少ないタスクにリソースを集中させることで、より迅速に価値を提供できます。
また、クッキーカッター型のようにスクラムを正確に行わないでください。 1週間の反復を行うことができます。ほとんどの計画と見積もりを1人に委任できます。ストーリーを開始する準備ができたときの独自の基準を作成します。定期的な回顧展を開催し、ニーズに合わせて調整します。プロセスおよびツールを介した個人および相互作用。
あなたはここにいくつかの良い反応がありますが、私には何の違いもありません。
私はあなたの現在の状況についてあなたが言った何かの鍵を握りました。アジャイルはカオスではありません。アジャイルであると主張する多くの人々に出くわしました。彼らは非常に柔軟で、重いプロセスがなく、効率的だと思っているからです...
私は、正式なフレームワークを持たない起業家企業で働いていましたが、彼らは彼らが機敏であると思っていましたが、あなたは正しいです。カールビーレフェルトの反応はまったく正しい。アジャイルフレームワークを採用することには多くの利点があり、それに伴う継続的な改善の原則があります。スクラムは1つの方法にすぎません。
このアプローチは、スタートアップの初期段階では素晴らしいかもしれません。しかし、規律の欠如は、時間の経過とともに会社の成長を妨げる可能性があります。
ちなみに、かんばんはスクラムよりも規律が厳しくはありません。正しく行われると、実際にはより厳格になります。プロセスとビジネスを確認し、軽量化を維持しながら、いくつかの利点をもたらす何かを調整するのを支援するには、アジャイルコーチが必要になる場合があります。たぶん、スクラムはあなたにぴったりかもしれません。おそらくそれはかんばん、XP、またはブレンドです。あなたの会社、あなたの製品、あなたの開発文化などを知るために少し時間をかけずに誰もあなたに言うことができません。