アジャイル手法で優れたソフトウェアを開発する方法は？

顧客満足の狩野モデルは、製品機能のさまざまなクラスを定義します。それらの中には

1. 必須の品質：これらが実装されていない場合、顧客は製品を受け入れません。

2. 魅力的な品質（喜び）：顧客が最初に期待することさえないが、発見されたときに興奮と喜びをもたらす機能。

魅力的な資質は明らかに多くのビジネス価値を持っています。5.000未満の使用済みフィアットがすべての必須要件を満たす場合、人々は500.000でフェラーリを購入します。

ただし、私が知っているすべてのアジャイルプロセスは、必須の要件を強く支持しています。これらは常に最高の優先度を取得します。アジャイルには魅力的な資質がある場所すらありません。

アジャイルプロセスはソフトウェア開発に非常に役立つと思います。しかし、どうすればそれらを適用して、必須の要件をかろうじて満たす最低限のものだけでなく、楽しい高品質のソフトウェア製品を作成できますか？

補遺：最初の2つの答えが指摘したように、必須要件に最高の優先順位を与えることは理にかなっています。しかし、私たち（および顧客）は、必要な要件が何であるかを事前に常に知っていますか 私は、最初に高い優先度が与えられた要件が、後で役に立たないとしても、それほど重要ではないことが判明したことを何度か経験しました。したがって、私は、必要な要件に慎重に焦点を合わせるべきではないと考えています。

正式な答えは、アジャイルを誤解している、アジャイルは要件を指示していない、利害関係者がしているということです。アジャイルの核心は、要件を明確に刻むのではなく、進行中の洞察の恩恵を受けて、クライアントと密接に接触しながら、要件を明確にすることです。

しかし、それはすべて理論です。実際に目撃したのは、アジャイルな作業方法を採用した多くのソフトウェア生産ラインの一般的な特徴です。

問題は、顧客の声に耳を傾け、顧客のニーズに迅速に対応することは、多くの場合、製品について何も考えないか、設計をまったく行わないことになります。かつてはビジョンと専門知識を備えたプロアクティブなプロセスでしたが、多くの場合、顧客の希望に応じた受動的で完全にリアクティブなプロセスに悪化する可能性があります。これは、「仕事をする」必要最低限​​のものを作ることにつながります。

当時のメーカーが「アジャイル」だったとしたら、自動車は決して発明されなかったでしょう。なぜなら、すべての顧客が求めているのはより速い馬だからです。

ただし、これによってアジャイルが悪くなることはありません。それは共産主義に少し似ています。人々は単なる人間であり、人々のことをやっているので、ほとんどうまくいかない素晴らしいアイデア。そして、方法/イデオロギー/宗教は、彼らが動きを通り抜けて、そして/または規則に従っている限り、彼らがうまくやっているという考えに彼らをなだめます。

[編集]

スレベトマン：

皮肉なことに、アジャイルが自動化産業（つまりトヨタ）から発展したのです。

自動化の黄金律を覚えていますか？「最初に整理してから自動化する」。壊れたプロセスを自動化する場合、起こりうるすべてのことを加速させることが最善の方法です。トヨタの人​​たちは馬鹿ではありませんでした。

新しい方法論を採用する典型的な理由は、物事がうまくいかないことです。経営陣はそれを認めていますが、中核的な問題を理解していないかもしれません。そこで彼らは、アジャイルとスクラムについて回復力のあるスピーチを提供するこの教祖を雇います。そして誰もがそれを愛しています。独自の理由で。

開発者は「ねえ、これはうまくいくかもしれない。私たちはビジネスの問題にもっと関与し、このバックログを埋めるためのインプットを提供できるだろう。これは私たちの仕事、なぜそして、私たちが合意したことを透明に燃やしている間に、私たちは髪からそれらを取り出します。」あなたの机に飛び出すのを先延ばしにしたくない男によって、これ以上「あなたがしていることを止めてください、これは今やられる必要があります」。

一方、営業、顧客サービス、または所有者は、おそらく必要なことを行っている部門のこのブラックボックスを制御（バック）する方法としてそれを見るかもしれません。彼らはそこで何が起こっているのかはわかりませんが、問題の核心はどこかに埋もれていると確信しています。そこで、彼らはスクラムを導入し、彼らが選んだ製品所有者をインストールし、突然彼らはすべてをコントロールし、すべての弦は手元にあります。今何？... Ehrr ...

本当の問題は、店がそもそもうまく組織されておらず、これが変わっていないことです。人々は対処できない責任を割り当てられているか、あるいはおそらくできるかもしれませんが、ボス氏は常に自分のしたことを妨害し、破滅させています。

時には、正式なラインの間に非公式の組織が現れることがあります。これにより、正式な構造の欠如を部分的に補うことができます。一部の人々は、それを証明する名刺を持っているかどうかにかかわらず、自分の得意なことをやるだけです。アジャイル/スクラムの鈍い導入は、それを即座に台無しにするかもしれません。人々は今、規則に従って遊ぶことが期待されているからです。彼らは、彼らがかつてやったことは高く評価されず、代わりに小さな物語が書かれた黄色い小さな紙を受け取り、メッセージは次のようになります。言うまでもなく、これはそれらの個人に特にやる気を起こさせるものではないでしょう。彼らはせいぜい注文を待って開始し、もはやイニシアチブを取りません。

それで事態は悪化し、結論はアジャイルが悪いということです。

アジャイルは吸わず、保守プロジェクトに最適であり、慎重に適用すれば新しい開発にも適していますが、間違った人がそれを理解していないか、間違った理由で採用している場合、最も破壊的です。

アジャイルには魅力的な資質がある場所すらありません。

あなたはリンゴとオレンジを比較しています。伝統的な滝では、あなたの要件があなたが必需品を必要とすると言うならば、あなたはフィアットを得ます。要件がそれが一流でなければならないと言うならば、あなたはフェラーリを手に入れる。

アジャイルでも同じことが起こります。あなたの要件が必需品で停止する場合、フィアットを取得します。卓越したストーリーがあれば、フェラーリを手に入れることができます。アジャイルが本当に強制するのは、最初に必要なことを行うことだけです。2年間スーパークールスポイラーを構築してから、エンジンの締め切りを逃さないでください。

要するに、必要なものを手に入れることができます。スポーツカーを計画している場合、スポーツカーを取得します。アジャイルはそれをまったく変えません。あなたのアジャイルプロセスがフィアットの要件を考え出した場合、アジャイルを非難せず、フィアットのみを必要とする人を非難してください。

ただし、私が知っているすべてのアジャイルプロセスは、必須の要件を強く支持しています。これらは常に最高の優先度を取得します。

必要に応じて、カノモデルをもう一度見てください。必須要件が満たされていない場合、顧客は製品を受け入れません。そして、あなたの喜びは重要ではありません。

アジャイルには魅力的な資質がある場所すらありません。

真実と違うことがあってはならない。

通常、アジャイルプロセスは次の点を強調しています。

• フィードバックを得ることができる実用的な製品の頻繁な配信。
• フィーチャを小さなパーツに分割し、短時間で完成できるようにします。
• これらの部分を優先度の高い順に実装します。

「楽しい」機能に高い優先度を与えることを妨げるものは何もありません。それは完全に優先順位を決定する担当者に依存します。

今では、そのような人々の多くはリスクを冒さないことを好み、したがって「喜び」に高い優先順位を与えないかもしれません。しかし、アジャイルではないプロジェクトでは、そうなります。

アジャイルは、最初に何をすべきかについては何も言っておらず、次のリリース可能な状態になるまで数ヶ月間使用できないように計画するのではなく、そのコードのみをインクリメンタルに書き、できるだけ頻繁にリリース可能な状態に保つ必要があります。

私はアジャイルとBDUF（Big Design Up Front）の両方のプロセスで働いてきましたが、両方のプロセスから革新的で魅力的な機能を確実に得ることができますが、BDUFでは、当然のことながらそれらを事前に計画する必要があります。つまり、設計プロセスで影響力を持つ人々がイノベーションを提案するか、少なくとも後援する必要があります。

これは、次のリリースまでに6か月（または何でも）あり、プロジェクトマネージャーはそのリリースに含まれる内容について強調されているためです。なぜなら、機能が入らない場合、次のリリースまでさらに6か月になるからです。 。詰まったスケジュールには詰まった機能のリストがあり、低ランクのファイルが2〜3日間クールなもので動作するようになった場合、彼らは顧客が好きだと思うだけで、それはそうではありませんリスト、彼らは全体のスケジュールを危険にさらし、支払う地獄があるでしょう。

アジャイルプロセスでは、ソフトウェアをリリース可能な状態に保つよう努めています。プロジェクトマネージャーは、機能が落ちても2週間で取得できるため、ストレスが少なくなります。そのため、開発者がクールなアイデアで会議から戻ってきて、何かに数日を費やしたとしても、6か月間の血まみれのスケジュールを危険にさらすことはありません。

基本的に、種をまくものを刈り取る。イノベーションを奨励し、チームに十分な自主性を与えれば、それを実現できます。締め切りに間に合わせるために常に手抜きを要求する場合、方法論に関係なく、ソフトウェアを一致させることができます。

優れたソフトウェアは、次の2つのことから生まれます。

• 顧客に必要なものを提供する

• プロであること

ソフトウェアを開発する際に従うべきあらゆる種類の原則があります。顧客の要件とは関係のない、乾燥した、読み取り可能な、固体など。顧客はスポーツカーを求めました。顧客がスポーツカーをすばらしいものにするために必要なことを理解していれば、彼らはあなたを必要としません。他に何が重要かを理解するのはあなた次第です。

私たちの仕事の一部は、物事がひどく間違っていない限り、顧客が決して経験しない基準を維持することです。

あなたがそれを正しくしているなら、アジャイルは顧客が本当に望んでいるものである場合にのみフィアットに向かう傾向があります。それは彼らが解決する必要があると彼らが考えるものではありません。

ウォーターフォールは、ハイエンドのスポーツカーの要件に関する誤解が収まると異なるため、異なります。アジャイルは新しい情報に対処し、本当に必要なのが弾丸バイクであることが判明した場合に適応できます。

滝は今でも多くの店で使用されています。これらのショップの要件は1年で​​2％未満しか変わらないため、成功しています。

あなたの仕事は、顧客に欲しいものを与えるだけではありません。それはまた、あなたがまったく信用を得られないことを知っていることの世話をすることです。物事をひどく間違えさせない限り、顧客が持ち出すことのないもの。これらのものは、適切に選択するか、時間を浪費するために多くのがらくたを取る必要があります。

どんなバカでも無制限の予算で橋を架けることができます。専門家は、たまに倒れることのない橋を建設します。

したがって、私は、必要な要件に慎重に焦点を合わせるべきではないと考えています。

確かにすべきです。時間を見積もる場合を除きます。これらの必須要件だけが考慮事項ではないからです。

OK、

アジャイルでは、プログラマーはソフトウェアを作成できますが、最終的には製品を作成するのは製品所有者です。（ソフトウェア開発者を使用して。）

「魅力的な品質」については、製品所有者次第です。

製品所有者が「セクシーなデザイン」を義務付けている場合、それを要件にすることができます。開発者はこれらの選択について心配する必要はありません。

また、ソフトウェアは実際の物理的な製品とは非常に異なるため、多くの狩野モデルは当てはまらないと思います。たとえば、なぜFacebookを使用するのですか？唯一の理由：私の友人がそうするからです。それを次のスプリントに入れる方法........また、ソフトウェアで最も魅力的な性質の1つは、それが実際にすべきことをするということです。（そして、アジャイルは多くの場合に役立ちます：P）

私の経験は上記のコメントに同意します- 優れたソフトウェアの開発を妨げるアジャイルに固有のものは何もありません-しかし、アジャイルが「（十分な）」実践される方法にいくつかの側面があります。 」

• アジャイルは、できるだけ早く何かを動作させることに重点を置いています。ただし、これは、特にユーザーに表示されないインフラストラクチャで、仮定を簡素化し、コーナーをカットすることを意味します。単純化された仮定を修正するコストが低い場合、これについて本質的に問題はありません。しかし、多くの場合、この「技術的負債」は製品が生産される前に削除されません。
• アジャイルは、スプリントの終わりに、できる限り出荷可能なものに近いものを常に用意して、関係者とプロジェクトマネージャーが「自分の持っているもの」を押し込むのに十分であると判断できるように説く製造。ここでも、これで本質的に間違って何もない、もしあなたはすべての「技術的負債」をクリアしました（またはあなたがどれだけ持っているか、それがどこにあるかであなたは和解しました。）しかし、私の経験では、あまりにも多くの技術的負債が「出荷のプレッシャーがなくなると、それをクリーンアップします」、それはすぐに「生産中です、私たちは今何を変更するかについて非常に注意する必要があります」次回はもっと良い仕事をしなければなりません！」「低価格の甘さが忘れられた後も品質の悪さは長く続く」というベン・フランキンの教訓は決して学ばれないようです。
• ただし、信頼できるマネージャーと規律のある開発者であっても、実装が開始および完了されると予想されるスプリントの開始前に、適切な分析、設計、および設計レビューがあまりにもわずかしか行われないという一般的な問題があります。思慮深く代替案を検討しなかったUIのメタファーとデザインは大きく、通常、プロジェクトの開始後にこれを大幅に修正するのはコストがかかりすぎます。ジュニアチームが競合製品の入念な研究を怠った場合、またはI18N、通知フレームワーク、ロギング、セキュリティ、APIバージョン管理戦略などのインフラストラクチャテクノロジーの定義と実装に優先順位を付けなかった場合、最終的にはより高いバグが発生します。必要なトレーニング、分析、設計、およびプロトタイピングを行うために最初の2〜5個のスプリントを前もって行っていた場合よりも、生産性が低下し、より多くの技術的負債が発生します。つまり、アジャイルチームは、ハッキングするライセンスに抵抗する必要があります。
• 第2レベルのマネージャー（100人以上の開発者）がいて、最も基本的なレベルであっても、開発者が計画した設計を書き留めるのをやめさせています。彼の推論-「私は人々がお互いに話をしたい」-彼らは5つの異なるタイムゾーンと3カ国にいたので皮肉でした。言うまでもなく、誰もが他の人が何らかの機能を実装する責任があると思ったことがわかったら、プロジェクトの後半で多くの夜と週末に仕事をしなければならないチームについて、多くの指差しがありました（またはサプライヤーと消費者のデザインが噛み合わなかったため、再実装します。）

プロジェクトマネージャーと利害関係者が高品質の製品を提供したいかどうかにかかっています。彼らがそうすることにコミットしている場合、アジャイルはそれを有効にします。OTOHは、アジャイルがスケジュールの意思決定を利害関係者とプロジェクトマネージャーのみに委ねているため、アジャイルは、開発チームがそのサポートなしで優れたプロジェクトを提供することを困難にします。要するに、製品の品質に対する説明責任は、ほとんどプロジェクトマネージャーの足元にあります。

TL; DR

実際、アジャイル開発は、ソフトウェアの品質を向上させ、顧客を満足させ、非常に価値のある製品を提供するのに役立ちます。

アジャイル開発は、多くのソフトウェアプロジェクトが従来のプロセスで直面している問題に対処するために、少数の賢い人によって導入されました。

アジャイルマニフェスト（1）で定義されているアジャイル開発の重要な価値は、

• プロセスとツールを介した個人と相互作用
• 包括的なドキュメントよりも動作するソフトウェア
• 契約交渉を介した顧客コラボレーション
• 計画に従った変更への対応

したがって、アジャイル開発では、高品質のソフトウェアを作成できます。アジャイル開発では、高品質のソフトウェアを提供できます。

しかし、私たち（および顧客）は、必要な要件が何であるかを事前に常に知っていますか

それが全体のポイントです。個人に焦点を当てることで、顧客、作業ソフトウェア、要件の変更により、アジャイル開発により、最終製品が出荷される前に顧客が何を望んでいるかを把握できます。

そのため、スクラムのようなアジャイルフレームワークの反復サイクルが短く、結果は実用的な製品です。早い段階で顧客の期待に照らして作業をすでに検証し、オンデマンドで目標/要件を調整できます。アジャイル開発は、製品の必須品質を確実に実現するのに役立ちます。

昔のこと-今日でもそれは真実です-従来のアプローチで開発された多くのソフトウェアプロジェクトは失敗するか、成功しなかったか、必須品質に達していないために顧客に不快感を与えていました。

さらに、アジャイル開発は魅力的な品質に到達するのにも役立ちます。各反復後に製品を反映することで、プロジェクト開始時に顧客が関心を持たなかった新しい要件（魅力的な品質）が明らかになります。これにより、顧客は満足しています。

また、Kanoモデルの逆品質 -不満につながる属性- に言及したいと思います。

すべてのプロジェクトには、プロジェクトの開始時に良いアイデアと思われる要件があります。しばらくすると、彼らは反対に変わり、失望を引き起こします。

従来のソフトウェア開発プロセスでは、長いプロジェクトの実行後、最終製品でそのような要件を認識します。顧客の失望を避け、それらを変更するにはフォローアッププロジェクトが必要です。

アジャイル開発は、機能していないまたは不満な要件を早期に特定し、プロジェクト中にそれらを変更するのに役立ちます。

先ほど述べたように、アジャイル開発は、ソフトウェアの品質を向上させ、顧客を満足させ、非常に価値のある製品を提供するのに役立ちます。

私はこのパーティーにかなり遅れていますが、このテーマに関する別の角度を共有したいと思います。

しかし、どうすればそれらを適用して、必須の要件をかろうじて満たす最低限のものだけでなく、楽しい高品質のソフトウェア製品を作成できますか？

アジャイルソフトウェア開発には一時的な側面があり、これはアジャイル手法の2つの重要な要素である反復アプローチと顧客フィードバックの検討から生じます。例：反復tで魅力的な品質として識別された特徴は、次の反復t + 1で必須の品質になる可能性があります。

アジャイルメソッドを適用すると、機能の品質カテゴリを動的に変更できます。反復tの計画された特徴を、後の反復t + nの完成した特徴と比較すると、まさにあなたが言及したことを経験するでしょう：

私は、最初に高い優先度が与えられた要件が、後で役に立たないとしても、それほど重要ではないことが判明したことを何度か経験しました。

この一時的な側面を念頭に置いて、アジャイル手法が最低限の品質に 集中しながら、楽しい高品質のソフトウェア製品を生み出すことができると考えられます。反復的なアプローチと対になって、顧客からのフィードバックは、時間をかけてゲームのルールを変更します。

結論

アジャイル手法で優れたソフトウェアを開発する方法は？

反復的なアプローチを適用し、顧客のフィードバックに耳を傾けます。これらの要素の1つを捨てると、アジャイルソフトウェア開発の成功率が低くなります。

   > How to develop excellent software with agile methods?

• 顧客固有の個々のソフトウェアを作成する場合：
  • 「楽しい」機能には追加の費用がかかり、顧客はこれを支払うかどうかを決定する必要があるため、コストが問題にならない顧客を見つけます。
• ソフトウェア製品を生産する場合：
  • 「楽しい」機能は新しい顧客を引き付けるのに適しています。また、「楽しい」機能を実装するコストは、製品が1000回以上販売されている場合はそれほど重要ではありません。
• 「十分な（最も安い）最高の」環境では、「楽しい」機能を実装するためのお金を得ることができません

スクラムチームでは、製品所有者が実装する機能を選択する責任があります。そのため、「十分な」または「優れた」ソフトウェアを定義するのは彼次第です（そして彼の予算次第です）

良い点をいくつか挙げます。しかし、これらの問題はアジャイルなプロセス/方法論に限定されるとは思わない。

本質的な機能とそうでない機能については、さまざまな意見があります。あなたの例を使用するために、自動車を買う人は、注意を引くことを必須の機能と考え、したがってフィアットはこの必須の要件を満たさないと考えます。
より現実的には、ソフトウェア製品は、実際のエンドユーザーのニーズを満たすために特定の機能を必要とするかもしれません...しかし、販売するためには特定の他の機能も必要とするかもしれません。多くの場合、購入を承認する人はエンドユーザーではありません。
そのため、エンドユーザーにとって「必須ではない」機能は、製品を販売するために不可欠である可能性があります...したがって、製品を作成する会社にとっても不可欠です。

これらはすべて、要件と優先順位を適切に設定するために優れた製品開発チームを持つことが重要であるという事実に要約されています。しかし、それはアジャイルショップだけに当てはまるわけではありません。

また、決定を下す権限を持つ製品所有者/利害関係者を持つことも重要です。あなたの製品所有者の決定が他の誰かによって絶えず却下されているなら、私はそれが問題だということに最初に同意するでしょうが、それはアジャイルの問題ではありません。

製品所有者には他にも欲しいものがあります...私が聞いた説明の1つは「CRACK」（共同作業、代表、承認、コミット、知識）です。これらの領域のいずれにも欠けている製品所有者は、プロジェクトの問題を引き起こす可能性があります。しかし、この頭字語は滝の環境で最初に聞いたので、明らかに悪い顧客/製品所有者の痛みはアジャイルショップに限定されません。

アジャイルができる（助ける）ことは、これらの問題のいくつかを表面化することです。

たとえば、XPの文献は、「顧客」が知識を持ち、チームにアクセス可能であり、決定を下す権限を与えられていることについて、IIRCがかなり明示しています。「製品所有者」という用語は、ある程度の知識、コミットメント、および権限を意味します。

提供されている機能のほとんどが必須の機能ではなく喜びで構成されている状況にある場合、作業中またはほぼ稼働中のソフトウェアを提供するたびにその問題を提起するのがはるかに簡単です（そして原因を特定するのがはるかに簡単です）配達が数ヶ月または数年離れている場合よりも2〜3週間。

小規模なイテレーションで作業しており、バックログを頻繁に確認する（優先順位の再検討を含む）場合、以前のミスから学ぶ機会をチームに与えます。「これは今では本当に重要なように感じますが、ダイナミックナビゲーションを使用していないことが必要だと確信していたことを覚えていますか？」他の人が指摘したように、すべてが事前に計画されていれば、これらの議論ははるかに少なくなります。

対照的に、事前設計の方法論では、製品および機能の理解は静的であると（デフォルトで）想定しています。それは私の経験ではありませんでした。ほとんどの場合、仕事をするための具体的なものがあれば、ビジネスの人々の問題に対する理解が変わります。したがって、迅速なフィードバックが重視されます。（開発者の理解の変更も同様ですが、それは優先順位に影響を与えません。）

一部の計画を延期すると、ビジネスニーズの変化に対応することもできます。「あなたが構築しているウェブサイトを知っていますか？それは、切断された操作が可能なモバイルアプリであることが本当に必要です。」これは具体的に尋ねられたものではありません...しかし、あなたはあなたのプロセスが（少なくとも理論的には）ビジネス環境の変化に対応できることを望みませんか？

アジャイルは「重要ではない機能を構築しない」とは言いません。「どの機能を構築する（しない）かを企業が決定できるようにする」と書かれています。
...そして（同様に重要な）「技術者があなたが望む機能がどれくらいの期間で構築されるのかをあなたに伝えることを許可する」。

1. Must-be qualities多くの場合、判断が困難です。人々は良心でそれらを持っています。アジャイルなイテレーションとクライアントの参加は、ほとんどの必需品を見つけるのに役立ちます。それがアジャイルの力であり、それを無視するのはバカです。
2. One-dimensional qualitiesつまり、満たされなければならない約束は、変化しない限り、ウォーターフォールOKによってサポートされます。ここでアジャイルであることは役立つだけですが、それほど強力ではありません。
3. Attractive qualities素晴らしい機能です。彼らは次世代の必需品になる可能性があります。しかし、現在の世代では、彼らは合意にさえ入っていません-さもなければ、彼らは一次元の性質になるでしょう。クライアントの代表者の参加を想定したこれらのアジャイル手法は、これらの品質を非常によくサポートします。作業中にスコープを軽く変更できるからです。別の場所で何らかの補償をするために、ある場所で改善を交渉することができます。滝では、実際には不可能です。組織の大幅な遅延がなければ、機能を無料で追加することしかできませんでした。前もって予算に余裕を持たせることができます。

そのため、アジャイルプロセスはKanoモデルをサポートできます。一部のモデルは大規模にサポートしており、最高のウォーターフォールプロジェクトよりも間違いなく優れています。

あなたの理解の中でそれを大いに行うには、責任あるクライアント代表参加者とアジャイルプロセスを設定する必要があります。