読了 SCRUM BOOT CAMP
- 作者: 西村直人,永瀬美穂,吉羽龍太郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/02/13
- メディア: 単行本（ソフトカバー）
- 購入: 5人 クリック: 13回
- この商品を含むブログ (33件) を見る
読んだのでアウトプットしておく
スクラムとは
- プロダクトをチームで作り上げる
- プロジェクトの透明性を大切にする
- プロダクト小さく作って育てていく ためのメソッド
ウォーターフォルと比較
- ウォーターフォルはタスクで担当が決められて分業なイメージ、スクラムは全員がプロダクトに責任を持つスタイル
- ウォーターフォールはリーダーが管理するスタイル、スクラムは全員がプロダクトの方向性や機能の背景、要件を知りかつプロジェクトの状況も把握し課題があったらチームで解決する
- 要件がかっちり決められたらウォーターフォール、それができない新しいプロダクト、未来がわからないものについてはスクラム
メソッド
- プロダクトバックログ：要求がすべて記載されているリスト。優先順位が高いものを上にもっていく。開発は上から順に実装していく。機能をどうつかうかというストーリー、テストができる具体的なレベルで記載する
- スプリント：2週間とか1ヶ月とかテンポを決めてプロダクトをシップする。期間を延長しない。
- スプリントバックログ：開発チームのためのタスク一覧
ロール
プロダクトオーナー
開発チーム
- プロダクトバックログの項目に従って開発していく
- 3-9人で構成される
- 上下関係なし
- スキルを補って全員で開発する
- スプリント期間を決め、その間にリリース判断 可能な成果物をアウトプットする
- プロダクトバックログからタスクとして切り出して、スプリントバックログを作る
- デイリースクラム：昨日やったこと、今日やること、困ってることを簡潔に共有する
スクラムマスター
- プロジェクトがうまくまわるようにサポートする
- 妨害を排除し、支援し、スクラムについて教育する
- プロジェクト効率的に進めるために妨害リストを作って、課題を解決していく
- PMとしてスケジュール管理するS
プロジェクトのキックオフ
インセプションデッキやビジネスモデルキャンバスを使って、チームないでプロジェクトに関する共通認識をもっておく
見積もり
プロジェクトがいつ終わるか、どれくらいの工数がかかるかを見積もるにはプロダクトバックログを利用する プロダクトバックログには、要件がまとまってるので、どれくらい開発がひつようか、1つ1つの項目に対して行なって合計をみる 開発チームが見積もるのがよい、この機能を開発するにはどれくらいか、1から10で数値化する あとはスプリント1回でどれくらいのポイントを消化できるかがわかれば、必要な期間、期間に合わせて人数がどれくらい必要かを見積もることができる
ただし、マニュアル作成やリリースにかかる作業が見積もりから漏れることがある マニュアルやリリース、インフラ構築など非機能要件、マーケティング活動につても最初から検討できるとよい
リリース作業が見積もれない場合は、スプリント以外のスケジュールとしてリリース期間を設ける
ルールはチームで決める
- デイリースクラムの目的とルール
- リリースに関するルール
- などなど チームで決めることで、なぜこのルールが必要かの共通認識を持つつともに、ルールに問題があればチームで改善できる
進捗アップするには？
スケジュールを前倒ししたいと言われても簡単ではない 前倒しするには人を増やすことで可能だが、スクラムに慣れる、チームに慣れることが前提になるため時間がかかる
技術的負債
プロジェクトを進めていくと必ず発生する これをいつ返すか、必ず悩む時期がくる 技術的負債を理解した上でプロジェクトを進める必要がある
スコープの調整
リリース前にスケジュールが間に合わない可能性が出てきたらどうする？ 予算、期間、スコープで調整する ただ、まずスコープを再度検討することからはじめる 最低限の要件を満たすようにする、必要な機能に対し優先順位を決める、ユーザーの要件を満たすようにしながら不要な機能をけずる、実現方式をかえて簡単な実装に変更するなど
開発チームでのスキルマップ
全員がなんでもできるわけではないので、スキルマップを作って得意不得意を見える化し、得意なことでチームに貢献できるような仕組みを作ろう
規模が大きい場合の開発
規模が大きい開発でスクラムをやるには、スクラムチームを複数作って対応していく マイクロサービス化し、システムを分割してスクラムチームを作る
