アジャイル手法で優れたソフトウェアを開発する方法は？
顧客満足度のカノモデル は、さまざまなクラスの製品機能を定義します。その中には
必須の品質：これらが実装されていない場合、顧客は製品を受け入れません。
魅力的な品質（喜び）：お客様が最初から期待していなくても、発見されたときに興奮と喜びをもたらす機能。
魅力的な資質には、明らかに多くのビジネス価値があります。中古のフィアットが5.000未満ですべての必須要件を満たしている場合、500,000でフェラーリを購入させることになります。
ただし、私が知っているすべてのアジャイルプロセスは、必須の要件を強く支持しています。これらは常に最優先されます。アジャイルで魅力的な資質を提供する場所はないようです。
アジャイルプロセスはソフトウェア開発に非常に役立つと思います。しかし、それらをどのように適用すれば、必要不可欠な要件をほとんど満たす最小限の機能だけでなく、高品質のソフトウェア製品を作成することができますか？
補遺：最初の2つの答えが指摘したように、必須要件に最高の優先順位を与えることは理にかなっています。しかし、私たち（そして顧客）は、必ず必要条件を事前に知っていますか？初めに高い優先度を与えられた要件が後で役に立たないとしても、それほど重要ではないことが判明した経験を数回行いました。したがって、必須の要件に怠惰に焦点を当てるべきではないと私は信じています。
正式な答えは、アジャイルは誤解され、アジャイルは要件を規定するものではなく、利害関係者が規定するものです。アジャイルの核心は、要件を石に刻むことではなく、クライアントと密接に連絡を取りながら進歩的な洞察の恩恵を受けて、要件を明確にすることです。
しかし、それはすべての理論です。あなたが目撃したのは確かに、機敏な作業方法を採用した多くのソフトウェア生産ラインの共通の特徴です。
問題は、顧客の声を聞き、顧客のニーズに迅速に対応することは、すぐに製品について何も考えなかったり、設計をまったく行わなかったりすることです。かつてビジョンと専門知識によって供給されていたプロアクティブなプロセスであったものが、顧客の希望によって供給される受動的で完全にリアクティブなプロセスに劣化する可能性があり、しばしば悪化します。これは、「仕事をする」という必要最小限のものを作ることにつながります。
当時のメーカーが「機敏」だったとしたら、自動車は発明されなかったでしょう。
これはアジャイルを悪くしません。それは共産主義のようなものです。人々はただの人々であり、人々のことをしているので、ほとんどうまくいかないという素晴らしいアイデア。そして、方法/イデオロギー/宗教は、彼らが運動をしている間および/またはルールに従っている限り、彼らがうまくやっているという考えに彼らを落ち着かせます。
[編集]
Slebetman：
皮肉なことに、アジャイルが自動化産業（つまり、トヨタ）から進化しました。
自動化の黄金律を覚えていますか？ 「最初に整理してから自動化する」。壊れたプロセスを自動化する場合、発生する可能性のある最良の方法は、問題が発生するすべてを加速することです。トヨタの人たちは馬鹿ではなかった。
新しい方法論を採用する一般的な理由は、物事がうまくいっていないことです。経営陣はそれを認めていますが、彼らは核心的な問題を理解していないかもしれません。そのため、彼らはアジャイルとスクラムについて弾力的なスピーチを与えるこのグルを雇っています。そして、誰もがそれを愛しています。彼ら自身の理由のため。
開発者は「ねえ、これでうまくいくかもしれません。私たちはビジネスの問題にもっと関与し、このバックログを埋めるための入力を提供できます。これは、セールスとカスタマーサービスに私たちの仕事、なぜ必要なのかを理解させる機会になるかもしれません。私たちが合意したことを透明に燃やしている間、私たちはそれらを髪の毛から取り除くでしょう。」デスクにポップアップを表示するのを遅らせたくない相手によって、「今やっていることをやめなさい。これは今やらなければならない」ではありません。
一方、営業、カスタマーサービス、または所有者は、おそらく必要なことを行っている部門のこのブラックボックスを（バック）コントロールする方法としてそれを見るかもしれません。彼らはそこで何が起こっているのかはわかりませんが、問題の核心がそこに潜んでいると確信しています。そこで、彼らはスクラムを紹介し、好きな製品の所有者をインストールします。突然、すべてがコントロールできるようになり、すべてのストリングが手に入ります。さて…？.
本当の問題は、ショップが最初からうまく整理されておらず、これが変わっていないことです。人々は処理できない責任を割り当てられているか、おそらくはできるが、ボス氏は常に彼らの行動を妨害し台無しにしている。
時々、非公式の組織が正式なラインの間に出現することがあります。これにより、正式な構造の欠如を部分的に補うことができます。名刺を持っているかどうかにかかわらず、得意なことをやってしまう人もいます。アジャイル/スクラムの率直な導入は、それを即座に台無しにするかもしれません。なぜなら、人々は今やルールに従うことを期待されているからです。彼らはかつて何をしていたかが評価されないと感じ、代わりに小さな話が書かれた黄色の小さな紙を受け取り、メッセージは「あなたがやっていたことは何でも、誰も気にしない」です。言うまでもなく、これはそれらの個人に特にやる気を起こさせるものではありません。彼らはせいぜい注文を待つことから始まり、もはや主導権を握らないでしょう。
したがって、事態はさらに悪化し、結論はアジャイルが悪いことになります。
アジャイルは吸わず、メンテナンスプロジェクトに最適であり、注意深く適用すれば新しい開発にも役立ちますが、間違った人々がそれを理解しなかったり、間違った理由でそれを採用したりすると、最も破壊的になる可能性があります。
アジャイルで魅力的な資質を提供する場所はないようです。
リンゴとオレンジを比較しています。従来のウォーターフォールでは、必須条件で必須アイテムが必要であると言う場合、フィアットを取得します。要求がそれが一流である必要があると言うならば、あなたはフェラーリを手に入れます。
同じことがアジャイルでも起こります。あなたの要件が必需品で止まるなら、あなたはフィアットを手に入れます。あなたが卓越したストーリーを持っているなら、あなたはフェラーリを手に入れます。俊敏なreallyが適用するのは、必須のfirstを実行することだけです。 2年間超クールなスポイラーを構築せず、エンジンの期限を逃さないでください。
要するに、短い話です。必要なものが手に入ります。スポーツカーを計画しているなら、あなたはスポーツカーを手に入れます。アジャイルはそれをまったく変えません。アジャイルプロセスでフィアットの要件が発生した場合は、アジャイルを非難せず、フィアットのみを必要とする人を非難します。
ただし、私が知っているすべてのアジャイルプロセスは、必須要件を強く支持しています。これらは常に最優先されます。
彼らがすべきこと-あなたのカノモデルをもう一度見てください：必須要件が満たされていない場合、顧客は製品を受け入れません。そして、あなたの喜びは関係ありません。
アジャイルで魅力的な資質を提供する場所はないようです。
真実と違うことがあってはならない。
アジャイルプロセスは通常、次の点を強調します。
- あなたがフィードバックを得ることができる実用的な製品の頻繁な配達。
- フィーチャーを小さなパーツに分割し、短時間で完成させることができます。
- これらのパーツを優先順に実装します。
「楽しい」機能を優先することを妨げるものは何もありません。それは、優先順位の決定を担当する人々に完全に依存します。
現在、そのような人々の多くはリスクを冒さないことを好み、したがって「喜び」に高い優先順位を与えない可能性があります。しかし、まだそうであろう非アジャイルプロジェクトでは。
優れたソフトウェアは次の2つに由来します。
顧客に必要なものを提供する
プロであること
ソフトウェアを開発する際に従うべきあらゆる種類の原則があります。乾燥、可読、SOLIDなど、お客様の要件とは関係ありません。顧客はスポーツカーを求めました。顧客がスポーツカーを素晴らしいものにするために必要なことを理解していれば、彼らはあなたを必要としません。他に何が重要かを理解するのはあなた次第です。
私たちの仕事の一部は、物事がひどくうまくいかない限り、顧客が経験することのない基準を維持することです。
あなたがそれを正しくやっているなら、それが顧客が本当に望んでいるときだけ、アジャイルはフィアットに向かう傾向があります。それが彼らが解決する必要があると彼らが考えているものではないとき。
ハイエンドのスポーツカーの要件についての誤解が収まると、ウォーターフォールは変わります。アジャイルは、新しい情報に対処し、本当に必要なものが弾丸バイクであることが判明した場合に適応できます。
現在でも多くの店で滝が使われています。これらのショップは、要件の変化が1年で2％未満であるため、成功しています。
あなたの仕事は、顧客に欲しいものをただ与えることではありません。また、クレジットがまったく得られないことがわかっていることにも注意してください。あなたが物事をひどく間違って行かせない限り、顧客が持ち出すことのない事柄。これらのものはよく選ばれるべきです、そうでなければあなたはそれらに時間を浪費するためにがらくたをたくさん取るでしょう。
バカなら誰でも無制限の予算で橋を架けることができる。専門家は、ほとんど倒れることのない橋を築きます。
したがって、私は、必須の要件に怠惰に焦点を当てるべきではないと思います。
もちろんそうすべきです。あなたの時間を推定するときを除いて。なぜなら、これらの必須要件だけが考慮事項ではないからです。
アジャイルはwhatについては何も最初に行わないでください。そのコードのみを増分的に記述し、次のリリース可能な状態になるまで数か月間使用できないようにするのではなく、できるだけ頻繁にリリース可能な状態に保つ必要があります。
私はアジャイルとBDUF（Big Design Up Front）プロセスの両方で作業してきましたが、両方のプロセスから革新的で魅力的な機能を確実に得ることができますが、当然ながらBDUFでは、それらを前もって計画する必要があります。つまり、イノベーションは一般に、設計プロセスに影響力を持つ人々によって提案されるか、少なくとも後援される必要があります。
これは、次のリリースまで6か月（または何でも）あり、プロジェクトマネージャーはそのリリースの内容についてストレスを感じているからです。 。そのため、満員のスケジュールには機能が満載のリストがあり、低ランクとファイルが2、3日間クールな作業に巻き込まれた場合、顧客は気に入ると思いますが、それはリスト、彼らは全体のスケジュールを危険にさらし、支払うべき地獄があります。
アジャイルプロセスでは、ソフトウェアをリリース可能な状態に保つように努めています。プロジェクトマネージャーは、機能が低下しても2週間で取得できるため、ストレスを軽減できます。したがって、開発者がクールなアイデアで会議から戻ってきて、何かに2、3日費やしても、6か月の血に書かれたスケジュールを危険にさらすことにはなりません。
基本的に、あなたはあなたが蒔いたものを刈り取ります。イノベーションを促進し、チームに提供する十分な自律性を与えると、それが得られます。締め切りに間に合わせるために常にコーナーを切り詰めることを要求する場合、方法論に関係なく、ソフトウェアを一致させることができます。
OK、
アジャイルでは、プログラマーはソフトウェアを作成できますが、最終的には製品を作成するのは製品所有者です。 （ソフトウェア開発者を使用して。）
「魅力的な資質」については、製品の所有者次第です。
製品所有者が「セクシーなデザイン」を義務付けている場合、それは要件にすることができます。開発者はこれらの選択について心配する必要はありません。
また、ソフトウェアは実際の物理的な製品とは非常に異なるため、カノモデルの多くは適用されないと思います。たとえば、なぜFacebookを使うのですか？唯一の理由：友達がそうするからです。それを次のスプリントに入れる方法........また、ソフトウェアの最も魅力的な特質の1つは、実際に行うべきことを実際に実行することです。 （そして、それがアジャイルが大いに役立つところです：P）
私の経験は上記のコメントに同意します-優れたソフトウェアの開発を妨げるアジャイルには何も固有はありません-しかし、アジャイルにはいくつかの側面があります多くの場合、（十分に）十分に機能するソフトウェアにつながる（不正な）練習が行われます。
- アジャイルはsomethingをできるだけ早く取得することに重点を置いています。ただし、これは、特にユーザーから見えないインフラストラクチャで、仮定を単純化し、コーナーを切り詰めることを意味します。これについては本質的に問題はありません。if単純化する仮定を修正するコストは低いです。ただし、多くの場合、この「技術的負債」は製品が生産される前に削除されません。
- アジャイルは、スプリントの最後に、できる限り出荷可能に近いものを常に持っている必要があることを説きます。これにより、利害関係者とプロジェクトマネージャーは、「持っているもの」で十分にプッシュできると判断できます。製造。繰り返しますが、これに固有の問題はありません。ifすべての「技術的負債」をクリアしました（または、自分が持っている量と場所で平和を作りました）しかし、私の経験では、「出荷のプレッシャーがなくなったらすぐにクリーンアップする」というマネージャーの約束により、あまりにも多くの技術的負債が生産に費やされ、急速に「生産中です。私たちは今何を変えるかについて非常に注意しなければなりません」、そしてそれは最終的に「あなたは私たちにその露出があるとは決して言わなかった！私たちは次回より良い仕事をしなければならない！」ベン・フランキンの「低価格の甘さを忘れた後も、質の悪い苦味は長く残る」という教訓は決して学ばないようです。
- ただし、信頼できるマネージャーやよく練られた開発者であっても、適切な分析、設計、および設計レビューがほとんど発生しないという一般的な問題がありますprior実装の開始と完了が予想されるスプリントの開始。 alternativeUIのメタファーとデザインを慎重に検討する失敗は大きく、プロジェクトの開始後にこれを大幅に修正すると、通常、コストがかかりすぎます。ジュニアチームが競合他社の製品を注意深く調査しなかったり、I18N、通知フレームワーク、ロギング、セキュリティ、APIバージョン管理戦略などのインフラストラクチャテクノロジーの定義と実装に優先順位を付けなかったりすると（たとえば）、最終的にはバグが増えることになります。必要なトレーニング、分析、設計、プロトタイピングを行うために最初の2〜5回のスプリントを先行して費やした場合よりも、生産性が低下し、より多くの技術的負債が発生します。つまり、アジャイルチームはハッキングのライセンスに抵抗する必要があります。
- 私はセカンドレベルのマネージャー（開発者100人以上）がいて、最も基本的なレベルであっても、開発者が計画した設計を書くのに時間をかけるのをやめさせました。彼の推論-「人々に互いに話してもらいたい」-それは彼らが5つの異なるタイムゾーンと3つの国にいたので皮肉でした。言うまでもなく、誰もがその他のことを考えていることがわかった後、プロジェクトの後半で多くの夜と週末を過ごす必要のあるチームについて、多くの指示がありました。 guyは、一部の機能を実装する責任がありました（または、サプライヤとコンシューマのデザインがメッシュ化しなかったため、再実装しました）。
プロジェクトマネージャーと利害関係者wantが高品質の製品を提供するかどうかが、すべての問題です。彼らがそうすることにコミットしている場合、アジャイルはそれを可能にします。 OTOH、アジャイルはスケジュールの意思決定を利害関係者とプロジェクトマネージャーのみの手に委ねているため、アジャイルは開発チームがそのサポートなしに優れたプロジェクトを提供することを困難にします。要するに、製品の品質に対する説明責任は、プロジェクトマネージャーの足元にほとんどあります。
Must-be qualitiesを決定するのは難しいことがよくあります。人々は良心にそれらを持っています。アジャイルなイテレーションとクライアントの参加は、必須のほとんどを見つけるのに役立ちます。 それがアジャイルの力であり、それを無視するのは愚かです。One-dimensional qualitiesつまり、実行する必要がある約束は、変更されない限り、ウォーターフォールOKによってサポートされます。ここでアジャイルであることは役立つだけで、それほど強力ではありません。Attractive qualitiesは素晴らしい機能です。彼らは次世代のマストアイテムになる可能性があります。しかし、現在の世代では、それらは合意にさえありません-そうでなければ、それらは一次元の特質です。クライアントの代表者の参加を想定したこれらのアジャイル手法は、これらの資質を非常によくサポートしています。作業中にスコープを軽く変更できるからです。ある場所での改善のために別の場所でいくつかの補償を交渉することができます。滝では実際には不可能です。大幅な組織的な遅延がなければ、無料で機能を追加することしかできませんでした。以前にいくらかの時間を予算に入れておけば可能です。
したがって、アジャイルプロセスはKanoモデルをサポートできます。それらのいくつかは、それを非常に大きく、間違いなく最高のウォーターフォールプロジェクトよりもはるかに優れています。
理解を深めるには、責任あるクライアントの代表的な参加者にアジャイルプロセスを設定する必要があります。
私はこのパーティーにかなり遅れていますが、このテーマについて別の見方を共有したいと思います。
しかし、それらをどのように適用すれば、必要不可欠な要件をほとんど満たす最小限の機能だけでなく、高品質のソフトウェア製品を作成することができますか？
アジャイルソフトウェア開発には時間的側面があり、これは反復的アプローチとアジャイル方法論の2つの重要な要素である顧客フィードバックを考慮した結果です。 。例：反復tで魅力的な品質として識別される機能は、次の反復t + 1で必須の品質になる可能性があります。
アジャイルメソッドを適用すると、機能の品質カテゴリを動的に変更できます。イテレーションtの計画された機能を、後のイテレーションt + nの完成した機能と比較すると、あなたが言ったことを正確に体験できます。
初めに高い優先度を与えられた要件が後で役に立たないとしても、それほど重要ではないことが判明した経験を数回行いました。
この一時的な側面を念頭に置いて、アジャイルメソッドが楽しい高品質のソフトウェア製品を生成できることはもっともらしいwhile集中する最小。 反復的アプローチ顧客のフィードバックと組み合わせると、時間の経過とともにゲームのルールが変わります。
結論
アジャイル手法で優れたソフトウェアを開発する方法は？
反復的なアプローチを適用し、顧客のフィードバックを聞きます。これらの要素の1つを捨てると、アジャイルソフトウェア開発の成功率が低下します。
> How to develop excellent software with agile methods?
- 顧客固有の個別ソフトウェアを作成する場合：
- 「楽しい」機能には追加の費用がかかるため、費用が問題にならない顧客を見つけます。顧客は、この費用を支払うかどうかを決定する必要があります。
- 生産時Softwareproducts：
- 「楽しい」機能は新規顧客を引き付けるのに適しています。製品が1000回以上販売されている場合、「楽しい」機能を実装するためのコストはそれほど重要ではありません。
- 「十分な（最も安い）が最高」の環境では、「楽しい」機能を実装するためのお金がありません。
スクラムチームでは、製品所有者は実装する機能を選択する責任があります。したがって、「十分な」ソフトウェアまたは「優れた」ソフトウェアを定義するのは彼次第です（そして彼の予算次第です）。
あなたはいくつかの良い点を上げます。しかし、これらの問題がアジャイルプロセス/方法論に限定されているとは思いません。
必須機能と非必須機能の違いについては意見が異なります。あなたの例を使用すると、自動車を購入する誰かが注意を引くことを必須の機能と見なす可能性があるため、フィアットはこの必須の要件を満たさないと見なします。
より現実的には、ソフトウェア製品は実際のエンドユーザーのニーズを満たすために特定の機能を必要とする場合がありますが、販売するには他の特定の機能を必要とする場合もあります。購入を承認する人はエンドユーザーではないことが多いためです。
そのため、エンドユーザーにとって「必須ではない」機能は、製品の販売に不可欠である可能性があります。したがって、製品を作成する会社にも不可欠です。
これらはすべて、要件と優先順位を適切に設定するための優れた製品開発チームが不可欠であるという事実に要約されます。しかし、それはアジャイルショップだけに当てはまるわけではありません。
また、意思決定を行う権限を持つ製品の所有者/利害関係者がいることも重要です。あなたの製品所有者の決定が常に他の誰かによって却下されている場合、私はそれが問題であることを最初に同意しますが、繰り返しになりますが、アジャイルの問題ではありません。
あなたが製品の所有者に求めているものは他にもあります...私が聞いた説明の1つは「C.R.A.C.K」です。 （協力的、代表的、承認済み、献身的、知識豊富）。これらの領域のいずれかが不足している製品所有者は、プロジェクトに問題を引き起こす可能性があります。しかし、私は最初に滝の環境でこの頭字語を聞いたので、明らかに悪い顧客/製品所有者の痛みはアジャイルショップに限定されていません。
アジャイルができる（助ける）ことができるのは、これらの問題のいくつかを表面化することです。
たとえば、XP文献は、「顧客」に知識があり、チームにアクセス可能であり、意思決定を許可されていることをかなり明確に示しています。「製品所有者」という用語は、ある程度の知識を意味します、コミットメント、権威。
提供されている機能のほとんどが必須機能ではなくディライトで構成されている状況に気づいた場合、すべての機能するソフトウェアまたは機能するソフトウェアを提供するときに、その問題を提起するのがはるかに簡単です（そして原因を特定するのがはるかに簡単です）。配達が数か月または数年離れている場合よりも2〜3週間。
小さなイテレーションで作業していて、バックログを頻繁に確認している場合（優先順位付けの再検討を含む）、これはチームに以前の過ちから学ぶ機会を与えます。 「これは本当に重要なことのように思われますが、最終的には使用しなかった必要があると確信していたダイナミックナビゲーションを覚えていますか？」他の人が指摘したように、すべてが事前に計画されている場合、これらの議論ははるかに少なくなります。
対照的に、事前の設計方法では、製品と機能の理解は静的であると（デフォルトで）想定しています。それは私の経験ではありません。ほとんどの場合、具体的な作業を行うことで、ビジネス人々の問題に対する理解が変わります。したがって、迅速なフィードバックに重点を置いています。 （開発者の理解も変化しますが、それが優先順位に影響することはありません。）
一部の計画を延期すると、ビジネスニーズの変化に対応することもできます。 「あなたが作成しているWebサイトを知っていますか？切断された操作が可能なモバイルアプリであることが本当に必要です。」これは具体的に尋ねられたものではありません...しかし、ビジネスランドスケープの変化に（少なくとも理論的には）対応できるプロセスが必要ではないでしょうか。
アジャイルは「重要でない機能を構築しない」とは言っていません。それは「企業が構築する（しない）機能を決定できるようにする」と言っています。
...および（同様に重要）「必要な機能を構築するのにかかる時間を技術者が教えられるようにする」。
TL; DR
実際、アジャイル開発は、ソフトウェアの品質を向上させ、顧客を満足させ、非常に価値の高い製品を提供するのに役立ちます。
アジャイル開発は、多くのソフトウェアプロジェクトが従来のプロセスで直面する問題に対処するために、数人の賢い人によって導入されました。
アジャイルマニフェスト （1） で定義されているアジャイル開発の主要な値は、
- プロセスとツールに関する個人との相互作用
- 包括的なドキュメント上の作業ソフトウェア
- 契約交渉を介した顧客コラボレーション
- 計画変更後の変更への対応
したがって、アジャイル開発は、高品質のソフトウェアの作成を妨げるものではありません。アジャイル開発は、高品質のソフトウェアを提供することをサポートします。
しかし、私たち（そして顧客）は、必ず必要条件を事前に知っていますか？.
それがポイントです。個人、顧客、作業ソフトウェア、要件変更のアジャイル開発に焦点を当てることで、最終製品が提供される前に顧客が何を望んでいるかを理解するのに役立ちます。
これが、スクラムのようなアジャイルフレームワークが短い反復サイクルを持ち、その結果が成果物である理由です。顧客の期待に反して初期段階ですでに作業を検証し、オンデマンドで目標/要件を調整できます。アジャイル開発は、製品の品質でなければならないを確実に実現するのに役立ちます。
品質である必要があるため、従来のアプローチで開発された多くのソフトウェアプロジェクトは失敗したり、成功しなかったり、顧客の不満を引き起こしたりしますに到達しませんでした。
さらに、アジャイル開発は魅力的な品質に到達するのにも役立ちます。各反復後に製品を反映することで、プロジェクトの開始時に顧客が気にしていない新しい要件（魅力的な品質）が明らかになります。これは顧客を満足させます。
また、カノモデルのReverse Quality-不満につながる属性-についても触れたいと思います。
すべてのプロジェクトには、プロジェクトの開始時に良いアイデアであると思われる要件があります。しばらくすると、彼らは反対に変わり、失望を引き起こします。
従来のソフトウェア開発プロセスでは、プロジェクトを長時間実行した後の最終製品でこのような要件を認識します。顧客の失望を避け、それらを変更するには遅すぎるため、フォローアッププロジェクトが必要です。
アジャイル開発は、機能していないまたは満たされていない要件を早期に特定し、プロジェクト中にそれらを変更するのに役立ちます。
先ほど述べたように、アジャイル開発は、ソフトウェアの品質を向上させ、顧客を満足させ、非常に価値の高い製品を提供するのに役立ちます。