はじめに

この記事は、Microsoft Learn の下記のモジュールの中から重要と思われる内容を(筆者が勝手に抽出して)書き残しているものです。

Choose an Agile approach to software development

上記のモジュールは、2020/5/4 現在、英語でのみ提供されています。日本語の内容を確認されたい方は、こちらを参照してください。※公式のものではありません

Azure DevOps - ソフトウェア開発にアジャイルなアプローチを選択する Part.1

アジャイルとは何か？

アジャイルはチームが行う作業を計画するための哲学や考え方

これも勘違いする人が多いのですが、アジャイル=ソフトウェアの開発プロセスではありません。チームで開発を行うための哲学や考え方に近い。つまり何を言っているかと言うと、これがアジャイルだと定められた開発プロセスなんて存在しない ということです。
アジャイル開発という言葉が世に出てもう随分と経ちますが、この言葉は、特定の正しい開発プロセスを指し示しているのではなく、新しい開発プロセスの考え方、哲学に近いものだと言うことです。

アジャイルソフトウェア開発宣言

アジャイルが哲学や考え方である、ということを証明するものが、Agile Manifesto です。これは日本語で アジャイルソフトウェア開発宣言 と言われています。

この Agile Manifesto は、以下のように記載がなされています。

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
・プロセスやツールよりも個人と対話を、
・包括的なドキュメントよりも動くソフトウェアを、
・契約交渉よりも顧客との協調を、
・計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
（引用元：アジャイルソフトウェア開発宣言）

見てわかる通り、私たちは以下の価値に至ったと記載がされています。つまり、宣言を出した人物たちの価値観の話しかしていない のです。左が右より劣っていて軽視して良い、などとは一言も言っていません。

アジャイルという定められた開発プロセスはない、という認識を持っておくことが重要ですね。

アジャイルを採用するための推奨事項

アジャイルは哲学や考え方だ、という話がありましたが、ではそれをどうやって組織に浸透させていくか、という話ですね、これは長文になるので、是非翻訳した記事の方を参照していただければと思います。

アジャイルプラクティスを支える組織体制を作る
アジャイル技術と実践についてチームメンバーを指導する
チーム内およびチーム横断のコラボレーションを可能にする

Azure Boardsとは？

やっと Azure DevOps の中身に入っていきますね。なぜここまでに時間をかけているかというのは、(これは私個人の意見ですが) マイクロソフト社のブランド戦略によるものが大きいと思っています。
昔と違って、今のマイクロソフトは、ユーザーは自分たちのニーズや背景を踏まえて好きなものを使用すればいい、そのための様々なサービスをマイクロソフトは用意するので、気に入れば使ってくださいというような雰囲気があります。DevOps、アジャイルを自分たちの組織に導入、定着、推進させるために、Azure DevOps がマッチするなら使ってください、という感じに見えなくもないです。

4つのプロセス

Azure Boards は、プロジェクトを作成する際に設定する内容によって、表示内容や活用方法が少し変わってきます。Azure DevOps では、4パターンのプロセスが選択可能です。

Capability Maturity Model Integration (CMMI)
Scrum
Agile
Basic

スクラムやアジャイル開発の経験があるチームは、それらのプロセスを選択すればいいと思います。モジュール内では、Basic を選択している通り、まだスクラムやアジャイル開発のナレッジや文化が定着していない組織では、最初は Basic を選択するのが無難だと思います。

スプリントは2週間から4週間

ここは難しいところですね。大抵は2週間でスプリントを切ると良い思います。(4週間=1ヶ月って、正直、結構長い)

プロダクトバックログに投入されているタスクの内容は、粒度が非常にバラバラで統一されていないことが普通です、そのため、1スプリントで対応できる内容にするために、タスク内容を分解しなければなりません。1スプリントの期間が長ければ、その分タスクを細かく分解することが困難になり、タスク漏れやスプリントがうまくいかなかった時の影響が大きく出てしまいます。(だって1ヶ月分の作業が無駄になったとしたら、誰もが嫌ですよね。。)

演習

ここでは、実際に以下の作業を行っています。

プロジェクトを作成する (Basic プロセスを選択)
チームを作る・チームメンバーの追加
ボードを作成する
スプリントを定義する
タスクを割り当て反復を設定する

日本語訳した記事を順に実施してもらえればと思います。
作成したワークアイテムを元に作業が進められていくわけですが、この演習を消化すれば、実業務でも Azure DevOps を使い始めるためのきっかけには十分だと思います。

さいごに

Azure Boards は、いわゆるプロジェクト管理のサービスではありますが、ツールだけ導入してもプロジェクトは上手く進まないですよね。チームで仕事をする以上、そこには信頼関係や文化、価値観の共有が必須です。皆に使われないツールに価値はありません。

そのために、本モジュールでも、前半はアジャイルについての認識を共有したりする場面があったのだと思います。DevOpsはツールではないという言葉を覚えているでしょうか。ぜひ、この事を忘れることなく、Azure DevOps をチーム全員で使い始められるといいですね。