あらすじ
※この商品はタブレットなど大きいディスプレイを備えた端末で読むことに適しています。また、文字だけを拡大することや、文字列のハイライト、検索、辞書の参照、引用などの機能が使用できません。
マスターセンセイと学ぶアジャイル開発の道動くソフトウェアを素早く開発するための「アジャイルソフトウェア開発手法」を、実際に導入するにはどうすればよいかを、豊富な図を使い親しみやすい言葉で解説しています。経験豊かな著者が具体的なノウハウをまとめた本書は、アジャイル開発を導入したいと考えている組織や人のための「現場のマニュアル」として役立ってくれることでしょう。
感情タグBEST3
Posted by ブクログ
言葉として知っていた『アジャイル』の背景を知ることができた
大学や現場では、知識は教えてくれるがそれ以上は教えてくれない
開発者としての経験を何年か積んで得られる内容を、簡単に得ることが出来る良書だ
大学やプロジェクトを初めて任された人たちが絶対読むべきである
深掘りしたい箇所でも読むべき本が提示されているので、親切
あっという間に読み終えることができます！
Posted by ブクログ
いきなりマスター・センセイってなんやねんって感じだけど、
文章も画像もいい塩梅のユーモアがあり、訳註も親切で非常に読みやすかった
(荒ぶる四天王ってこれが元ネタだったのか......)
Posted by ブクログ
荒ぶる四天王の元ネタがついに！
古典的と思い後回しにしていたけれど、アジャイル開発を理解するにあたり素晴らしい知見のかたまりでした。
軽快なトーク（のような語り）も味があります。
まさにアジャイルマニフェストの12の原則を体現していたと思いました。
Posted by ブクログ
こんなに軽やかに読めるタッチの本が、バイブル的な立ち位置になってるのすごい。
当然、元々の内容が素晴らしいことはあるだろうが、訳者の些細な気遣い・心意気が、メチャメチャ効いてるんだろうなと思う(細部の挿絵の言葉選びとかライトなネットスラングとか)
最後の一節は、エモすぎて、全文メモ余裕でした。
Posted by ブクログ
『デイリースタンドアップでの報告の仕方をこう変えてみては？』の例示がユーモア溢れるな〜と感じるとともに、「顧客への価値を届ける上で、実際に何を成し遂げたか／今日は何を成し遂げるつもりか」という一つ視座を上げた考え方にも繋がりそうでアリだな〜と気付きを得られた。
Posted by ブクログ
Xでバズってたので再読。あのページ、著者は外国の方だからそこまで意識していないはずだけど、日本にソードマスターヤマトのミームがあるから素材として最高だなw
Posted by ブクログ
「アジャイルサムライ−達人開発者への道」は、アジャイル開発を学ぶのに最適な一冊です。この本では、マスター・センセイと弟子との会話を通じて、読者はアジャイル開発のエッセンスを楽しみながら理解することができます。特に、インセプションデッキやドラッカー風エクササイズのような、すぐに実践できるワークショップの記述が豊富で、内容が非常に充実しています。この本は、アジャイル開発に関する理解を深めたいすべての人にお勧めできる作品です。
Posted by ブクログ
アジャイルの要点を理解し、それが自身の携わる業務に適しているかどうかを考えることができるようになる本。
・相対サイズで見積もり、チームがどれくらいの速度で仕事を進められるかを計測する（ストーリーポイントとベロシティ）。
・プロジェクトに先立つ概算見積もりは当てずっぽうである。これは不確実性コーンとして示されている。
・プロジェクトの開始時点では、ベロシティは推測であり、実際にやってみないと分からない。
・想定より進みが遅い場合、最初に立てた計画にはこだわらず、スコープを調整して対処する。※そのためには、取り繕わず、隠し立てせず、プロジェクトの計画や進捗を顧客と常に共有して、情報の非対称性を解消しておくことが必須だと感じた。
Posted by ブクログ
これだけ読んどけば良いと言われたことがあるが、アジャイル、スクラムを始めてみて知りたいこと、疑問に思うことが一通り語られているのではなかろうか。後で必要に応じて本棚から手に取り参照することもしばしばあるので、物理本で買って良かったなと思った一冊。
Posted by ブクログ
「毎週、価値ある成果を届けられているか？」何度も繰り返されているが、アジャイルかどうかはこれに尽きると思う。
インセプションデッキ、イテレーションが〜のような難しそうなワードを聞くたびにアジャイルから避けて来てたが、これらはあくまで手段。チームによって必要なものを取り入れていけばいい。
開発者であれば12章〜の内容は基本スキル。
以下は引用
P22 これから2週間で課題を解決すると宣言。
P25 お客さんを目の前にしてデモをする。
P64 今回は気にしない。→今回がプロジェクトを指してるのか、スプリントなのか不明。
P68 助けを求めたくなる前から知り合いになっておくんだ。
P106 しかる時が来たら詳細を検討するが、それは本当に必要だと確信をもてるようになってからの話だ。
P191 ペルソナがいるとシステムに人間味を持たせることができる。
P214 デイリースタンドアップでの報告の仕方をこんなふうにしてみたら〜。
P216 ストーリは完了したか、してないか。そのどちらかだ。
P226 チームの意思を明確にする
Posted by ブクログ
陽気な達人プログラマーに教えてもらった気分だった。
めっちゃいいです！
いきなりページを開くと(厳密には数ページだけど)
1. 君は学ぶことが心から好きだ。
2. 君はソフトウェアのことを大切に思っている
めちゃくちゃ歓迎ムードである笑
いろいろ面白い内容が盛り沢山だったけど印象的なところだけ上げておく(なるべくソフトウェア開発以外にも通ずるような部分を、、、)
1. チームメンバーを探すコツ
・ゼネラリスト
→なんでもそつなくこなせる人。器用貧乏⁈)
・曖昧な状況に抵抗がない人
→どっしりと構えてくれる、臨機応変
・我をはらないチームプレイヤー
→ありのままの姿で、調和できるように
2. エレベーターピッチ
エレベーターで一緒に乗った友達に自分の仕事を30秒で説明してみよう
3. どのリスクには取り組む価値があって、そうじゃないのらどれなのかを決める
→願わくばわたしに、変えることのできない物事を受け入れる落ち着きと、変えることのできる物事を変える勇気と、その違いを常に見分ける知恵とをさずけたまえ -ニーバーの祈り-
4. 計画の立て方
・顧客にとって価値ある成果を届けられる計画
・わかりやすく、ありのままを伝える、誠実な計画
・約束したことを守り続けられる計画
・必要に応じて変更できる計画
5. 本当に重要なものだけをまずは実装
ここまで読んでいただきありがとうございます。
でもアジャイルって一体なんやねん！と思った方は是非読んでみてください。
読んだその日からあなたも私もアジャイルです。
Posted by ブクログ
アジャイル開発についての理念やら進め方について短くまとまっている。
手法そのものよりも「なぜ、何のためにやるのか」を説明しておりわかりやすい。
Posted by ブクログ
アジャイル開発に興味があるなら一度読んでみると良いと思う。マネージャーや現役のエンジニアだけではなく、これから開発をやっていくような人にもオススメしたい。
Posted by ブクログ
アジャイルの入門書。アジャイルとはなんぞや？から始まり、計画やプロジェクトの運営方法、プログラム、テストまでの流れが記載されている。あくまでも考え方がのっているものなので、そのままプロジェクトに適用できるかと言ったら怪しいかもしれない。ただこの本は所々に挿絵があったり、文章が口語体になっていたりして、非常に読みやすい。すぐに読みきることができた。
Posted by ブクログ
マインド、プロセスの基本を知れる。
ただし発注者のためのアジャイル目線が強い。
より良いものを作る事は大事だが、ベンダー視点では数あるプロジェクトの一つ。利益相反にもなり得る。リソース調整、契約交渉、利益確保といった泥臭い観点の記載はない。その点は別に学ぶ必要あり。
Posted by ブクログ
アジャイルサムライ――達人開発者への道
Jonathan Rasmusson氏の著書です。
アジャイル開発の入門書になります。
アジャイル開発とは何かから、計画～実践までの全体的な流れが解説されています。
【本書で学べること・考えること】
- アジャイル開発とは
- アジャイルなチーム
- インセプションデッキ
- ユーザーストーリー
- 概算見積り
- アジャイルな計画作り
- イテレーション運営
- アジャイルなプログラミング
読んでみての感想です。
アジャイルの全体像を掴む入門書としては、とても平易な内容でわかりやすいです。
まず、これを入口にアジャイルの全体像を掴み、自分の役割に合わせた内容を深掘りするのが良いと思います。
特にプログラミングの手法については、それぞれの内容で一冊の本になっているくらいなので、是非、深掘りして欲しいです。
Posted by ブクログ
仕事でアジャイル開発に取り組むことになり、2周目を読み終えました。
圧倒的に2周目の方が噛みごたえがあり、サムライが登場したり、キャッチーな語り口といったいわゆるハードルを下げる工夫と骨太な本質が両立していて、内容も網羅的な名著。
「インセプションデッキ」「マスターストーリーリスト」「ユーザー計画ミーティング」などオリジナルの概念も紹介され、これは「どのように開発するかは自分次第だ」という著者の思想を体現しているように思える。
それにしても、後書きを読んで気づいたのだが、文章のところどころに挟まれたアジャイル開発の原則が、アジャイルソフトウェア開発の12の原則そのまんまだったなんて！素晴らしい。
Posted by ブクログ
質の高いソフトウェアを高速に届け続けるための開発手法、アジャイル。 変化が多く、スピーディなアウトプットが求められる環境ではめちゃくちゃぴったりな手法だと思う。
Posted by ブクログ
2011年の出版。それでも色あせていない。インセプションデッキという考え方。相対サイズの見積、リファクタリング、テスト駆動開発、継続的インテグレーションといったアジャイルならではの手法。「イテレーション計画ミーティング」「ショーケース」「デイリースタンドアップ」「ミニふりかえり」というイテレーションの運営。アジャイルに必須の要素が詰まっている。お陰様でアジャイル検定レベル１に合格できた。実践に使えるかはこれから。
Posted by ブクログ
アジャイル開発の概要を理解したいときに読む本。
事例を踏まえて学びたいときは、次に「アジャイルな見積りと計画づくり」を読むとよい。
アジャイル開発は、実態を可視化しづらいウェブアプリを前提としており、実態やプロトタイプを作る組み込みの世界にそのまま適用できなさそう。
特に、エンドユーザが直接的に価値を感じ取れないデバイス系や、Tire2サプライヤの開発には適用が難しいと思った。
組み込みの世界に適用できないところ。
１．部分発注
２．途中からの機能ドロップ
３．ストーリベースの開発
ハードウェア上でソフトウェアが動くので、
どうしてもソフトウェア階層の下位から上位へ開発が進むので、エンドユーザへリリースできない。
組み込みの世界に適用できるところ。
１．インセプションデッキでプロジェクトの外観を知る
２．TDD 検証基準で顧客と合意しておく。
Posted by ブクログ
アジャイル開発の方法・志を説明している本です。
軽快な文章であり、それに加えて300ページほど文量なので非常に読みやすかったです。
開発者ならアジャイルについて理解するためにも読むべき本だと感じました。
Posted by ブクログ
アジャイル開発のテキストとしては有名な本だったので、読んでみました。
内容はアジャイル開発とは何ぞやから始まって、プロジェクト発足からリリースまでにどのようなことを行うのか、その際の注意点などがみっちりと書かれています。
ただ、海外の技術書によくある回りくどい表現がとても多く、内容を理解するにはそこから要点を見出して頭の中で情報を整理する必要があります。個人的にはこの作業にとても疲労感を覚えるため、本書を読解するのにとても苦労しました。
オライリー本を抵抗なく読める人であれば重宝すると思いますが、私みたいにちょっと苦手という方は誰かが要点をまとめたサマリーを探す方が良いかも、なんて思いました。
Posted by ブクログ
「サムライ」というタイトルだが、訳書。
なので、洋書独特の言い回しや、アイスブレイクの仕方は好みが分かれるところ。
（マスターセンセイと弟子のくだりとか）
内容はアジャイル開発を始めるために必要な情報が網羅されていて、入門書としてオススメの一冊。
Posted by ブクログ
分量が多く斜め読みした。
アジャイル開発に携わっていた時に良んでおくべきだった。
アジャイル開発のフレームワークについてはこれを読んでおけばいいかなという印象。
やり方どうこう以前にもっと量書かないといけないなと自覚した。
アジャイルで躓いた時に再度読み直そうかな。
一冊家に置いておけばいい一冊
Posted by ブクログ
顧客とプロジェクトの状況を正直に包み隠さずに共有出来ることが、ベースとしての大事な考えだと感じた。
ただ、上記はこれまで経験してきたプロジェクトや契約の習慣とは大きく異なっていて、それがアジャイルをイマイチ有効活用できてない原因なのかもと。
もう一度本書を元にチームで原点に立ち返ってみようかと思う。
Posted by ブクログ
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.チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
