agile manifesto understanding agile values
アジャイルマニフェストの紹介：
以前のチュートリアル アジャイル手法 アジャイルモデルと方法論について詳しく説明してくれました。
しかし、これまでは、そもそもアジャイルが必要だった理由や、ウォーターフォールモデルなどの既存のソフトウェア開発方法論の欠点をアジャイルがどのように克服したかについては説明していません。
このチュートリアルでは、アジャイルとアジャイルマニフェストの詳細について詳しく説明します。マニフェストが何を言っているのか、そしてマニフェストに祀られている価値観と原則は何かを見ていきます。
学習内容：
前書き
私たちが見たように 前のチュートリアル 、以前の開発方法論には時間がかかりすぎ、ソフトウェアを展開する準備が整うまでに、ビジネス要件が変更されていたため、現在のニーズに対応できませんでした。
当時欠けていた変化のスピードが多くの問題を引き起こしていました。さまざまな開発方法論のリーダーが集まり、今後の方向性を決定し、より良い方法に合意することができ、マニフェストの文言を完成させることができました。
これは、実践者が理解し、参照し、実践するのを助けるために、4つの値と12の原則として捉えられました。そしてその時点では、これがプロジェクト管理の将来に与える影響を想像することはできませんでした。
アジャイルマニフェスト
マニフェストは、アジャイルの本質を最小限の言葉で捉えるために非常に注意深く表現されており、以下のように書かれています–
「私たちは、ソフトウェアを開発し、他の人がそれを行うのを助けることによって、ソフトウェアを開発するより良い方法を発見しています。この作業を通じて、以下の値に到達しました。
- プロセスとツールを介した個人と相互作用。
- 包括的なドキュメント上で動作するソフトウェア。
- 契約交渉をめぐる顧客のコラボレーション。
- 計画に従った切り替えへの対応。
つまり、右側のアイテムには価値がありますが、左側のアイテムにはもっと価値があります。」
ご覧のとおり、これらは非常に簡潔で単純なステートメントであり、創設者が宣伝したかったことを非常に明確にしています。通常、従来のプロジェクト計画は厳格であり、手順とタイムラインに重点を置いていますが、アジャイルマニフェストは正反対のものを伝播します。
それは好む：
- 人
- 製品
- コミュニケーションと
- 即応性
アジャイルの価値観と原則をより深く理解することにより、創設者が詳細に推進したかったこの新しいパラダイムを探求します。
4つのアジャイルバリュー
4つの価値観と12の原則が、アジャイルソフトウェアの提供を導きます。ここで、それぞれの値について詳しく説明します。
＃1）プロセスとツールを介した個人と相互作用
個人と相互作用は、プロセスの応答性を高めるため、プロセスやツールよりも優先されます。個人が連携し、お互いを理解すれば、チームはツールやプロセスの問題を解決できます。
しかし、チームが盲目的にプロセスに固執することを主張する場合、それは個人間の誤解を引き起こし、予期しない障害を引き起こし、それによってプロジェクトの遅延をもたらす可能性があります。
そのため、前進するためのプロセスに盲目的に依存するのではなく、チームメンバー間でやり取りやコミュニケーションを行うことが常に望ましいのです。これを実現する方法の1つは、開発チームと協力して作業し、意思決定を行うことができる、関与する製品所有者を配置することです。
個人が自分で貢献できるようにすることで、テーブルに持っていくことができるものとして自由に披露することもできます。これらのチームの相互作用が一般的な問題の解決に向けられている場合、結果は非常に強力になる可能性があります。
＃2）包括的なドキュメントを介した作業ソフトウェア
従来のプロジェクト管理には、数か月の遅れを伴う包括的なドキュメントが含まれていました。これは、プロジェクトの実施に悪影響を及ぼし、結果として生じる遅延は避けられませんでした。
これらのプロジェクトのために作成されたドキュメントの種類は非常に詳細であり、非常に多くのドキュメントが作成されたため、プロジェクトの進行中にそれらの多くは参照されませんでした。これは、プロジェクトチームが一緒に住んでいた不必要な悪でした。
しかし、これは配達の問題も悪化させました。チームは仕様どおりの100％の完成品を完成させたいと考えていたため、この程度の文書化に重点が置かれました。そのため、すべての仕様を詳細に把握することに重点が置かれました。
しかし、それでも、最終製品は予想とはかなり異なっていたか、関連性を失っていたでしょう。そのため、アジャイルは、大量のドキュメントよりも、機能するソフトウェアの方が顧客の期待を評価するためのはるかに優れたオプションであると述べています。
これは、ドキュメントが不要であることを意味するものではありません。これは、機能する製品が、数か月前に作成されたドキュメントよりも、顧客のニーズと期待に適合していることを示す優れた指標であることを意味します。また、スプリントが終了したときにクライアントに動作中のソフトウェアを表示しながら、チームが応答し、必要に応じて変更に適応する準備ができていることも意味します。
スプリント中に製品のテストに失敗すると、次のスプリントでさまざまなコストと労力がかかります。機能が展開されると、これらの変更のコストは大幅に上昇します。
3.契約交渉をめぐる顧客コラボレーション
交渉とは、詳細がまだキャプチャされており、確定されていないことを意味します。再交渉の余地はまだあります。しかし、交渉が終わったら、それについての議論はあり得ません。アジャイルが言うことは、交渉の代わりに、コラボレーションに行くということです。
コラボレーションとは、まだ議論の余地があり、コミュニケーションが継続していることを意味します。
一回限りのことではありません。これにより、2つの利点が得られます。チームが早い段階で必要に応じてコース修正を行うのに役立ちますが、クライアントがビジョンを改善し、必要に応じて要件を再定義するのにも役立ちます。事業。
もう1つの側面は、従来のソフトウェア開発モデルでは、文書化と交渉の段階で開発が始まる前に顧客が関与し、プロジェクトの開発ではそれほど関与しないということです。
要件が凍結されると、製品の準備が整うと、製品のみが表示されます。アジャイルは、ライフサイクル全体にわたって顧客の関与を可能にすることで、この障壁も打ち破ります。
これにより、アジャイルチームは顧客のニーズによりよく対応できます。これを達成する方法の1つは、チームをリアルタイムで明確にし、作業を顧客の優先事項に合わせることができる、献身的で関与する製品所有者を介することです。
4.計画に従った切り替えへの対応
標準的な思考プロセスでは、変更は費用のかかる問題であり、変更は絶対に避けなければなりません。それが、タイムラインと製品仕様に固執することによって提供するドキュメントと綿密な計画に不必要に焦点を当てていることです。
しかし、経験からもわかるように、変更はほとんど避けられないので、そこから実行するのではなく、それを受け入れて計画する必要があります。
アジャイルにより、この移行を行うことができます。アジャイルが考えるのは、変更は費用ではなく、プロジェクトの改善に役立つ歓迎すべきフィードバックです。それは避けられるべきではありませんが、代わりに、それは付加価値をもたらします。
アジャイルによって提案された短いスプリントを使用すると、チームは迅速なフィードバックを受け取り、短い通知で優先順位を変更できます。新しい機能は、反復ごとに追加できます。
なぜこれを行うのですか？ウォーターフォールアプローチを使用して開発された機能のほとんどは使用されないためです。これは、ウォーターフォールモデルが計画に従っているのに対し、それが私たちが最も知らないフェーズであるためです。
アジャイルも計画を立てますが、必要なときに十分に計画を立てるジャストインタイムアプローチにも従います。そして、スプリントが進むにつれて、計画は常に変更される可能性があります。
12のアジャイル原則
チームがアジャイルに移行するのを支援およびガイドし、彼らが従う慣行がアジャイル文化に沿っているかどうかを確認するために、マニフェストの作成後に追加された12のアジャイル原則があります。
以下は、2001年にアジャイルアライアンスによって公開された元の12の原則のテキストです。
＃1） 私たちの最優先事項は、価値のあるソフトウェアを早期かつ継続的に提供することでお客様を満足させることです。
＃二） 開発の後半であっても、要件の変更を歓迎します。アジャイルプロセスは、お客様の競争上の優位性のために変化を利用します。
＃3） 動作するソフトウェアを数週間から数か月の間、より短いタイムスケールを優先して頻繁に配信します。
＃4） ビジネスマンと開発者は、プロジェクト全体を通して毎日協力する必要があります。
＃5） やる気のある個人を中心にプロジェクトを構築します。彼らに必要な環境とサポートを提供し、仕事を成し遂げるために彼らを信頼してください。
＃6） 開発チームとの間で情報を伝達する最も効率的で効果的な方法は、対面での会話です。
＃ 7） 動作するソフトウェアは、進歩の主要な尺度です。
＃8） アジャイルプロセスは持続可能な開発を促進します。スポンサー、開発者、およびユーザーは、無期限に一定のペースを維持できる必要があります。
＃9） 卓越した技術と優れたデザインへの継続的な注意が敏捷性を高めます。
＃10） シンプルさ—行われていない作業の量を最大化する技術は非常に重要です。
＃十一） 最高のアーキテクチャ、要件、および設計は、自己組織化チームから生まれます。
＃12） チームは定期的に、より効果的になる方法を検討し、それに応じてその動作を調整および調整します。
これらのアジャイル原則は、開発チームに実用的なガイダンスを提供します。
12の原則を整理する別の方法は、次の4つの異なるグループでそれらを検討することです。
- 顧客満足
- 品質
- チームワーク
- プロジェクト管理
＃1） 私たちの最優先事項は、価値のあるソフトウェアを早期かつ継続的に提供することでお客様を満足させることです– 顧客は明らかに、機能するソフトウェアがスプリントごとに配信されるのを見てワクワクするでしょう。あいまいな待機期間を経る必要はなく、最後に製品を見ることができます。
ここで、顧客はプロジェクトのスポンサーまたは開発の費用を負担している人として定義できます。製品のエンドユーザーも顧客ですが、エンドユーザーはユーザーと呼ばれるため、この2つを区別することができます。
＃二） 開発の後半であっても、要件の変更を歓迎します。アジャイルプロセスは、お客様の競争上の優位性のために変化を利用します– 変更は、全体的なタイムラインを大幅に遅らせることなく組み込むことができます。
アジャイルチームは何よりも品質を信じているため、変更を避けてビジネスニーズに合わない製品を提供するよりも、変更を組み込んで顧客の要件に従って提供することを望んでいます。
＃3） 動作するソフトウェアを数週間から数か月まで頻繁に提供し、より短いタイムスケールを優先します– これは、スプリントで作業するチームによって処理されます。スプリントはタイムボックス化された反復であり、各スプリントの最後に機能するソフトウェアを提供するため、顧客は定期的に進捗状況を把握できます。
＃4） ビジネスマンと開発者は、プロジェクト全体を通して毎日協力する必要があります– 両者が協力して作業し、コース修正と変更の敏捷性のために2つの間に一定のフィードバックループがある場合、より適切な決定が行われます。利害関係者間のコミュニケーションは常にアジャイルの鍵です。
＃5） やる気のある個人を中心にプロジェクトを構築します。彼らに必要な環境とサポートを提供し、仕事を成し遂げるために彼らを信頼します– チームをサポートし、信頼し、やる気を起こさせる必要があります。やる気のあるチームは成功する可能性が高く、最善を尽くそうとしない不幸なチームよりも優れた製品を提供します。
これを行う方法の1つは、開発チームが自己組織化され、独自の決定を下せるようにすることです。
＃6） 開発チームとの間で情報を伝達するための最も効率的で効果的な方法は、対面での会話です。 チームが同じ場所にいて、話し合いのために顔を合わせて会うことができれば、コミュニケーションはより良く、より影響力があります。信頼を築き、さまざまな利害関係者の間で理解をもたらすのに役立ちます。
Windows10用の最高のYouTubeダウンローダー
＃ 7） 動作するソフトウェアは進歩の主要な尺度です– 動作するソフトウェアは、他のすべてのKPIを上回り、実行された作業の最良の指標です。
＃8） アジャイルプロセスは持続可能な開発を促進します。スポンサー、開発者、およびユーザーは、無期限に一定のペースを維持できる必要があります– 配信の一貫性が強調されています。チームは、プロジェクトの期間中、ペースを維持でき、最初の数回のスプリント後に燃え尽きないようにする必要があります。
＃9） 卓越した技術と優れた設計への継続的な注意が敏捷性を高めます– チームは、変更を処理し、変更を組み込むことができる一方で高品質の製品を生産するためのすべてのスキルと優れた製品設計を持っている必要があります
＃10） シンプルさ— 行われていない作業の量を最大化する技術は不可欠であり、行われたという定義を満たすのに十分です。
＃十一） 最高のアーキテクチャ、要件、および設計は、自己組織化チームから生まれます –自己組織化されたチームは権限を与えられ、作業の所有権を取得します。これにより、チームメンバー間でオープンなコミュニケーションと定期的なアイデアの共有が可能になります。
＃12） チームは定期的に、より効果的になる方法を検討し、それに応じて行動を調整および調整します– 自己改善は、より迅速な結果とより少ないやり直しにつながります。
結論
顧客中心主義とコミュニケーションへの集中は、今日目に見えるアジャイルに成功をもたらしました。
これは、ソフトウェア配信だけでなく他の業界にも影響を与える実証済みの手法であり、今日ではそれ自体が業界になっています。
このシリーズの今後のチュートリアルでは、スクラムチームとその役割について詳しく説明します。
推奨読書
- アジャイルスクラムオンラインクイズ：アジャイルスクラムの知識をテストする
- アジャイルテスターの考え方の変化：アジャイルマニフェストとの整合
- かんばんvsスクラムvsアジャイル：違いを見つけるための詳細な比較
- アジャイルスクラムプロセスを使用して、高価値のソフトウェア機能を短期間で提供する方法
- SAFeアジャイルチュートリアル：Scaled AgileFrameworkとは
- アジャイルプロセスへの移行を成功させるためのアジャイルテストマインドセットの開発に向けた4つのステップ
- JIRAアジャイルチュートリアル：アジャイルプロジェクトを管理するためにJIRAを効果的に使用する方法
- アジャイルマニフェストに基づくDevOpsプラクティス（パート2-ブロック1）