アジャイルは従来のソフトウェア開発ライフサイクルに同意しますか
かつては昔ながらのウォーターフォールプロセスを踏襲していた多くの企業が、スクラムに切り替えてアジャイル開発を行っていると主張しているのを見てきました。しかし、彼らのソフトウェア開発プロセスは、以前とそれほど変わらない。
- マーケティング/セールスは新機能のアイデアを思い付く
- 彼らはアイデアと要件をビジネスアナリストに渡し、ビジネスアナリストと協力して詳細な実装計画を作成します。
- アナリストは、完成した仕様を開発チームの責任者に渡します
- 開発責任者は、アナリストおよびマーケティング/セールスと協力して、要件と実装の詳細を明確にします
- 開発責任者がタスクを複数の部分に分割し、それらを特定の短期間スプリント（通常は1週間から1か月の長さ）で実行するようにスケジュールします。
- スプリントが開始されると、開発者には個別のタスクが割り当てられます
- 必要に応じて、開発者はアナリスト/マーケティングと連絡を取り、要件を明確にします（この段階で要件が大幅に変更され、現在のスプリント内で機能を完了できなくなった場合、スプリントから削除され、明確化のためにアナリストに戻されます）
- 開発者がすべてのタスクを完了すると、リリース候補が組み立てられ、QAチームに渡されます。
- テスターは、個々のタスクをテストするために割り当てられています
- スプリントの最後に、QA承認済みのリリース候補が本番環境に公開されます
- マーケティング/セールスを公開した後、要求された機能がどのように実装されたかを確認し、必要に応じて、アナリスト、開発責任者などに再度渡される改善要求を考え出します。
正式には、このアプローチはアジャイルマニフェストポイントと矛盾しないようです。開発チームは常に顧客（マーケティング/販売）と連絡を取り、顧客のニーズを明確にし、タスクを小さくしてフィードバックを早期に取得することで、間違った製品を出荷するリスクを最小限に抑えます（すべてのスプリントの終わりに）、確固たる契約条件に従うのではなく、価値を提供することに焦点を当てています。
しかし、どういうわけか、このアプローチは怪しげに見えます。すべてのアジャイル/スクラムチュートリアルは、「完全にアジャイル」にするために、さらに多くの変更を加える必要があることを示唆しています。チームをクロスファンクショナルにし、厳密な従来のマネージャー/開発/ QAの役割を削除し、個別の分析-開発-テスト-展開ステージを一般的なワークフローなど。
私の質問は次のとおりです。
- 上記の開発アプローチは、アジャイルマニフェストポイントと実際に矛盾していませんか？企業はそれを「アジャイル」と呼ぶのに正しく利用していますか？
- このアプローチと比較して、「フルアジャイル/スクラム」を実行するとどのようなメリットがありますか？
あなたが説明するプロセスについて何が怪しいのかわかりません。短いリリースサイクル（内部リリースであっても）と継続的な製品所有者のフィードバック、および各リリースで得られた知識に基づく計画の再評価を伴う反復型開発がある場合は、アジャイルだと思います。
反復開発の利点は古くから知られています。たとえば、Galls Lawは次のように述べています。
機能する複雑なシステムは、機能する単純なシステムから進化したものであることが必ずわかります。
これは、アジャイルマニフェストの25年前の1975年に作成されたもので、用語が発明される前の「ウォーターフォール」モデルを撃墜します。
SCRUMは、アジャイルよりもはるかに具体的なものです。 SCRUMは反復的な開発を義務付けるだけでなく、部門横断的なチーム、明確な開発者対QAの役割などのような要求も出します。 SCRUMはアジャイルよりも論争の的になっています。多くの場合、それは実用的ではなく（QAを開発者になるためにすぐにトレーニングすることはできないため）、その利点は疑わしいものです。
方法論は問題の解決策です。ウォーターフォールの問題はよく知られています。仕様からシステムを構築しますが、システムが終了すると、仕様が間違っていて不十分であることに気付き、変更が遅れています。反復型開発は、この問題の解決策です。
したがって、現在のプロセスが「完全にアジャイル」であるかどうかを尋ねる代わりに、現在のプロセスに観察可能な問題があるかどうかを検討する必要があります。その場合は、何らかの方法でプロセスを変更することが役立つかどうかを分析してください。
一部の人にとって最大の恐怖は、実際にはそうではないのに自分をアジャイルと呼ぶことによるかもしれません。原則の半分しか守らないのなら、スクラムをやっているのか？開発者の友人はこの偽善についてどう思いますか？
アジャイルマニフェストはそれほど具体的ではありません。それは意図的に行われました。彼らは他のことよりもいくつかのことを好むだけですが、他のことを避けることさえ提案していません（はい、まだドキュメントを作成する必要があります。最初はそれほど多くないかもしれません。）彼らはスクラムやXtremeプログラミングのような完全なレシピを提供しないかもしれません行う。 「新鮮な食材を使って料理し、人々が好きな食べ物を作る」と言っているのは、シェフのようなものです。
あなたの質問は彼らがアジャイルですか？実践とテクニックを忘れてください。以前の（ウォーターフォール）と現在のアプローチ（アジャイルであるかどうかに関係なく）を比較して、次のことを決定する必要があると思います。
- 変更をより速く処理できますか？.
- 機能をより早くリリースしていますか？.
これは測定不可能であると多くの人が言うでしょうが、彼らが本当に意味していることは、正確にするのは難しいということです。それを行うには間接的な方法があります。お客様に聞いてみてください。機能のリリースが早くなると思いますか？他にバグはありますか？それは十分に速いですか？あなたはソフトウェアの人々を好きにしています。これを複雑にしないでください。
これらの領域で状況が改善されていないと思われる場合は、プロセスを分解して、いくつかの特定のプラクティスを開始できます（確立された方法論によって推奨されるか、自分で理解することをお勧めします）。
上記の開発アプローチは、アジャイルマニフェストのポイントに本当に矛盾していませんか？企業はそれを「アジャイル」と呼ぶのに正しく利用していますか？
あなたが説明している会社は、4つのアジャイルマニフェストポイントの1つと矛盾しています。
- 計画に従った切り替えへの対応
開発前に完全な仕様を考え出すことは、まっすぐなウォーターフォールプロセスです。仕様が設定されている場合、プロジェクトは変更を歓迎することはほとんどできません（これは12のアジャイル原則の1つです）。アジリストは、大きな事前設計（別名、大きな要件）を非難します。なぜなら、それは顧客が何を望んでいるのかわからないで無駄になる可能性が高く、要件がおそらく変化するためです。
企業は1つ、2つ、または3つのアジャイルマニフェストポイントと矛盾する可能性がありますが、アジャイル開発企業とは言えないという意味ではありません。企業は、アジャイルプラクティスを実践している、またはアジャイル手法の下でアジャイルの原則に従っている限り、それらをアジャイルと呼ぶことができます。しかし、彼らがうまくやっているかどうかは別の問題です。
このアプローチと比較して、「フルアジャイル/スクラム」に移行するとどのようなメリットがありますか？
スクラムはプロジェクトの組織的な部分に影響を与え、そのルールと実践の優れた規律として機能します。いくつかの良いものは
ユーザーストーリー実行する作業を説明する反復バックログのタスクに分解されます-正しく実行されれば、説明のためにBAまたは顧客を追跡する必要はありません。ただし、完全な要件仕様のように、特定の機能のケースを完全にカバーすることはできません。
クローズドウィンドウルール-個人が機能を追加することを厳密に禁止し、スコープのクリープを減らすのに役立ちます。機能性は、スプリントが終わったときに評価することができ、アイデアを思いついたときほど素晴らしいものではないことがよくあります。ただし、それが本当にクリティカルである場合、製品の所有者はスプリントをキャンセルして追加することができます。
毎日のスクラム会議-「前日に何をしましたか？」、「今日は何をしますか？」という3つの質問。そして「何か障害は？」プロジェクトメンバーに、プロジェクトで何が行われているのかについて概要を説明します。
いいえ、あなたが説明したようなウォーターフォールスタイルの開発プロセスは、アジャイル開発を行う人々がアジャイルと呼ぶものではありません。しかし、あなたが本当にそれを何と呼んでいるかは誰が気にしますか
本当の質問は、なぜあなたはアジャイルをしているのですか？それがクールに聞こえる流行語だからといって、現在のプロセスをアジャイルと呼ぶのは確かに十分です。人々は流行語をよく使うようになり、誰も彼らの働き方を変える必要はありません。
他の目標*がある場合でも、プロセスがアジャイルと呼ばれるか、アジャイルであるかは問題ではありません。重要なのは、これらの目標が達成されたかどうかです。
言い換えれば、「「フルアジャイル/スクラム」を使用することで、このアプローチと比較してどのようなメリットがあるのですか？は、経営陣がアジャイルを導入する前ではなく、アジャイルを導入する前に自問すべきです。
*優先順位の変更がより安く、より早い成果物、より高い品質、より良い士気、より満足した顧客、より低いコスト、より高い生産性、より高い透明性は、通常アジャイルに関連するものの一部です。しかし、どれを達成できるかは、どのプロセスから来ているかによって多少異なります。
あなたの会社をよりアジャイルにするかもしれない異なる慣行があります。人々に仕事が割り当てられていることを読むと、スプラインを震わせ始めますが、それが機能する場合、それは反アジャイルの見方ではありません。
アジャイルフルーエンシーモデル をご覧ください。レベル1に近づいているように感じますが、はしごを上ることはまだまだあります。