【感想】いちばんやさしいアジャイル開発の教本　人気講師が教えるDXを支える開発手法

# 「アジャイル開発」という言葉の説明

## 面白かったところ

* 開発者を含めたプロダクト開発に関わる人向けに書かれているため、IT業界を取り巻く状況などの背景知識もざっくり知れるとこ
* アジ…ャイル開発のはじめ方にも種類があり、導入や初歩でつまづきそうなQ＆Aも揃っていて安心感があ

## 微妙だったところ

* 本に書かれていることは、おそらく「スクラム」というフレームワークに沿って進めていること前提に書かれている印象だが、スクラムとアジャイルは似て非なるものなのでごっちゃになりやす

## 感

仕事をすればするほど、本を読めば読むほど、ソフトウェア開発は難しいと思う

現場で開発者として働いていて思うのだから他の方々はもっと理解が困難なのだろうと思う

だからこそこの本を読んで、「アジャイル開発」という魔法のような言葉に親を殺される前に正しい知識をつけていただきたいと思った

もちろん、チームメンバーには推薦図書として紹介する続きを読む

アジャイルの案件に入ることになったので。 SCRUM BOOT CAMP THE BOOKと比べると一歩引いた視点から俯瞰してる感じ。 アジャイルとはなにか、なぜアジャイル7日、何が実現できるのかなど…を、ウォーターフォールと比較しながら説明されている。 ウォーターフォール経験者なら「わかるぅ?」となること請け合い。続きを読む

◆上手く乗りこなすには？
仕様変更に対応するには、①余白の戦略、②スプリント強度を高める戦術の2つがある。

①プロジェクト全体に関わることは、余白の戦略をもってプロジェクトの初期に実施。
②各スプリ…ントに関わることは、スプリント強度を高める戦術を各スプリントが始まる前に実施。

①期間、工数ともに余白を作っておく。また、号口前に受入期間の余白もつくる。

②作るもののイメージを認識合わせして、ベロシティを計測し、安定させる。ベロシティが不安定になるのは、バックログの見積の正確度が要因。バックログの規模感で相対的に見積する必要があるため、小さく分割させて正確度を高める。また、振り返りは必須。

※ベロシティとは？
ベロシティとはアジャイル・スクラムのチームが１スプリント内で作業できる平均的な作業量を表す指標です。 ベロシティは、開発完了見込みの時期予測や、次のスプリントでどれくらいの作業に対応できそうか検討する際の参考値として利用することができます

◆アジャイル開発の理解を深める
・アジャイル開発は早さ、安さを約束するものではない。試行錯誤を前提に置く進め方。余白がないと試すことも方向性を変えることもできない。★

・アジャイル開発は、価値を探索するプロセスが必要なときに採用する。一直線にたどり着いたほうが早いが、初期に完成イメージが定義されることは少ない。なので探索を織り込んだアジャイル開発を含める。★

・探索は、計画検証(こういう課題があり、こう解決できるはず)→仮説立案→検証→評価の繰り返しで実施。

・・・・・


続きを読む

アジャイルについて、わかりやすく書かれていて、なんとなく把握するにはいい感じの本だった。
実際にやってみないとわからないけどもね。。

コンパクトに要点が纏まっていて何回でも読み返し出来そうな内容でした。実際に体感して読み返すとより理解が深まりそうです。まだやってみてないのでサーっと読んでしまいました。

伸びしろの若手エンジニアをアジャイル開発に参画させると、旧来のウォータフォール開発に比較して、何倍も大きく成長するように思えます。
「巨人の肩に乗る」とは、若手の方が、プロジェクトのエキスパートにささ…えられながら、全体を見渡して成長していくという意味なのでしょうか。

大規模な基幹システムの更改については、アジャイル開発はどうも向いていないように思えますが、スクラムマスターが何人もいるような、しかも請負で開発しているプロジェクトが出現し
急速に成長している分野と認識しています。本書は、アジャイル開発の基礎を解説したものですが、用語を含めてとっつきにくい内容だと思います。ブレークダウンをして具体的な作業や、ツールなどを解説していただいたら、もっと充実した内容になるとおもいました。

気になった点は以下の通りです。

・リリース時点で開発から手離れすることはまれになりました。ユーザーの反応をプロダクトに反映しながら改善し、ビジネス価値を向上させ続ける必要がでてきたのです。
・ソフトウエアの利用を通じて達成したいことを「要求」といいます。この「要求」を実現するために必要な機能や性能が定義されたものが「要件」です。
・ソフトウエアの３分の２の機能はつかわれていません。
・ウォーターフォールは、よくも悪くも、不確実性を減らすモデルです。
・想定だけで一度に多くのことを実現しようとしても、的を得たものにならない。だから、少しづつ繰り返し的に作り進めていく。
・統合：インテグレーションとは、ソフトウエアを動作させるために必要なプログラムや、設定ファイル、データ、ライブラリを全て集めて、まとめる作業のことをいいます
・常にリリース可能な状態に整備シテオクプラクティスがあります。それが「継続的インテグレーション」です。テストやビルド、配置のタスクを流れるように自動化しておく仕組みです。
・ソフトウエア開発に価値探求のためのタスク「仮説検証」を織り込む考えがあります。
・アジャイル開発は２つの見積で構成されます。１つは、全体感の見積、もう１つは、実際に開発するにあたってたいむボックスごとに行う見積もりです。
・アジャイル開発における計画づくりとは、大きな計画づくり、小さな計画づくり、その日に計画づくりの３種をさします。それぞれ、リリースプラニング、スプリントプラニング、デイリースクラムといいます。
・アジャイル開発では一度に広範の要件定義ではなく、その時点で必要な範囲と深さでの「作るべきものはなにか」を定義します。その時点は２種類あります。リリースプラニングの段階で全体を知るための整理。スプリント段階で、スプリント分を知るための整理の２種類です。
・段階ごとの青写真を描いて、見えるようにしておくことは思いのほか重要です。
・これまでアジャイル開発が失敗してきた理由は３つあります。①受託開発や、ＳＩでの同意形成が難しい　②他の現場プラクティスをそのまま適用してしまっている　③経験者不足、経験者の偏り。です。

結論は、「アジャイル開発」はいつだれが始めるのか。その答えはもう出ています。アジャイル開発の積み重ねに次の越境を重ねるのは、この本を閉じたときから、あなたが始めるのです。

目次は以下の通りです。

Chapter１　アジャイル開発の世界

　　０１　本書の読み方：アジャイル開発を始める
　　０２　ソフトウエアを取り巻く環境①：進化するＩＴ市場
　　０３　ソフトウエアを取り巻く環境②：ビジネスモデルの変化
　　０４　さまざまなソフトウエアの形：見えるソフトウエア、見えないソフトウエア
　　０５　ＳｏＲ，ＳｏＥ，ＳｏＩ：ユーザーとソフトウエアの関わり
　　０６　アジャイル開発の基本：アジャイル開発とは何か
　　０７　アジャイル開発の原点：アジャイル開発の源流「カイゼン」
　　０８　アジャイル開発の成功率：アジャイル開発の広がり

Chapter２　なぜアジャイル開発なのか

　　０９　ウォーターフォール開発：従来型の開発手法「ウォーターフォール」
　　１０　作ったけれど使われない：顧客が本当に欲しかったもの
　　１１　不確実性コーン：ソフトウエア開発は不確かなもの
　　１２　ムダ：ソフトウエア開発のぜい肉
　　１３　ウォーターフォールの課題：手戻りできないウォーターフォール
　　１４　アジャイル開発の原則：アジャイルは不確かさと踊る
　　１５　アジャイルソフトウエア開発宣言：なぜアジャイル開発なのかを考える

Chapter３　アジャイル開発がもたらす変化

　　１６　アジャイル開発がもたらす変化：チームの成長とプロセスの進化
　　１７　アジャイルソフトウエア開発宣言の実践①：個人と対話
　　１８　アジャイルソフトウエア開発宣言の実践②：動くソフトウエア
　　１９　アジャイルソフトウエア開発宣言の実践③：顧客との協調
　　２０　アジャイルソフトウエア開発宣言の実践④：変化への対応
　　２１　タックマンモデル：職能横断型モデル
　　２２　チームの機能期：自己組織化チームとリーダーシップ
　　２３　成長戦略：アジャイルチームの成長戦略
　　２４　ＹＡＧＮＩとＫＩＳＳ：筋肉質なソフトウエア
　　２５　トレードオフの神話：質とスピードは両立する

Chapter４　アジャイル開発の中核にあるコンセプト

　　２６　コアコンセプト：アジャイル開発の３つのコアコンセプト
　　２７　チーム①：チームのフォーメーションを定める
　　２８　チーム②：チームの共通理解を育む
　　２９　チーム③：チームの活動する場を用意する
　　３０　インクリメンタル①：少しづつ形づくる
　　３１　インクリメンタル②：構想とプロダクトを合わせる
　　３２　イテレーティヴ①：反復的に作る
　　３３　イテレーティヴ②：反復的な計画作り
　　３４　イテレーティヴ③：反復的な作成物レビュー

Chapter５　小さく始めるアジャイル開発

　　３５　方法論、プラクティス：アジャイルのはじめの一歩
　　３６　スプリントバックログ、プロダクトバックログ：タスクの見える化
　　３７　タスクボードの作り方：状況の見える化
　　３８　プラニングポーカー：タスクのサイズをチームで見積もる
　　３９　朝会：日常の見える化
　　４０　ペアプログラミング、ペアワーク：ペアで作る
　　４１　ふりかえり：やったことの見える化
　　４２　習慣化：プラクティスの習慣化

Chapter６　上手にのりこなすためのカイゼン手法

　　４３　方法論：より上手にレベルアップする
　　４４　継続的インテグレーション、バージョン管理：流れるように自動化するには
　　４５　テスト駆動開発：エンジニアリングでテストのムダを解消する
　　４６　チーム①朝会とふりかえりのステップアップ：チームの活動が形骸化し始めたら？
　　４７　チーム②見える化のステップアップ：散乱した見える化を棚卸しする
　　４８　チーム③カンバン、モブプログラミング：成果の停滞感に直面したら
　　４９　契約：契約ってどうするの？
　　５０　パターン：プラクティスを自ら実践し自ら作る
　　５１　組織にスケール：日本の既存の組織に合わせて拡大させる

Chapter７　アジャイル開発の理解を深める

　　５２　アジャイル開発の誤解：なぜ、アジャイル開発は誤解を生みやすいのか
　　５３　仮説検証：アジャイル開発は早く安くできる？
　　５４　見積もり：アジャイル開発は見積もりしない？
　　５５　リリースプライニング、スプリントプラニング、デイリースクラム：アジャイル開発は計画しない
　　５６　ドキュメント：アジャイル開発はドキュメントを書かない？
　　５７　要件定義：アジャイル開発は要件定義しないの？
　　５８　不確実性：アジャイル開発は設計しない？
　　５９　テスト戦略：アジャイル開発はテストしない？
　　６０　アジャイル開発の進め方：アジャイル開発は本当にできるのか？

Chapter８　アジャイル開発はあなたから始まる

　　６１　失敗の歴史：素直な声に耳を傾けよう
　　６２　ハンガーフライト：アジャイル開発の学びを深める、広げる
　　６３　越境：アジャイル開発を始めよう続きを読む