Category アジャイル・DevOps

アジャイルができない理由は「イノベーションのジレンマ」か?

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

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

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

Read More

完成の定義(完了の定義、DoD、Definition Of Done)から改善してみる

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

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

Read More

スクラムマスタ不在だとデイリースクラムをしない

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

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

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

Read More

アジャイルは文化に踏み込む・そうじゃないと勝てない!

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

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

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

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

Read More

アジャイル&DevOps ならこの本を読んで

先日、DevOps・アジャイルでよさそうな書籍を紹介してほしいと頼まれたので、ピックアップしてみました。

変革の軌跡【世界で戦える会社に変わる”アジャイル・DevOps”導入の原則】
分かりやすくアジャイル・DevOps導入の考え方が解説されています。実際に組織に導入するときに最初に読むのにお勧め。個人的にはメトリクスの話がわかりやすくお気に入り。

Effective DevOps ―4本柱による持続可能な組織文化の育て方
しっかりとDevOpsについて解説されている、おそらく現在一番スタンダードな教科書だと思います。

進化的アーキテクチャ ―絶え間ない変化を支える
実際にアジャイルでどうやってマイクロサービスを使ってくのか?について、より詳しい解説を読みたい場合に。

業務システム開発モダナイゼーションガイド 非効率な日本のSIを変革する実践的ベストプラクティス
現場の開発者向け、少しシニアナメンバーに(アジャイルやDevOpsをいきなり導入するのは難しくても)少しずつDevOpsのツール・方法を導入してみては?という実践的な視点で。

SCRUM BOOT CAMP THE BOOK
定番のスクラム解説の本、マンガ・ストーリーで解説されているので、まだアジャイルトレーニングを受けたことがない人が全体イメージを理解するのにお勧めです。

The Scrum Guide™
スクラムガイドは、簡潔に書かれているのでこれだけで勉強するには不向きですが、アップデートがないか?確認したり、全体をおさらいしたりするのに最適です。日本語版は https://www.scrumguides.org/download.html からPDFをダウンロードできます。

「良いとこどり」でなく本気でどれで開発するか?選んでください

アジャイルがうまくいかなくなる魔法の言葉があると思います。「いい所を組み合わせれば」この言葉が出てくると、私は、あぁこのプロジェクトはアジャイル崩れになって、失敗するだろうな、と思います。

良いとこどり、ができると思って皆、悪いところどりをして、結果としてウォーターフォールでもアジャイルでもない、ただのグダグダ、素人が初めて開発やってみました、みたいな失敗プロジェクトになってしまうのです。

Read More