SCRUM BOOT CAMP THE BOOK: スクラムチームではじめるアジャイル開発

著者 :
  • 翔泳社
4.08
  • (83)
  • (111)
  • (51)
  • (4)
  • (1)
本棚登録 : 937
感想 : 111
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・本 (278ページ)
  • / ISBN・EAN: 9784798129716

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • 2015.2.25読了

    スクラムでもプロジェクトのゴールやミッションは大事 ➡︎インセプションデッキをつくる

    スクラムチーム全員がプロジェクトについて十分知っておく

    プロダクトバックログは、最初に重要な項目が漏れないようにしていく

    全体は大雑把な順序をつけておいて、直近は詳細に順序をつける

    見積もりの基準は、作業の量として真ん中くらいの項目がいい

    見積もりは推測
    詳細にするのは直近のものだけにしておく

    見積もりポーカー、話し合うことであいまいなことが明確になる

    ベロシティがわかるとプロジェクトの先が見えてくる

    スプリント計画会議、第一部ではどうなったら終わりかも決めておく
    第二部は本当に達成できるか考える
    確実に終わらせられる計画を立てる、確実な計画をつくるための活動

    デイリースクラムは、スプリントのゴールを守るための毎日の検査

    スプリントレビュー
    デモを見ると終わったかどうかと本当にどうすべきがわかる
    完了の定義はスクラムチームで合意する

    問題になる前に見つけて対応する
    タスクボードを使えばタスクの状況を把握できる
    いろんなことを透明にできる

    タイムボックスはゆずれない
    予測に使う
    タイムボックスに入るようにしていく

    次にやることはだれもが知っている
    プロダクトバックログの順序は常に見直していく
    直近の項目の順序が一番重要
    順序を決定するのはプロダクトオーナーの大切な仕事

    人を増やしてもすぐにベロシティはあがらない
    より作業をうまく進められればベロシティはあがる
    でもベロシティはあくまで目安

    プロダクトオーナーと開発チームとでは責任を持つ部分が違うので誤解が生じやすい
    ユーザーストーリーでは、なぜそれが必要なのかその理由を明確に書かないといけない
    少なくとも実現したいことの意図は書かないとダメ
    ユーザーストーリーをわざと短く書くことによって、実現したいことについてチームが話す機会を持つようにしている

    スクラムマスターがスクラムチームを良い状態に保つ

    もっと良い状態にできない原因が妨害で、それを管理しておく
    妨害はリストにしてどれを優先的に解決するかを明らかにしておく



    プロジェクトの進む先をいつも明確にするためにプロダクトバックログを整理し続ける
    プロダクトバックログの手入れを定期的なイベントにしておくといい

    実現したいことがあいまいだといろいろ問題が出てくる
    直近のスプリントの分だけあいまいなことをなくせばよい
    スプリントの準備はプロジェクトをうまく進める上で不可欠
    スプリント期間中に準備の作業をできるようにしておく

    プロジェクトで調整できるものは4つ
    品質、予算、期間、スコープ
    品質は常に一定じゃないといけないので調整できない
    どう実現するかを調整するのもスコープの調整
    実現方法を工夫するのはスクラムチームにとってやりやすい調整のしかた

    状況に応じて誰かがリーダーシップを発揮していく
    開発チームのスキルを理解しておく
    全員でさまざまな状況を克服できるようにしていく
    得意な作業だけやっててもダメ

    実際の作業に関係ない人の意見は参考意見

    スクラムは問題を見つけやすいやり方
    もっと良いものをつくっていくためにカイゼンが大事
    プロジェクトの問題を見つけられるのは現場の人たちだけ

  • SCRUMのエッセンスはわかった。

    使うことがないのでこのくらいにする。

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

  • これはとても面白い。スクラムを用いたプロジェクトについて、漫画を用いてかなりソフトなタッチで書きつつ、実際にやってみた時に悩むであろう数々のポイントについてアドバイスを書いている。まさに実践の手引き。こういう本が出るくらいにはスクラムも普及したということなのだろうか。一番の入門書として読むのは適さないかもしれないが、スクラムが何を目指してやろうとしているのかを把握した後に必ず浮かぶ「とはいえ現場でどうやるの」という点に出会ったら読むのが最適。

    例えばデイリースクラムがスクラムマスターへの単なる報告会になってしまったら目的を改めて理解すること(p.122ff)、スプリント内のタスクが早めに終わってしまったらバックログの次のタスクにとりかかること(p.156ff)、デイリースクラムに全員が参加できないならチームの責務を理解し直すこと(p.164ff)、プロダクトオーナーが参加できなくても小さく時間を確保すること(p.180ff)など。他にもユーザーストーリーにはそれが必要な理由をきちんと明記し、スクラムチーム内の理解を促進すること(p.190f)、チームを自己組織化してそれぞれがリードを取れるようになること(p.235f)などが目にとまる。

    スクラムに限らず、アジャイル開発全般に渡って思うのは、失敗を許容し、学習することの重要性だ(p.245f)。逆に言えばこのポイントが守れない組織ではアジャイルで回すのは難しい。他に感じたのは、この本のように優秀なプロダクトオーナーを確保するのはかなり難しいであろうこと。それから大規模開発の難しさ。スクラムチームを構成するのはせいぜい10人までで、大規模ではチームを分割するが、それぞれがスクラムに慣れてなければ止めておけと記されている(p.259ff)。

    それにしてもこんな風にプロジェクトができたら楽しいだろうな。Water-Scrum-Fallでもいいからやってみたいものだ。

  • アプリ開発手法の説明本。最近読んだ、フランクリン・コヴィーの戦略推進プロセスと、基本は同じ。経営学の影響を受けているのかと思っていたら、基本となる構想は、あの、野中郁次郎先生!ちなみにこの「スクラム」という名前も元は先生が名付けたものらしい。恐るべし、野中先生の影響力。

  • 【目的】 Scrumを始めようと考えている人に対しては、Scrumを始めるまでに一通り必要なことを伝える。Scrumを既に始めている人に対しては、悩んでいることへの解決の糸口やより成果を出すために身に付けるべきことを伝える。

    【収穫】 アジャイル開発を全く知らない状態から、どのように開発を進めていくか雰囲気を感じ取ることができた。

    【概要】 本書はアジャイル開発の手法の1つであるScrumについて、基礎編と実践編を通して、以下のことを学べるようにしている。
    ①全体像と決められているルールについて
    ②プロジェクトをうまく進めていくためのポイント
    ③自分の現場でうまく取り入れていくためのポイント
    うまく進めていくためのポイントとしては、例えば以下のようなものが紹介されている。
    ・スプリントバーンダウンチャートにスプリントレビューに出せばいい項目の見積もりポイントの合計をプロットしていくことで、タスクが順調に進んでいることを明確にする。
    ・開発を進めていく上で必要なスキルの見落としがないように、チームメンバと必要スキルのマトリックスを作成する。
    ・スクラムイベントを継続して全員で進めていくために、全員で合意したルールを目に見えるところに明文化して貼っておく

    【感想】 新規案件にてScrumを導入した開発に関わる可能性ができたことから、基礎知識を身に付けるために読んでみた。類書に比べ、漫画を使うことでわかりやすく解説しているが、決して内容は薄くない。実際にアジャイル型開発の経験がある人によれば、まさに本書で紹介されているケースのイメージとのことだったため、アジャイル開発に向けた初めの一冊としておすすめ。

  • 再読しました。

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

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

  • ブチョーがかわいいw

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

全111件中 61 - 70件を表示

西村直人の作品

  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×