スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

  • 技術評論社
3.81
  • (13)
  • (22)
  • (15)
  • (4)
  • (0)
本棚登録 : 302
感想 : 21
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・本 (240ページ)
  • / ISBN・EAN: 9784774172361

作品紹介・あらすじ

複雑で変化の激しい問題に強いチームで立ち向かう。要求、見積り、進捗、問題を可視化する。ふりかえりとレビューにより、改善を繰り返す。属人化を解消し、チーム全体を成長させる。導入時に起こりがちな失敗を回避する。DeNA、GMOペパボ、mixiのノウハウを凝縮。

感想・レビュー・書評

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

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

  •  スクラムのお勉強。

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

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

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

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

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

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

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

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

    <b>【所感】</b>

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

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

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

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

  • スクラムを実践するときの経験談が一通り入っていて参考になる。

    [more]

    - スクラム
    - アジャイル開発手法のひとつ。
    - 「理解は容易だが習得は困難」と言われる。解決策そのものではなく手助けだから。

    - 構成
    - 1-4章 スクラムの背景・基本ルール
    - 5章 汎用的プラクティス
    - 6-8章 事例:GMOパペポ、mixi,DeNA
    - 9-12章 問題と解決策

    ## 1-4章 スクラムの背景・基本ルール
    ### ソフトウェア開発の困難
    - ソフトウェアの不可視性。
    - 問題の分解・整理: 5W1H (Who,What,When,Where,Why,How)
    - スクラムの定義: 複雑で変化の激しい問題に対応するフレームワーク
    - ラグビーのスクラムに由来
    - 野中・竹内の論文1986に由来
    - 野中・竹内の論文1986 The New New Product Development Game
    - 新製品開発の手法は2種: リレー競争型、ラグビー型
    - スクラム
    - 問題に経験主義で対処する
    - スプリント:一定期間で区切って反復
    - リーダーシップは2種: プロダクトオーナー(What)、スクラムマスター(How)
    - まとめ

    | | 意味 | 性質 | 領域 | 検査 | 役割 | リーダーシップ特性 |
    |----|---------|-----------|---------|----------------------|----------|--------------------|
    |What|何を |複雑 |プロダクト|スプリントレビュー |プロダクトオーナー|課題達成志向|
    |How |どうやって|変化が激しい |プロセス |スプリントレトロスペクティブ|スクラムマスター |人間関係志向|

    ### スクラムチーム
    - 自己組織化 Self-organization
    - 外からの指示ではなく自分たちで最善策を選択する。
    - 自分たちで能動的に学習と成長をし続ける
    - 3つのロール
    - プロダクトオーナー : プロダクトの責任者。優先順位付け。チームに一人。本来チームから独立。
    - 開発チーム : 3〜8人が望ましい。職書の違いによっては区別されない。サブグループなし。
    - スクラムマスター: サーバントリーダー。チームに一人。
    - ステークホルダー : チームには属さないが影響を及ぼす関係者

    ### スクラムイベント
    - 5つのイベント

    1. スプリント
    - 開発期間の1単位。XPならイテレーションと呼ぶ。
    - 1週間から1ヶ月。 Webサービス系だと1or2週間が多い。
    - 一度決めたら延長しない。
    - 理想的にはスプリント毎にリリースできるように。
    2. スプリントプランニング
    - スプリント開始時のMTG。何ができるか、どうやって達成するか。
    - タイムボックスは、1週間スプリントでも1-2時間。Max8時間。
    - リファインメント(グルーミング): バックログの整理
    - ベロシティ: チームがスプリントで達成できる仕事量。
    3. デイリースクラム
    - 1日1回15分のMTG。朝会、スタンドアップMTG。
    - 昨日したこと、今日やること、困っていることを話す。
    - 15分で終わらなければ関係者を絞って二次会
    4. スプリントレビュー
    - プロダクトインクリメントの確認とフィードバックを得るMTG
    - 動くデモ。
    5. スプリントレトロスペクティヴ
    - 振り返りMTG。1時間程度。
    - KPT(ケプト) Keep Problem Try

    - スプリント・ゼロ
    - 開発の前段階
    - ビジネスモデルの仮説。リーンキャンバス。
    - プロダクトを作る理由と実現方法
    - インセプションデッキ。プロジェクト憲章。
    - チーム作りのワークショップ。マシュマロチャレンジ。
    - 開発環境の準備。Git,CI,Chat,など
    - プロダクトバックログ
    - リリーススプリント
    - リリース前の仕上げスプリント

    ### スクラムの作成物
    3つの作成物
    1. プロダクトバックログ
    - プロダクトで実現したいことを優先順位付けしたリスト
    - ユーザストーリーで表現すると簡潔。 Who, What, Why
    2. スプリントバックログ
    - スプリント期間内で行うと判断したプロダクトバックログアイテムとタスク
    - タスクボードで可視化。
    - ToDo(未着手)、Doing、Done
    3. インクリメント
    - リリース可能なプロダクト

    ## 5章 汎用的プラクティス
    - インセプションデッキ: 10の課題への回答を通じて、プロダクトへの共通理解を得るプラクティス
    - 我々はなぜここにいるのか? :プロダクトの作成に取り組む理由を明らかに
    - エレベータピッチを作る : ターゲットユーザや競合を明らかに
    - パッケージデザインを作る
    - やらないことリストを作る
    - 「ご近所さん」を探せ : ステークホルダーの中から依頼しそうな人物を洗い出す
    - 解決案を描く
    - 夜も眠れなくなるような問題は何だろう?
    - 期間を見極める
    - 何を諦めるのかをはっきりさせる
    - 何がどれだけ必要なのか
    - リーンキャンバス
    - ユーザストーリー
    - 良いユーザストーリーには、INVEST を満たす
    - Independent :独立している
    - Nogotiable :調整可能である
    - Valuable :ビジネス価値がある
    - Estimable :見積もり可能である
    - Small :手頃なサイズ
    - Testable :テスト可能
    - ユーザストーリーマッピング
    - ユーザストーリーを「時系列にそったユーザ行動」「実装の優先順位」の2軸で整理
    - プランニングポーカー
    - 見積もりを行うプラクティス
    - フィボナッチ数列のカードを用いる。 0,1,2,3,5,8,13,...
    - 全員が詳細までイメージできるバックログアイテムに「2」を割り当てる。※ 絶対値の正規化
    - アイテム毎にカードを出す。一致ならOK
    - 不一致なら、最大値と最小値の人が見解を述べる。
    - 3回繰り返してもまとまらなかったら、平均値 or 最大値を採用する。
    - スパイク
    - 見積もりできない項目の事前調査をスパイクと呼ぶ。
    - 数日間を上限に調査を行い、その後にバックログ更新や新計画へ
    - KPT
    - レトロスペクティブの方法の一つ
    - Keep 良かったこと。続けたいこと
    - Problem 困ったこと。改善したいこと
    - Try より延ばす案や改善案。

    ## 6-8章 事例:GMOパペポ、mixi,DeNA
    ### GMOパペポ
    - 作業の属人化を防ぎたい
    ### mixi
    - 作業の属人化を防ぎたい
    ### DeNA
    - 優先順位を決めたい。
    - 大規模スクラム開発へ。
    - スクラムマスターは専任化(複数のチームをみる)

    ## 9-12章 問題と解決策
    - 適切な優先順位を付けるには
    - ポイントを絞る。AとBのどちらを先に終わらせるか?
    - 投資対効果で決める(ROI)
    - サポートチームをつける。優先順位付けの材料集めのサポート
    - スクラムマスターがスクラムの奴隷化
    - 次の発言が増えたら注意。
    - 「○○はスクラムではないのでダメだ」
    - 「スクラム的には○○であるべきだ」
    - 目的の整理フレームワーク GR(R)OW モデル
    - G Goal 目標 目指したいゴールは?
    - R Reallity 現状 ゴールと現状とのギャップ
    - R Resources 資源 手を貸してくれる人や情報源は
    - O Options 選択肢 とれる打ち手は
    - W Will 意思 すぐにやった方が良さそうか
    - ロールの兼任による問題
    - スクラムマスターとプロダクトオーナーは兼任するな
    - スクラムマスターと開発チームの兼任するな
    - スクラムマスターのリソース活用なら複数チームのマスター兼任
    - 1-3チームの兼任
    - こなせる作業量を見積もれない
    - ベロシティを測定する
    - 1日5-6時間使えるとして見積もるチームが多い。

    eof

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

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

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

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

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

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

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

全21件中 1 - 10件を表示

貝瀬岳志の作品

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
宮下 剛輔
有効な右矢印 無効な右矢印
  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×