わかりやすいアジャイル開発の教科書

わかりやすいアジャイル開発の教科書

昨夜、帰りの電車で読みました。感想を少し書かせていただきます。

これまで個人的に読んだ本は、前口上やあるべき論や概念の紹介にページを割いていて、じゃ実際はどうするの？がよくわからないものが多かったように記憶しています。

本書は上流から下流まで開発の流れの中で開発者・チームの視点で問題をどのようにとらえ取り入れていくかについて具体的に書かれていると思います。

アジャイル開発を既に実践されている方というよりは、既に何らかのプロセスで開発していて、これからアジャイルを導入しようと考えている方が全体を把握するために読む本だと思います。そういう意味ではまさに「教科書」というタイトルがピッタリだと思いました。

開発経験がある方なら読み終えるのに時間はかからないと思います。いまさらだけどアジャイルが気になるという方は手にとられてみてはいかがでしょうか。

以下は読書メモです。既存のプロセスがある会社で新しいプロセスを導入する難しさは理解しているつもりです。この身となっては実践する場がありませんが、やはり知識だけでなく実践してみないと本当のところは身に付かないですね。

■読書メモ（お気に入り、疑問など）

• まさに現場のプロの声ですね。ICSEのKeynoteか何かで産学がどう関係していくのかよい方向性を模索しているとありました。

ソフトウェア開発を「工学」として考えていくことで、ソフトウェアが大規模でも成立でき、社会に対して大きな価値を生み出せるものに発展してきたのは確かです。（略）さらに発展するために、もう一度原点に戻る必要があったのではないでしょうか。つまり、いったん置いてきた「ソフトウェア開発は人の作業である」という視点をもう一度取り戻しているのがアジャイルだといえます。

• 開発にはリズムが大切。そのためにタイムボックスを定義する。期間は任意（通常は１〜２W）。ただし一度決めた期間は絶対に変えない。
• 思いから価値を描く（ストーリーカード、プロダクトバックログ）→タイムボックスで価値を確認する（タイムボックス）→価値をカタチにする（タスクカード、スプリントバックログ、コード）。
• ストーリーはタイムボックスで完成させること。
• 問題・疑問整理にはSmiling Adventure
• タイムボックスは単なるマイルストーンではない。マイルストーンは段階的な成果物がある程度まとまってできていなければならない時期に設定する。そのため一定ではない。一定でないとリズムにならない。ズルズル行ってしまうのが現状。なるほど！リズム、ベロシティ大事。
• いま必要なものだけ実践する：YAGNI
• 計画は固定せず、変化に対応させていく
• タスク分割はリーダー一人がやるものではなくチーム全員でやるもの。やらされ感がない。
• パーセントマジック：９０％からが進捗しない。残り何日で報告させる。
• Road to done（）；作業完了までの作業項目とパスと完了条件を明確にしメンバーで共有すること。
• タイムボックスの中でKPT（けぷとと呼ぶらしい）を実施するのが効果的。
• ソフトウェアかんばん(個人別にToDo, Doing, Doneを見える化)
• burn down chart（タイムボックスごとに作る）
• ニコニコカレンダー
• ソフトウェアあんどん
• ペアプロ、ペアプロシミュレーション
• TDD、リファクタリング具体例（P１６２〜１９４）
• CI
• アジャイルを現場に定着するための方法（ワークショップ、レゴスプリント、偏愛マップ、ペアドロー）
• 見積もりをコミットメントにしない←などほどなぁ。。。創造作業ですから時間はなくても心にゆとりをもちたいですね。言うは易しとは思いますが。
• プランニングポーカー
• ドキュメント化することの善し悪し。合意形成のためのドキュメント、保守のためのドキュメント
• ソースコードの品質はオーバーコミットによって無理をして悪くなる。オーバーコミットを防止してチームで達成すべき質を合意する。

補足でもう少し書きます。

前職で仕事に慣れたころに、ここまでやったら帰ろうという目標を作るように心がけていたような気がします。プロジェクト型の仕事はそうではない仕事とは違って、完成までに必要な作業は延々と続くわけで。そういう意味ではタイムボックスをはじめ、KPTやソフトウェアかんばんなどのツールを利用することで、見えにくい個々の作業を見える化でき、早く帰っても周りに影響がないかどうかもわかりますし、お互いに安心できるような気がしました。

もちろん人間は生ものですから後ろ向きなこともあるでしょうし。負荷バランスが悪くできる人に作業が集中したり、わざとできないふりをして怠ける人が出たり、ということもあるでしょう。本書の冒頭で述べられているように企業の歴史が長くなればなるほどその経験値が邪魔をして開発プロセスをいじることに抵抗があることもあるでしょう。その辺はアジャイル以前の問題だと思いますが。

実践する上で難しそうに感じたのが、タイムボックスへの落とし込みとタイムボックス間の関係の見極めです。予算と納期がある仕事ですので、都度、タイムボックスを見直すといってもタイムボックスをこれこれの順で並べるとソフトウェアが完成するという全体像はプロジェクト初期に決定すると思います。プロジェクトの中盤まできて変更依頼があったときに、既に確認済みのタイムボックス内で産み出した成果物に影響があることも十分に予想できます。できるだけ、ふりだしに戻ることなくタイムボックスをならべたり機能あるいはモジュールを分割する”センス”は重要なように思いました。あと見積もりですね。。。当然、競合他社との競札になるでしょう。そのときに見積もった価格は作業ボリューム（タイムボックス数）の上限を制約するでしょう。初期見積もりとユーザー・開発者でともに価値創出のためにできることをどう折り合いをつけるのか、そのあたりもミソのような気がしました。