アジャイル開発ってどんなことをしてプロジェクトを進めていくんだろうと気になり読みました。 マンガもあり読みやすいかと思いましたが、カタカナ語のオンパレードで意識高い系の人には、良いかと思いますが初めて読む人には、あまりお勧めしません。 中身も言葉を置き換えているだけで、それらしく聞こえますが、どこの会社でもやっているスケジュール管理でした。

魔法生物とは契約はしていないが、「弊社はこれからアジャイル開発を取り入れたシステム開発をしようとしているので君がプロダクトオーナーになってよ!」と言われ、(まじでござるか?)と思いつつ当該発言をしたITの人に借りていた本。申し訳なくも他業務に追われ数ヶ月寝かせていましたが、どうも様子を見るにマジで私がPOになるしかないようなので読みました。良いシステム(プログラム?)であるのはわかるが、回し方(特にPOのあり方)は正直わかったかと言われると自信がない。実際にスクラムが始まったらわかるようになるのだろうか。

スクラム開発の基本を漫画形式で学べる メモ 1. プロダクトバックログ: 実現したい要求をリストにして並び揃え、常にメンテナンスして最新に保つ。価値、リスク、必要性が具備。ユーザーストーリー形式で書くことが多い。 2. スプリント: 1〜4週で期間は固定、計画設計開発テストとリリースに必要なすべてのことを行う。 3. スプリント計画ミーティング: スプリントの目標を簡潔にまとめスプリントゴールを決める。タスク一覧(スプリントバックログ)を計画する。タスクは1日以下の単位とする。開発は合意内容を完了させることに全力は尽くすが約束してるわけではない。 4. リリース判断可能なプロダクトとは、完了の定義 * コードレビュー * チェックイン * ユニットテスト * カバレージ * ドキュメント * セキュリティ * 性能 * デプロイ 5. スプリントレビュー: 動作するプロダクトをオーナーがレビューする 見積もり - バックログの工数はわかりやすいものを基準としておき、感覚で置いていく。フィボナッチ数列の値を使うとやりやすい。 - 実際にスプリントでいくつ分消費できたかがわかるとベロシティがわかる。そこから全体のバックログを消化するのに必要なスプリント数が割り出せる

めっちゃ作者の親切が伝わる良本 スクラムがどんなものか、どのあたりが難しいのかイメージがしやすい。 どのフレームワークで開発できるかも重要だけどまずこの開発枠組みを知ることが大事だと思う。

なぜか購入したまま放置していたのか、どこかから出てきた。 実践的という意味では非常によくまとまっている。もう少し早く読めば良かったか。

漫画でアジャイル活動の説明がされており、初めてアジャイルに取り組む人が一般的な流れを理解するにはとても良い。

会社のメンバーにSCRUMの本質的な部分を、自分なりに解釈して伝えたいなという思いで読了。独断ですが、私が感じるポイントは以下の点なのかと。 ①目標設定 インセプションデッキという方法論は、簡単にいうとプロジェクトが向かうゴールを設定して、メンバーで共有しようということかと思います。硬い言葉でいうとミッションとかいう話になりますが、要は全員の共通認識となるゴール設定の必要性の手段としてインセプションデッキが定義されているのかと思いました。 ②タスク分割と優先順位付け プロダクトバックログは、ざっくりとした理解では、タスク分割して、どのタスクから優先的に実施するかを見える化したもの。ただし、このタスク分割が実はめちゃめちゃ難しい。この方法論として、ストーリーベースで考えたり、見積もりをカードで実施したりする工夫がなされている。いきなり詳細と正確性を求めるとより難しくなるが、まずはざっくりベースで考えて、徐々に詳細かするプロセスを取ることで、心理的なハードルも下げている。 ③時間の意識を持つ スプリントとかは、本質的には、有限の時間を最も効率的かつ効果的に使うための仕組みではないかと思いました。あとは、期間を短く設定することで、未来を見通しやすくする効果もありますかね。時間の設定は、「ここまでに出来る事を規定する」ことにもなり、理想と現実のギャップが生まれる場面で、実はここが1番難しさがあるのかなと。 ④判断基準の明確化 目標未達成＝悪ではなく、現状把握。そのためにも、設定した目標を達成できたのか達成できなかったのかをしる必要があり、明確な判断基準が必要になります。我々は、できなかったと言いにくい心理があるので、なかなか判断基準を明確に設定することができないことが多い印象です。うまくいかなかったらそこから学ぶ。このマインドセットが必要です。 上記①から④は、最低限の規定として、それを実行する上で、チーム内での役割明確化、責任の明確化、マインドセット（全員で協力してやりきろう）、誠実さ（お互いに対するリスペクト）が必要で、その方法論が、まさにSCRUMでしょうか。

5年ぶりに読み返したが、忘れていた大事な要素を再確認できた。 プロジェクトが長く続いていくとscrumの本来の目的から徐々に解離していっている部分があるなと（特にカイゼンのアプローチなど。。） 関係者にも本書は改めておすすめしたい。

Scrumの基本のキ システム開発に関わる人全てが読むと良いと思っているし、自分のチームのメンバーには必ず読んでもらっている

スクラムとはどういうものかはざっくり理解した。 典型的な開発者だが経験から独自にこれに近い思想に至っていたので、スクラムは開発の本質を捉えているのだと思う。 この手の開発管理手法の書籍は知識としては得るものがあった半面、興味は覚えなかった。

アジャイル開発の一つ、Scrumの方法や心持ちを漫画とともに説明してある本。 なんちゃってアジャイルしか経験がなかったので、非常に参考になった。 すぐに理想的に実践できるのは不可能だが、知っているのと知らないのでは大きく違うと思います。 あるプログラミング言語を知らなくても別の言語の経験から大体理解することはできますが、チーム開発手法はある程度知らないと前に進めないと思うので、知らない人は目を通すだけでもしておくといいと思います。

【一口感想】 　「Scrum導入本の決定版！これ一冊でスクラムのエッセンスの全てがわかる」 【３行要約】 　・あるプロジェクトにScrumを導入してみるという実験をストーリー仕立てで解説 　・スクラムマスターに抜擢された主人公もPOもチームもスクラム初体験のなか徐々に成長していく姿がまぶしい 　・重要な用語やマインドセットなどももちろん網羅 【所感】 打ち合わせでスクラムの話をしたばっかりに、新しいプロジェクトにスクラムの導入を命ぜられ、 そして自身もスクラムマスターとして任命されてしまった主人公「ボク」。 「スクラムとは何か？」 を常に自問自答しながら、迫り来る数々の問題をクリアしていき、最後にプロジェクトはいろんな 意味での「成功」に導かれていく。 ストーリーの展開はマンガ＋文章という２段構成で進められ、リズムも良いのですぐに読み切れてしまう。 遅読の私でも２時間もかからなかった。個人的には面白くて２度通し読みしてしまった。 この本のすごいところは、最初に全てをまとめて説明するのではなく、ストーリーが進んで行く なかで必要な事実としてスクラムを解説しているところだ。ストーリーをマンガに乗せて展開 していくというスタイルは最近のハウツー本では流行りなのかもしれないが、私が読んだことのある いくつかの本の中でもリズム感というか、マンガと文章の組み合わせの長さなどがちょうどよく、 それこそ「今必要な最低限のものを短いタームで作ってイテレーティブにリリースする」という、 スクラムのスタイルそのものに近いリズムで展開されていくところがとても読みやすかった。 また、個人的にものすごく心に響いた点は２つ。 ひとつは、このストーリーはスクラムマスターであるボクくんの成長ストーリーと捉われがちだが、 実は彼だけでなくPOのキミちゃんも、ボクくんの上司であるブチョーさんも、そしてチームの メンバーそのものも、スクラムというプロセスの導入をきっかけにみんなが成長していくストーリーだ という点だ。 チームは自分たちの活動内容がつまびらかになっていくことで不安もあったろうが、最後の方では どうやればものごとを正しく、そして最短距離で解決に向かわせることができるのかわかるようになり、 そしてそれを自律的に行えるようになっていく。 スクラムは個人の能力もそうだがチームとして人が強くなり、リーダーを持たなくても自発的・自律的 に行動がとれるようになるというのは、まさにこういうことなんじゃないかと感じた。 もう１点は、プロジェクトの途中で起きるシステム的ではなく人為的な「障害」が、あまりにも自分の 過去に経験してきたことと重複してした点だ。 「人を投入すればベロシティ（開発速度）上げられるだろ。だから期間短くしろ」と上司が言ってくるとか プロジェクトのステークホルダではない部署の人間がプロジェクトルームに来て、無意味な正義感を振り かざして、仕様書を見せろ！こんな仕様は間違っている！と「口」も「手」も出してくる、とかいったやつだ。 スクラムにおいては、ステークホルダとチームメンバー以外の人間の意見はただの参考であり、基本的に 意思決定を左右するものにならない。彼らは自分たちのやり方が絶対で、それが正しいと信じ込んでいる ので、そうでないやりかたをしているのが気に入らないのだろうが、そもそもプロセスも価値観もゴールも まったく違う世界で、ひとつのやり方が絶対正しいなどという保証はない。 というかほぼ100％、間違っている。 私は、過去経験してきた数多くの開発の現場で何度もこの場面に遭遇してきた。 立場がメンバーだったこともあるしリーダーだったこともあるが、そのいずれの場合も、 チームは最終的にこの「部外者」からの意見に屈服してしまった。 しかし、それではダメだったのだ。 私はこの本を読んで確信した。 「プロジェクトのステークホルダでないやつの発言は、聞くだけ聞いて無視しろ」 この一言につきる。もしそれがステークホルダではない上司だったら、POやSMは意地でも説得する 必要があるだろうし、そうでなければチームメンバーのみんなに迷惑がかかるし、そもそもチームの 存在意義である「ユーザーに価値のある動くサービスを提供する」という目的を達成できなくなって しまう。発言してくる人には悪意はないと思うし、上司だと言いにくい局面もあるかもしれないが、 ここは絶対に折れてはダメだ。粘り強く交渉・説得する必要がある。 スクラムとは、チームを強くするということと同時に、リーダーとなる人間がどうやって チームを支えていくのか？ということの１つの答えであるような気がしてならない。 どうやったら部下が自律的に行動してくれる人間になるのか？ スクラムを導入することでおそらくリーダーの負荷は一時的には高くなるだろうし、これまでの 進め方では必要なかったタスクも多くなるだろう。 でもチーム全体としての生産性はきっと、それまでの何倍も高くなるはずだ。 本書では、そのきっかけとなる何かに気づかせてくれる気がする。 スクラムに限らず、リーダーとしてどう振舞うべきか？と悩んでいる人に向けても、とても良い 参考資料になるのではないかと思う。 チームのメンバーに限らず、この業種に関わる全ての人に読んでもらいたい「逸冊」だ。

マンガの登場人物たちの社内営業システム開発ストーリーに沿ってスクラムのノウハウについて解説されている。 初めてシステム開発をすることになった人の1冊目に最適な本。

Scrumについて学ぶ最初の1冊として、とてもオススメです。 技術書によくあるあるような、無駄にくどい説明や硬い文面を避け、全体を通して理解のしやすさに主眼が置かれていて、頭にすっと入ってきました。 実際に起こりそうな問題を踏まえストーリー仕立てでプロジェクトのイニシエーションからリリース、振り返りまで書かれているので、開発経験のある人であれば、実際の現場と比較しながら読めるのではないかなと思います。

「大きな問題なくスクラムが導入できた事例」となっていて、スクラムの基本的な考え方を学ぶのに良い。 現実はもうちょっと強い抵抗勢力や失敗があるのでこれだけ読んでうまく導入するのは難しいかもしれない。初めの一冊としておすすめ。

Scrumに関して，基本的なことから実際におこなう上での注意点が書かれている． そのため，主な対象読者であるScrum初学者だけでなく，実践している人でも学びのある本だと思う． また，口語調の文体や問題の状況をマンガで表現するなど，読みやすい本になっている． ただし，逆に全体的にさらっとしているため，重要さが伝わらない感がある． 何度も読むなり，問題に直面したら読み返すなりの対応が必要かと思う．

2013年初版発行なのでちょっと古い本だが、中身は今でも問題なく読める。 スクラムのはじめから終わりまで、どういうことをやってどういう問題が起きるのかを漫画と解説で順に説明してくれる形式になっているので、これからスクラムを導入しようとしている人、スクラムをやっているけどうまくいかない人は、何かと参考になるはず。

現場でscrumではないがほぼほぼscrumでのチーム開発になり、上司におすすめされて読んでみました。バックログを頻繁に直してタスクの見える化を行っていた理由やPOがなぜ重要かがいまいち腑に落ちていませんでしたが、この本を読んで納得できました。scrumは体験して学んでいくための仕組みということを肝に命じてこれからに備えていきたいと思います。

悩んだら見返す本。 最近SCRUM回してないけど、回しているときは結構重宝してた。 軽く書かれているので、入門本としてはおすすめできる。 （SCRUM Guideが真なのはわかっているが、全体像つかみにくい）

アジャイルサムライの後に読んだ。アジャイルサムライが要点がコンパクトにまとまっているのに対して、この本は実際にスクラムを運用していくうえでの tips やハマりがちなポイントなどが書かれていた。アジャイルサムライと相補的な内容があることを期待していたけど、あまりなかった。

スクラムとは何かにマンガと解説で答えてくれる本。実際のプロジェクトの雰囲気を伝えながら、スクラムでやるとどうなるかを実況中継的に伝えてくれる。実際にスクラムに取り組む際に、羅針盤となってくれる書と思う。

こういうライトタッチな本がSCRUMの本質を捻じ曲げ、反対派からの反撃ポイントを作ってしまう。この本を読んでSCRUMに取り組もうとしている人たちに、「こんな簡単な話じゃないよ」といいたい。

以前？散々振り回されたアジャイル開発。今年からは違った形でこれを学び直し、の第一弾は軽めな一冊。ほとんどの講演は聴くだけ時間の無駄、知らない事は読んで知ればいいと普段から思っているしそうしているが、今日は聴く前に読んだのと、聴いてから改めて読むのでは吸収力が違う事を実感。ただし、理解はし易く実行は難しいと言うのも今日の学び。さてさて。

アジャイルソフトウェア開発手法の1つであるscrumについて、実践的な部分に重きを置いて説明されている。 scrumで知っておかないといけないことと、scrumで進めていくときによくありそうなアンチパターンが織り交ぜられていて、とても参考になる。 「だいたい終わってまーす！！」→「確実に終わらせて進むんだ！！」とか。 マンガ形式になっている部分はイメージしやすくて、サクッと読める内容となっている。 前提知識を揃えるためにも、是非ともチームメンバ全員に読んでもらいたい一冊。 参考文献も必読です。 「scrumの本質は、学びの仕組み」はいい言葉。素早く反省して学んでいくフレームワークがscrumだと感じている。

仕事で実際に使う知識なので読みました。 ふわっと全体像を知れたので、あとは実務と照らし合わせながら定着させよう。未経験には一発で理解するのは難しかった。

ひとまず斜め読み終了。何ヶ月かのうちに再読する見込み。 マンガだから、でなく、マンガを含めて読みやすくする工夫に満ちてる良い本です。

もう少し凝ったイラストよりもこれくらい簡素な方が絵の主張が強すぎなくて好感が持てる。巻末にある「理解を深めるために読んでほしい文献」と「ボクくんが気づいた大切なこと」は、この本のまとめであり、見返して役に立ちそう。コラムに記述者名が書いてあって、文責が誰にあるのかが明確にされている感じがして好印象。似たような構成だったけれど、以前読んだ『アジャイルでやってみた。』よりは読んでいて楽しめた。なぜだろうと考えたけれど、ボクくんの会社の雰囲気が良かったのかもしれない。

ざっくりやることを理解。 バックログはTask chuteの考え方にも近い。 直近のプロジェクト2つで試せるから実践してみる

今更だけど重厚長大な大企業にもAgileがやって来た。 いや、正確にいうと言葉自体はもっと前からもちろん来ていたが、インフラ屋のところまでついに降りてきた上にそれでチームを回そうという機運が出そう（で、まだ出てないんだけど）ということで、今更ながらスクラムというものをお勉強。 諸氏が書かれている通り、導入にはとても良い。なぜタイムボックスを厳守するのか、そしてなぜ『実運用において）見積りがズレるのか、納得できた。 イケるかな、スクラム。

スクラムは、チーム自身の学びと成長に期待している: Meet Up 大阪 @ blog http://meetuposaka.seesaa.net/article/449479749.html

スクラムについて勉強したかったので、読みました。 スクラムでPJを進めていく場合、締切とか全体的なスケジュールとかをどうするのかってあると思うけど、そこら辺の心配事もきちんと書いているので、良かったです。

ここに書かれているのはおそらく基本的なスクラムなはず。スクラムをやっている、やっていたならそれとの差異を感じながら読めて、基本に戻った方がいい部分とか、こういう理由でルール変更してるな、とかを考えながら読むと良いのではないでしょうか

スクラム開発未経験者が、どのようにスクラム開発を進めていくかがストーリー仕立てで説明されている。 そのため、初心者でもスッと入ってくる。 未経験者ならとりあえずこの本のやり方に則って実践してみればいいんじゃないだろうか。

スクラムの入門書のような本。しかし、自己流にアレンジしている部分も多く、なぜその役割で、なぜこのタイミングで行っているのかを、著者が理解していない。もしくは読者にうまく、伝わらない表現になっていると感じた。

本書は「スクラム」理論を読んだ学んだ人が、「スクラム」でプロジェクト管理を行う際にどのようにチームを立ち上げて「スプリント」を行えば良いかとか、実際にプロジェクトをスタートさせた場合に直面する問題点を具体的（物語風）にマンガや図、写真を用意してわかりやすく解説してくれているので非常に役に立ちます。 スクラム関連本のほとんどが背景や理論の説明本なので「理論」はわかったから実際に試してみたいという方や実際に導入してみたがうまく行かなくて悩んでいる方に超オススメ。まさにブートキャンプだ。

もう一つのスクラム本とは違って、開発を主眼に、マンガで書かれています。ある程度わかりやすくは書かれているんだとは思うのですが、なんか、すーっとは入ってこなくて、、、ある程度は、慣れ何だろうとは思うのですが。。。また、しばらくしてから、改めて読んで見ようと思います。

スクラムのことをひと通り学べて、かつマンガなのでとても読みやすかった。とっかかりとしておすすめできる一冊です。

アジャイルなソフトウェア開発をするためのフレームワーク「スクラム」を解説した書籍です。実際に現場でスクラムをやり始めると起きそうなことがマンガを使って解説されていて読みやすかったです。次は自分たちで実践しながらもう一度読み直したいと思いました。

SCRUM初心者向けの本。 漫画を交えて一から分かりやすく説明されている。 自分でも出来る、やりたいという感覚になっているのが受託開発のSEには難しいということが改めて理解できた。

scrumでの開発を漫画を交えて分かりやすく説明した本。 インセプションデッキはみんなで、見積りは時間をかけない、がなるほどと思った。scrumを始める時にみんながつまずく所をまとめたのだろう。実践的です。

スクラムをやろうと思ったわけではないけど、あちこちでスクラムスクラム言われているから、さくっと知るために読んだ。その目的は十分果たせたと思う。

2015.2.25読了 スクラムでもプロジェクトのゴールやミッションは大事 ➡︎インセプションデッキをつくる スクラムチーム全員がプロジェクトについて十分知っておく プロダクトバックログは、最初に重要な項目が漏れないようにしていく 全体は大雑把な順序をつけておいて、直近は詳細に順序をつける 見積もりの基準は、作業の量として真ん中くらいの項目がいい 見積もりは推測 詳細にするのは直近のものだけにしておく 見積もりポーカー、話し合うことであいまいなことが明確になる ベロシティがわかるとプロジェクトの先が見えてくる スプリント計画会議、第一部ではどうなったら終わりかも決めておく 第二部は本当に達成できるか考える 確実に終わらせられる計画を立てる、確実な計画をつくるための活動 デイリースクラムは、スプリントのゴールを守るための毎日の検査 スプリントレビュー デモを見ると終わったかどうかと本当にどうすべきがわかる 完了の定義はスクラムチームで合意する 問題になる前に見つけて対応する タスクボードを使えばタスクの状況を把握できる いろんなことを透明にできる タイムボックスはゆずれない 予測に使う タイムボックスに入るようにしていく 次にやることはだれもが知っている プロダクトバックログの順序は常に見直していく 直近の項目の順序が一番重要 順序を決定するのはプロダクトオーナーの大切な仕事 人を増やしてもすぐにベロシティはあがらない より作業をうまく進められればベロシティはあがる でもベロシティはあくまで目安 プロダクトオーナーと開発チームとでは責任を持つ部分が違うので誤解が生じやすい ユーザーストーリーでは、なぜそれが必要なのかその理由を明確に書かないといけない 少なくとも実現したいことの意図は書かないとダメ ユーザーストーリーをわざと短く書くことによって、実現したいことについてチームが話す機会を持つようにしている スクラムマスターがスクラムチームを良い状態に保つ もっと良い状態にできない原因が妨害で、それを管理しておく 妨害はリストにしてどれを優先的に解決するかを明らかにしておく プロジェクトの進む先をいつも明確にするためにプロダクトバックログを整理し続ける プロダクトバックログの手入れを定期的なイベントにしておくといい 実現したいことがあいまいだといろいろ問題が出てくる 直近のスプリントの分だけあいまいなことをなくせばよい スプリントの準備はプロジェクトをうまく進める上で不可欠 スプリント期間中に準備の作業をできるようにしておく プロジェクトで調整できるものは4つ 品質、予算、期間、スコープ 品質は常に一定じゃないといけないので調整できない どう実現するかを調整するのもスコープの調整 実現方法を工夫するのはスクラムチームにとってやりやすい調整のしかた 状況に応じて誰かがリーダーシップを発揮していく 開発チームのスキルを理解しておく 全員でさまざまな状況を克服できるようにしていく 得意な作業だけやっててもダメ 実際の作業に関係ない人の意見は参考意見 スクラムは問題を見つけやすいやり方 もっと良いものをつくっていくためにカイゼンが大事 プロジェクトの問題を見つけられるのは現場の人たちだけ

アジャイルサムライを読んだ後だととてもすんなり入ってきてよかった。ストーリ仕立てにすることで状況のイメージがしやすかったところが◎。

スクラムを始める現場向けの本。 全体的に漫画で書かれていて、単なるやり方だけではなく、現場で起こりえそうな問題とそれに対する解決アプローチが章立てされていて、スクラムやる前、後でそれぞれ違った見方で読めそう。 スクラムだけじゃなくて、ソフトウェア開発現場で良くある問題書かれているので、スクラムやってなくても参考になる部分もある。特にメンバーの理解に対しての取り組み方が参考になった。

【目的】　Scrumを始めようと考えている人に対しては、Scrumを始めるまでに一通り必要なことを伝える。Scrumを既に始めている人に対しては、悩んでいることへの解決の糸口やより成果を出すために身に付けるべきことを伝える。 【収穫】　アジャイル開発を全く知らない状態から、どのように開発を進めていくか雰囲気を感じ取ることができた。 【概要】　本書はアジャイル開発の手法の１つであるScrumについて、基礎編と実践編を通して、以下のことを学べるようにしている。 ①全体像と決められているルールについて ②プロジェクトをうまく進めていくためのポイント ③自分の現場でうまく取り入れていくためのポイント うまく進めていくためのポイントとしては、例えば以下のようなものが紹介されている。 ・スプリントバーンダウンチャートにスプリントレビューに出せばいい項目の見積もりポイントの合計をプロットしていくことで、タスクが順調に進んでいることを明確にする。 ・開発を進めていく上で必要なスキルの見落としがないように、チームメンバと必要スキルのマトリックスを作成する。 ・スクラムイベントを継続して全員で進めていくために、全員で合意したルールを目に見えるところに明文化して貼っておく 【感想】　新規案件にてScrumを導入した開発に関わる可能性ができたことから、基礎知識を身に付けるために読んでみた。類書に比べ、漫画を使うことでわかりやすく解説しているが、決して内容は薄くない。実際にアジャイル型開発の経験がある人によれば、まさに本書で紹介されているケースのイメージとのことだったため、アジャイル開発に向けた初めの一冊としておすすめ。

再読しました。 最近スクラム道に参加してるので、 読みなおしてみると全然違う印象でした。 かなり奥深い事が分かりました。

アジャイル開発手法の一つであるスクラムについての解説本。架空のキャラクターによるストーリー展開、マンガ表現を利用した説明をもって「スクラムとは何か？」「スクラムは具体的に何をやっていくのか？」という部分を紹介している。 アジャイルやスクラム等と開発手法については色々な横文字がついていてさぞ難しそうに感じるが、実際にやってみると難しい事は無く、普通に効率化やリスクテイキングしていけば帰結するような手法に収束していくものだと考える。現実にこの本に書かれているエピソードでも「あぁ、こんな事やったなー」だとか、「そうそう、こんな問題あったよ」なんて場面が随所に出てくる。そのように現場で積み重ねられた手法も重要なのは間違いないが、本書のように体系的にそういった手法を学ぶ機会も等しく重要だと考えられる。その意味において、具体的な開発ストーリーや理解しやすいマンガ表現を利用して、文章だらけで抽象的になりがちな開発手法を分かりやすく説明している本書は有用だと言える。 しかしながら細かい誤字脱字（初版に近いので後ろの方では直っているかも）が多く、肝心のマンガ表現は吹き出しの不自然な並びがキャラクターのやりとりにおける時系列を上手に表現できていない。またメイン部分にある「ボク」による説明文書は言っている事は体系的でまともだと感じられるが、微妙に的を得ていない主題とざーと書かれた文章による構成がイマイチだと感じられる。あえてキツい表現をすると、文章ばかりで伝わりづらいパワーポイントのようになってしまっている。箇条書きや表組等を利用して、文章部分についてもあと少し分かりやすくする表現が欲しいと感じる。とはいっても全体として非常に分かりやすくまとまっているので初めてスクラムを学ぶ人にとっては有用な一冊となるだろう。

スクラム開発のことはわかったような気がするけど、実際のところやってみないとよくわからないなっていうのが正直な感想。 プロダクトバックログを管理して、タスクに落としてスプリントごとで都度振り返る機会を設けるっていうのは開発関係なく大事だなと思った。

アジャイル開発手法で現在主流と言える、スクラムの概要について非常にわかりやすく理解することができた。現在アジャイル開発をバリバリしている人には、物足りない内容かもしれないが、これからの人や新しく入ったチームメンバーに読ませるには最適の本と思われる。良著

アジャイルソフトウェア開発手法の1つである「スクラム」について、実例を交えて書かれた本。文体も読みやすく、ストーリーに沿ったイラストが要所要所に挟まれており導入のイメージがしやすいのが特徴。 アジャイルサムライやアジャイルレトロスペクティブズなどといった、関連書籍を読み合わせることにより、理解が深まりそう。これからスクラムの導入を検討しているのであれば、まずこの本を読むことをオススメする。それくらい分かりやすい内容。 現場によってはスクラムを取り入れることは簡単ではないかもしれないが、小さなプロジェクトで少しずつでも導入し、経験を積んでいくのが効果的と思われる。 陥りやすいポイントや、よくある悩みどころも豊富に書かれているため、共感を得られる開発者も多いのではないかと。そしてこの本を手にとるスクラムマスターの卵が増えることこそが、現場にとって理想的なのではと感じた。

開発物語を通して、スクラムを疑似体験できる良書。漫画と解説コラムを挟みながら、とても読みやすくなっている。 スクラムは、開発プロセスではなくフレームワークなので、決まり事はとても少ない。守るところさえ守っていれば、他は良いと思うことを自由に取込めばいいのだけど、それがかえって何をどうしていいのか分からない状況になっている…というのが、スクラムに興味のある人の実情だろうと思われる。そんな人は、きっと本書を読めば、スッキリするはず。 ^^ 一つだけ違和感を感じたのは、「P.O. って、そんなに甘くないんぢゃない? (*1)」ってこと。良かったプロジェクト (当社比)、そうでもなかったプロジェクト(当社比) を思い起こすと、P.O. の善し悪しが大きかったような気がするのだ。P.O. が世の中の不合理との接点なので、正解のない中で、センス、判断力、洞察力、調整力などなど…を駆使して、ゴールへたどり着くキーマンとなるように思うのだが…。 日本のソフトウェア開発が変わるためにも、多くの人に読まれますように… (とにもかくにも、エンジニアの外の人に広まって欲しい…)。 (*1) スクラムマスターも甘くないと思うが、スクラムの解説書なので、悩めるスクラムマスターが都合がいいのだろうなぁ…と理解。 (^^;

アジャイルなソフトウェア開発現場におけるフレームワークである「スクラム」について書かれた本。著者の実体験をもとに、非常にわかりやすく書かれている。Daily Standup Meetingのやりかたとか、良いと思ったところは実践していきたい。

アジャイル関連一冊目に最適(^O^)／ この本で概要をつかんでから、他のを読むとすごく頭に入って良かったです。 アジャイル興味あるけど、どんなものなの？って思っている人に、ちょうどいい情報量だと思います。

タスクが洗い出されていなくて、 スケジューリングされていなくて、 リソースがあてがわれていない。 みんな何やっているかわからなくて、 やれる人は一人しかいない作業があって、 谷が死ぬほどある。 みんなで責任もって見積もる。 壁に貼って朝会やって作業確認する。 チームのありかたとして、 ウォーターフォールでも取り込める要素が多々ある。 （以下抜粋。○：完全抜粋、●：簡略抜粋） ○相対見積もりでは不確実なものを少しでもうまく扱えるように、 　使う数字を工夫している。 　たとえば、１，２，３，５，８，１３・・・という 　フィボナッチ数と呼ばれるすうじが使われることが多い。（P.85）

・漫画もありで、表現も固く無く、サクっと読める。一通りの流れが分かりやすく書かれている。 ・スクラムにおける各アクターの役割や、進め方が分かった。実際はこんなうまくはいかないだろうけれど。 ・ストーリーで表現する方法や、whatをhow（要求を実装）につなげるやり方は、もっと書いてて欲しかった。

読みやすい内容ではあったけど、アジャイルサムライを焼き直した感じ。 ただ、Scrumの進め方についての概要は、この本で十分つかめるのではないかと。 この本に限らずだけど、Scrumやその他アジャイル開発を適用したことで、プロジェクトや組織全体に対して、具体的にどういった効果が現れて、それがどのように利益に結びついたのか、ということに触れられていないのが残念。

レビューはこっちに書きました。 http://d.hatena.ne.jp/miyohide/20130405/1365171598

会社で紹介して、「マネジメントは自分はまだまだ...」て思ってる人に「やりたい！」って感じてもらえそう。 この本では響かない老害は私が抑えます。

SCRUMの概要、サッと読めて軽く知ることができました。実践している人達の話す言葉が何か理解できました。

アジャイル開発手法の一つ、SCRUMについての本。 大きく２部構成になっていて、第一部でSCRUMの概要を、第二部で初めてSCRUMを実践するときにつまづきがちなことをマンガのストーリー形式で紹介している。 このような本を読んでもなかなか職場の開発体制を変えるのは難しいけど、こうゆう知識があると上司がやりたいことの意図がわかる気がするので結構好き。

スクラムについて、漫画でさらっと読める。がちがちの理論書も、洋書の翻訳もいいけど、こういうのもすぐ実感できていい。

マンガでわかりやすかった SCRUMについて体制、スケジュール管理、課題の見つけ方の方法がざっくりわかる本だと思います。 SCRUMは期間が6ヵ月以上のプロジェクトが対象だと思いました。あまりにも短い期間のプロジェクトでは計測も改善もないで終わってしまいますからねー 全員が協力意識を持って、改善の気持ちなどの前提があればうまくいくのかな～ 【ボクくんが気づいた大切なこと】 ・ロールは単なる目印 ・プロジェクトを進めるうえで大切だと思うことは何でも話し合っておく ・スクラムチーム全員がプロダクトバックログについて知っておく ・見積もりは推測 ・自分たちの作業は自分たちで見積もる ・べロシティがわかれば、プロジェクトの先が見える ・スプリント計画ミーティングでは確実に終わらせられる計画を作る ・スプリントのゴールを守るために毎日検査する ・完了の定義は、スクラムチームで合意する ・問題になる前に見つけて対応する ・タイムボックスに入るようにしていくのが重要 ・プロダクトバックログの順序は常に見直していく ・自分たちの責務について理解しないとうまくいかない ・べロシティはあくまで目安 ・ロールで担当する部分を分けているので、どこに問題があるかわかる ・頻繁に話し合って伝えていくのが一番大事 ・スクラムマスターがスクラムチームをよい状態に保つ ・妨害はリストにして、どれを優先的に解決するかを明らかにしておく ・プロジェクトの進む先をいつも明確にするために整理し続ける ・スプリントの準備はプロジェクトをうまく進めるうえで不可欠 ・実現方法を工夫するのはスクラムチームにとってやりやすい調整の仕方 ・全員でさまざまな状況を克服できるようにしていく ・責任を持って取り組めるようにして、良いスクラムチームを少しずつ築き上げていく ・何でもリリーススプリントに回すのはよくないこと ・Scrumは体験して学んでいくための仕組み

3人の著者の経験、伝えたいことが凝縮された内容でとても良かった。 (おそらく文章にするのが難しいと思う)「なぜ」の部分を書いていたりする点も良かった。 おそらくScrumを1度でもやっている人には、ここに書いていることはものすごく勇気づけられるし、具体的な武器になると思う。

スクラムの考え方はITだけてわはなく、組織全般について適用できる。 この本は、スクラムマスターがどんな点に注意したら良いかマンガでわかりやすく書かれており、隅から隅まで有用な本だった（≧∇≦）

自身の業務というか自身のチームも現在SCRUMを採用してソフトウェア開発に取り組んでいます。この本を読んで自分のチームのやり方を振り返ってみると、意外と「ウチのチームも出来ているよね」という部分があったり、逆に「ウチのチームはこの点はまだまだ」といったヒントがいくつも現れて非常に参考になりました。

「アジャイル」に関する本がいろいろある中で、Scrumにフォーカスした本です。（著者の3氏共、認定スクラムプロフェッショナルで、Scrumの為に書いた本なので、当たり前といえば当たり前ですが・・・） ひょんなことからスクラムマスターをやることに「ボク」君を中心として初めてScrumで開発を行うことになった開発チームの面々、そしてPOの「キミ」ちゃん。彼らを通じてScrumってなに？Scrumってどうやるの？を分かりやすく教えてくれる良書です。 本書は、メンバ集めから最終リリースまでに起こるであろう問題を文章だけでなく「マンガ」として描いてあり、その時のスクラムチームの雰囲気がよく分かる構成となっています。読み終えた時には自分が実際にそこに居て一緒に開発をしていた気になり心地の良い疲れを覚える程でした。 又、著者達が実際に行なっている手法や経験等がTipsとして含まれており、気付きの切掛があるところも嬉しいポイントです。 願わくば、本書では敢えて書かれなかったレトロスペクティブ等を含んだ続編も出して貰えたら。あと、プランニングポーカーも。(^_^) 最後に、このレビューを読んで「スクラムマスターやらPOやら意味が分からない」と思われた方には（そうでなくても）、是非この本を開いて下さい。下手なレビューで説明するよりずっと分かりやすく、楽しく説明されています。

自分が何をしたってプロジェクトは変わらないーーそんな風に思っている人に届くといいな。 「自分たちのため」に「自分たちができる」ことは、まだきっとあちこちに残っている。 本書を読めば、きっとそのあちこちを考える「きっかけ」と「勇気」をもらえるはずだ。

改善に関する現場の知恵が詰まった良書！ アジャイルやスクラムに関わるすべての利害関係者にオススメです！ 私が学んだこと； ・スクラムは改善の旅の出発点 ・まず問題に気づくこと。ロール、イベント、成果物はそのための工夫 ・失敗は恐るに足らず。失敗から学ぶこと