体はドクペで出来ている

インフラ、Goの割合が多い技術ブログ

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

はじめに

この本はアジャイル開発の実践的な考え方・プラクティスを紹介していくもので、親しみやすい口語と豊富なイラストを中心にしているのが特徴です。

shop.ohmsha.co.jp

そもそもアジャイル開発とは、という入門編から始まりツールの紹介や計画作り、プロジェクト運営、プログラミングの手法まで一通り開発の全体を扱います。また単なる方法論のみではなく日本語訳者によるコラムを通して実例の紹介等もあり、親しみやすさと相まってとても理解がしやすい一冊となっています。

読書メモ

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

  • 誰もがアジャイル開発を気に入るわけではない
  • アジャイルは決まりきったものではない。自分自身が編み出したアジャイルもあり得る
  • 物理的に同じ場所で働くチームは生産性が高い
    • 分散する場合はキックオフとして集まる予算を確保しお互いをよく知る機会を作る
    • 立ち上げが上手くいけばあとはリモートでも上手くいく
  • 顧客と信頼関係を築いて開発に巻き込んでいく
  • アジャイルの資質
    • ゼネラリスト
    • 曖昧な状況に抵抗が無い人
    • 我を張らないチームプレイヤー

第II部 アジャイルチームのご紹介

  • プロジェクトを始める時にステークホルダーを集めて期待の摺り合わせと疑問の解消をする
  • 作ろうとするものの背景を掴む
  • 解決したい課題が発生する現場に足を運び自分で確かめる
  • 「司令官」の意図を掴む
  • フィーチャーではなくフィーチャーの効能をアピールする
  • ご近所さんを探す(プロジェクトのコミュニティに関わる人を洗い出して予め知り合いになっておく)
  • チームの選定はアーキテクチャーの選定と同義
  • リスクには取り組む価値のあるものとそうでないものがある
    • ニーバーの祈り
  • トレードオフスライダー
  • 開発チームに語りかける声は一つだけにする

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

  • ソフトウェアで実現したいものを表現する手段として文章は貧弱過ぎる
    • 不要というわけではなく、頼りすぎてはいけないとうこと
  • 今挙げられている要件は本当に「要件」なのか?
  • ユーザーストーリで要件を確認する
  • 見積もり技法
    • 三角測量
    • プランニングポーカー
  • 現実(に起こるトラブル)に立ち向かう
  • 現実を計画に合わせるのではなく、現実に計画を合わせる

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

  • 価値ある成果を毎週届ける
  • ストーリーは必要な時に必要な分だけ掘り下げて分析する
  • 建設的にフィードバックする
    • 糖衣に包んで冷たい言い回しは避ける
  • 振り返りを魔女狩り・裁判の場にしない
  • 貼りもので現場の状況を可視化する
  • プロジェクトで使う言葉を明確にし共有、ソフトウェアにも反映する

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

  • 問答無用で実践すべきプラクティス
  • 技術的負債は避けられないのでこまめに返済する
  • 金銭と同じく、技術の負債も大きくなりすぎると破綻し返済不能になる
  • TDDはテストを先に書くのが目的ではなく、必要最小限のコードを書くため
  • ビルド時間は短く(10分以内)保つ
  • アジャイル開発であるか否かは気にせず、良いプロダクトをリリースできているかを気にするべき

第VI部 付録

割愛

感想

本書で一番良いと思ったのは本記事冒頭にも書いた読みやすさです。基本的な文章は口語体で書いてあり、随所に図がちりばめられていて理解を助けてくれます。カイゼン・ジャーニー等も良い書籍ではありますが、私としてはストーリーが比較的重厚でありアジャイルの第一歩としてはやや重たいと感じていました。本書は知識の習得という面においては過去に読んだことのあるアジャイル系書籍の中では抜群に優れているので、まずこの書籍で知識を身に着けその後より実践的なストーリーをベースに他の書籍で理解を深めるのが良いのではと思います。

ページ数自体はそこそこ多いのですがそれを全く意識することなく休日にまとめて通読することができる良書でした。