名古屋アジャイル移動図書館「導入しやすいアジャイルプラクティス本」ブックトーク会

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

久しぶりに読み返しました。第一章と第八章を読みました。

第一章
  • 「ソフトウェア開発はもはやプロジェクトですらない」
    • 継続的な開発、価値探求こそが今日の開発
    • 「まとめて後でやる」をしない
  • アジャイルであるとは、(中略)フィードバックに基づいた調整を行ない続けること」
第八章:アジャイルなコラボレーション
  • 定常的に顔を合わせる
  • アーキテクトもコードを書く
    • これは時代を感じさせる物言い。別にコードだけが大事というわけではなくて、工程間に壁があって壁越しに成果物を投げつけるのはよくない、ということがいいたいのだと思う。
  • みんなに知らせる
  • 共同所有
  • 力を貸す
  • メンターになる
  • レビューする

協調しようとする意思と行動

「価値ある成果を毎週必ず届ける」

  • 大きな問題は小さくする
  • 本当に大切なことに集中する
    • トヨタ式で言うところの「ムダを排除する」
  • ちゃんと動くソフトウェアを届ける
  • フィードバックを求める
  • 必要ならば進路を変える
    • 計画は手段
  • 成果責任を果たす
    • 成果責任とは、品質、コスト、期日、そして顧客の期待を満たすこと

「たゆまぬ改善のための努力を惜しみなく続ける」

  • アンチパターン「忙しくて改善活動している暇なんてない」
    • メタ視点、目的意識、自律、自己組織化チーム…

「自分の頭で考えるのをやめちゃだめ」

  • ウォーターフォールはリーダーの力に依存する
  • アジャイルはビジョン(に導かれるチームの力)に依存する
  • ラクティスには二つの面がある
    • 思想・背景
    • 手法・フロー
    • ラクティスを説明するときには、この二つのどちらを聞き手は求めているかを考えて話す必要がある
      • 聞き手の期待のたすき掛けになると、理解も満足も深まらない