いきなりマスター・センセイってなんやねんって感じだけど、 文章も画像もいい塩梅のユーモアがあり、訳註も親切で非常に読みやすかった (荒ぶる四天王ってこれが元ネタだったのか......)

マインド、プロセスの基本を知れる。 ただし発注者のためのアジャイル目線が強い。 より良いものを作る事は大事だが、ベンダー視点では数あるプロジェクトの一つ。利益相反にもなり得る。リソース調整、契約交渉、利益確保といった泥臭い観点の記載はない。その点は別に学ぶ必要あり。

荒ぶる四天王の元ネタがついに！ 古典的と思い後回しにしていたけれど、アジャイル開発を理解するにあたり素晴らしい知見のかたまりでした。 軽快なトーク（のような語り）も味があります。 まさにアジャイルマニフェストの12の原則を体現していたと思いました。

アジャイル開発のテキストとしては有名な本だったので、読んでみました。 内容はアジャイル開発とは何ぞやから始まって、プロジェクト発足からリリースまでにどのようなことを行うのか、その際の注意点などがみっちりと書かれています。 ただ、海外の技術書によくある回りくどい表現がとても多く、内容を理解するにはそこから要点を見出して頭の中で情報を整理する必要があります。個人的にはこの作業にとても疲労感を覚えるため、本書を読解するのにとても苦労しました。 オライリー本を抵抗なく読める人であれば重宝すると思いますが、私みたいにちょっと苦手という方は誰かが要点をまとめたサマリーを探す方が良いかも、なんて思いました。

こんなに軽やかに読めるタッチの本が、バイブル的な立ち位置になってるのすごい。 当然、元々の内容が素晴らしいことはあるだろうが、訳者の些細な気遣い・心意気が、メチャメチャ効いてるんだろうなと思う(細部の挿絵の言葉選びとかライトなネットスラングとか) 最後の一節は、エモすぎて、全文メモ余裕でした。

『デイリースタンドアップでの報告の仕方をこう変えてみては？』の例示がユーモア溢れるな〜と感じるとともに、「顧客への価値を届ける上で、実際に何を成し遂げたか／今日は何を成し遂げるつもりか」という一つ視座を上げた考え方にも繋がりそうでアリだな〜と気付きを得られた。

Xでバズってたので再読。あのページ、著者は外国の方だからそこまで意識していないはずだけど、日本にソードマスターヤマトのミームがあるから素材として最高だなw

「アジャイルサムライ−達人開発者への道」は、アジャイル開発を学ぶのに最適な一冊です。この本では、マスター・センセイと弟子との会話を通じて、読者はアジャイル開発のエッセンスを楽しみながら理解することができます。特に、インセプションデッキやドラッカー風エクササイズのような、すぐに実践できるワークショップの記述が豊富で、内容が非常に充実しています。この本は、アジャイル開発に関する理解を深めたいすべての人にお勧めできる作品です。

一旦ななめよみ アジャイルのマインドと進め方がわかる センセイといい、アジャイルを説明する人は終始胡散臭く感じる

アジャイルの要点を理解し、それが自身の携わる業務に適しているかどうかを考えることができるようになる本。 ・相対サイズで見積もり、チームがどれくらいの速度で仕事を進められるかを計測する（ストーリーポイントとベロシティ）。 ・プロジェクトに先立つ概算見積もりは当てずっぽうである。これは不確実性コーンとして示されている。 ・プロジェクトの開始時点では、ベロシティは推測であり、実際にやってみないと分からない。 ・想定より進みが遅い場合、最初に立てた計画にはこだわらず、スコープを調整して対処する。※そのためには、取り繕わず、隠し立てせず、プロジェクトの計画や進捗を顧客と常に共有して、情報の非対称性を解消しておくことが必須だと感じた。

アジャイルを実践するのであれば、確実に読んでおきたい一冊 理論の紹介から実践方法、そのはてには、原則や価値観についても書かれている

所在: 展示架 請求番号: 007.61 || R17 資料ID: 12300407 アジャイル開発とは何かを学ぶことができる。 選書担当者 : S

アジャイルサムライ――達人開発者への道 Jonathan Rasmusson氏の著書です。 アジャイル開発の入門書になります。 アジャイル開発とは何かから、計画～実践までの全体的な流れが解説されています。 【本書で学べること・考えること】 - アジャイル開発とは - アジャイルなチーム - インセプションデッキ - ユーザーストーリー - 概算見積り - アジャイルな計画作り - イテレーション運営 - アジャイルなプログラミング 読んでみての感想です。 アジャイルの全体像を掴む入門書としては、とても平易な内容でわかりやすいです。 まず、これを入口にアジャイルの全体像を掴み、自分の役割に合わせた内容を深掘りするのが良いと思います。 特にプログラミングの手法については、それぞれの内容で一冊の本になっているくらいなので、是非、深掘りして欲しいです。

言葉として知っていた『アジャイル』の背景を知ることができた 大学や現場では、知識は教えてくれるがそれ以上は教えてくれない 開発者としての経験を何年か積んで得られる内容を、簡単に得ることが出来る良書だ 大学やプロジェクトを初めて任された人たちが絶対読むべきである 深掘りしたい箇所でも読むべき本が提示されているので、親切 あっという間に読み終えることができます！

アジャイル開発のメリットが痛いほど分かる本。 実際にアジャイル開発に携わるようになってから読み返せていないので、改めて読んでみようかな…と。

アジャイルとはあくまで概念の話なので、解釈の仕方を学んだ。インセプションデッキなどは実際にPJでも活用し、PJ推進に大きく役立った。

仕事でアジャイル開発に取り組むことになり、2周目を読み終えました。 圧倒的に2周目の方が噛みごたえがあり、サムライが登場したり、キャッチーな語り口といったいわゆるハードルを下げる工夫と骨太な本質が両立していて、内容も網羅的な名著。 「インセプションデッキ」「マスターストーリーリスト」「ユーザー計画ミーティング」などオリジナルの概念も紹介され、これは「どのように開発するかは自分次第だ」という著者の思想を体現しているように思える。 それにしても、後書きを読んで気づいたのだが、文章のところどころに挟まれたアジャイル開発の原則が、アジャイルソフトウェア開発の12の原則そのまんまだったなんて！素晴らしい。

2021/12/6 アプリケーション開発は難しい、検討能力もコミュニケーションも限界がある。だが、学習能力はある。だから小さいE2Eの成果をこまめに出しつつ、軌道修正をしていく エンジニアが効率的な開発を目指して、下記4点を宣言したのがアジャイル開発の始まり。 ・プロセス・ツールは重要だが、対話をより重視 ・包括的なドキュメントは重要だが、動くソフトウェアをより重視 ・契約交渉は重要だが、顧客との協調をより重視 ・計画の遵守は重要だが、変化への対応をより重視 アジャイル開発実践の要諦は下記2点。 ・価値ある成果を定期的にクイックに出し続ける。できれば毎週→フィードバックを早めに受けることができて、柔軟な変更が可能になる。本当の速度がリアルタイムでわかり、期待をマネジメントしやすくなる。成果責任を果たして信頼貯金をためていける ・ビズとテックはプロジェクトを通じて一緒に働く→対話を重視し、変化への対応力を上げる 実際の進め方は下記 ・インセプションデッキでプロジェクトの目的を明確にして、常に意識する 　-目的・背景、エレベーピッチ、パッケージデザイン、やらないことリスト、ステークホルダー、解決案を描く、リスク、期間、何を諦めるか、何がどれだけ必要か ・ユーザーストーリーを定義する。よいユーザーストーリーはINVESTの特徴を持つ、independent, negotiatable, valuable, estimatable, small, testable。機能要件だけでなく、非機能の成約も明らかにしてマスターストーリーリストを作る ・マスターストーリー(半年目安)から、市場で価値のある最小単位のリリース(1-3ヶ月目安)を計画し、そこからイテレーション(1-2週間目安)に細分化。 ・見積は相対単位で見積もる。見積はずれるので、実際のベロシティに合わせて迅速に修正可能なため リリースボードで、プロジェクト全体に対するストーリーの完了面積を明らかにして、次のイテレーションの決定の参考にする ・バーンダウンチャートでベロシティと完了目処を明らかにする。イテレーションが終わったら、ベロシティを計測して次のイテレーション計画の参考にする ストーリーボードで、今回のイテレーションのストーリーのステータスを可視化する ・テスト駆動開発でユニットテストを必ず行う習慣をつける。リファクタリング、継続的インテグレーションで、こまめにきれいにしてタスクを完了させる

これだけ読んどけば良いと言われたことがあるが、アジャイル、スクラムを始めてみて知りたいこと、疑問に思うことが一通り語られているのではなかろうか。後で必要に応じて本棚から手に取り参照することもしばしばあるので、物理本で買って良かったなと思った一冊。

「サムライ」というタイトルだが、訳書。 なので、洋書独特の言い回しや、アイスブレイクの仕方は好みが分かれるところ。 （マスターセンセイと弟子のくだりとか） 内容はアジャイル開発を始めるために必要な情報が網羅されていて、入門書としてオススメの一冊。

分量が多く斜め読みした。 アジャイル開発に携わっていた時に良んでおくべきだった。 アジャイル開発のフレームワークについてはこれを読んでおけばいいかなという印象。 やり方どうこう以前にもっと量書かないといけないなと自覚した。 アジャイルで躓いた時に再度読み直そうかな。 一冊家に置いておけばいい一冊

「毎週、価値ある成果を届けられているか？」何度も繰り返されているが、アジャイルかどうかはこれに尽きると思う。 インセプションデッキ、イテレーションが〜のような難しそうなワードを聞くたびにアジャイルから避けて来てたが、これらはあくまで手段。チームによって必要なものを取り入れていけばいい。 開発者であれば12章〜の内容は基本スキル。 以下は引用 P22 これから2週間で課題を解決すると宣言。 P25 お客さんを目の前にしてデモをする。 P64 今回は気にしない。→今回がプロジェクトを指してるのか、スプリントなのか不明。 P68 助けを求めたくなる前から知り合いになっておくんだ。 P106 しかる時が来たら詳細を検討するが、それは本当に必要だと確信をもてるようになってからの話だ。 P191 ペルソナがいるとシステムに人間味を持たせることができる。 P214 デイリースタンドアップでの報告の仕方をこんなふうにしてみたら〜。 P216 ストーリは完了したか、してないか。そのどちらかだ。 P226 チームの意思を明確にする

陽気な達人プログラマーに教えてもらった気分だった。 めっちゃいいです！ いきなりページを開くと(厳密には数ページだけど) 1. 君は学ぶことが心から好きだ。 2. 君はソフトウェアのことを大切に思っている めちゃくちゃ歓迎ムードである笑 いろいろ面白い内容が盛り沢山だったけど印象的なところだけ上げておく(なるべくソフトウェア開発以外にも通ずるような部分を、、、) 1. チームメンバーを探すコツ 　・ゼネラリスト 　　→なんでもそつなくこなせる人。器用貧乏⁈) ・曖昧な状況に抵抗がない人 　　→どっしりと構えてくれる、臨機応変 　・我をはらないチームプレイヤー 　　→ありのままの姿で、調和できるように 2. エレベーターピッチ 　　エレベーターで一緒に乗った友達に自分の仕事を30秒で説明してみよう 3. どのリスクには取り組む価値があって、そうじゃないのらどれなのかを決める 　→願わくばわたしに、変えることのできない物事を受け入れる落ち着きと、変えることのできる物事を変える勇気と、その違いを常に見分ける知恵とをさずけたまえ　-ニーバーの祈り- 4. 計画の立て方 　・顧客にとって価値ある成果を届けられる計画 　・わかりやすく、ありのままを伝える、誠実な計画 　・約束したことを守り続けられる計画 　・必要に応じて変更できる計画 5. 本当に重要なものだけをまずは実装 ここまで読んでいただきありがとうございます。 でもアジャイルって一体なんやねん！と思った方は是非読んでみてください。 読んだその日からあなたも私もアジャイルです。

アジャイル開発についての理念やら進め方について短くまとまっている。 手法そのものよりも「なぜ、何のためにやるのか」を説明しておりわかりやすい。

質の高いソフトウェアを高速に届け続けるための開発手法、アジャイル。 変化が多く、スピーディなアウトプットが求められる環境ではめちゃくちゃぴったりな手法だと思う。

アジャイル開発に興味があるなら一度読んでみると良いと思う。マネージャーや現役のエンジニアだけではなく、これから開発をやっていくような人にもオススメしたい。

# 読む前 ３年半前にアジャイル開発を始めることになった時にアジャイル入門書として読んだ本。自身の役割が初めてプロダクトオーナーになったので違う目線で改めて読んでみる。 # 内容 アジャイルな方向づけ アジャイルな開発プロセス（計画・運営） アジャイルにやるためのプラクティス アジャイルにやれてるかどうかを確認する問い ・継続的に価値ある成果をあげてるか？ ・カイゼンを続けているか？ # 所感 初めてこの本を手にした時、入門書と思って読んでいたけれど、改めて読み返してみると、具体的な手法が多く書かれているわけでもなく、アジャイル開発を経験していない人には少しとっつきにくいかもと思った。決まったルール、お作法があるわけではなく、原則（マインド？）に従いやり方はチームや環境に合わせていくというのがアジャイルの考え方だから仕方のないことなんだと思うけど。 アジャイル開発にしばらく慣れて、やり方、考え方が固定化してきちゃってるかなぁ、という時に立ち返るために読み返すのにも適していそうだと思った。 今回の改めての気づきというか意識しておきたいなと思ったのは「期間を見積もる」の章で触れられていた、プロジェクトそのものも長期になると不確実性やリスクが増すということ。（開発サイクル（イテレーション）としての「短く期間を区切る」という考え方だけでなくプロジェクトも短く。） もう１個の気づき（本書に対する気づき）、もともとPO側の視点で、が再読のきっかけだったけど、本書の中ではPOは「お客様」という表現でちょっと外の人の扱いだった。。。

顧客とプロジェクトの状況を正直に包み隠さずに共有出来ることが、ベースとしての大事な考えだと感じた。 ただ、上記はこれまで経験してきたプロジェクトや契約の習慣とは大きく異なっていて、それがアジャイルをイマイチ有効活用できてない原因なのかもと。 もう一度本書を元にチームで原点に立ち返ってみようかと思う。

2011年の出版。それでも色あせていない。インセプションデッキという考え方。相対サイズの見積、リファクタリング、テスト駆動開発、継続的インテグレーションといったアジャイルならではの手法。「イテレーション計画ミーティング」「ショーケース」「デイリースタンドアップ」「ミニふりかえり」というイテレーションの運営。アジャイルに必須の要素が詰まっている。お陰様でアジャイル検定レベル１に合格できた。実践に使えるかはこれから。

アジャイル開発の概要を理解したいときに読む本。 事例を踏まえて学びたいときは、次に「アジャイルな見積りと計画づくり」を読むとよい。 アジャイル開発は、実態を可視化しづらいウェブアプリを前提としており、実態やプロトタイプを作る組み込みの世界にそのまま適用できなさそう。 特に、エンドユーザが直接的に価値を感じ取れないデバイス系や、Tire2サプライヤの開発には適用が難しいと思った。 組み込みの世界に適用できないところ。 　１．部分発注 　２．途中からの機能ドロップ 　３．ストーリベースの開発 　　　　ハードウェア上でソフトウェアが動くので、 　　　　どうしてもソフトウェア階層の下位から上位へ開発が進むので、エンドユーザへリリースできない。 組み込みの世界に適用できるところ。 　１．インセプションデッキでプロジェクトの外観を知る 　２．TDD　検証基準で顧客と合意しておく。

【読書メモ】 ・アジャイル開発ではToDoリストのことをマスターストーリーリストとかユーザーストーリーと呼ぶ（スクラムで言うプロダクトバックログ） ・〃プロジェクトで具体的に成果を上げていくためのエンジンをイテレーション（1，2週間）と呼ぶ（スクラムで言うスプリント） ・〃一回のイテレーションで完了させられるストーリーの量をベロシティと呼ぶ「どれくらいの速さで進んでいけるか」 ・〃プロジェクトで行う作業の範囲と成果物に何を含めるかを定めたものをスコープと呼ぶ ・スコープは柔軟にしておく。やることを減らし、計画のバランスを保ってやると決めたことはやり遂げる ・顧客（スクラムでいうプロダクトオーナー） ・ソフトフェア開発の3つの真実は①プロジェクト開始時点ですべての要求を集めることはできない　②集めたところで要求は必ずといっていいほど変わる　③やるべきことはいつだって与えられた時間と資金よりも多い ・アジャイルなチームは役割分担がはっきりしていない。帽子をかぶり分ける ・アジャイルなプロジェクトは分析、設計、実装、テストといった開発工程が連続的に取り組まれている ・アジャイルなチームは、チームが一丸となって責任を果たす ・同じ仕事場で働くことがコツ。冗談を言い合ったり食事をとったり、旅行に行ったり。お互いをよく知ることがまとまった高いパフォーマンスを発揮できるチームになるコツ ・チームを自己組織化させるために、計画を自分たちで行う、肩書や役割を気にせず、テスト済みのちゃんと動くソフトウェアを提供し続けることに心を砕く、自ら動ける人を探す ■アジャイルな開発チームは職能横断的なメンバーで構成されている ★アジャイルなアナリスト：冷静な探偵「お客さまからの宿題は僕にお任せ！イテレーションごとにきっちり片づけていくよ！」 ・ストーリーを書くのを手伝う ・分析 ・プロトタイプ作成 ・顧客と意思疎通を図る ★アジャイルなプログラマ：質の高いプログラムを生み出すことに心血を注ぐプロフェッショナル「僕のことはキーボードをもった顧客と思いねえ！」 ・テストをたくさん書く ・プロジェクト進行中でもアーキテクチャの設計と改善に継続的に取り組む ・コードベースをいつでもリリースできる状態にしておく ★アジャイルなテスター：「うまく動いたら知らせるよー。うまく動かなくても知らせるよー。本番環境でコケるとかありえないからね」 ・アジャイルプロジェクトでは何もかもがテストされなければならず、随所に登場する ・顧客の隣に座って要求をテストの形式に書き出す ・開発者の側でテストの自動化を手伝う ・ソフトウェアの不具合を一緒に探す ・プロジェクト全体のテストにも関心をもつ ★アジャイルなプロジェクトマネージャ：「やあ！なんか手伝えることある？いつも着地点をきにするよ」 ・プロジェクトを成功させる唯一の方法は、開発チームを成功させることだと心得ている。チームの成功を阻む障害を取り除くためなら地の果てまで行く ・今どうなっているかを追跡する→プロジェクトの状況を伝える→チームの取り組む障害を取り除く ・より上位のプロジェクト関係者へ向けて、開発チームに期待できることをマネジメントする ・ステークホルダーへの状況報告 ・社内の人間関係を円滑にする ・チームを外から守る盾になる ・優れたアジャイルマネージャの条件は1週間姿をくらましてもプロジェクトの業務に何の支障も出ないようにできること ★アジャイルなUXデザイナ：I ♡ customers.　利便性の高い、魅力的な体験を顧客に提供することに心を砕く「お客さんのことを考えるのってクールだよね」 ・イテレーションを通して少しずつ積み重ねていくことにためらいがない ・他のあらゆる作業に先立ってすべてをデザインしてしまうのではなく、フィーチャーを実装するタイミングに合わせて少しずつデザインする ・ペルソナ、絵コンテ、ペーパープロトタイプ、コンセプトデザイン、、あらゆる技術を駆使する ■チームメンバーを探すコツ ・ゼネラリスト：フロントエンドからバックエンドまで、分析とテスト ・曖昧な状況に抵抗がない人：要求は出揃ってないし（それを見つけ出すところから）、計画は変わる。変化球を投げられても慌てず打ち返す。脱線事故が起きたら冷静に電車を乗り換えられる人 ・我を張らないチームプレイヤー：合奏団のようなチーム。自分のありのままの姿を受け入れ、人と分かち合うことをためらわず、互いに学び合って成長することを心から楽しめる人 ■プロジェクトを始めるときに4つの質問をしてみたら？ ・自分は何が得意なのか？ ・自分はどうやって貢献するつもりか ・自分が大切に思う価値観は何か？ ・チームメンバーは自分にどんな成果を期待していると思うか？ ■インセプションデッキ ①我々は何故ここにいるのか ②エレベーターピッチを作る ・エレベーターで同乗している30秒の間に新規事業の説明を説明をしなきゃならないことが語源。成功すれば資金援助、失敗すればまたカップラーメンをすする生活 ③パッケージデザインを決める ④やらないことリストを作る ⑤「ご近所さん」を探せ ⑥解決案を描く ⑦夜も眠れなくなるような問題は何だろう？ ・失敗しそうなありとあらゆることを紙に書き出す→防止策を真剣に考える→破り捨てる ・取り組む値打ちのあるリスク：低スペックな開発マシン、お客さんに時間を割いてもらえない、作業場所が分散している ・取り組む値打ちのないリスク：不景気、会社の買収、お客さんの人事異動 ・変えることのできない物事を受け入れる落ち着き、変えることのできる物事を変える勇気、その違いを常に見分ける知恵 by ニーバーの祈り ⑧期間を見極める ・開発のプロジェクトは長くても6ヶ月以内で。期間に応じてプロジェクト失敗のリスクが増加する ・小さく分解する ⑨何を諦めるのかをはっきりさせる ・トレードオフスライダーを使う ・時間、予算、品質は固定されたもの。スコープ（計画）は柔軟に扱える ・同じ目盛りの項目を２つ作らない ・捉えどころのないものを忘れない。「思わずハマっちゃうくらい楽しいコンピュータゲーム」「コールセンターへの問い合わせを20％削減する」「顧客が自分で問題を解決できる」 ⑩何がどれだけ必要なのか ・プロジェクトの予算：メンバーの人数×プロジェクト期間中の時間当たりのコスト ・期間と費用をざっくり、いい線行ってるあてずっぽうでも出す ・プロジェクト契約までのスコープ設定や計画に何か月も時間をかける必要はない。インセプションデッキを使って数日で。 ・ユーザーストーリーはポイントを使って相対サイズで見積もる ■アジャイルな計画づくり ・マーフィーの法則：失敗する余地があるなら失敗する。トーストバターカーペットの例 ・アジャイル開発の原則：シンプルさ ・リリース単位のことをMMFという →Minimal Marketable Feature。20％くらいの早いうちから価値や成果を届けたい ・チームのベロシティ＝完了させたストーリーポイントの合計/イテレーション ・期日固定orフィーチャセット固定

アジャイルの入門書。アジャイルとはなんぞや？から始まり、計画やプロジェクトの運営方法、プログラム、テストまでの流れが記載されている。あくまでも考え方がのっているものなので、そのままプロジェクトに適用できるかと言ったら怪しいかもしれない。ただこの本は所々に挿絵があったり、文章が口語体になっていたりして、非常に読みやすい。すぐに読みきることができた。

アジャイル開発の方法・志を説明している本です。 軽快な文章であり、それに加えて300ページほど文量なので非常に読みやすかったです。 開発者ならアジャイルについて理解するためにも読むべき本だと感じました。

読みやすく，アジャイル開発に関して網羅的に書かれているので，初学者に薦められる．また，インセプションデッキや様々なポイントについても書かれているため，アジャイル開発に慣れた人も一度読んでみると良いと思う．

原著がThe Pragmatic Bookshelfから出ていて、そして安心の訳者／監訳者陣（＋豪華レビュアー陣）、いい本であることは最初からわかっていたけど、なぜか邦訳発刊直後の品薄状態で入手しそこねて、その後、入手だけはしていたものの ずるずると読まずに来てしまっていた一冊。 今回、とあるきっかけをいただいて読み始めたのですが、各地で「道場」が開かれたのは納得。私にとっては「アジャイルプラクティス」を読んだ時の衝撃が一番すごかったですが、きっと同じようなインパクトをこの本から受けた人たちがたくさん居たってことだと思います。 いろいろ考えながら、そして来し方とこれからに思いを馳せながら読んだので、読了まで結構時間もかかってしまいました。これは、確かに珈琲の肴にして誰かと語りたい類の書籍でしょう。 監訳者あとがきが読める分、邦訳版は得かも。見事な l10n にも脱帽です。

Agile開発の本は、どうも苦手な内容が多かった。 あまりにも抽象的すぎて、効果の高さだけが宣伝されている「幸運のツボ」的な内容が多かったからだ。 この本は初めてライフサイクル全体に関するウォークスルーがなされていた。 そして、重要な事は、Agile開発での一般的キーワード、「ユーザーストーリー」「スタンダップミーティング」「ふりかえり」というものは、単なる方法の一つにすぎず、 「価値あるものを創るための障害は全て排除し、助けになるものはなんでも使え」 という事がよく分かる内容だった。 メソドロジーの本にあまり良書はないけど、これは良い本だと思う。

#アウトプットファースト 開発としてではなく、「プライベート部分のタスク管理の中で、アジャイル的要素を取り入れられるか」というテーマで読む。 アジャイル＝決まった期間で顧客に価値を提供し続けられること プライベートなタスクということで、顧客には自分も含まれると考えている。 アジャイル＝決まった期間で顧客に価値を提供し続けられること プライベートなタスクということで、顧客には自分も含まれると考えている。 "ある粒度以上"のタスクにはユーザストーリーを設ける。 ユーザストーリーを書くための条件は大きく6つ。見積もれること、独立していること、テストできること、交渉できること、価値があること、小さいこと。 書き方としては2通り。 ①シンプルなキーワード、②誰のための、何をするか、なぜそうするか、がセットになっていること。 プライベートなタスク管理の課題としては、長期間タスクの設定が難しいこと。家事など、自由時間が非常に限られるため。実際に計測してみたら1日に捻出できる自由時間は長くても3時間程度だった。 そうなると、イテレーションを2週間とすると、2*7*3=42h。細々としたタスクにまでユーザストーリーを書いていたらタスク管理だけで飽和する。バランスをどこで取るか、が課題。 アジャイル思想を取り込むため、タスクを「①ユーザストーリーを必要としない単調タスク」「②ユーザストーリーを考える必要がある複雑なタスク」を考えた。今はTrelloでカンバンに近い形でのタスク管理+GAPで個数計測を実施しているが、更に①、②で分類して個数計測できるようにする。なお、②のタスクの切り分け粒度をどのように適用するかは今後の課題。

認識合わせのために、プロジェクトの最初期にインセプションデッキを作る。これによってチームとしてのプロジェクトの認識が共有される。 どんなやり方が、チームや環境に適しているかは誰にもわからない。顧客に価値を素早く提供し続けることを意識して、日々の改善ができていたらアジャイルとしては上出来かもしれない。

プログラマとしての生き様を描いた本。Q/C/Dが確定した状況では、スコープを調整する以外にソフトウエアを開発する方法はなく、この事実に向き合わないことが現在のソフトウエア開発の問題であることを再認識させられる。

2023/5/14 ■インセプションデッキの10の設問 1.我われはなぜここにいるのか? 　何のために自分たちはチームを組むのか。自分たちの顧客は誰なのか。そもそもこのプロジェクトが始まった理由は何なのか。こうしたことを再確認する。 2.エレベーターピッチを作る 　30秒以内に2センテンスでプロジェクトをアピールするとしたら、何を伝えるべきだろうか? 3.パッケージデザインを作る 　何気なくめくった雑誌のページに、自分たちのプロダクトやサービスの広告が載っているとしたら、それはどんな内容がいいだろうか?それからもっと大事なのは、その広告を見た人は君のプロダクトを買いたくなるだろうか? 4.やらないことリストを作る 　プロジェクトで実現したいことというのはかなり明確になっているものだ。それと同じかそれ以上に、やらないこともはっきりさせよう。そしてそれをわかりやすく一覧にするんだ。 5.「ご近所さん」 を探せ 「プロジェクトの関係者」に含まれる範囲というものは、自分たちが思っているよりもずっと広いものだ。そうした「ご近所さん」を招いて、コーヒーでもごちそうしながら自己紹介ぐらいしてもいいんじゃないだろうか。 6.解決案を描く 　チーム全員の認識が揃っていることを確認するために、概要レベルのアーキテクチャ設計図を描こう。 7.夜も眠れなくなるような問題は何だろう? 　プロジェクトで起きる問題のなかには、考えることすら恐ろしいものだってある。だが、あえてそうした心配事について話し合おう。どうすれば最悪の事態を避けられるだろうか?被害を最小限に食い止める方法はあるだろうか? 8.期間を見極める 　どれぐらいの期間が必要なプロジェクトだろうか?3ヶ月? 半年?それとも9ヶ月? 9.何を諦めるのかをはっきりさせる 　プロジェクトにはいくつか操作可能な要素がある。期間、スコープ、予算、それから品質。現時点で譲れない要素はどれだろう?譲ることになるのもやむを得ない要素はどれだろう? 10.何がどれだけ必要なのか 　期間はどれぐらいかかりそうか?コストは?どんなチームならプロジェクトをやり遂げられるだろうか? ・作ろうとしているものは何なのか、それはなぜ必要なのか。 ・このプロジェクトの魅力はどこにあるのか。 ・プロジェクトで解決したい課題は何か。 ・「ご近所さん」は誰なのか。 ・解決策はどんな風になりそうか。 ・向きあうことになりそうな課題とリスクは何か。 ・プロジェクトの期間はどれぐらいの長さになりそうか。 ・柔軟に対応すべきところはどこか。 ・(期間や費用は) ざっくり何がどれだけ必要なのか。 ＝＝＝ アジャイル開発のお勉強。 ・ソフトウェア開発の３つの真実 　1.プロジェクトの開始時点にすべての要求を集めることはできない 　2.集めたところで、要求はどれも必ずといっていいほど変わる 　3.やるべきことはいつだって、与えられた時間と資金よりも多い ・アジャイルプロジェクトの3つの特徴 　1.役割分担がはっきりと分かれていない 　2.分析、設計、実装、テストといった開発工程がどれも、途切れることなく続く連続的な取り組みになる 3.チームが一丸となって成果責任を果たす ・インセプションデッキの課題一覧 　1.我われはなぜここにいるのか？ 2.エレベーターピッチを作る 3.パッケージデザインを作る 4.やらないことリストを作る 5.「ご近所さん」を探せ 6.解決案を描く 7.夜も眠れなくなるような問題は何だろう？ 8.期間を見極める 9.何を諦めるのかをはっきりさせる 10.何がどれだけ必要なのか ・荒ぶる四天王 　・スケジュールは圧縮される 　・予算は削減される 　・バグのリストは長くなる 　・やるべきことは際限なく湧き出てくる ・文書化の難しさ 　実際のソフトウェアプロジェクトで、重厚な文書化が要求を捉える手段として本当にうまく機能したことなんて一度もない。顧客は自分たちの欲しいものを手に入れることはほとんどなく、開発チームは求められたものを構築しきれない。 ・ユーザーストーリーVS要件定義書と仕様書 　無駄がない、正確、必要な分を必要なときに　vs　重厚、不正確、最新じゃない 　対面でのコミュニケーションを促す　vs　憶測や誤った前提を招き寄せる 　計画がシンプルになる　vs　計画が複雑になる 　低コスト、素早い、手軽　vs　コストがかさむ、遅い、手間がかかる 　最新の情報が反映されている　vs　情報が古くなったまま放置される 　チームが学習するということを踏まえている　vs　チームが学習するということを考慮しない 　フィードバックを即時反映できる　vs　フィードバックを即時反映できない 　見積り精度の高低を当てにしない　vs　さも見積り精度が高いかのように取り繕う 　チームの協調作業や新しい取り組みを歓迎する　vs　オープンな協調作業や新しい取り組みを歓迎しない ・アジャイルソフトウェア開発の12の原則 1.顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 2.要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。 3.動くソフトウェアを、2-3週間から2-3ヶ月という、できるだけ短い時間間隔でリリースします。 4.ビジネス側の人と開発者は、プロジェクトを通して、日々一緒に働かなければなりません。 5.意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。 6.情報を伝えるもっとも効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすることです。 7.動くソフトウェアこそが進捗の最も重要な尺度です。 8.アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。 9.技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 10.シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 11.最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 12.チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

整理されてはいる。が、広範なのである人にはぼんやり伝わってしまうような気がして、これで技術者を勇気付けたり煽ったりすることができるのか知りたい。

マスターセンセイと学ぶアジャイルソフトウェア開発の本。 アジャイルなソフトウェア開発とは何か？という方法論だけでなく、マスターセンセイがちょくちょく何故それをやるのか？何のためにやるのか？と問い掛けてくるので、後から読み返してもとても参考になると思う。 まずはこれを読め、と言われているだけあって入門書としてももちろんよいけど、ある程度アジャイルな考え方に慣れてきて再度読み返してみるとよさそう。 参考文献もかなり必読なものが多いです。特に後半の技術的なプラクティスは本書だけではカバー出来ないので、関連の本で勉強するのがいいと思います。

仕事とすごくリンクしていて、いろいろと考えさせられるものがあった JIRAの意味がわかっていなかった部分とか、背景にある思想を知ることができたのも良かった

webディレクター、プロジェクトマネージャーは必読！ わかりやすくすぐ実践できるものばかり。何度でも読みたい。

アジャイルの指南書であり、達人開発者への道が開ける、と思う。 いろいろと書かれていることが有機的に重要で、 その有機性を表現するようなマネージメントが難しい。 実行するためには何本もの素振りが必要であり、 実際に戦場に出て何回も戦わなくてはならない。 矛盾とも取れるような状況に出くわすたびに決断し進むだろうが、 最初はボロボロにしかならないだろう。 心が折れずに次に進めたチームのみが、 道が開ける、と思う。 （以下抜粋。○：完全抜粋、●：簡略抜粋） ○それは、開発サイクルが6ヵ月を超えないことへのこだわりだという。（P.81） ○顧客の要求を書き出す時間よりも、顧客の要求について話し合う時間をもっと増やすべきである（P.122） ○文書の限界を知れ。文書化は最後の手段だ。（P.122） ○よいか。収まらないなら、それは収まらないのだ。たとえばインフラ構築が1回のイテレーションに収まらないなら、その作業を終わらせるのに必要な分だけのイテレーションを費やすしかなかろう。（P.202）

ソフトウェア開発の開発手法の本なのですが、外国人から見た侍のイメージで、アジャイルを選択させようとしている。日本のように非効率的であったり、無駄であったりする作業を大量にする代わりに、責任明確にして無駄な仕事を減らす手法とも言える。

ソフトウエア開発で起きる事象、想定しておくべきことが理解できる。 自分は何が得意か。 どうやって貢献するつもりか。 自分が大切に思う方は何か。 チームメンバーは自分に何を期待していると思うか。 これを聞いてみる。 インセプションデッキ なぜここにいるのか。 エレベーターピッチ。 パッケージデザインをつくる。 やらないことリストをつくる。 ご近所さんを探せ。 解決案を描く。 夜も眠れなくなるような問題は何だろう。 期間を見極める。 何を諦めるかはっきりさせる。 何がどれだけ必要なのか。

システム開発者にはすごく有益。 プロジェクトにかんしてなら、インセプションデッキの詳細を知れてよい。 システムのとこはむずかしいから読み飛ばした。 得たいものは得れた。

読了：2018/3/18 海外モノ翻訳にありがちな軽い口調が意外と読みやすい。 これから始めるならインセプションデッキ（P.43） もう始まっているならストーリー収集ワークショップ（P.117） (1) 大きくて見通しの良い部屋を用意する (2) 図をたくさん描く (3) ユーザーストーリーをたくさん書く (4) その他もろもろをブレインストーミング (5) リストを磨きあげる P.253 「技術的負債が累積しすぎて生きるのが辛い」（毎週） 「こんなふうにリファクタリングしよう」（毎分） の図がわかりやすい。というか身につまされる。

始めに作るもの全てを決めて開発を開始するのがウォーターフォール型開発。一方で、ある程度決めてから徐々に作って積み上げていくのがアジャイル開発。 ”作る”という点では同じだが、そのアプローチは全く異なり、作り方そもそもの思想も異なるため、根っこから考え方を変えましょう、を知るのに良い本。 ウチはウォーターフォール型を今まで進めていたので、どこかのタイミングでアジャイル開発を試すのも良さそうです。

アジャイル開発を始める際にぜひメンバー全員に配って、読み切ってほしいです。 語り口調がとてもユニークで面白いので、すらすら読めると思います。 チームメンバーが同じ方向を向いて開発を進めなければならない、 意識づけのところから書かれているので、マネージャーの方はとくに熟読してほしいです。 私も実際にチーム全員にこの本を配り、意識づけを行いました。 マネージャーにも読んでもらい、上司の理解も得て進めました。 本書を読んだ上司も大変気に入っていました。 プロジェクトをいかに成功にもっていくかというところで、プロジェクトの管理体制がウォーターフォール型開発との歴然とした差がわかると思います。

今風の開発スタイルのゆるい解説 アジャイルというソフトウェアの開発手法について解説している。 現代の開発においてどういう問題があるか，アジャイルではそれに対してどのようなアプローチを取るかといった感じに解説されている。 現実的な問題や経験談が散りばめられて読み物としては面白かった。 実際に導入するとなると，周囲（特にリーダークラス）の理解が必要なので，教養として知っておくのがよいかなと思った。

言わずと知れた名著。 アジャイル開発の考え方・進め方について実に丁寧に説明してある。 著者の経験に基づいて書かれているため、説得力があり実践的な内容になっている。 アジャイルをうまくやることで開発途中の仕様変更に対応できるなど、開発者だけではなく顧客にもメリットがある。しかし、その道は決して簡単ではないことも気付かせてくれる一冊。

レビュー書いた http://kimikimi714.hatenablog.com/entry/2015/12/25/210000

アジャイル開発の指南書。 先に入門書など読んだ上で読むことを勧める。 内容はかなり広い範囲にわたるが、開発の最初から最後までを具体的にリンクさせているので非常にイメージしやすい。 相当な良書。オススメ。

身に覚えがあるような、チーム開発で陥りがちな悪しき状況をうまく描写していて、苦々しい気持ちになりながらも読み進めていった。 RUNNING LEANとほぼ同時に読んでいたけど、こちらのほうが、いわゆる「現場」をよく表現している。RUNNING LEANはビジネス寄りな印象だった。 ユニットテストやらTDDのところは飛ばし気味に読んだけど、技術的負債をどうやって返済していくのが理想的か、みたいなところまで踏み込んで言及していたのが印象的だった。 開発者必携だと思う。

ソフトウェアのアジャイル開発について書かれた本です。 アジャイル開発本の代表作SCRUM BOOT CAMP THE BOOKと比べると、チームの方向性を合わせるために使うインセプションデッキやプログラミングでのプラクティスが紹介されています。 特にインセプションデッキはプロジェクトの初期に整合すべきことがはっきりするので使ってみたいと思いました。

近年注目されているアジャイル開発(アジャイルマニフェストは10年以上前であるが)とはどのようなものか、親しみのある絵や言い回しとともに説明されている。 ソフトウェアのプロジェクトによっては、従来では仕様書を作ること自体がソフト開発の重要な成果としているものが少なくないと思う。 対してアジャイル開発の考え方は、「動くソフトウェアをリリースする」こそが最も重視すべき成果としている。 それも短い期間で動くソフトをリリースすることが、重要だというのだ。 短い期間でソフトウェア開発のサイクルを回すのは、設計・コーディング・テストを分けて開発するウォーターフォール型の開発を今まで行ってきた人にとってはなかなか難しい。 そのような人のために、アジャイル流の開発計画の立て方や開発体制、テスト技法など動くソフトを短期間でリリースする方法などをこの本は教えてくれる。 プロジェクトによってはアジャイルを適用することが難しい場合もあるが、アジャイルを適用しないでも参考になる部分はあるので、ソフト開発している人がこの本を読む価値はありそう。 ただし、この本で紹介されているアジャイル適用例はあくまで例であるため、アジャイルをプロジェクトに適用するためには、実際のソフト開発の中で試行錯誤していくしかなさそう。

めっちゃ読みやすかったし分かりやすかった。アジャイル系の専門書数冊の内容がギュッと詰まっているよとお勧めされたので入門に読んでみた。 タイムボックスとかカンバンとか、周りで飛び交っている言葉の意味がわかったし、「もっとソフトウェアをうまく作りたい」「顧客のためにいいものを作りたい」という信念がベースにあることもわかった。あと、プログラマだけじゃなく、すべての関わる人が同じ方向を向いて健康な状態でプロダクトを開発すること。「早く、安く作って儲けたい」とは違う信念だなと(良いものを作った先に利益はあるかもしれないけど)。早く、っていうのも、ウォーターフォール時代の要件すべてを実現する時間が早くなるってわけじゃなくて、顧客に最初のプロダクトが届く時間が早くなるってことかと納得(今になってやっと＼(^o^)／)。 テスト駆動開発も、CIの話も、それだけでかなり専門的な内容になるけど、ソフトウェアを作る上で、それがなぜ必要とされていてどんな役割を担っているかを知れたのでよかった。UXの話も、エンジニアリングの話も重なっている部分があって、軸足が違うだけでどの分野も「よいプロダクトを早く届ける」に向かっている気がした。

アジャイルとは単なる手法ではなく、自らでプロジェクトを改善し続けていれば、それがアジャイルだという考え方だった。アジャイルでよく使われる色んなツールや手法はあるものの、それを導入するのはプロジェクトを運営する人達自体。この根底の考え方は何年経っても通用するものだと思った。

ソフトウェア開発上、必ず遭遇する困難を解決するための、素晴らしい手法だと思う。まずは、実践することだね。

発売直後にざっと読んだが、もう一度じっくり読んでみた。 必要なことが十分網羅されている。 今更ながら納得出来ることも多かった。 実際はシステム開発以外のことにも何とか適用出来ないかと考えているのだが・・・

面白すぎて寝不足になってしまうほど読みやすい。開発系の複雑な用語が少なくて初心者に最適。「アジャイル開発とスクラム（緑の本）」と並んでお世話になった1冊。

アジャイルの手法とその意義を軽快な語り口で極めて明瞭に解説した名著。 肩の力を抜いて読める相応にくだけた口語体、適宜挿入されるポップで分かり易い図、マスターセンセイと熱心な弟子が交わす会話の形で提示される、熟慮すべきポイントや注意点。 極めてシンプルでありながらも本質を付き、かつリラックスして楽しく読める。正に、アジャイル開発をそれ自体で体現するような本を書く、という著者の意志がビシバシ感じられる。 特に最後、 アジャイルとは、変化に対応し続けること、特定のプラクティスに縛られてはいけない、本書で紹介したものもまた、数ある一つのプラクティスにすぎない という趣旨のことが書かれているのを見て、「あ、東洋思想っぽい、だから（西洋人から見た変な）東洋文化仕立てにしてあるのか！」、と、独特の演出が全てアジャイルを体現する意図を持って練られていることに気づき、ちょっとした感動を覚えた。 アジャイルの勉強を始める上で最初に手に取る本として、ぶっちぎりのオススメ。☆５つ。

ニーバーの祈り マカレナを踊る ジャグリング Intangibles：とらえどころのないもの 特攻野郎Aチーム ストーリー収集ワークショップ エピックとユーザストーリー 「相対サイズ」で見積もる 期日固定orフィーチャーセット固定 ジャストインタイム方式 ペーパープロトタイプを沢山つくり、ベストを選ぶ ーー分析ツールーー 絵コンテ、コンカレンシー図、プロセスマップ、ワイヤーフレーム ーーー カンバン：WIP（運用などの開発手法）？？ デイリースタンドアップ 「価値につながる習慣」を守る ビジュアルワークスペース（貼物を作る） ーーー ●アジャイルなプログラミング 技術的な負債：リファクタリング

面白いというか、少し珍しい書き味だった。アジャイル開発導入には、もう一歩踏み込んでほしいと思う内容だったものの、既存の開発にアジャイル開発の要素を部分的に取り込むには十分で、それによって効率化できそうだと感じた。

アジャイル開発を本質的かつ体型的に理解できる良書。より正直に、シンプルに、カスタマー志向に、というスピーディーな開発手法が、システム開発の世界にも広く浸透してきた最近のテーマだけに、上っ面だけでなく、深く解釈出来た。 文体すら、アジャイル！です。

アジャイル開発をこれから始める/始めたばっかりの人には 最初の一冊としておすすめできる。 『何をやるか』と『なぜ』がちょうど良いバランスで書かれていると思った。 ボリュームもちょうど良く、 退屈するほど詳細でもなく、要領を得ないほどあいまいでもない。

アジャイルの流儀から方法論のさわりまでをワンストップで解説。原書の軽妙な雰囲気を再現するためか「イテレーションが面倒すぎて生きるのが辛い」などのネットスラング風味な言い回しが随所に見られる。

図書館で借りてきたが、買う価値のある本。 アジャイルを 最初から最後まで擬似体験できる。 プログラムだけじゃなく、ホントに 最初から最後まで

***** アジャイル開発に関して基本的な概要の理解。 要諦はあくまで思想とプロセスを共有化する。 *****

多人数でバラバラに仕事をすると、どうしても統制が取れなくなったりして、結果プロジェクトが崩壊したりする。それを防ぐために納期に向かって、時には必要性の少ない要素をなくしてでも、計画的に推し進めていかなければならない。その心構えややり方について、この本はユーモラスに書いてある。プログラマーだけでなくどんな仕事にも必要なことだよね。スティーブ・ジョブズがピクサーの巨大な平屋を建てた件は、さすがジョブズは違うよなあと感心した。

開発者やプロジェクトマネージャ向けの本 ・アジャイルな開発をするための心構えや方法を学べる． ・ジョーク交じりの文章で，わかりやすくハイセンスな図もあるため，気軽に一気に読める． ・アジャイル開発の上で大切な言葉（心構えなど）は本の中で何度も出てくるため，何度も読み返す必要がない

「個人の生産性を計測すると、プロジェクトで大切に育んでいきたい心構えと振る舞いを台無しにしてしまう(P.161)」でも気になっちゃうよな〜。これはこれで個人のモチベーションアップになる気もするけど‥個人を攻撃するんじゃなくて、フォローするために計測するならありだとおもう。問題は本当にそうできるか。 「必要な分だけを必要なときに分析する(p.187)」分析しだしたらついついアレもコレもしがち。特に清書にめちゃくちゃ時間かけたりはもったいない。 「問答無用でやるべきプラクティス。ユニットテスト、リファクタリング、テスト駆動開発、継続的インテグレーション(p.195)」 「プロジェクトで使う言葉を共有する(p.228)」これがなかなかできない。仕様書の中でずれてたり、ひどいときはUI上で統一されてなかったりするもんなぁ。手戻りを減らすためにもプロジェクト開始時からコレを気にしていきたい。 「テスト駆動開発、ルールその2。『危なっかしい所を』すべてテストする(p.263)」ポイントは『危なっかしい所を』という点。夢中になって対した意味のないテストを書くことに時間を割いて大事なテストが書けないようなことはしたくない。 「誰かにアジャイル開発を押しつけるのはだめだ。何をすべきか口で言うだけじゃいけない。具体的に行動して、君が模範を示すんだ。(p.287)」うん、がんばろう！

二度目の読み終わり。 アジャイルかどうか関係なく、開発に必要な考え方が記載されていたと思う。 特にインセプションデッキや、ユニットテスト、リファクタリング、CIなどは、必要性を感じた。 個人的には、日々の業務に取り入れていきたいと強く感じた。

アジャイル開発については無知だったが、本書を通じてアジャイル開発がどのようなものか、その大枠を理解できた気がする。本書で書かれているような、客に商品を提供するための知恵は、それ以外の仕事であっても活かすことのできるものが多いため、大変参考になった。

アジャイル関連の書籍は多々ありますが、この書籍は異常とも言える読みやすさです。挿絵、対話形式、ちょっとしたジョーク、などで飽きさせず楽しみながらアジャイルの手法を学ぶことができます。

問答無用の☆4　これはソフトウェア業界における愛の物語である。愛から始まり勇気で終わる物語である。 ユーモアのある筆致に比べ、この本において説明されている状況というのは、過酷そのものである。残酷である。そしてその残酷さは、海の向こうの遠い世界の出来事でも、遠い昔の物語でもない。今この瞬間に、目の前で、自分自身も含めた身近な人々をなぎ倒してしていることだ。 そしてそれを、なんとかするのは、It's youってわけだ。これが愛と勇気でなくてなんだ？ 私のコンピュータ屋である。プログラマだとは言わない。エンジニアであるとも言わない。だけどサムライになる。

実際には電子版を読んだ。アジャイル開発とは何かをわかりやすく、具体的に説明している。実際の開発プロセスに適用する上で活用できそう。

楽しく読めるのに、アジャイル初心者にも全体像をつかみやすい。 アジャイルで開発してみたいと思わせられた一冊です。

•ずっとわくわく。表現にセンスがある。訳者の方も、流石。 •この楽しくわくわくするような表現や伝え方、アジャイルを円滑に進める上での礎になるのだろう。そういう意味で、アジャイルを体現した本な気がする。 •ストーリーの抽出は、つくるものに依って最適化をはかる。運用や使い方が明確なら、フローチャートを辿りながらユーザーストーリーを抽出するとか、画面が少なく構成がある程度見え、かつUXが肝なら、画面にうつる機能からストーリーを抽出するとか。なるほど。

まずは、マスター先生からとても多くの事を学ぶことができました。 プロジェクトを１つのバスにのせるインンセプションデッキ 顧客の要望を考えるユーザストーリー 作るものを決めるイテレーション イテレーションを見積もるポイント制（名前わすれたww） プロジェクトの状況を確認するバーンダウンチャート 継続的に品質のよいプロダクトを生み出すための ・ユニットテスト ・リファクタリング ・テスト駆動開発 ・継続的インテグレーション ウォーターフォールでいう、 要件定義からリリースまでの プロジェクトのすべての工程が 書かれているのでとても勉強になりました。 やってみよう！できると思わせてくれる あとは実際にやってみるだけ！

アジャイル開発とはどんな事を目指すのか、どんな事をやるのかを非常にわかりやすく説明してます。導入としては非常にすばらしかったです。あとはどう実践するか。

最初から最後まで読んでて楽しかった もうちょいここら辺の本を読見あさろうと思う 今後のイメージをするうえでまさにこれだ！みたいな爽快さがあった　あたまでっかちになっちゃったのかもしれないけど先読んでよかったと思っている

本当に読みやすい、アジャイル開発の入門書。 CIやXPについて詳細は別途書籍で学習する必要はあるが、その前の事前知識をつけるにはもってこい。 ウォーターフォール経験しかなかった人間にとっては、とても刺激的で楽しい書籍でした。

チームメンバーはこれで概要を把握してもらって、プロセスを具体的に引っ張るリーダーは「アジャイルな見積りと計画づくり」などで補完。

とても読みやすかった。知りたいトピックから読むのではなく、最初から読んでいくタイプの本。 開発において何を問題として捉えていて、アジャイルでどう解決するか、具体例を使って説明されている。時にはソースコードまで用いているが、その言語に通じていなくても分かる様に書かれている。 アジャイル開発を始める情報を得るために十分な内容になっていると思う。 本書でも書かれているとおり、アジャイル開発というのは、ある固定した方法の事をいうのでないので、他にもアジャイル関係の本を読んだ方が、より自分の直面している問題に良く対処できると思う。

アジャイル採用してないから関係ない。 どんな開発プロセスを使っていてもそんな言い訳はしないで読んだ方がいい。 TDD、TiDD、CIの概要もフォローしている。 内容は言うまでもないとして本書が優れている点は以下の通り •小サイズ、300P程度で携帯性に優れている •5-6時間で読める •取得言語に関係なく読める（簡単なC＃は記載されてるが平気） •訳がとても読みやすい 外食一回ガマンすれば買える値段なのでぜひ買うべき

具体的なアジャイル開発の手法が網羅されており、文章もなじみやすい。 実際に現場で実践することができた。 楽しく読み進めることが出来る、翻訳クオリティがすばらしい。 アジャイル系ならとりあえず読んでおけという良書。

ウォーターフォールではないモデルの解説。 てか、会社でやってることとおんなじかと思ったら、だいぶ整理されてて違うのな。 エッセンスはあるけど、ここまで余裕をもってやれない、というのが現実じゃないの？違う？ …結局は、もっとリソースがほしいという、勝手な結論。

◆良書。分かりやすくて面白い。 ◆近年、行動経済など心理学を他の分野応用する事例が多いが、アジャイルでもプラクティスに人間心理を活用している点が興味深かった。 具体的には、 ・ストリーポイントによる相対的な規模の見積り 　→人間は絶対値より相対値を扱う方が得意。 　　例えば、統計数値などで、値が2倍になったなどと強調される時、実は絶対値で見ると元々の値が小さい為、絶対値で見ると0.001→0.002など微々たる増加に過ぎなかったりする、など。（統計数字のトリック。うーん、ちょっと例が適切じゃないかな。 ・プランニングポーカー 　→集団知。みんなの意見は案外正しい。牛肉の重量について、プロの見積り値より、素人の集団の見積り値の方が実際の重量に近かったという話。 　→ただし、集団知と衆愚の違いは紙一重なので、その点に注意する必要がある気がする。（衆愚=アンチパターンか？ ◆アジャイル的な仕事の進め方について ・スコープを固定（タイムボックス）して、チームのベロシティ（生産性）を測定し、ベロシティ以上のタスクが振りかかった場合は、次のイテレーションへと持ち越すという手法は、良く言えば「合理的」（チームの生産性以上の仕事量をこなすのは物理的に不可能=無い袖は振れない）だが、悪く言うと「開き直り」とも取れなくもないと思う。 ・スコープの変更をスムーズに行う為には、顧客との信頼感の構築が必要。（論理を認めさせるには感情で納得する事が重要） 　その為には、毎週、機能（顧客が求める価値）をリリースして、顧客に見てもらう（受け入れテスト）事で、顧客からの信頼を蓄積する必要があるというのが本書の主張。 　→アジャイルでは、メーカーの責任（一括請負では無限責任）を減らして、顧客の責任を増やす為、顧客との信頼関係の構築は必須条件。 　→アジャイルで顧客が担う責任（実現する機能の優先付け、スコープの変更など）は、権利（製品により深く関われる）の裏返しである事が多い。 　　（権利と責任をワンセットで考える思想はとても欧米的） 　→顧客が責任を果たす際の判断材料を増やすため、メーカーは作業状況を詳細（=メトリクスの測定）に報告する責任がある。 　　つまり、ガラス張りにしろという事。自分を守る為の工数や作業時間を水増し（=安全バッファ）は不要。ただし、それには顧客とメーカーは一蓮托生という一体感が育まれないと難しいと思う。

アジャイルなんてスパイラル開発を格好良く言っただけ、 そんな風に思っていたのがこの本を読んで目が覚めた。 アジャイルとは、プロマネやプログラミングやテストの手法の集合ではなく、 「ユーザーの期待に一番うまく応えるにはどうすればよいのか」 と考えて実践し続けることなのだな、と思った。

アジャイル開発を進めていく上での大事なことが、実際のプロジェクトの始まる段階前→プロジェクト開始→計画をたてる→運用の流れで示されている。 一冊で、アジャイルなプロジェクトマネジメントののうはうがざっくりとつかめた。 アジャイル開発に限らず、プロジェクトを進めていく上で大切なノウハウや考え方がぎっしりつまっているので、プロジェクト運営者におすすめの本である。

アジャイル入門書。ちょっと理想論も入ってる感。 しかし構成や図解が非常によく工夫されていて、理解に苦しむことが無い。毎日の開発に悩んだらたまに読み返すとよさそう

アジャイル開発への理解が曖昧だったので読んでみた。言葉が独り歩きしている状態だったけどマインドぐらいは理解できた気がする（完全に理解するには実際のプロジェクト経験も必要だと思うので）。第7章の見積りの話と第V部のエンジニアリングの話が特に勉強になった。くだけた文体も読みやすい。

アジャイルを実行する為のノウハウをモデル化することに成功している。 この通りには進められないケースのが多いんだろうけど、「何故駄目だったのか？」を検証する材料になる一冊。