アジャイルサムライを読みました

なんかなんとなくやったことあるから分かってる、ググって断片的には知ってる、 っていう感じで、体系的に学びたかったので読んだ。

めちゃくちゃ学びがあるっていう感じでもない。 っていうのもここに書いてあることのエッセンスのほとんどを前職で体験していた。

そして開発進行にストレスを感じていなかったので、 アジャイル開発としての良い例を体験出来ていたんだなという学び。

反対に現職でストレスを感じていて、 自分があまりアジャイルを勉強していないこともあって、 こういうふうにしたいっていうのをあまり強く押し出せなかったのが、 ここでしっかりと勉強できたことで、ちゃんと持ち込めるなっていう気がした。

以下メモ

  • 書き方ちょっとうざいな
  • 明確な役割分担はしない
  • 誰もがこの働き方を求めているわけではない
  • 4つの質問をチームに投げかける
    • 得意なこと
    • どういうふうに仕事するか
    • 大切に思う価値
    • チームは自分に何を期待しているか
  • エンジニア
  • テスター
    • 専任の人と直接会って喋ったことがないのでこういう人がいるならいいなぁという願望
  • PM
    • 障害を取り除く
    • 優れたPMは1週間いなくてもチームが回っている
  • スクラムマスター
  • 曖昧な状況に抵抗がない人がいい
  • 駄目なプロジェクト
    • 答えるべき問に答えられない
    • 手強い質問をする勇気がない
  • インセプションデッキ
  • 顧客がコミットメント出来ないならそのプロジェクトはやらないほうがいい
  • アーキテクチャはチームメンバーによって決まってしまう
    • なので自分の出来ること得意なことを表明する
  • ニーバーの祈り
  • 四天王
    • 時間
    • 品質
    • 予算
    • スコープ
      • スコープは変えやすい
  • INVEST
  • 必要なときに必要な分だけ
  • イテレーションnで分析イテレーションn+1で実装
  • カンバン
    • WIPに上限
  • ストーリー計画ミーティング
    • 着手する準備は万全であるか確認する
  • おかわり
  • 人を動かす〜
  • デイリースタンドアップ
    • 会議体として正式に開催はしない
    • 毎日自主的に5~10分立ったままやる
    • 共有するのは3点
      • 昨日やったこと
      • 今日やったこと
      • 何か進捗を妨げる問題
    • ちょうど朝会に対する改善案を書いていたけど、いい感じに学べた
  • 成果がなくても披露する
    • 目を背けてはいけない
  • 毎回のイテレーションで10%はバグ潰しや改善に使うと良い
  • ユニットテスト
  • バグを修正する前に失敗するテストを書く
    • もうこれ親の顔より見た
  • 危なっかしいところをテストする
  • テストは自信を持つために書く
  • リファクタリング
    • 変数名・メソッド名から始める