アジャイルサムライを読んだ

アジャイルサムライ――達人開発者への道

感想

・読みやすい！

目次

・これは今まで思っていたことと違うなあ、という部分をかいつまんで紹介する

第I部「アジャイル」入門

第1章 ざっくりわかるアジャイル開発

・アジャイル開発の原則について
・ちゃんと動くソフトウェアを届けることが大事
・マスターストーリーとユーザストーリーを作って、それを実装することで最終的なソフトウェアを作成
→　これはSIer語に翻訳すると機能要件一覧とWBSで分割された後のタスクに近い*1
・開発はイテレーションで行う
・フィードバックを求める

第2章 アジャイルチームのご紹介

・意外にここは今までとあまり変わらない気がした。イテレーション的な開発を全員が理解していればOKなのでは
・いいチームというのは協力しあうチームだし、いいマネージャーは開発のための障害を取り除くものだ

第II部 アジャイルな方向づけ

第3章 みんなをバスに乗せる

第4章 全体像を捉える

第5章 具現化させる

・３〜５章までまるっきり要件定義の話ですよ！
・インセプションデッキという武器、使おう
・わりと要件定義のテクニックな話なので関心しきりです*2
・「不確実性コーン」は知った上で、手ごわい質問をしろ
・間に合わんときは作業者を増やすのではなくスコープを落とす*3

第III部 アジャイルな計画づくり

第6章 ユーザーストーリーを集める

・変化に対応できないドキュメントなんて作らねえよ！そのためのユーザストーリーや！

第7章 見積り：当てずっぽうの奥義

・進捗はユーザストーリーの消化具合と、作業したタスクとの比較で求める

第8章 アジャイルな計画づくり：現実と向きあう

・進捗管理の話、特に感想なし

第IV部 アジャイルなプロジェクト運営

第9章 イテレーションの運営: 実現させる

第10章 アジャイルな意思疎通の作戦

第11章 現場の状況を目に見えるようにする

・９〜11章アジャイルな開発を運営する場合のサンプルケース、必読

第V部 アジャイルなプログラミング

第12章 ユニットテスト：動くことがわかる

・ユニットテストの運用の仕方、大切さを説く。
・やっぱりイテレーション型の開発でないとユニットテストは有用ではないのかなあ…

ユニットテストの利点を抜粋

・素早いフィードバックが得られる
・極めて低コストにリグレッションテストを実行できる
・デバッグ時間を大幅に削減できる
・自信を持ってデプロイ出来る

第13章 リファクタリング：技術的負債の返済

・プロダクト or プロジェクトマネージャーへ
「早い目に古いコード＆フレームワークを片付けないとソフトウェアが腐って更新できなくなるよ」
→　腐ったコードは複雑性が上がる、複雑性が上がると修正難度が上がる、修正難度は指数関数的に上がる→動かない

・プログラマーへ
「普段からリファクタリングしないで後からまとめてやると進捗０になるから激おこプンプン丸になるよ」
→　まとめてリファクタリングするぜ
→　機能追加してるわけじゃないのにどんだけ時間使ってるんや
→　（アカン）

第14章 テスト駆動開発

・テスト駆動開発、出だしが通販の宣伝みたいだから半信半疑
・ユニットテストがしやすいコードを書くことには賛成

第15章 継続的インテグレーション：リリースに備える

・常在戦場の精神

今までの自身の経験と比較してみる

・開発項目を大雑把に見積もった場合、タスクが大きくなるほど見積もりの時間が不正確になることは経験上私もよく理解している。アジャイル開発では、そもそものその過ちを犯さないようなルールで作業を行う。
・ユーザストーリーごとに作業を分割することで要件と実装を二項対立させている、なるほど上手い手法である。仮にエンジニア側がタスクを細かくした場合、おそらく機能単位で分割され非効率だ。
・かつてSIerだったときユニットテストの有用性について話しても大抵あまり同意はされなかった。それは最終的にテストコードを書いたら工数がかかるという意見に収斂された。いくら有用性があっても時間的なコストがかかると。それはたぶんテストコード書く前提の開発スタイル（イテレーション）ではないから。なおかつユニットテストを通せるコードをかける人が少ないことにつきると今思う。*4

*1:生物でいうところの相同に似ている。 相同 - Wikipedia 、見た目は似てるが根っこは違う

*2:私は要件定義したことなし

*3:このへん人月の神話案件ですね

*4:mockを使ったコーディングはJavaでもPythonでもちょっと難しいし、きちんとクラスとメソッドを分割してコーディングするのは一山いくらの労働者では無理だ。ユニットテストをよく理解しないままコードを書いてもバグはとれないし死ぬしでいいことがない。じゃあ、言語の複雑性を排して、ユニットテスト止めて人海戦術で開発…有る意味それも正解かもしれないが永久に終わらないサグラダファミリアの出来上がりを予感させる。なぜか？ユニットテスト時点ではソースコードの複雑性は最小まで分解されているため、そこでバグを修正して結合すれば修正難度は高くない。ユニットテストをせず、結合後に人海戦術でバグを見つけると、ソースコードの複雑性は増しているので修正難度は高くなる。でも見た目のコストは低い、炎上するまでは、炎上したらお金がかかるから誰でも失敗だとわかる。