Clean Agileを読んだメモ

最近Clean Agileを読みました。
ソフトウェア開発に関わる者として、心に残ったセンテンスが多かったので今の考えといっしょにメモに残しておきたいと思います。
※引用は一部自分用に意訳されているものがあります。

鉄十字
品質、速度、費用、完成のうち好きな3つを選べる、4つは選べない

トレードオフがあることを常に認識しておきたいです、切羽詰まると忘れてバランスを欠くことがあるので。

希望の喪失がアジャイルのゴール
希望がプロジェクトを殺す前に、アジャイルで希望を破壊するのである

名言と思いました。いかに早期に現実を知るか(= 希望を破壊する)が大事と。

要件変更は我々のゲームの名前
変更を受け入れてエンジニアリングする能力と、そうした変更を比較的安価にできるかどうかにかかっている

改めて自分の仕事がなんなのか認識させられました。
変更の容易性を保ちつつ品質や速度などとバランスを保つのは難しいなと日々思います、精進しないといけないです。

イテレーションは失敗しない、イテレーションの目的はマネージャーのためにデータを生成することだ

ベロシティが下がってもそれは失敗ではないと。

ストーリーはINVESTという頭文字のガイドラインに従う
Independent, Negotiable, Valuable, Estimable, Small, Testable

このガイドラインは知らなかったのでなるほどと思いました。覚えやすいし使いやすい。
とても有用なガイドラインと思ったので自分のところでも使ってみようと思います。

仕様とはテストである

名言②。極論ですが、ビジネスサイドは開発サイドに雰囲気で要件を察してほしいと思っていて、逆に開発サイドはビジネスサイドに詳細な仕様を要求しがちです。 これは両方極端に自分たち本位な考えなので、ではどこが落としどころとして良いかという意味でテストが仕様として最適だという話です。
上の例ほど極端な考えは持っていないですが、もう少し具体的に要件を固めてほしいなと思ったり、 逆にそこまで踏み込んで決められるとやりづらいのだが、という感じの線引きの難しさみたいなのは日々感じており、 そこでこれを読んで、テストでもらえばいいのかと目からウロコが落ちる思いでした。

QAはプロジェクトの後方でテスターとして活動するのではなく、前方で活躍する仕様作成者となるのだ

これぞQAのあるべき姿と思いました。

TDDの3つのルール
・失敗するテストを書くまではプロダクションコードを書いてはならない
・失敗するテストを必要以上に書いてはならない
・プロダクションコードを必要以上に書いてはならない

テストもプロダクションコードも両方とも必要以上に書いてはならないというルールは知りませんでした。
インクリメンタルに、かつ着実に開発を進めるために、明確で良いルールだなと思いました。

リファクタリングは計画に入れるようなアクティビティではない、分単位あるいは時間単位でソフトウェアを書くアプローチである

いざリファクタリングを計画に入れようとしても、なかなか時間を取れず、結局できずに時間だけが過ぎていくというのが往々にしてあります。 この文章を忘れずに、普段から負債を返済するアプローチを取りたいです。

仕事(job)を持つことと、職業(profession)を持つことは別ものだ。仕事はやるものであり、自分の一部ではない。一方、職業は自分の一部である。職業は投資するものである。職業は人生に意味を与えてくれるものである。

アジャイルとはあまり関係ないですが、まさにと思ったのでメモ。