アート・オブ・アジャイルデベロップメントを読み始めた

以下の輪読会イベントがあり、興味があったので購入。
（実際には1ページくらいしか読んでなくて、輪読会イベントには間に合わなかった）

アートオブアジャイルデベロップメント輪読会 #1 (2020/11/15 20:00〜)

本書に興味を持った理由と現状の課題感

現場ではスクラムを取り入れた開発を行っている。

だから対外的にはアジャイルな開発を行っていると言っているのだが、疑問に思う時も多い。

・そもそも何をやっていたらアジャイルなのか。ウォーターフォールで無ければいいのか？
・何のためにアジャイルやっているのか？　というのが自分でうまく言語化できない
・受託の場合、顧客に「どんどん要件変更やっていいんだ！」って思われて、ガンガン要件変更、そのたびにスケジュール見積もり、当初見積もった期間・お金から変更ないかどうか調査をするタスクが毎回発生する。→これがアジャイルなの…？

アジャイルを始める為のマインドセットが失われて、プラクティスにやらされている感がすごくする、というのが割と課題になっている気もする。

プラクティスをルール通りに守るのは大事ではあるけど、ルールを守ることが目的になってはいけないような。

スプリントの期間を最初1週間に設定したとして、
何か機能開発をやるのはそれで良いとしても、状況が変わって、
たとえばよくわからない技術調査タスクが主体になっているところは、1週間のスプリントでは齟齬が出るかもしれない（出ないことももちろんあると思うけど）

そうなったときに、臨機応変にスプリントの長さを変えたり、何か対応していくのがアジャイルなチームだと思うけど、
そういう考えではなかった場合「スプリントはタイムボックスを守るのが大事だから変えないままでいこう」となるのは、なんだかプラクティスを守る方に目的が偏ってしまっているのではないかと感じてしまう。
（あとよくあるのが、こんなのスクラムじゃない。みたいな議論。目的がスクラムをやることにすり替わってしまっている）

個人的には、アジャイルマニフェスト（や、背後にある原則）に書かれている、アジャイルの価値や原則を理解することが出発点だと思っているけど、フレームワークやプラクティスを導入する方が断然やりやすいのもわかる。

だし、結局なにができればアジャイルなのか？　というのがあまりわかっていない。

そういった課題感と、上記輪読会が始まるということで、読み始めることにした。

この本に期待すること

・何ができるとアジャイルなのか、何ができればアジャイルな開発をしていると言えるのかが学べること
・アジャイルの価値や原則を周囲に（より早く）理解してもらう方法
・これがアジャイルなのか、という気付きが得られること

これらを考えながら読み進めてみよう。