スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス

投稿元：

レビューを見る

実践で培われたノウハウ盛りだくさんです。
スクラムを始めたけどイマイチしっくりこない方に特におすすめ。
一方で、ノウハウ満載なゆえ、考えずにマネすると怖そうな部分もありました。
マネするのと同時に、スクラムの背景にある考え方と照らし合わせて理解し、自分たちの課題を解決するか確認しながら使うと、より良い結果につながると感じました

投稿元：

レビューを見る

最初は．スクラムの基本的な知識，スクラムが用意するメソドロジーについて著名な書物の引用などをはさみながら簡単に解説する．このパートはインデックス論文的な感じで取っ掛かりとしては非常に良いパートでした．

次に GMO, mixi, DeNA のスクラム導入実例．特に DeNA が大規模開発にスクラムをどのように取り入れたかとかは，実践的であるがゆえに，実例からどのように教訓や理論の適用を見出すかが重要だけど，非常に興味深い実例が記載されていたと思います．

最後に，ありがちなスクラムでのトラブルシュート．ここらへんも著者陣が実際に直面した経験などを元に書かれていて，教科書的でありながら非常にわかりやすい指針となりそうなレシピ集となっていました．

投稿元：

レビューを見る

読んでいると心が痛くなってくるけどとてもよい本だった〜！1度読んで終わりよりも、定期的に読むべき本だなあと思うので、電子版買おう〜（あるのかな）

投稿元：

レビューを見る

可能な限り価値の高いプロダクトを生産的かつ創造的に届けるため: Meet Up 大阪 @ blog
http://meetuposaka.seesaa.net/article/429269446.html

投稿元：

レビューを見る

感想をブログに書いてみました。

http://blog.a-know.me/entry/2016/05/08/230331

投稿元：

レビューを見る

これからスクラム開発を始めようとしている人、現在進行形でスクラム開発を行っている人、どちらでもためになる内容が本書には書かれている。

各スクラムの意図の説明から、各社の事例、よく起きる問題の順に記載されており、順を追って読んでも必要な箇所だけ読んでもOK。
自分は現在進行形でやっているため、9章から12章の問題事例と対策がまさにその通りと納得するものばかりだった。

何か困ったときのリファレンスとして時々見返したい本。

投稿元：

レビューを見る

定義から始まって、実例や、問題点とその解決方法などが具体的に書いてあり、スクラムを導入するなら非常に役に立ちそうな一冊。

投稿元：

レビューを見る

実際にスクラム体制でソフトウェア開発をしており、スクラムについて、よく勉強しないまま、進めていました。
いままでのアジャイル・スクラム開発の書籍に比べ、わかりやすい言葉で整理されてます。一度で理解できるわけではなく、手元に置いて何度か読んで理解を深めていきたい。

投稿元：

レビューを見る

【一口感想】
　「アジャイル開発手法のひとつである『Scrum』のポイントと日本での実例を把握するのには最適」

【３行要約】
　・前半はスクラムそのものの解説、中盤は日本での実例、後半はよくある疑問やポイント
　・スクラムの解説は必要十分
　・リファレンスというよりは概要を掴む資料としての本

【所感】

会社の書庫にあったものを流し読みしただけ。
スクラムの概要を掴む目的として前半だけなら３０分、後半と合わせても１時間もかからない。
中盤の実例はお好みで。

実践入門とあるが、実際にこの書籍だけで完全にスクラムを履行できるとはすこし考えにくい。
スクラムの根底にある部分であったり、具体的な導入イメージがちょっと掴みにくい。
またどこでハマりやすいとか、必ずぶつかる壁や訪れるステップみたいなものも同様だった。

そういう意味でこの本は、いわゆる「管理者層」が「スクラムのイメージを掴む」という意味では最適の本かもしれない。逆に実際に現場でスクラムを導入したいと考えているリーダーや現場のメンバーが、未経験者ながらこの本一冊のみでプロジェクトにスクラムを導入するのはちょっと厳しい気がする。この本をきっかけとして概要を知り、詳しいところを抑えるには別の本も必要ではないだろうか。

ただ、やはりスクラムを正しくチームに導入したいならアジャイルコーチの存在は必須だとは思う。

投稿元：

レビューを見る

スクラムという言葉を使うことになった由来が日本の論文でもあったことは知らなかった。ラグビーの試合も思い出すとなるほど確かにと思う表現ではある。複雑で変化の大きないまの時代に知っておくべき方法論だが、実践は簡単ではない。トライ＆エラーを積み重ねていく必要はあるし、またやはりどの開発方式を取るにしろ、プロダクトオーナーの役割や、関係者とのコミュニケーションの重要性は変わらない。

投稿元：

レビューを見る

　スクラムのお勉強。

■組織パターン
　繰り返し発生する構造的な形で、あるコンテキストにおける問題を解決するもの。何らかの全体の全体性あるいはシステムに寄与し、美的あるいは文化的な価値を反映する。

■パターンのフォーマット
・状況
・問題
・空気
・解決

■インセプションデッキの10の課題
・我われはなぜここにいるのか？
・エレベーターピッチを作る
・パッケージデザインを作る
・やらないことリストを作る
・「ご近所さん」を探せ
・解決案を描く
・夜も眠れなくなるような問題は何だろう？
・期間を見極める
・何を諦めるのかをはっきりさせる
・何がどれだけ必要なのか

■ユーザーストーリー
　「〈ユーザー〉として、〈達成したいゴール〉したい。なぜなら〈理由〉だからだ」というフォーマットで要求をシンプルかつ簡潔に記述し、プロダクトオーナー側と開発チーム側との対話を促進するプラクティス。

　ユーザーストーリーは、機能の細部を表現できるほどの情報量を持つことができません。そのため、実際にどのような画面になるのか、どのような挙動をするのかという情報は、文章に頼らず、プロダクトオーナーと開発チームの会話を通じて引き出されることになります。この過程を経ることで、プロダクトオーナーの意見だけでなく、開発チームの持つ経験や知識もプロダクトに反映させることができ、プロダクトの品質向上につながります。
　良いユーザストーリーを作るには、INVEST(Independent:独立している、Negotiable:調整可能である、Valuable:ビジネス価値がある、Estimable:見積り可能である、Small:手ごろなサイズである、Tastable:テストが可能である)を満たすとよいとされています。

投稿元：

レビューを見る

一旦前半のスクラム開発の説明まで。スクラム開発そのものの説明が薄いものの、きっと後半の事例紹介は貴重

投稿元：

レビューを見る

複数の企業のスクラムの導入事例とよくある問題への解決策が書かれている。導入の壁にあたった時には、これらの解決策はスクラムマスターには救いのように感じるだろうと思うが、実際はこれらは解決策ではなくて対応例だろう。
組織固有の複雑な事情もあるだろうし、所属する組織や事業の特性や一緒に働いている一人一人に目を向けてた上で、責任をもって問題に対応しフィードバックを見て判断するのは自分であるということを忘れないようにしたい。本の感想というか、自戒を込めて。