書籍情報

レガシーコードからの脱却
ソフトウェアの寿命を伸ばし価値を高める9つのプラクティス
Amazon

概要

プロジェクトに挑む前にレガシーコードはなんたるや、コードをレガシーにしないための心構えを作る本

前提知識

必須

なし

推奨

「レガシーコード」「スクラム」「TDD」にピンとこない人

再読するなら

9つのプラクティスを目次で。
半年に1回とか、自分のプロジェクトの軌跡と照らし合わせてこの行いができたかを振り返る

一連の流れを説明している本なので、各手法の細かい方法を把握したい場合はそれ専用の専門書を買うべき。

9つのプラクティス

1. やり方より先に目的、理由、誰のためかを伝える
2. 小さなバッチで作る
3. 継続的に統合する
4. 協力し合う
5. 「CLEAN」コードを作る
6. まずテストを書く
7. テストで振る舞いを明示する
8. 設計は最後に行う
9. レガシーコードをリファクタリングする

つまり？

①やり方より先に目的、理由、誰のためかを伝える

スクラム＆PO向け説明を考えて行動する

②小さなバッチで作る

ユーザーストーリーをタスクに分解し、小さな単位で実装を行う

③継続的に統合する

CI＆テストを導入する

④協力し合う

エクストリーム・プログラミングな話

⑤ 「CLEAN」コードを作る

• Cohesive：凝縮性
• Loosely Coupled：疎結合
• Encapsulated：カプセル化
• Assertive：断定的
• Nonredundant：非常帳
  …な、コードを心がける

⑥まずテストを書く

⑦テストで振る舞いを明示する

⑨レガシーコードをリファクタリングする

素晴らしきTDD

⑧設計は最後に行う

設計を後に回し、末端から作ることでソースの重複やよりカプセル化された構造にできる。
タイトルに対して説明しにくい章だ…

所感

割と読んでる本のジャンルが被ってるのでそんなに目新しい発見はなかったかな的な。
レガシーコードを意識するための本としては良さそう。

書籍情報

アジャイルコーチング
Amazon

概要

チーム（対人）にアジャイルを浸透させる術、アジャイルを導入させる側としての本。
ところどころにチームリーダーとしての意識を考えさせられるような記述あり。
具体的な見積もり手法とかの話はアジャイルな見積もりと計画づくりの方が濃い。

前提知識

必須

なし

推奨

スクラムの実経験

アジャイルを導入させるための本なので、導入させるつもりがあって読むべき。

再読するなら

アジャイルを実践して、壁に当たったとき。
各章末尾に「苦難」の項目があり、こんなときは…の参考になる。
割と方法論なので、そんなに再読する系ではない。

人を導く立場として

第Ⅰ部

アジャイルの運用の仕方（人の説得の仕方）

第Ⅱ部

アジャイルの計画の立て方を明確な指標とともに考える

×
アジャイルな見積もりと計画づくりを読むべき

品質を考える上で必要な作業（バグ・テスト・リファクタリング）

第Ⅲ部

1イテレーションの終わりと次への始まり

第Ⅳ部

内容メモ

第Ⅰ部　コーチングの基本

アジャイルが云々というよりも、コーチとして、人の上に立つリーダーとして、認識しておきたい事項の確認。

第1章　旅を始める

アジャイルコーチのはじめ方～また次へ、を簡潔に説明した章。

• コーチを始める前に、動機・スキル・責任・支援を再認識する
• チームへは適切に紹介を受けて加入する。曖昧に入ると、コーチとしての信頼を失う
• PrOpERサイクルを意識する。
  　問題を探し（Problem）、改善の選択肢を検討し（Option）、実験（Experiment）、成果をレビューする（Review）
• 時間の概念を持ち、問題の原因・結果を考える
• ペースを維持する。進みが遅くとも、挫折せずに進み続けること

第2章　みんなと一緒に働く

チームとして他人と働く上でのコミュニケーションで大切にするべき部分の話。
相手の話はきちんと聞くとか、行間を読むとか。
議題によって対立した場合には即座に仲裁役に回る必要はなく、話を聞いたり、出ている意見に投票して視覚的に理解できるようにして感情論にならないようにする。

第3章 変化を導く

アジャイルの導入としてだけではなく、なにかの導入のときの心がけとも読める。

• チームに急速な変化を求めない
• 提案は宗教ではない。盲信しない。
• 説明だけでなく、実演して見せる
• 導入しないことによる問題を提示する
• 「提案された内容」ではなく、当事者意識を持たせることで自主性が高まる
  　・相手にオープンクエスチョン（「なぜ～だと思う？」のように、YesNoで回答できない質問）をする
  　・5回のなぜ（原因を5回探すとその間に根本的な問題が現れる）
  　・質問は誘導尋問ではない。明確な助言を持っているときの答えを促すための質問は信用をなくすので控える
• 学習の機会を作る

第4章 アジャイルチームを作る

アジャイルチームを作る前に、チームとしてのあるべき姿を考える話。心理的安全性の話とかまさにこれ。
まずはチームとしてお互いを信頼し、働くための場所を整える（物理的な席の場所を近づける）
チームのやる気を維持する。

• 簡単すぎず、難しすぎない程よい目標を常に立てる
• 説得力のあるゴールを決める
• イノベーションの時間を設ける（ゴールドカードを出した日は自分のやりたいことをやる＆結果を発表するとか）
• インセンティブ報酬には気をつける。他人を出し抜くような報酬はチームの協力を失う

第Ⅱ章　チームで計画づくり

いよいよスクラムし始める。

第5章 デイリースタンドアップ

いわゆる朝会。チーム全員がボード前に立って昨日の作業・今日の作業予定・困ってることを１０分程度で報告しあうのがテンプレ。
（これに限らず）ルールに縛られる必要性はない。「ルールに従っていればいい」と思うと自主性がなくなる。
あくまでチーム間での作業情報共有が目的なので、特定人物だけが話す場にはしない。
2部構成にして、対開発チーム・対営業チームとか分ける手法もあり（スクラムオブスクラム）
開始時間は絶対に朝ではなく、チームの都合で決める。
コーチとしては話が脱線したら補正する、当事者が慣れてしまった問題がないかを第３者の目線で考えながら参加する。

第6章 何を作るか理解する

ユーザーストーリーの作り方の話。
「＊＊というユーザーとして＊＊という機能がほしい。そうすれば＊＊という利益が得られる」をテンプレとして作成する。
３C（カード・会話・確認）が重要。
ストーリーを作成したあとにストーリーテストの詳細を確認する。
ユーザーの要求に応じて、詳細を詰めていく。
ユーザーが触れない機能（インフラ整備とか)もユーザー→プロダクトマネージャなどに置き換えて同じようにストーリー化できる。

第7章 前もって計画する

ユーザーストーリーを出したあとの見積もり・優先度会議の話。
顧客から次イテレーションに向けた目標を説明してもらう→チームで見積もり（※顧客は一旦退室しても可）→イテレーション計画（優先度・作業依存順に決定する・顧客にも説明する）

• イテレーションは数回の平均＝チームの作業可能実績であって、徐々に上がり続ける値ではない。そのような期待を持たない。
• イテレーション内で計画が変わり続ける場合、見積もりなどがうまく行っていない。調査が必要であればスパイクを設ける
• バグ修正の見積もりは難しい。かんばん方式への移行も視野に入れる

第8章　見える化する

チームボードの運用例。
・物理的
・見やすい
…なら、割となんでも良さそう。
ストーリーを優先度順に縦に貼って、横にToDOなどを並べるのが一般的な様子。（他の本もだいたいそう

なんでも見えるようにする必要はない。必要なくなれば運用を終える。
保守の仕方はチームで集まって検討するのが吉。

第Ⅲ部　品質に気を配る

テストどうするべきか？とかリファクタリングとか。
おそらく、この本自体が非エンジニア向けだから、こういう手段もあるよという紹介なんだと思う。
あまり深い部分までは突っ込まれてない。

第9章　完成させる

ストーリーテストの完成の定義を明確にする。
「テストする」だけでなく、自動テストとか、データ用意とか、実は作業はたくさんある。

バグを埋もれさせない。
変に気を遣って連絡しない（先にマネージャーを通してしまい、話が大きくなってる）とか、
頻繁に連絡して士気を下げるとか、やり取りは対人であることを意識する。

ストーリー未達を真摯に受け止め原因を振り返る。

強制されたツールの運用もきちんと考える

第10章　テストで開発を駆動する

ストーリーの完成条件でもあるテスト、それをTDDにしてみませんか、という提案。

TDDが早すぎるケースもある。
チームがテストのあり方について理解・同意できていない。
そのときは書き方を学ぶことから。

どこからテストを書くべきか？
まずは分離しやすい中間コードから。

CIも大切だがCIの規律はより大切。CI結果を無視しない

テストに時間がかかるようになると生産性が落ちてTDD持続も難しくなる。実行時間にも気を配る。

第11章　クリーンコード

作り続けるだけではなく、コードの綺麗さも考え続ける必要がある。

分析麻痺に陥ってないか？
ソースコードを書かずに設計ばかり考えてる。
逆に設計0も問題。
ユーザーストーリーに対して設計も意識する。

リファクタリングとか、チームでコードを共通所有する意識とか、ペアプロの話。

ペアプロは勉強のためではない。
少なくとも同じ言語で行う。
初心者対ベテランの組み合わせは問題ないし、お互いにお互いの意見をリスペクトし合う。

第Ⅳ部　フィードバックに耳を傾ける

イテレーションが終了して、次のイテレーションへ…行く前の、イテレーションデモ・その回のイテレーションの振り返りの話＋α。

第12章　結果をデモする

イテレーションの終了時のデモのやり方の話。

プレゼンの構成を決めて、全員が役割を果たす。
リリース事項として確認すべき事項も掲載。

技術的問題でデモが実行できない等は避けるべし。
事前準備・確認や、安定版を用意する。

第13章　ふりかえりで変化を推進する

ふりかえりのあるべきでない姿が載っている。
たまに見返して、自分たちの行っているふりかえりがどうかを考えてみると良さそう。

その期間にあった出来事と感情を導き出す。その時の気づきから改善のアイデアを探し、次に実行する
リリースレトロスペクティブでチーム全員で振り返る。これは大規模なので、事前に準備もする。

全員から、建設的な話を得るための場である。
話さない人がいる、不満ばかりの場になるべきではない。

第14章　あなたの成長

あなた自身が成長するために…のきっかけを渡そうとする章。
読み返すべきとすればこの章だけど、自己啓発話なので、それに特化した本を読んだほうが良さげ。

書籍情報

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～
Amazon

概要

スクラムにおけるストーリー・ベロシティの見積もり方、優先順位の付け方、ストーリーを計画に組み込む手法についての説明

前提知識

必須

なし

推奨

スクラムの実経験
SCRUM BOOT CAMP THE BOOK 、カイゼン・ジャーニーなどのスクラムの流れを把握できる本

アジャイルを初めて勉強するためには向かなさそう。先に別の本を読んでおきたい。

再読するなら

第22章：なぜアジャイルな計画づくりがうまくいくのか

アジャイル計画試したけど何かの壁に当たったとき。
計画づくりのためのガイドラインが載ってて9ページ。

内容メモ

第7部・ケーススタディから逆算する

結局の所、～の手法がわからないから読み返したいはずなので、
ケーススタディの流れに沿って再読するのが良さそう。

ユーザーストーリーの洗い出し

P273：「プレイヤーとしてxxしたい」をベースにユーザーストーリーを探し出す。
例：「プレイヤーとして新しいゲームを開始したい」

ユーザーストーリーの見積もり

P279：ユーザーストーリーに対し、ストーリーポイント（≠作業時間、≒作業規模）、もしくは理想日（≒作業日数）を割り当てる

見積もり方

第6章：見積もり技法

見積もりのスケール

フィボナッチ数列（1,2,3,5,8…）を利用する。
スケール値をバケツと見なし、若干多く入れることもできるが、多すぎるとあふれる、程度の感覚でスケールする

対比・分割

ストーリーごとの見積もり結果が同じ程度の単位までに収まるようにする。
1~8であれば、作業間の規模を読み取れるが、1:100では100の規模を読み違える。

第12章：ユーザーストーリーの分割

ストーリーが大きすぎて1つのイテレーションに収まらない場合は分割を考慮する。
ただし、タスク単位への分割は行わない。
・データ境界に沿って分割する
・操作の境界で分割する
・横断的な関心事を分離する
・パフォーマンス成約を分離する
・優先度に沿って分割する

プランニングポーカー

各人にスケール値のカードを配り、ストーリーに対する見積もりを同時に出す
・同時に出すので、他人の意見に引きずられない
・値に差が出たときにそう感じた理由を説明してもらう。ほぼチーム全員が話すことになるため、団結感が出やすい
・説明により、全員が同意して平均化された値になる。

再見積もりの必要性

第7章：再見積もり

ユーザーストーリーの優先順位

P285：ユーザーストーリーの優先度をリサーチして決める

優先順位の要素

第9章：テーマの優先順位付け
・フィーチャの金銭価値
・フィーチャの開発にかかるコスト
・フィーチャの開発を通じて学べる知識の量とその意義
・フィーチャの開発によって低減できるリスク
P106：図9.2の「リスクと価値の四象分類」がある。フィーチャごとにこの図に載せて決定するのもあり。

第10章：金銭価値による優先順位付け

収益、開発コストなど、金銭的要素を考慮する場合の説明

第11章：「望ましさ」による優先順位付け

ユーザーへのリサーチも視野に入れた開発優先度考慮手法

第15章：イテレーションの長さを決める

リリースまでの長さを考慮して決める。
大体1～2週間がオススメ。

イテレーションの計画を作成

P288：第1イテレーションの計画づくり

この段階までで、ユーザーストーリーはあくまで「プレイヤーとして新しいゲームを開始したい」の単位から変更していない。
ユーザーストーリーの優先順位が付けられ、優先度の上位から改めてユーザーストーリーをタスクに分割する。

第14章：イテレーション計画づくり

ユーザーストーリーをタスク（＋作業時間）に昇華する。
この時点では担当者は決めない。

ストーリー割当の基準

ベロシティ駆動

1イテレーションごとの目標ベロシティを決定し、それに収まる量のユーザーストーリーをそのイテレーションの目標に定める。
定めた分のユーザーストーリーをタスクに見積もる。

コミットメント駆動

ユーザーストーリーを一つ選びタスクを見積もる。
それのコミットがイテレーション内で確約できるなら対応し、次のユーザーストーリーを見積もる。
確約できないなら、それまでの確約分がそのイテレーションの目標になる。

タスク分割の補足

大きくても1営業日＝1タスク程度の粒度で有るべき。

タスクが見積もれないとき

P170：調査をする・修正するの2タスクに分ける。

第16章：ベロシティの見積もり

下手に予想するよりは実際にやってみるほうが良し。
個人レベルの作業可能時間も見積もり、1イテレーションあたりの作業可能時間も見積もることで、進捗の把握がしやすくなる（バーンダウンチャート）。

第17章：不確実性に備えるバッファの計画

1タスクごとにバッファをつけるとパーキンソンの法則により、いっぱいまで時間を使ってしまいがちになる。
プロジェクトバッファを別枠で確保する。

プロジェクトバッファの計算例

・平均対応時間+√((最悪対応時間)-（平均対応時間）)^2
・すべてのタスクを平均対応時間で見積もった上で、平均対応時間*1.5

第18章：複数チーム編成プロジェクトの計画づくり

・早い段階でユーザーストーリーの詳細化
・先を見越した計画づくり
チームAのデータがなければチームBの作業が進まないケースなど。
その場合、チームAの作業がイテレーション0.5分だったとしても、チームBは次イテレーションからの作業開始とする。
（チームAの作業が完全完了できなかったとき、イテレーション中での待ち時間を避ける、合流バッファの考え方

リリースプランニング

P296:プロダクトリサーチの結果などを用いて、リリース時点での製品状態を確定する。

タスクボード

P239：タスクボードを用意し、ストーリーごとにタスク・作業中・確認待ち（＋その他）を貼り出すことで、視覚的にわかりやすくなる。

イテレーション終了時点で行うこと

P251の報告書の内容を確認していく。

バーンダウンチャート

リリースまでの残り作業の理想グラフに対して、実際の残り作業量グラフを書き込む。
理想に対する作業の進み具合・停滞具合が視覚化されるので、大きく問題が起きていたときに気づきやすい。

棒グラフ版

作業進捗＋作業が溢れてることを確認できる。
でも見慣れない。

メモ

バグの扱い

P168
そのイテレーションで発生したバグであれば、そのイテレーション内で直すべきである。
前イテレーションのバグ・着手できなかったバグは次以降のイテレーションのバグタスクとして積まれる。
バグの修正≒新規タスク