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

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

今日からアジャイルサムライを読みます。普段アジャイルや開発手法についての書籍を読むことはあまりないのですが、本書はとても独特な文体で読みやすいようなので、気楽に読んでいこうと思います。それにしてもかっこいい表紙ですねー。

• 読者の声多いっ。バンナムに認定スクラムマスターが居るというのにおどろきました(そこかよ)
• 本書で学ぶこと
  • プロジェクトの準備、立ち上げ
  • 見積、計画のたてかた
  • 成果をあげるための手法、プロジェクト運営
• 「からかっているわけじゃあないんだよ」
  • 「いいね、あたしそういうの好きよ」
  • 「サムライ戦記」実際のエピソードを交えたコラム
  • 「今すぐやってみよう」練習問題
  • マスター・センセイ登場

では第1章へ入ります。メモは書いてあることと自分で解釈した内容がごっちゃになってます。

• "価値のある"成果を"毎週"顧客に提供するには
  • "価値のある" とは
    • とにかく動く(書類ではない)
    • 必要な(優先順位の高い)機能が実装されている
    • 適切にテストされている(適切なテストって？)
• そのために必要なこと
  • 大きな問題は小さく分割
    • すごいどうでもいいけど「短かい」は「短い」の送り仮名のほうが教科書的には正しい
  • 大切なことに集中して他は忘れる
    • 実際にはドキュメント(というかマニュアル)はまっさきに要求されるので、うちでは機能のリリース時に書かないといけないことになってる
  • "ちゃんと"動くソフトウェアを届ける(つまりテストする)
  • フィードバックを求める
  • 進路を変える(ことを恐れない)
  • 成果責任
    • 品質、スケジュールの遵守
    • 期待のマネジメント？
      • 暗黙的な期待のいき違いが問題
• 「アジャイルに開発するというのは、これまで経験したことのないほど強烈なスポットライトを浴びてるみたいな感覚だ」
• アジャイルな計画づくり
  • ToDo リストのことを「マスターストーリーリスト」とか「ユーザーストーリー」と呼ぶ
    • アジャイルの人達って厨二病っぽい
  • feature - 機能、性能など。「ユーザにとっての価値」という側面から記述する
    • タスクじゃないんだよタスクじゃ
  • イテレーション - 1週間か2週間。あれ、毎週リリースするとしてイテレーションが2週間でもいいのかな？
  • ベロシティ - 1回のイテレーションでこなす feature の"量"を実測する
    • "量"であって"数"じゃないところがむずかしそう。"量"はどう測るんだ？
    • 継続的な測定でチームの作業キャパシティを予測できる
    • 「開発チームが自分たちの限界を超えた成果をあげることをコミットメントしてしまうことを避けられる」なるほど。しかしこれは見積だけの問題じゃなくて顧客との関係性の問題のほうが大きいと思う
    • スコープを柔軟に - まあつまり顧客との関係はアジャイルな開発をする以前の問題ってことか
  • 完了 - リリースするための全ての作業が終わってる
    • 動くソフトウェアが進捗の最重要尺度
• 3つの真実
  • 開始時に全ての要求を知ることはできない
  • 要求は変化する
  • やるべきことは常に与えられた時間と資金より多い
• いろんな手法
  • Scrum
  • XP
  • Lean
    • 実際のプロジェクトに応じて原則やプラクティスをどう適用するか「自分で考える」これが重要

「期待のマネジメント」という言葉の意味がよくわからなかったですが、おおむね大変読みやすいですね。疑問もふつふつと湧いてきますがそれもまた良し。