MicrosoftはVisual Studioを利用する開発者向けにアジャイル開発の原則やガイドラインを含んだリソースを提供している。このリソースにはJeff Sutherland氏, Ken Schwaber氏, David Star氏, Mitch Lacey氏, David J. Anderson氏などのアジャイルリーダーが書いた、どんな開発チームでも利用できるアジャイルの方法論の要点が含まれている。
このリソースは3つの部分に分かれている。アジャイルの原則、アジャイルの実践、リーンとCMMIだ。
アジャイルの原則
アジャイルの原則と価値
Jeff Sutherland氏がアジャイル開発のマニュフェストに定義されている、4つの価値について詳解している。
-
個人と個人同士の交流
-
動くソフトウエアを提供する
-
顧客との協力
-
変化に答える
また、氏はアジャイルの方法論と実践を区別し、スクラムとXPの意味と補助的な役割について説明している。
10 Year Agile Retrospective: 次の10年をどうやって改善するか
この記事で、Jeff Sutherland氏は2011年にユタ州スノーバードで開催された10 Year Agile Retrospectiveを回想している。このイベントはアジャイルマニュフェストの調印者とアジャイルのリーダー達が集まり、アジャイルの10周年を祝い、次の10年の成功のための4つの要因を示した。
-
技術的卓越を要求する。
-
個人の変化を促し、組織の変化を推し進める。
-
知識を組織化し、教育を改善する。
-
プロセス全体の価値創造を最大化する。
アジャイルの成功を阻む障害を紹介した後、氏は次のように結論付ける。
アジャイルチームが世界のアジャイルコミュニティが直面している最大の問題、つまり技術的卓越の問題を解決するために活動することが重要です。プロダクトバックログを準備完了にするには、プロフェッショナルなプロダクトマネージャはユーザのニーズとチームの能力を理解し、技術的卓越を提供する必要があります。プロダクトバックログを完了にするには、仕事の優先順位を決め、進行中の作業を定期的に統合し、欠点に耐える必要があります。技術的卓越を求めることは次の10年で最も重要なことだと思います。
完了と未完了
便利で想像しやすいケーススタディを示しながらKen Schwaber氏とDavid Starr氏が感覚的完了と真の完了について解説している。両氏はこの2つの区別の仕方や、この2つがプロジェクトの成功にどのように影響するかを解説している。また、透明性や技術的負債、リリース計画、そして、作業を完了させるための2つの方法、つまり、スクラムチームをまとめるためのスクラムと継続的統合について解説している。
アジャイルの実践
プロダクトバックログの構築と管理
この記事では、Mitch Lacey氏がプロダクトバックログの重要性を説明し、良いプロダクトバックログを作成し維持する方法を紹介している。この記事で氏は、ユーザストーリー、見積もり、優先順位付け、手入れについて論じ、次のように結論付ける。
優れたプロダクトバックログは、顧客や利害関係者との会話の中で見つかった最も重要な機能をユーザーストーリーで定義した通りに、実装できるようにしてくれます。優れたバックログを作成し維持するには、すべてのスプリントで利害関係者や顧客と開発チームの両方と活発に意見を交わし続ける必要があります。
優れたバックログがあれば、優れたシステムができるというわけではありません。しかし、優れたバックログがなければ、究極的には顧客が求める機能がないシステムになってしまいます。言い換えれば、バックログを最新の状態に保てなければプロジェクトはほぼ間違いなく失敗するでしょう。
プロダクトオーナーはフルタイムの仕事であり、バックログに責任を持つのはプロダクトオーナーです。この役割を真剣に考えなければなりません。プロダクトバックログの品質を維持すれば、顧客に感謝されることになるでしょう。
優先順位付け
Mitch Lacey氏は上述の記事の中で、バックログの優先順位付けの3つの方法を紹介している。
氏はバックログを“生き物”と見なし、成功するためには継続的な注意と再優先順位付けが必要だと論じている。
見積もり
Mitch Lacey氏はこの記事でプロジェクトの見積もりについて論じ、優れた見積もりを行うのが難しい理由を説明し、単位としてのストーリーポイントを取り上げ、2つの見積もり手法を提案している。それは、プランニングポーカーとウォール見積もりだ。氏は次の結論付ける。
見積もりが難しいのは、プロジェクトの開始には不確定ことだらけだからです。プロダクトオーナーとアジャイルプロジェクトのマネージャは利害関係者と議論し、動くソフトウエアを作り、リリース可能な状態にするためにフィードバックを取り込むことで、なるべく素早くプロジェクトの全体像を把握しようとします。しかし、アジャイルプロジェクトでは、ひとまとまりの機能がいつリリースできるのか見積もる必要があります。
スプリントの計画
Mitch Lacey氏は自身の記事をスプリントの計画についてのアドバイスで締めくくっている。氏は予測と制約の対立を取り上げ、計画をどのように作成するかについて、計画作成までに直面する問題とその問題に対する解決策と共に論じている。氏はスプリントを計画することを“難しく考える必要はありません。スプリントの計画は楽しい作業で、スクラムチームが一緒に働くことで進行を深められるようにするための作業なのです”と説明する。
リーンとCMMI
リーンソフトウエア開発
この記事でDavid J. Anderson氏はリーンやリーンとアジャイルの関係、リーンの価値や原則、実践について紹介している。氏によれば、リーンの価値とは、
-
人間の状態を受け入れる
-
知的労働においては複雑さと不確定さを当たり前のものだとして受け入れる
-
より良い経済的アウトカムを目指して仕事をする
-
より良い社会学的アウトカムを実現する
-
幅広い規律の中からアイディアを見つけ、問い、取り入れる
-
価値に基づくコミュニティは改善の速度を上げ、改善の度合いをさらに深くする
リーン開発を定義する原則は、
-
システム的思考とデザイン手法に従う
-
現れつつある結果が複雑適応システムの文脈の設計に影響を受ける
-
(システムの一部として)人々を気遣う
-
(改善を駆動するために)科学的な手法を使う
-
リーダーシップの発揮を促す
-
(作業や作業の流れ、システムの運用を)可視化する
-
ひとつの作業フローにかかる時間を短くする
-
効率を上げるために無駄を省く
Anderson氏はリーンソフトウエア開発は“具大的な実践を定義しない”が、コミュニティではたくさんの実践が行われており、そのなかには、累積フローダイアグラムやビジュアルコントロール、仮想カンバンシステムや小バッチ/単一ピースフロー、自動か、カイゼンイベント、デイリースタンドアップミーティング、振り返り、運用レビューが含まれる。
氏は下記のように結論付ける。
ひとつのリーンソフトウエア開発プロセスというものが存在するわけではありません。あるプロセスがリーンソフトウエア開発の価値と原則と連携したとき、そのプロセスをリーンであると呼べるのです。リーンソフトウエア開発自体は特定の実践方法を定義しません。しかし、リーン開発に共通する作業方法はあります。
リーン開発を導入した組織が本当にリーン開発を行っていると言える場合、その組織には3つの形態の不要物(“ムラ”、“ムリ”、“ムダ”)が少ししかなく、効率の良いリスク管理を通じて価値の提供が最適化されているはずです。完璧なリーンを求めるのは常に冒険です。しかも行き先はありません。リーンを導入した組織は常に、更なるカイゼンを求めます。
リーンソフトウエア開発はまだ発展途上であり、次の10年間での進化が期待されます。
CMMIの原則と価値
この記事では、David J. Anderson氏がマネージャやプロセスエンジニアや利害関係者は力成熟度モデル統合(CMMI)を使うことで組織について価値ある情報を得られる、と主張している。氏は組織の成熟、CMMIモデル、組織の成熟レベルの上がり方、CMMIでの成熟度の計測方法について説明している。