More Agile Testing 第一章の非公式翻訳

実践アジャイルテストの続編である、More Agile Testing の第一章が、アジャイルテストの歴史を端的に書いてていいな、と思ったのでその部分だけ訳してみました。

More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley Signature Series (Cohn)) (English Edition)

第一章 アジャイルテスティングはどのように進化してきたのか

私たちは、それぞれ、エクストリームプログラミング（XP）チームの中のソロのテスターとして「アジャイル」なキャリアをスタートしました。 当時、XPに関する出版物のどれも、チームにテスターがいることについて言及していませんでした。 プログラマーと顧客の2つの役割がありました。 顧客がすべての受入テストを指定し、プログラマーがそれらを自動化することで、これで完了です。 XPカンファレンスに行くときはいつも、自分たちをテスターと認識しているだけの、ソロの参加者でした。でも、テスターには多くの付加価値があることがわかっていました。 私たちは実験し、XPのパイオニアたちとテストについて話し合い、お互いにアイデアを交換しました。それぞれのチームの他のメンバーとも話し合いました。

アジャイル開発は進化し、それに伴って、アジャイルテストも進化しました。 チームは、単体レベル以上のテスト自動化のためのテストライブラリとフレームワークの開発を開始しました。 アジャイルテストの本を書く頃には、多くのアジャイル実践者が、エリザベス・ヘンドリクソンやマイケル・ボルトンなどの経験豊富なテスターの貢献を認めていました。 ブライアン・マリックやジョシュア・ケリエフスキーなどの実務家は、開発を導くために具体例とストーリーテストを使用するというアイデアを開拓してきました。

ウォード・カニンガムは、具体例を定義することを手助けするFit（結合テストのフレームワーク）を作成し、ダン・ノースはビヘイビア駆動開発（BDD）を導入し（North, 2006）その後の人気ツールへの道を開きました。アジャイルチームは、探索的テストの価値を理解しはじめていました。 アジャイルチームでのテストは、ブライアン・マリックのアジャイルテストの四象限（Marick, 2003）で示されているように、機能だけでなく多くの種類のテストを採用しました。

もちろん、アジャイルテストの成功を妨げる課題がまだありました。 私たちテスターは、プログラマーが使う統合開発環境（IDE）に単体テストが組み込まれているように、あらゆる支援を熱望していたのです。同じような手軽さを、テスターがテストを定義するときにも欲しかった。ジョージ・ディンウィディーがいう「Power of Three」または「Three Amigos」を適用することには大きな利点があります（Dinwiddie, 2010）。顧客・プログラマー・テスターは、機能がどのように振る舞うべきかについての質問があればいつでも協力します。 しかし、設計・ユーザビリティ・データ・その他の品質属性など、顧客の要件には多くの側面があり、それらを把握することは依然として困難であることがわかりました。 本書では、それらの課題の一部を扱います。

いくつかの手法の実践者たちはこれまで、アジャイルテストの実践における溝を埋めてきました。 私たちは幸運なことに、さまざまな異なるコンテキストでのアジャイルテストで成功した、他の実務家たちのストーリーを共有することができます。

重要なアイデアの1つは、すでに私たちの日常的な思考の一部になっています。アジャイルチームでのテストとは、フェーズではなく、活動です。 この概念をエリザベス・ヘンドリクソン（Hendrickson, 2006）から学び、本の全体を通して、テストとはソフトウェア開発中にすべての分野で考慮する必要があるものだということを強調しています。

アジャイルでテストするためのより優れたテクニックを継続的に学び、スキルセットの深さと幅の両方を備えたゼネラリスト・スペシャリスト(訳注: 幅広い複数の領域に専門性をもつ人)がいると、チームがテストにまつわる困難に取り組むのに役立つことを発見しました。 実践者たちは、さまざまな分野のチームメンバーが協力して、お互いの専門分野を「ちょうど十分に」学ぶのに役立つプラクティスとパターンを作成しました。

アジャイルアライアンス機能テストツール（AA-FTT）グループのメンバーなどの実務家は、テストのためのより優れたツールへの道を主導してきました。今日では、テストコードの作成は本番コードの作成と同等のものです。どういったフレームワーク、テストライブラリ、ドライバーがチームのニーズに適しているかを特定するためのより優れた方法を学びました。

ビジネスアナリストは、顧客の要件を発見するための専門スキルをアジャイル開発に取り入れます。テストとビジネス分析は、チームが適切なビジネス価値を提供するのに役立つ補完的なスキルをもたらします。同様に、ユーザーエクスペリエンス（UX）の専門家は、新しい機能が設計されたときに顧客の意見を得る、シンプルで優れた方法を示します。DevOpsの実践者は、開発・運用・テストのスキルを組み合わせて、デリバリーやデプロイなど、新しい次元で品質を向上させ、リリースサイクルを短縮してリスクと顧客への影響を軽減します。

数年前に比べ、探索的テストの価値を理解しているアジャイルチームにたくさん出会うようになりました。私たちの一冊目の本では探索的テストを扱っていますが、そうしたチームがもっと様々なやり方で探索的テストのパワーを活用できるであろうことは明らかです。 幸運なことに本書では、アジャイルな文脈で探索的テストを実践している人々が専門知識を共有してくれています。

私たちは、テスト計画とコラボレーションに関する新しく、創造的なアプローチにも出会ってきました。今日のチームは、品質を可視化する、より多くの方法を見つけています。アジャイルテストの四象限やテスト自動化ピラミッドは、より多くの次元を表すように適応・拡張されています。

今日、より多くのチームが、ますます拡大するデバイスとプラットフォームで、モバイルアプリと組み込みソフトウェアのテストに直面しています。 データを保存・管理・分析・検索・可視化する、新しいテクノロジーを備えた大規模で複雑なデータセットは、新しいカテゴリであるビッグデータとなりました。テストも引き続き進化しなければなりません。

アジャイル開発は、同じ場所にいる小さなチームのために生まれました。 現在、一部の小規模なアジャイル企業だけでなく、大企業の分散チームでも利用が始まっています。大企業の組織全体でソフトウェアソリューションを使用している場合、テストは重厚な組織の制約など、さまざまな障害に直面します。 同時に、組織は、高速フィードバックループと検証による学習を備えた反復的なリリースを使用して、最小実行可能製品（MVP）を開発する新しい方法を見つけています。

一冊目の本を書いた2008年に、本番環境でテストを行っていた企業はほんの一部だったため、その技術を知ることができたのは後になってからでした。今日、ログファイルのエラーを監視しながら、少ない割合の本番ユーザーに更新プログラムをリリースすることや、本番ユーザーから迅速なフィードバックを得る手法は、適切なコンテキストで行う限り、有効かつ必要な戦略です。

これらの変化とイノベーションによって、私たちや他の実践者たちが学んだことを共有するようになりました。 アジャイルは絶えず改善されています。みなさんの多くはアジャイルの採用に数年かかるかもしれません。学習するにつれてプロセスを変えるかもしれません。現在直面しているテスト関連の問題は、以前のアジャイル移行の際とは大きく異なる可能性があります。この本で共有された経験が、プロダクトの品質を可視化し、プロセスを検査・適応する際に、試すべき実験のアイデアを提供してくれることを願っています。

まとめ

アジャイルソフトウェア開発の進化に伴い、ペースを維持するためにアジャイルテストを継続的に検査・適応しています。この章では、アジャイルテストの変遷を概観しました。

• テストは、プロダクトの成功に不可欠な活動であり、ステークホルダーから運用やサポートに至るまでプロダクトチームのすべてのメンバーが関心を持つ活動であることを認識しています。

• アジャイルチームは、ビジネス分析・ユーザーエクスペリエンスデザイン・DevOpsなど他の分野の実践者たちの手法が、チームが顧客の望む品質を構築する能力を伸ばしてくれることを、ますます認識するようになっています。

• アジャイルテスト用のツールは大きな前進を続けており、アジャイルチームは学習と迅速なフィードバックをサポートするために必要なインフラストラクチャを実装できます。
• アジャイルチームは、顧客や開発チームに不可欠な情報を提供するのに役立つ探索的テストやその他のプラクティスの価値を学んでいます。

• アジャイルテストは、急速に変化するテクノロジーとアジャイル開発の新しいコンテキストに対応する必要があります。この本を通してこれらのアイデアを探求します。

追記

• 2019/11/21 Kyon_mm さんのレビューコメントをいただき修正しました。ありがとうございました。

『一兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え』を読みました

プロダクトマネージャーカンファレンスでキーノートを話してたMarty Caganさんがおすすめしていた本。Amazonのリンクが上手く貼れないのでKobo貼っときます。

1兆ドルコーチシリコンバレーのレジェンド　ビル・キャンベルの成功の教え【電子書籍】[ エリック・シュミット ]

シリコンバレーの伝説のコーチ、故ビル・キャンベル氏について、Googleの元会長兼CEOのエリック・シュミットらが書いた本です。あとがきにこの本が書かれた経緯が書かれています。これを見るだけで、読むべきだと思う人も多いかもしれないですね。

エリック・シュミット、セルゲイ・ブリン、ラリー・ペイジ、スンダー・ピチャイ、ティム・クック、ビル・ゲイツ、ジェフ・ベゾス、マーク・ザッカーバーグ、シェリル・サンドバーグ、ジョン・ドーア、マーク・アンドリーセン....。

これらの人々を育て、そして何より彼らに愛された人物がビル・キャンベルなのだ。

本書はその追悼式の席で、「コーチの教えをシェアしなければすべてが失われてしまう」という危機感を持った人々によって執筆された。スティーブ・ジョブズと並び、コーチと最も親しく仕事をしてきたエリック・シュミットらグーグルの三人である。

彼らは『How Google Works 私たちの働き方とマネジメント』(日経ビジネス人文庫)を書いたチームでもあり、その意味で本書はその続編として読むこともできる。

以下一部、抜書きします。参考になれば幸いです。まあ、どこもやばいんですけど。

チームのマネジメントについて。

チームがやっていることを君たちは理解しているのか？メンバーになにかうまくいっていないことがある場合は、どうやって方向転換して起動に戻れるかを示すべきだ。「すべての部下をわが子と思え」とビルは言った。「軌道修正して向上できるように、手を貸してやるんだ」

イノベーションについても話した。チームにはイノベーションに取り組む余地があるのか？イノベーションと業務遂行の本質的な対立関係にどう折り合いをつけているのか？どちらか一方ではだめだ。バランスを取ることがカギだ。

目標について。

重要なのは短期目標の達成ではない。オペレーショナル・エクセレンスが少しでも欠けた状態を許さない文化を醸成することだ。株主のためだけでなく、チームや顧客のためにも、結果を出すのが経営陣の仕事だ。

インテュイットのCEOとして有名だった人みたいですね。コーチでは一切お金を取らなかったということです。 

ビルはインテュイットのCEO時代、エンジニアリング部門の幹部と毎週金曜にランチミーティングを行い、彼らが何に取り組んでいるか、何が彼らを阻んでいるかについて、ピザを食べながら２時間ほど話し合った。

ビルはテック系ではなかったが、技術オタクたちから話を聞き出すのがうまかった。経営幹部は、たとえエンジニアリング担当でなくとも、エンジニアと話ができなくてはならない。オタクたちはCEOが毎週関心を払ってくれていることを知っていた。ビルはそうやって、彼らに本領を発揮させたのだ。

会議の話も面白いです。

彼は民主主義を好まなかった。(ビルが来る前のインテュイットではミーティングで採決していたが、ビルはそれをやめさせた。)

代わりに好んだのが、「即興コメディ」で使われるような手法だ。即興コメディでは芝居が終わってしまわないように、キャスト全員が入れ代わり立ち代わり舞台に立ち、力を合わせてできるだけ長く芝居を続けなくてはならない。

ビルはそうした「アンサンブル」の状態を好み、駆け引きのない環境が保たれるよう、つねに気を配っていた。経営トップがすべての決定を下すようでは、その正反対の環境になってしまう。なぜなら部下は自分のアイデアをマネジャーに認めさせることに終止する体。そうした環境では、最適解ではなく、最高権力者へのロビイングに長けた者、言い換えれば政治が勝利を収める。

具体的にはそんなに把握できてないのですが、会議には秘密がありそうです。

Twitterのボードメンバーの話も。

ディック・コストロがツイッターのCEOに就任したとき、取締役会のメンバーは彼のほか数人のベンチャーキャピタリストと創業メンバーだけだった。ディックはビルの助けを借りてそれを変え、事業運営の実務に精通した人たちを取締役会に迎え入れた。ビルは、頼りにできる実務家がいたほうがいいと勧めたのだ。

ビルは悪い取締役についても具体的なイメージを持っていた。

「それは、ただふらっと来て、自分が一番賢いと見せようとして喋りすぎるやつだ。」

 解雇を伝えるときにも、素晴らしいアドバイスをベン・ホロウィッツ(!!)にしているようです。

ビルはある時、会社をやめていく幹部のことでベン・ホロウィッツに言った。
「ベン、君は彼に仕事を続けさせることはできないが、自尊心を保たせることは間違いなくできる」 

 以上、なんというか、今年は岩田さんもすごかったけどこれもすごいなぁ。と思いました。

岩田さん 岩田聡はこんなことを話していた。

あ、pmconfでの私の発表資料はこちらです。

Agile Testing Days に行ってきた

ドイツのベルリン近郊のポツダム(ポツダム宣言のポツダム)で毎年行われている Agile Testing Days に来てます。

一昨年まで Rakuten Technology Conference をやってた都合上スケジュールが毎年あわなくて、遂に来ました6年越し。

実践アジャイルテストのジャネットグレゴリー夫妻に再会。

ワークショップ楽しいしためになる。

DevOpsな人もQAな人もTDD/ATDDな人も共通の話題があるし、英語ネイティブじゃない人も多いので話やすいと思います。

800人くらいで、昔のAgile20xxみたいな雰囲気があるなと思いました。人懐っこくて、歌う。これくらいのカンファレンスを作りたいなと改めて思いました。

さてサンスーシー宮殿行ってこよう。

Target Dojo に行ってきた - 受入型研修施設のエッセンス

Agile 2019 に行ったついでに、ミネアポリスに寄りまして、Target さんの Dojo という研修施設にお邪魔しました。

kawaguti.hateblo.jp

今年のDevOpsDays Tokyo でも来日してプレゼンしてくれています。

confengine.com

昨年のAgile2018で知り合いまして、Dojo遊びにきなよー、って言っていただいたんですけど、機会が作れず、今回は予めワシントンDCからの帰りをミネアポリス(デルタ航空のハブ空港で羽田に直行便があります)経由にして寄ってきました。つまり羽田から直行でいつでも行けるわけですね。空港からもライトレールで市内アクセスできるので、とても便利でした。

Target DOJO について

エンジニアの Mig さんが Dojo の仕組みについて、プレゼンしてくれました。(DevOpsDays のあとに日本企業さんの来訪があったそうで、スライドも日本語！）

　

dojo.target.com

Target 社は全世界に200ほどの店舗があって、38000人の従業員がいるそうなのですが、その全体へのデジタル教育を担っているのが、Target DOJO なんだそうです。エンジニアだけでなく、店舗で働く人や配送系の人も全部含めて対象、と言ってました。

 

Target Dojo Introduction (Japanese)

きっかけは、DevOpsで小さな問題解決をしたことで、サーバーの調達を早くしたり、開発からデプロイまでを超絶短くしてみたりという実績があって、そういう取り組みを常に行える施設として Dojo が生まれたようです。今は30人ちょっとのコーチがいて、技術だったりアジャイルだったり (ペアを組むそうです) のコーチや、受入型のトレーニングをしているそうです。

2日間、5日間、6週間までのコースが

 ２日コースが「フラッシュビルド」で、プロジェクトチームや、同じ場所で働いている人たちが研修施設に二日間籠もって、何らかの改善をするそうです。コーチがついて、問題の出し方や、コミュニケーション、進め方、モブプログラミング、実装技術そのものに至るまで手助けするそうです。施設も集中できるように工夫しているとのこと。

期間も5日間のものや、最大で６週間までの枠組みがあるそうです。

通常型のスペースはこれで、中心にモブや会議用の机、左右に個人作業用のブースがあります。ホワイトボードは潤沢。付箋やペンも無限に出てくるそうです。

最近は複数チームでの利用も増えたということで、２チーム連結型のブースを作ってみたとのこと。合宿のような会議にも使われている感じですね。ちなみに場所はミネアポリス中心部の「ミネアポリスセンタービル」がここで、それ以外にもDojoがあるようです。

壁にはさまざまなアジャイル関係のモットーなどが貼ってあって、Fearless Change の場所重要のパターンのようでした。

　

プロジェクトを始めるときのチャーターが整理されてていい図だなと思ったやつ。

Target DOJO が重視するアジャイルの価値、原則。

手書きのスキル表。

プロダクト開発のプレイブック。

個人の集中デスクは昇降可能なやつです。

以上、想像以上にちゃんと投資して、工夫を凝らして運用されていることが感じられました。すごい。

小売業もデジタルトランスフォーメーションが必要な時代

量販店のデジタルトランスフォーメーションなんて、どうせ大したお金使ってないんでしょ？と思った方もいると思いますが、これだけの設備を常設・内製で作っていることが伝われば幸いです。

Target社は業績すこぶる順調なようで、ディズニーのショップを展開するというニュースが流れてました。

www.inc.com

案内してくれたミケルさんとミグさん

今回案内してくれたミケルさんとミグさん。ありがとうございました！

Regional Scrum Gathering 2020 にも早速プロポーザルを出してくれまして、このお話を聞くことができます。９月までにVotingしてますので、ぜひ見てみてください。

confengine.com

「井の中の蛙大海を知らず」から始まるスライドが素敵です。

ライブラリのバージョンが古くなっていたのでアップデート

週末の作業記録です。

タイマーアプリのライブラリのバージョンが古くなっていたのでアップデートしました

http://tiimer.net

npm outedated でライブラリのバージョンをチェックします。あらあら真っ赤。

そもそもAngularの推奨バージョンが上がってしまったっぽいですね。

深く考えず npm update コマンドでアップデートします。

どががが、っとインストールされ、267個もの脆弱性が発見されます。脆弱すぎます。

npm audit fix を叩いてfixします。

ngx-multi-window の警告は、angularがより新しいバージョンなので一旦無視しておきます。本家が上がってくれると嬉しいです。

electron もコンパイルして、動作確認の上、コミットしました。

github.com

Angularを8.2にする

ついでに、Angularのメインバージョンが8.0から8.2に上がっているようなので、あげてしまいます。

ng update @angular/cli @angular/core

動作確認してコミット。

github.com

残った古いライブラリに対応する

この時点で npm outdated をすると、２つほどアップデートが必要とでました。

npm update @types/jasmine

npm update karma-coverage-istanbul-reporter

 順に叩いてアップデートしました。

もう一度 npm outdated を叩くと、赤い文字はなくなりました。

更に最新版があるようですが、一旦このままにしておきます。

github.com

Azure DevOpsで本番サイトに反映

pushするごとに Azure DevOps が動いて本番サイトにも反映してます。

Electronのバイナリは反映してないので面倒です。そのうち解消したい。

Agile 2019 に行ってきた

ワシントンDC近郊のNational Harborで行われている Agile 2019 に参加しています。今日は4日目の夕方で、今夜のパーティと明日午前のキーノートを残して90%くらいの日程を終了しました。

www.agilealliance.org

Lightning Talks で話してきた。

今回は5分のライトニングトークに応募したら、なんと通過しまして(多くのLikeありがとうございました)、比較的小さな部屋でしたが満員の中でトークするという機会がありました。全然受けなかったらどうしようと思っていたんですけど、結構笑いが取れました。すれ違いざまに「LTよかったよ」と何人かに言っていただいて、褒め合う文化大事！と思いました。陶山さんも見事笑いをとってました。

ちなみに、日本と違ってLT独特の文化はないので、ただ5分のトークをする人が多く、笑いを取ることが正解だったかどうかは今もって謎です。でも聞いてもらえたということだから、少なくとも爆死ではないと思いますし、よしでしょう。

まじ英語練習しないとだめだなーというモチベーションは高まりました。3-5分くらいの英語発表は楽天時代にちょくちょくあったのですが、とりあえず笑いをとって逃げるパターンで、それも今回は変わってません。なんとかしないとなーと思いました。

　

　

　

　

資料はこちらです。 

いろんな人に会いました

人に会いに行くのがカンファレンス、ということで、今回もいろんな人に会えました。同料金なのですが、広い部屋にあたったので、よなよな部屋飲みできたのも楽しかったです。ありがとうございました。

　

　

　

　

　　

　

ではまた！

スクラム現場ガイドの Mitch Lacey来日！認定スクラムマスター研修、認定スクラムプロダクトオーナー研修があります。

以前、教育心理学概論で得たジグソー法を使ってスクラム現場ガイドを読みました。

scrumfieldguide.doorkeeper.jp

本書は、1年目にスクラムとアジャイルで『どんなことが起きるか』についての本です。筆者が、1年目のアジャイルにまつわる物語を集め、難しいポイントと、それに対するソリューションをまとめています。

 

 

 

この本の著者の Mitch Lacey が日本で認定スクラムマスター研修をやってくれるということで、大変期待しております。

 

現場ガイドの元の単語、フィールドガイドというのはいわゆる木や虫などの図鑑のことで、自然豊かな国立公園みたいなところに行って見つけた草花を見分けたり、するためのものです。たとえばこんな。

www.shogakukan.co.jp

表紙がまさにそんな感じですね。スクラムの山の中に入って、そこで起こっている様々な事象について、この本と照合し、ふむふむなるほどと、現状を把握したり、次の手を探したりするための本になっています。 

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

（以下、著者による「まえがき」より抜粋）

スクラムやアジャイルを始めようと思っていたり、まさに始めたところだったり、1年くらいやってきて道に迷ったように感じているなら、本書はあなたのためにある。僕は公式には、新たにプロジェクトを始めて6ヶ月から18ヶ月の12ヶ月の間にいる企業が対象だとしている。

本書は実践主義者のためにある。あなたが理論や難解な議論に興味があるなら、他の本を選んだほうがいい―そうしたスクラムやアジャイルの素晴らしい本はたくさんある。そうでなく、実践的なアドバイスや現実のデータ、僕が実際にマイクロソフトのプロジェクトに参加したり、他の会社でチームをコーチしたり、フォーチュン100企業でコンサルティングしたりしてきた経験に興味があるなら、本書をおすすめする。

アジャイルに向けた旅をする中で、旅程のどのあたりであろうと、いま経験しているのは普通のことだと優しく教えてもらえれば有り難いものだ。いまの状況に対処するためのアイデアや、成功の鍵まで聞ければ、さらに助かる。本書はそうしたすべてを提供しており、必要な章だけ読めばいいように構成している。もちろん、パートを通して読んでも、全体を読んでもいい。現実的な状況なのであなたにとっても理解しやすく、紹介しているソリューションはどんなチームでも使える。

ページをめくって物語を読んでほしい。本書を頼れる仲間として、あなたはスクラムやエクストリームプログラミングのいいところも悪いところも一緒に経験することになるだろう。

本書はどの章からでも、どんな順番でも、いつでも読めるようになっている。それぞれの章は物語か始まる。物語はすべて僕が参加したりコーチしたチーム、企業、プロジェクトからとったものだ。ご想像の通り、何の罪もない人びとのため、名前は変えている（罪がないとは言い切れない連中もいるけれど）。

物語を読んだら、次はモデルを紹介するが、こちらも同じくらい聞き覚えがあると思う。紹介するモデルは僕が現場で、物語で現れたような問題を解決するのに使うものだ。中には不快に感じたり、あなたの会社ではうまくいくと思えないものもあるだろう。

僕としては、アドバイスを無視したいという感情や、モデルを変えてしまう衝動とは何としても戦ってほしい。少なくとも3回はそのままで試してみて、結果を見てほしい。驚くような結果になるかもしれない。各章の終わりには成功の鍵をまとめており、あなたが実現に成功するか失敗するか、その鍵となる要因を説明している。

本書は4つのパートに分かれている。

第1部「準備」ではスクラムを始めるに当たってのアドバイスと、成功に向けた準備について書いている。スクラムの導入を検討しているか、始めたばかりならばここから読むのがいい。

第2部「現場の基本」では、アジャイルのやり方を始めるとチームや組織が出会うことになる初期の障害物を、乗り越える助けとなるいくつかの項目について議論している。スクラムを実践していて、問題を抱えているなら、ここから始めるといい。

第3部「救急処置」は会社が抱える、より大きく深い問題に対応する方法をまとめている。プロジェクトへ要員追加するやり方や、機能不全になったデイリースタンドアップの直し方などだ。ここで紹介する状況は、あなたが最初の1年間のどこかのタイミングで遭遇するものになる。このパートではトリアージと治療によって、あなたのチームを健康に戻す方法を紹介している。

最後のパート「上級サバイバルテクニック」で取り上げる事項は、人びとがタイミングに関係なくよく悩まされているものだ。アジャイルやスクラムでのプロジェクトのコスト算出、契約の作り方、ドキュメントの書き方などだ。

あなたがまったく新たにスクラムを始めるところならば、末尾の付録で簡単に説明してる。基礎知識がないのであれば、ここで用語を学ぶといい。本書の前に、他の本でスクラムを勉強するのもいいだろう。