あらすじ
“はじめて「スクラム」をやることになったら読む本”が7年ぶりに増補改訂！
近年、より複雑化しているプロダクト開発をチームでうまく進めていく手法として、
世界中で注目されている「スクラム」。実際の開発現場にどう適用すればよいのかを、
とにかくわかりやすく解説しています。
・理論だけで終わらない“実践”の手引き
・架空の開発現場を題材に、実際のプラクティスを詳しく解説！
増補改訂では、初版以降のスクラムのルールの変更を踏まえて、用語や説明の変更、
最近の開発現場に向けた追補など、全面的な見直しを行っています。
・スクラムガイド2017年版に対応
・スクラムを実践しているチームの実情にあわせて更新
・開発現場の風景を更新
・プロダクトをより意識できるように修正
・コラムを全面刷新
これからスクラムをはじめたい人はもちろん、スクラムを導入してみたけどなんだか
上手くいかないなぁ……と思っている方にぜひ手にとっていただきたい一冊です。
【本書の概要】
はじめまして‼
今回、ひょんなことからスクラムマスターをまかされた「ボク」です。
スクラムについてまだ何もわかっていないので、この本を参考にしようと思っています。
おおまかな内容は、次のようになっているんだって。
●基礎編
スクラムの全体像と決められているルールについて説明する。
●実践編
架空の開発現場を題材に、開発が始まるときから時系列に
スクラムではどう進めていくのかを説明する。
なるほど。
それでは、ボクと一緒にこの本でスクラムとはどういったものなのかを学んでいこう！
※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。
感情タグBEST3
Posted by ブクログ
良かった。
実際のスクラム現場の雰囲気が分かった。
どう運用するかの一例が見れて参考になる。
デイリースクラムもこんな感じってことねとか。
開発チームの担当範囲。
スクラムマスターの担当範囲。
スクラムガイドじゃ分からなかったけど、イメージできた。
Posted by ブクログ
具体的なアジャイル開発の進め方がよく分かり、1冊目として最適。
実際にアジャイルのプロジェクトを経験すると、コミュニケーションの密さ度合いもよく表現されていたんだなーと実感。
場数を踏みつつ、適宜読み返して引き出しとしてストックできればと思います。
Posted by ブクログ
スクラムで使用する概念をストーリー形式で乗っけてくれているのでスクラムの原理がスッと理解できる。
スクラムについて理解したかったらとりあえず読んでおくと良い一冊。
Posted by ブクログ
スクラムとは、チームで学習を重ね、
いいものを作るアプローチ。
コンサルで普段やってる考え方に違いが、
取り入れたいこともいろいろある。
チームが作るものは、すべて
プロダクトバックログに書かれていく。
誰がいつ書いてもよい。
プロダクトオーナーが責任をもって、
優先度を決める。
直近やるものは、内容を具体化していく。
プロダクトバックログに要求を書く場合は、
誰が
何をするためにつかうのか
それは何を達成したいからか
を書く。これをユーザーストーリーと呼ぶ。
ユーザーストーリーが実現された姿として、
デモ方法を記載していく。
一定期間ごとに作業をこなしていく。
この期間をスプリントと呼ぶ。
スプリントの頭に、スプリントプランニングとして
当該スプリントでやるプロダクトバックログを
決める。
タスクに砕き、タスクをスプリントバックログとして管理する。
スプリント期間中、毎日同じ時間、場所で
デイリースクラムを15分行い、
やったこと
これからやること
課題
を確認しあう。
スプリントの終わりに、関係者に向けて
報告を行い、フィードバックをもらう。
次のスプリントに向けて、チームがよりよい
仕事ができるようにするたまの改善点を整理
する、スプリントレトロスペクティブを行う。
スプリントには、
プランニング、
デイリースクラム
フィードバック
レトロスペクティブ
次のスプリントのための
プロダクトバックログの見直し、具体化
の時間をとっておく。
リリースに向けた作業や、
フィードバックをふまえま修正なども
プロダクトバックログで管理する。
Posted by ブクログ
本書ではスクラム開発におけるロールやイベントが説明されており、
基本をおさえることができます。
スクラムの導入からプロダクトのリリースまでを
一つの物語として書かれており、
スクラム開発の流れを理解することもできます。
スクラム開発を行う上でよくある失敗やその対策も
あるのでスクラム開発を導入しようとしている組織には
おすすめの1冊だと思います。
Posted by ブクログ
It was nicer book to understand scrum as beginner. In fact, I also follow this book to start a scrum team as scrum master.
Posted by ブクログ
アジャイル開発とはどういうものか、プロダクト(社内システム)開発の流れを漫画を交えながらストーリー仕立てで解説してくれる。
耳慣れない用語や、イベント、役割なども一通り説明してくれるため、アジャイル開発の経験がない人にとってこれ一冊を読むことで一通りの知識を身につけることができる。
また知識がある人にとっても、開発中は必ず困難にぶち当たり、試行錯誤することが求められるのがアジャイルの常だが、実際に現場であるあるのことも取り上げられていたり、開発者目線での口語でわかりやすくツボを抑えた書き方をしているので、教科書としていつでも見返せるように手元に置いておきたい書籍となっている。
かくいう私はつい最近、初めて、且つ大規模なアジャイル開発を経験したばかりだったのだが、本書を見て改めて反省すべき点が多かったため、次回の開発ではその内容をしっかりカイゼンして臨みたいと思った。
Posted by ブクログ
スクラムチームにジョインすることになって数ヶ月、なんとなくイベントややることに慣れてきたけど、本当は何を気にしなきゃいけないんだっけ？と自信が無くなったこともあり読んでみた。
一冊でスクラムとはどういうものかというところから陥りがちな間違いまでがわかりやすくまとまっていて、自分の経験と照らし合わせながらなるほどなあと読むことができた。
ページ数の割に手軽に読めるので、初めてスクラムを実践する人には勧めたい一冊
Posted by ブクログ
知識を詰め込むのではなく、漫画でイメージしやすいシナリオが表現されており、自組織でのスクラムの運用をイメージしやすい。
スクラムについて知りたい、スクラムを始めたい人に最初の一冊として勧めたい。
Posted by ブクログ
スクラム開発がどのようなものかどのように進めるのかざっと知るには適した本だと思います。
私は、スクラム開発におけるドキュメント作成の重みはどうなるのか、追加開発によるデグレの工数はどう考えてるのか、運用が始まった後の故障対応はどの程度の優先事項なのかの考え方を知りたかったのですが、そういうことは書かれてませんでした。
Posted by ブクログ
失敗を学ぶチームになる
チームの課題を解決すためにチームがやりたいことを出来る環境を整える
チームが気づきを得られるように日頃のイベントをみんなで参加する
Posted by ブクログ
読むの2回目だけど、実践部分と概念の説明のバランスが良く非常に良著。
より深掘りした本はあるだろうが、
「どれか一冊で全部」ってことならスクラム開発のバイブルと言って良いと思う。
アジャイル、スクラムの全ての手法をトレースしようとは思わないけど、根っこにある
・プロジェクトは先行き不透明なもの
・だから重要なものから確実にfixさせて次に進もう
という考え方は全面的に同意…。
Posted by ブクログ
挿絵やマンガ形式の箇所もあり楽しく読めました。
知識としては聞いたことがあった内容を、具体例で説明してくれているので想像しやすかったです。(本のようにうまく行くのかは置いておいて)
アジャイルっぽい開発もかじった事があったので、よりイメージつきやすかったと感じました。
導入には良い本でなのでは無いかと思いました。
Posted by ブクログ
アジャイル開発に関してはアジャイルサムライを読んでざっくり理解して普段から行なっていたが、各役割の名前、各イベントの名前などは抜け落ちていたので改めて把握するいい機会になった。
また、開発メンバーへの教育に関しても考えさせられるいい書だった。
機能要望と実際のメンバーの力量や残工数のバランス取りが難しいなーと感じていたが、
本書で言われている、プロダクトオーナー兼スクラムマスターはあまり良くないという状況にまさに合致していることに気がつかされた。
メンバーの設計力や俯瞰力を考えるとなかなか任せにくい状況なのだが、なんとかスクラムマスターとして動ける人を育てられるようにしたい。
また、自分のチームを振り返ると、自己組織化されたチームにはできていない。
全員に心構えやどういうチームにしていきたいかを発信していけると良さそうだと感じた。
Posted by ブクログ
本書は、日本におけるスクラムのスタンダード、教科書であると位置づけられるであろう。
スクラムの定義は、「スクラムガイド」で読むことはできる。しかし、それだけで、実際のソフトウェア開発を進めるのは厳しいだろう。その時、次に手に取るべき書として、本書を強くお勧めする。スクラムの入門者は、「スクラムガイド」と本書を片手に進めるのが王道になるであろう。さらにスクラムの背景や、各スクラムイベントを深めたい場合に、別の書に当たればいいと思う。
日本のスクラム実践のために、本書を世に送り出してくれた著者の方々に感謝します。
Posted by ブクログ
スクラムという手法が、漫画でわかりやすく説明されており為になった。
プログラミングだけでなく、仕事に関するプロジェクトの進め方として、作業項目のリスト化、優先順位付け、作業工数等を見える化する点や、都度成果物を短期サイクルでレビューする事で、高速で成果物を完成させる良い手法の参考になりました。
Posted by ブクログ
実践編が充実しており、初期知識習得の読物としてとーってもわかりやすかったです。マンガつきでキャッチーですし。
個人的には、プロダクトバックログで管理する粒度と、スプリントプランニングでのやることが具合的にイメージできて有益でした。
Posted by ブクログ
スクラムlikeから、本格的にスクラムをやってみたいと思って読んだ本 (N氏オススメ)
ストーリ調で分かりやすく、頭に入ってきやすかった。
全体像を掴むには大変いい本だと思った。
# 面白tips
- リリースレゴ: リリースの度に、レゴ組み立ていく
- モブプログラミング: みんなでコーディング
# 細かい疑問点
- 運用フェーズでは、結構問合せタスクだったりなど飛び込み入ってくるがそれにはどのように対策するのか
- スプリントゴールに関係してないけど、これは3hで終わるしやっておいた方がよくない的なやつの扱い方
- ユーザストーリでプロダクトバックログ切っていくと、非機能要件的なものは優先度下がったり漏れちゃいそう
Posted by ブクログ
アジャイルサムライを読んで市谷さんがカイゼンジャーニーを書いたように、西村さん達はこの本を書いたのかな。
アジャイルサムライではハードルが高すぎたり、つまずきやすい点のフォローが不足しているのをカバーするには
どうしたらよいかを考え、実際によく詰まりやすい事例を示し、 実践に適用しやすいシナリオで解説されている。
初心者にもわかりやすい順で言えば、この本、カイゼンジャーニー、アジャイルサムライの順なのかもしれないが、
人それぞれ経験やわかりやすさも違うだろうから読む順番とかどれがベストかは決めづらいかな。
アジャイルサムライで全て理解できていたとしても、それぞれの書籍に新たな発見はありそうだし。
プチョーはなにやってんのかなーと思いつつ、みんなで同意して残業してやりきるのってちょっとうらやましい。ブラックかなと思いつつも胸が熱くなる。
Posted by ブクログ
スクラム聞いたことはあるけど、実際にどんな感じで進めるのかよく知らない人にぜひ読んでほしい本。
スクラムを実践していく過程で発生するイベントや問題について、具体例をもとに解説していて理解しやすい。漫画つきなのも、手軽に読みやすくて良い。
2017年度版スクラムガイドに合わせて改定されている点も嬉しい。
Posted by ブクログ
SCRUM BOOT CAMP THE BOOK
エンジニアである西村直人 氏、永瀬美穂 氏、吉羽龍太郎 氏の著書です。
スクラムに関する入門書です。
【本書で学べること・考えること】
- 基礎編
・スクラムの概要
・スクラムのルール
・スクラムの流れ
- 実践編
・プロジェクトオーナーの決め方
・ゴールとミッション
・プロダクトバックログの作り方
・見積り
・スプリントバックログの作り方
・デイリースクラムの進め方
・完成の定義
・問題点の早期発見、見える化
読んでみての感想です。
アジャイル開発に関しては初めて学びましたが、わかりやすかったです。
理論だけより、実際の開発ケースを想定したストーリーになっているので、想像力が働きました。
ただ、実際に取り組んでみないと本当に理解することはできないと思います。
始める前の知識をインプットするのに適した本です。
実務経験や開発経験がないとピンとこないかもしれないので、実務経験を積んでから読んだ方が良いかもしれません。
Posted by ブクログ
特に、プロダクトオーナーとスクラムマスターを兼任するのは絶対にダメだ。プロダクトオーナーは作るものをより良くすることに注力しないといけないので、開発チームに、もっとたくさん作ってほしいとかもっと作りこんでほしいというプレッシャーを無意識のうちにかけてしまうかもしれない。一方で、スクラムマスターは円滑に仕事を進めていきたいので、開発チームが無理している状態を見過ごすわけにはいかない。無理をしている状態が続けば、長期的にうまくいかなくなってしまうからだ。
■完成の定義の一例
・デモ手順の通りに動作する
・publicメソッドのテストコードがある
・調査した内容はWikiにまとめてある
・最新の仕様がWikiにまとめてある
・リポジトリからいつでも最新のデモ可能でテスト済みのソフトウェアが取得できる
スクラムチームを常に良い状態にしておくのがスクラムマスターの役目だ。スクラムチームを観察して、どこがうまくいっていないかを見つけよう。扱いにくいコードの場合でも、どこかに予兆はあったはずだ。
たとえば、その予兆は書いたコードからもわかる。どうみても良いコードではないのに誰も話題にしていないとか、ほかにも、開発チームが残業続きなのにスプリントプランニングでさらに多くの項目をやろうとしていることかもそうだ。こうしたことを見逃さないように工夫をしてみよう。実際、何時まで開発作業をしているかとか、テストコードが増えているかを測る仕組みを自動化しているスクラムチームもあるんだ。こういう仕組みはスクラムマスターが率先して準備しよう。良くない状態の開発チームは、こういうことに割く時間さえ作れないかもしれないからだ。
■リリーススプリント
…スクラムを始めたばかりのスクラムチームが採用することが多い。これは通常のスプリントが終わったあとに、リリースに必要な作業を片づけるための時間を最後にまとめて取るやり方だ。通常のスプリントとは違って、その期間のことをリリーススプリントと呼んでいるだけで、やり方はとくに決まっていない。スクラムイベントも必要なければやらなくていい。
スクラムで大人数による開発はできるのだろうか？作るものの規模が大きければ開発する人の数も多くしたくなるだろうが、スクラムでは開発チームの人数は３～９人の少人数が適切とされている。
■ボクくんがスクラムのプロジェクトを通じて気づいたこと
・ロールは単なる目印
・開発を進めるうえで大切だと思うことは何でも話し合っておく
・スクラムチーム全員がプロダクトバックログについて知っておく
・見積りは推測
・自分たちの作業は自分たちで見積もる
・ベロシティがわかれば、先の見通しが見えてくる
・スプリントプランニングでは確実に終わらせられる計画を作る
・スプリントゴールを守るために毎日検査する
・問題になる前に見つけて対応する
・完成の定義は、スクラムチームで合意する
・タイムボックスに入るようにしていくのが重要
・プロダクトバックログの順序は常に見直しておく
・自分たちの責務について理解しないとうまくいかない
・ベロシティはあくまで目安
・ロールで担当する部分を分けているので、どこに問題があるかわかる
・頻繁に話し合って伝えていくのが一番大事
・スクラムマスターがスクラムチームを良い状態に保つ
・障害に順序をつけてどれを優先的に解決するかを明らかにしておく
・スクラムチームの進む先をいつも明確にするために整理し続ける
・スプリントの準備は開発をうまく進めるうえで不可欠
・実現方法を工夫するのはスクラムチームにとってやりやすい調整の仕方
・全員でさまざまな状況を克服できるようにしておく
・責任を持って取り組んでいくのが大事
・なんでもリリーススプリントに回すのは良くないこと
・スクラムは体験して学んでいくための仕組み
