はじめて Azure DevOps を使うチームに、Azure DevOps でどういうことができるのか？を説明するときには私はいつも、こんな感じの表を使って説明します。
Azure DevOps は、他のさまざまなサービスを組み合わせて実現する部分を、代わりにAzure DevOps だけで実現できるようにカバーしています。そのため、似ている他のサービスをあげて説明するとわかりやすいようです。例えば、もともと「CI/CD に使おう」と思っていたケド、「作業管理も手動テストの管理もできるなら、それも一緒に扱えるようになりたい」という話になったりします。
また、私は、今はまだ GitHub を Azure DevOps の代わりに使うことが出来ないと思っていますが、それはこの表にあるとおり、チーム開発するときに特に重要な作業管理の部分などを、まだ今の GitHub は扱うことが出来ていないからです。この辺りは近々の GitHub のアップデートで変わっていくかもしれません。そうなってきたら、また表をアップデートして、GitHub と Azure DevOps の比較もしていきたいですね。
続きを読む
よく「アジャイルはどんなプロジェクトに向いているの？」という質問を受けます。以前は「計画通りに進められるプロジェクトなら、ウォーターフォールの方が向いていますよ」と説明していましたが、どうも伝わっていない感じがしていました。また、向いていない場合に「ウォーターフォールの方がいいですよ」と言うと、怪訝な顔（リモートワークだと「声」でしょうか）をされたり、アジャイルが向いていないプロジェクトがあるのか？と驚かれることがよくありました。
ずっと「どう説明するのが伝わるかな？」と色々考えて試していたのですが、昨年（2022年）は「持続的イノベーションにはウォーターフォール、破壊的イノベーションにはアジャイルが向いていますよ」という説明をしてみました。
この説明が今までで一番よく伝わったように思います。
続きを読む
ウォーターフォールとアジャイルを比較する話は、違いを説明する都合で、実際によく話をすることがあるのですが、実際にウォーターフォールと比較すべきなのはアジャイルではないと思っています。書籍 More Effective Agileには「アジャイルと比較すべきはシーケンシャル開発である」と記載されていますが、そういったいわゆるウォーターフォール的な開発だとみんなが認識しているものと比較すべきなのは、「スケールされたアジャイル」だと私は思います。
いわゆるウォーターフォールをソフトウェア開発で採用するのは、PMBOK で必要なプロセスとドキュメントがしっかりと定義されていて、エンタープライズ開発で採用しやすいからです。これがなければどのように進捗や品質を管理すればよいのか？わからなくなってしまいます。
そこでもしウォーターフォールから切り替えるとするならば、切り替える先としては、「アジャイルを採用した小規模な開発」ではなく、「大規模な開発も扱えるアジャイル」が求められます。しかし、一般的なアジャイルのフレームワーク「スクラム（Scrum）」では、最大10名までのチームで扱える範囲の開発しか対応できそうにありません。これがフィットする規模の開発であれば、例えば社内システムの開発で小規模から始めるというのであれば、イメージしやすく「アジャイル（Scrum）でやってみましょう」と言いやすいでしょう。しかし、ソフトウェア開発を請け負う会社にとっては、多くの場合は規模が小さすぎます。もっと大きな規模のエンタープライズ開発に耐えられる方法が必要です。そこでついつい、Scrumを自分たちにフィットするように変えてしまう Scrum But になってしまいます。しかし、Scrum But は成功しません。その結果「アジャイルはダメだ」という主張になったり、完全にウォーターフォールのまま用語だけ変えた「なんちゃってアジャイル」が流行ったりするのだと思います。
続きを読む
アジャイルコーチとして、あるいはスクラムマスタとして、スクラムチームの改善に取り組まなければならないとき、私がいつも最初に確認するのは「完成の定義（完了の定義、DoD、Definition Of Done）」です。
「スクラムがうまくいっていない」と表現されるとき、多くの場合、期待されるより開発のスピードが遅いということや、品質に問題があるということが起きています。そしてそれは、完成の定義が適切に記載されていない、あるいはそもそも完成の定義がない、ということが原因だったりします。
続きを読む
これはよくあるケースだと思います。
毎日デイリースクラムもうまくやれているし、だんだんチームがアジャイル（Scrum）に慣れてきたかな・・・というタイミングで、スクラムマスタやリードディベロッパーがお休みで不在だったりすると、デイリースクラムがスキップされる。いつものデイリースクラムの時間に集まった人も、誰も発言をしないで、自然に「今日はしなくていいよね」と解散になる・・・なんということでしょう？！チームはアジャイルに慣れてきたのではなかったのか？！
これは、チームが Scrum のイベントを定義の通りに行えるようになってきたとしても、それはメンバーが全員スクラムを理解しているわけではない、というのが重要なポイントかと思います。
続きを読む
会社のトレーニング資料で話をするときにも、Scrum.org 公式のスクラムガイドを使って社外の人に話をするときにも、初めてスクラムを勉強する人のために概要を説明するときに、必ず伝えるようにしていることがあります。それは「アジャイルは文化に踏み込む、そうじゃないと勝てない！」というお話です。
Scrum.org スクラムガイド（日本語ダウンロードできます）
従来のウォーターフォール（PMBOK）では、プロセスやドキュメントに注目していて、組織の文化は問われませんでした。
しかし、アジャイル（スクラムガイド）には、スクラムの５つの価値基準として「確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage）」があげられています。スクラムが成功するかどうか？は、チームのメンバーがこの価値基準を実践できるかどうか？にかかっていると明記されています。
続きを読む
最近、プロジェクトで Azure DevOps を使うことが多くなってきて、「Azure DevOps の Board の正しい使い方を教えてください。」というようなことを、よく質問されるようになってきました。
Azure DevOps は簡単に使い始めることができるので、かえって、自分たちがちゃんと使えているのか不安に思うのかもしれません。Azure DevOps 自体は、自分たちのプロジェクトに合わせて、自由に変えてよいのですが、例えば Scrum.org ではアジャイルのフレームワーク「スクラム」を変えないように（変えてしまうと スクラム じゃないよ）というような事が示されていたと思います。自分たちの好きにかえて、正しくない使い方をしてしまうのは不安。正しく使いたい。という気持ちはよくわかります。
なので、今回は「スクラムとしてAzure DevOpsを使用するにはどうするのがよさそうか」という観点で見てみたいと思います。Azure DevOps にはすでに Scrum テンプレートが設定されているものとします。
例えばシナリオとして、「GitHub のソースコードをビルドして、GitHub の Releases にリリースするときに、バージョン番号をファイルから取得してタグやタイトルに使用したい」というような場合を考えます。
GitHubRelease タスクには Tag や Release title が指定できるので「ver.$(version)」のように指定して「ver.1.0.2.3」のように展開されると嬉しいです。リリースノートは Release notes file path で指定できるので、Markdownファイルに書いておいてそのパスを指定することができますが、タグとタイトルはファイルのテキストそのままではなく、他の文字と連結したテキストにしたいところです。
スクラムのチームは全員が同じ場所にいることが推奨（だったと思います、Scrum.org の Scrum Guide には書いてないかも）ですが、そうも言っていられない状況。しかし、リモートワークでスクラムをする場合には、かなり頑張って、メンバーが密にコミュニケーションできるように準備する必要があります。
そのための工夫のひとつとして Azure DevOps のタスクのメンションを使うのが良い感じです。
スクラムイベントの スプリント振り返り ( Sprint Retrospective ) は Scrum.org の Scrum Guide に定義されています。スプリント期間の終了時に、スプリント期間1週間につき 45分（4週間なら3時間）の時間をとって、何が良かったか？何が良くなくてどう改善するか？をみんなで話し合います。
他のスクラムイベントはしっかりやれているのに、スプリント振り返り だけやれてないという話はよく聞きます。重要なこのイベントを、ちゃんとやれるように何とか定着させたいところです。
