Scrum での「よくある勘違い」として、PBI(プロダクトバックログ / スプリントバックログ)をScrum チームのメンバーで分担してしまうというのがあります。

ウォーターフォールでの慣習・考え方では特に問題がないことのように思うかもしれませんが、Scrum ではこれはうまくいかないことが多いです。

続きを読む

Scrum のスプリント計画での「よくある勘違い」として、最初に全 Task を各メンバーに振ってしまうというのがあります。

ウォーターフォールでの慣習・考え方では当然のことのように思うかもしれませんが、これはうまくいかないことが多いです。

続きを読む

はじめて Azure DevOps を使うチームに、Azure DevOps でどういうことができるのか?を説明するときには私はいつも、こんな感じの表を使って説明します。

Azure DevOps は、他のさまざまなサービスを組み合わせて実現する部分を、代わりにAzure DevOps だけで実現できるようにカバーしています。そのため、似ている他のサービスをあげて説明するとわかりやすいようです。例えば、もともと「CI/CD に使おう」と思っていたケド、「作業管理も手動テストの管理もできるなら、それも一緒に扱えるようになりたい」という話になったりします。

また、私は、今はまだ GitHub を Azure DevOps の代わりに使うことが出来ないと思っていますが、それはこの表にあるとおり、チーム開発するときに特に重要な作業管理の部分などを、まだ今の GitHub は扱うことが出来ていないからです。この辺りは近々の GitHub のアップデートで変わっていくかもしれません。そうなってきたら、また表をアップデートして、GitHub と Azure DevOps の比較もしていきたいですね。

続きを読む

最近、プロジェクトで Azure DevOps を使うことが多くなってきて、「Azure DevOps の Board の正しい使い方を教えてください。」というようなことを、よく質問されるようになってきました。

Azure DevOps は簡単に使い始めることができるので、かえって、自分たちがちゃんと使えているのか不安に思うのかもしれません。Azure DevOps 自体は、自分たちのプロジェクトに合わせて、自由に変えてよいのですが、例えば Scrum.org ではアジャイルのフレームワーク「スクラム」を変えないように(変えてしまうと スクラム じゃないよ)というような事が示されていたと思います。自分たちの好きにかえて、正しくない使い方をしてしまうのは不安。正しく使いたい。という気持ちはよくわかります。

なので、今回は「スクラムとしてAzure DevOpsを使用するにはどうするのがよさそうか」という観点で見てみたいと思います。Azure DevOps にはすでに Scrum テンプレートが設定されているものとします。

例えばシナリオとして、「ドキュメントは Markdown 形式のテキストファイル(.md)で編集し、最終的な成果物として Word ファイルを作成する」というような場合、私は Pandoc を使用します。

ローカル環境なら、Pandoc をインストールして、Visual Studio Code の拡張機能も入れて・・・ これはこれで書式などを細かく調整するときには小回りが利いていいのですが、ドキュメントを書くメンバー全員がこれをやる必要はないなと感じてしまいます。

もしビルドパイプラインで Pandoc が使えるなら「Git リポジトリを更新すると、最新の Word ファイルが誰でもダウンロードできるようになっている!」ということが実現できます。

例えばシナリオとして、「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時間)の時間をとって、何が良かったか?何が良くなくてどう改善するか?をみんなで話し合います。

他のスクラムイベントはしっかりやれているのに、スプリント振り返り だけやれてないという話はよく聞きます。重要なこのイベントを、ちゃんとやれるように何とか定着させたいところです。

スクラムイベントは Scrum.org の Scrum Guide に定義されています。

新しく開発チームのサイトを作るときに、サイトの Welcomeページにこれらのイベントを記載してメンバーに周知したいので、私はよく README.md Markdown ファイルにチートシートを書いておきます。

現在ではクラウドの Azure DevOps を使用できれば、簡単にCI/CDを構成できます。開発者がコードを変更したら、自動的にビルドして、テストを行い、開発・動作確認用のWebサーバーなどに自動的にデプロイ。管理者に承認依頼が送信されて、承認すると、次のテスト環境や運用環境に自動でデプロイされる、という構成を簡単に作ることができます。

※CI/CD : Continuous Integration(継続的インテグレーション)/ Continuous Delivery(継続的デリバリー)

現代の開発では、このCI/CDなしにはもはや開発をすることができないと言っても過言ではありません。たとえクラウドのAzure DevOpsを使えなくても、常にCI/CDを実現したいものです。今回は、Azure DevOps Server(オンプレミス版の Azure DevOps、旧称 Team Foundation Server : TFS )を使用してこれを実現しました。

今回はこのフローを実現しました。ソースコードを変更すると自動的にWebサーバーに配置されます。