新年あけましておめでとうございます!今年もよろしくお願いいたします。ということで(?)、このブログのデザインを新しくリニューアルしました。

PC表示のキャプチャイメージ1
続きを読む

そろそろ、「入社してからずっとリモートワークで、他の人がプログラミングする様子を見たことがない!」という方も多いのではないでしょうか?私がプログラミングを始めたばかりのころは、他の人がコードを書いているのを後ろから見て、「あぁ、そうやってやるのか」と自然に覚えたことも沢山あったので、今からプログラミングを始める人は、もしかしたらそういう機会が少ないのではないか?とちょっと心配しています。

また、プログラミングが上達してくると、後輩から「それどうやってるんですか?早くて全然何やってるか?わかりません」と言われて、コードの書き方やIDEの使い方を教えたりという機会がありました。そういう機会も最近は少ないような気がします。こんな状況であっても先輩として、後輩にさっと覚えておいてほしいことを伝えられるようにと、今回 Visual Studio の便利な使い方の中で、特にプログラミングが劇的に早くなる方法を5つ選んでまとめました。

ウォーターフォールとアジャイルを比較する話は、違いを説明する都合で、実際によく話をすることがあるのですが、実際にウォーターフォールと比較すべきなのはアジャイルではないと思っています。書籍 More Effective Agileには「アジャイルと比較すべきはシーケンシャル開発である」と記載されていますが、そういったいわゆるウォーターフォール的な開発だとみんなが認識しているものと比較すべきなのは、「スケールされたアジャイル」だと私は思います。

いわゆるウォーターフォールをソフトウェア開発で採用するのは、PMBOK で必要なプロセスとドキュメントがしっかりと定義されていて、エンタープライズ開発で採用しやすいからです。これがなければどのように進捗や品質を管理すればよいのか?わからなくなってしまいます。

そこでもしウォーターフォールから切り替えるとするならば、切り替える先としては、「アジャイルを採用した小規模な開発」ではなく、「大規模な開発も扱えるアジャイル」が求められます。しかし、一般的なアジャイルのフレームワーク「スクラム(Scrum)」では、最大10名までのチームで扱える範囲の開発しか対応できそうにありません。これがフィットする規模の開発であれば、例えば社内システムの開発で小規模から始めるというのであれば、イメージしやすく「アジャイル(Scrum)でやってみましょう」と言いやすいでしょう。しかし、ソフトウェア開発を請け負う会社にとっては、多くの場合は規模が小さすぎます。もっと大きな規模のエンタープライズ開発に耐えられる方法が必要です。そこでついつい、Scrumを自分たちにフィットするように変えてしまう Scrum But になってしまいます。しかし、Scrum But は成功しません。その結果「アジャイルはダメだ」という主張になったり、完全にウォーターフォールのまま用語だけ変えた「なんちゃってアジャイル」が流行ったりするのだと思います。

続きを読む

アジャイルコーチとして、あるいはスクラムマスタとして、スクラムチームの改善に取り組まなければならないとき、私がいつも最初に確認するのは「完成の定義(完了の定義、DoD、Definition Of Done)」です。

「スクラムがうまくいっていない」と表現されるとき、多くの場合、期待されるより開発のスピードが遅いということや、品質に問題があるということが起きています。そしてそれは、完成の定義が適切に記載されていない、あるいはそもそも完成の定義がない、ということが原因だったりします。

続きを読む

これはよくあるケースだと思います。

毎日デイリースクラムもうまくやれているし、だんだんチームがアジャイル(Scrum)に慣れてきたかな・・・というタイミングで、スクラムマスタやリードディベロッパーがお休みで不在だったりすると、デイリースクラムがスキップされる。いつものデイリースクラムの時間に集まった人も、誰も発言をしないで、自然に「今日はしなくていいよね」と解散になる・・・なんということでしょう?!チームはアジャイルに慣れてきたのではなかったのか?!

これは、チームが Scrum のイベントを定義の通りに行えるようになってきたとしても、それはメンバーが全員スクラムを理解しているわけではない、というのが重要なポイントかと思います。

続きを読む

会社のトレーニング資料で話をするときにも、Scrum.org 公式のスクラムガイドを使って社外の人に話をするときにも、初めてスクラムを勉強する人のために概要を説明するときに、必ず伝えるようにしていることがあります。それは「アジャイルは文化に踏み込む、そうじゃないと勝てない!」というお話です。

Scrum.org スクラムガイド(日本語ダウンロードできます)

従来のウォーターフォール(PMBOK)では、プロセスやドキュメントに注目していて、組織の文化は問われませんでした。

しかし、アジャイル(スクラムガイド)には、スクラムの5つの価値基準として「確約(Commitment)、集中(Focus)、公開(Openness)、尊敬(Respect)、勇気(Courage)」があげられています。スクラムが成功するかどうか?は、チームのメンバーがこの価値基準を実践できるかどうか?にかかっていると明記されています。

続きを読む

最近、プロジェクトで 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 のタスクのメンションを使うのが良い感じです。