再読！アジャイルサムライ

転職前に読んだアジャイルサムライを改めて読み直した。自分用に整理しておく。
個人の感想で組織を代表する意見ではありません！

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

• 本当に大事なことは動くソフトウェアを定期的に届けること

  • 計画を立てて、うまく行っているか検査して、真実を受け入れるといいらしい。
  • 価値ある成果を毎週だすのが顧客（これは経営者も含むのだろう）。
    • • 成果を毎週というのは言葉のあやで詳細な方法は自分たちで考えろとのこと。

• 大事なこと

  • 大きな問題を小さく
  • 選択と集中
  • ちゃんと動くソフトウェアを届ける
  • フィードバックを求める
  • 必要とあらば進路を変える
  • 成果責任を果たす
    • 極論これらが果たせていれば方法はなんでもいいのだろう。
    • この本ではスクラムというワードはあまりでてこないが、スクラムでは透明性、検査、適応を通してこれらを達成したい感じなのかな。

• 紹介している手法は経験を共有しているだけでやらなくてはいけないものではない

  • 試してみてその中から使えそうなやつだけ続けていくのが良さそう
    • この考えがないとアジャハラ、スクハラになってしまう気がする。（僕は遭遇したことはない）

第2章 アジャイルチームのご紹介

• 機能をふんわりした構想から顧客にデリバリするまで全部やるチーム

  • いわゆるフューチャーチーム
    • 社でもクロスファンクショナルが熱かったり熱くなかったりする
      • 自分は最初クロスファンクショナルというのはメンバー単体でなんでもやれる状態をつくることだと思っていた
        • が実はそうではなく、一人でなんでもこなすと言うよりはチームで役割にこだわらず自発的になんでもやっていくということっぽい
        • アジャイルサムライでも、チームがいろんな役割をこなすが良いのではなくチームが自分たちの役割分担を自分たちで決めているのが良いことであると書いてあった
          • 自己組織化していけ

• 熱心な顧客のために信頼貯金を稼げ

  • 信頼してけ

第3章 みんなをバスに乗せる

• 今見ると表題が完全にLOLである。
  • バスを運転しろ。¹

• プロジェクトの期待と認識を揃えろ
  • 揃ってたほうが打ち手も正確になりそう

第4章　全体像を捉える

• Why here we are
  • これがないと期待されていることと関係ないことに時間を浪費してしまう
  • 正直株式会社組織で働いている以上「株価を上げる」から始まって「プロダクトの売上が伸びる」とか「チャーンを低くする」とがが目的になると思うのだが、もっと噛み砕いて、「〇〇がめっちゃ便利になる、同じような商品とは〇〇が違う」ぐらいまでは具体的に言えるとユーザーストーリーの優先度等が話しやすくなると思った
• パッケージデザインをつくろう
  • これは自分もやってみたいと考えていた
  • どんな製品を作りたいか考えるときに製品のLPから先につくれば、なにを売りたいのか？どんな機能が充実しているべきなのか？逆にやらなくてもいいことは？がLP上に現れると思う
    • セキュリティが大事なtoB製品ならデカデカとセキュリティしっかりしてますマークをLPに書くだろうし、toCで差別化が重要ならデカデカとその点をLPに書くだろう。文字だけよりよっぽどチームの認識が揃いやすいのではないかと思う

第5章 具現化させる

• チームで取り組む値打ちのあるリスクにだけ投資する
  • 心配してもしょうがないことを心配したり改善しようとすると疲れる
  • 判断がつかなかったら祈れと書いてあって草だった
• トレードオフスライダー
  • やったことがある
    • 時間と予算は簡単（決まっている）のだが、品質というワードが定義からして皆バラバラである
      • ある人はちゃんとテストがあることを品質と言うし、ある人はSLOを高めに設定することが品質だと思っているし、また別の人はユーザー体験の質を品質と考えている
        • 自分も品質ってなんなのかわかってないし、これだ！という一声を成功者が発していればそれになるのも違うと思う
        • というか時間も予算も品質もどうせ固定されるってアジャイルサムライに書いてあるので最初からスコープの話だけするトレードオフスライダーとかやったほうが良いのではないだろうか

第6章 ユーザーストーリーを集める

• 情報を伝えるもっとも効率的な方法はフェイス・トゥ・フェイスで話をすることです
  • はい…
  • ユーザーストーリーは簡潔に書きたいから小さいインデックスカードに書くと良い
    • なるほど
    • 大体のチケット管理ツールは文書欄がデカすぎる。
    • ビジネスの観点から評価できること
      • ビジネス側と仕事せよって第二章にも書いてある

第7章 見積もり: 当てずっぽうの奥義

• 当てずっぽうを前提に
  • そらそう
  • Netlifyはポイントをフルーツで例えているらしい。イメージしやすさが大事で数字より良い点もあるかもしれない
    • https://fberriman.com/2020/01/22/fruit-salad-a-scrum-estimation-scale/
  • 調査タイムも言及されている
  • プランニングポーカーについても言及がある
    • 基本1か3か5があれば良いらしい
    • 自分たちもだいたい松竹梅ぐらいでしか見積もりしてない気がするし正しそう
      • どうせ精密ではないのだから

第8章 アジャイルな計画づくり：現実と向きあう

• プロジェクトの状況も、顧客のやりたいこともころころ変わる
  • そりゃそう
• ユーザーストーリーが増えたら別のユーザーストーリーを減らしてもらう
  • 期日かスコープ減らすか
  • 基本は後者で
  • 無理なら全て打ち明けて黙って座って待ち続けるらしい
    • 深いなぁ
• 残作業と消化速度を見積もれ
  • そりゃそう
• スコープも期日も予算も固定されていたらどうするの？
  • どうせ無理だから隠すかさらけ出すしかない
  • そりゃそう。
    • 捨てたスコープを記録しておくと監査担当も楽なので○らしい
    • いいネ

第9章 イテレーションの運営: 実現させる

• ユーザーストーリーをJITコンパイルしていけ
  • はい..
  • 分析に使う手法はたくさんあるので模索していけ
    • はい…
• 開発はとりあえず自動テストを書いてCIに利用すること。TDDもいいぞ！
  • そりゃそう
  • 常に「テストが通ってるならGOGO」の状態を作らなくちゃいけないと思う
• たとえ自動テストがあっても形式ばった受け入れテストはなくさない方がいい
  • 受け入れテストはスプリントレビューのこと
  • 顧客は文字のチェックリストだけではわからない。動いているソフトウェアを動かして初めて本気でチェックしてもらえる
    • 確かに
• カンバン
  • ストーリーボードと違って、カンバンはチームをイテレーションから開放させるという点が決定的に違う
    • なるほど
    • カンバンとストーリーボードの違いが言語化されていて良い。本番環境へのサポート等現実的な悩みに対応している。
    • カンバンはイテレーションとは違うというのは改めて読んでみると興味深い記述。ストーリーポイントはいらないし、優先順位だけが全てらしい。ホントか？

第10章 アジャイルな意思疎通の作戦

• イテレーション計画ミーティング
  • 次回のイテレーションの具体的作業を計画したり、現状のプロジェクトの健康状態を確認する。
  • これはアジャイルサムライの内容からは脱線するが、イテレーションの具体的作業内容（〇〇を実装する、レビューする等）を見える形で可視化しておくと作業の進捗が確認しやすい。前職でも現職でも同じような作業を見かけたが、結構役立っていそうな気配を感じた。
• ミニ振り返り
  • 振り返りが10分とか15分で終わってほしい…
  • 振り返りは魔女狩りではない
    • 日頃思っているが口にできないこととして、振り返りで毎回TRYをひねり出すのは辛いというのがある。
      • とりあえず放置しちゃまずいかな？解決策でるまでちゃんと話あったほうがいいのかな…

第11章: 現場の状況を目に見えるようにする

• 経営陣にちゃんと状況を説明する
  • これを説得力もってやりたいから色々記録してる
• 用語を共有する
  • 現場で使う用語とDBのカラム名とかがピッタリ合ってるプロダクトは強い
    • しかし毎回要求も変わっていくなかでそれができるのか？
    • 開発者も最初はドメイン知識薄いわけだし
• この章には最高の文章があるので引用したい

うまくいかないときの根本原因は、感情に起因していることが多いものだ。 おそらくは、 お前が実現したいと思っている方向とは正反対の向きに引っ張る力が作用しておるのだ。 お前が立ち回る相手は、 お前のやり方への抵抗それ自体ではない。 その背後にある精神構造だ。

• つまるところ仕事全部これ！

第12章 ユニットテスト: 動くことがわかる

• テスト書け
  • あたり前田のクラッカー
    • 全部を網羅するのは無理そうな箇所でも少しでも書く
    • 大事そう。
    • この章では色々なテストに関する記事へのリンクがあるが、特にこれは良かった
      • テスト熱中症
        • 2000年時点でCIの重要性が書かれていてすごい。
          • 個人的には無駄な共通化して後悔してことはあるが、テスト書きすぎて後悔したことはない。本当に必要なテストか厳選するのも大事だが、テストを消すのは実装を消すより10000倍簡単だ

第13章 リファクタリング: 技術的負債の返済

• 技術的負債
  • なにかと荒れがちな話題
    • 変更しづらいから変更しやすくしたい！が根源的な欲求だと思う
      • ソフトウェアは進化し続けていくことに価値があるので
      • 名前を変えたり、それこそテストを足すとかも変更しやすくする方法として最高だと思う
  • リファクタリングの投資対効果
    • 投資対効果に言及してあるのが良い
    • 開発者は自分の人件費がこの負債によってどれくらい無駄になっているのか説明する必要があると思う

第14章 テスト駆動開発

• TDD
  • やると気分はいいのだが結構実装を先に書いてしまうことが多い
    • なんとなく実装を書く -> テストを書く -> 実装をちゃんと書く
      • なんとなく書いた実装をリファクタリングしてもテストが通っていることが確認できて最終的に良い実装になる気がする。
      • ただこの手順の問題点はテストが実装を知っているようなテストになりがちなこと
        • すぐ壊れるテストになりかねない。
        • がテストは簡単に消せるし良いのでは？とも思い始めている

第15章: 継続的インテグレーション: リリースに備える

• いつでもリリース可能な状態をつくる
  • レポジトリ、ビルドの自動化、チェックイン
    • 開発者が気をつけるべきこととして作業単位を小さくすることが挙げられている。
      • インテグレーションの頻度が高いほど（取り込む差分が小さいほど）簡単に統合できるのはそりゃそうである。

最後に

• アジャイルであるかなんて気にしない
  • 良く「アジャイルが状態でスクラムが手法」みたいに言われることが多い
    • 自分もそう思っていた
      • が、アジャイルサムライにはアジャイルであることはどうでも良くて大切なのは素晴らしいプロダクトを顧客に届けることと書いてあった
        • いい話