スクラム開発について勉強しよう!
ある時、ぴこーん! となりました。
同人サークルでもスクラム開発できないかなあ。
でもスクラム開発のことは、小さなチームで短い期間でがんがんリリースするから差分少なくて安全な開発ぐらいにか考えてなくて、
きちんと勉強したほうが良さそうだなとおもって、早速本をかって勉強してみました。
スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)
- 作者: 貝瀬岳志,原田勝信,和島史典,栗林健太郎,柴田博志,家永英治
- 出版社/メーカー: 技術評論社
- 発売日: 2015/03/18
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
個人的なメモっぽくなってしまいましたが、
スクラムをまったく分からない人が、ざっとみるだけでも、スクラムの雰囲気が伝わってくる……といいな。
なぜ、スクラム開発なのか、どのようにスクラムチームを作るのか、スクラム開発は実際にどうやるのか、参考になれば。
ソフトウェア開発は困難すぎるけど、それをスクラム開発で立ち向かう!
ソフトウェア開発が困難ってどういうことだろう。
困難さを理解することで、その困難さにたいしてどのように「スクラム開発」が適応するかが分かる。
ソフトウェア開発における困難
- 本質的な困難の4つの性質
- 複雑性
ソフトウェアが、人間の作り出す最も複雑な構造物であること - 同調性
ソフトウェアが、現実世界の複雑性に対して同調(適応)する必要があること - 可変性
ソフトウェアが、常に変更という圧力にさらされていること - 不可視性
ソフトウェアは、目に見えないものであり、空間に埋め込むこともできないものであること
- 複雑性
- さらにこれらの本質的困難は解決不可能
- 不可視性という困難のために、開発者が複雑性に対処することがますます困難になり、さらには、変化し続けるソフトウェアを前にして、コミュニケーションに齟齬が生じてしまう。
不可視性によるさらなる困難
- ソフトウェアの不可視性:ソフトウェアの汎用性
開発する側にとってもユーザにとっても、機能的な広がりの限りのなさゆえに、その領域を確定しがたいという困難
- コミュニケーションの不可視性:ビジョンへの時間の影響
新鮮なビジョンに基づく、緊密なコミュニケーションとともに始まったソフトウェア開発において、時間が経つにつれ、当初の目的が次第にないがしろにされていってしまうのは、人間は物事を確実に記憶にとどめておくのが難しいという至極当然の理由による
では、この目に見えないソフトウェアとはどこにあるか
- ソフトウェアは人々の心の中に
それぞれの視点、立場、趣味嗜好、自己の能力や経験の範囲でソフトウェアを認識している
- ソフトウェアは人々のコミュニケーションの中に
各人の心の中に独立して存在する思いが、集団作業というコミュニケーションを通じて、時には齟齬をきたしたり衝突したりしながら、ソフトウェアの輪郭をおぼろげながらも浮かび上がらせる。
ソフトウェアの困難に立ち向かう
- 5W1Hによる問題の分解、整理
- 誰が
- 何を
- いつ
- どこで
- なぜ
- どのように
- Whatとしてのソフトウェア
5W1Hで分解、整理して得られた、Whatに関する下位問題を解決することは、ソフトウェアの見えなさに対する解決を与える事
- Howとしての開発プロセス
コミュニケーションは目に見えないという問題に解決を与える事
スクラムで複雑で変化の激しい問題に対応する
- 目的の不可実性、手段の不可実性
- 目的の不確実性:最終的なプロダクトのフィーチャーを取り巻く不確実性
- 手段の不確実性:プロダクトを開発するために用いられるプロセスやテクノロジーを取り巻く不確実性
この不確実性に対処する必要がある。
- スクラムは、複雑で変化の激しい問題に経験主義で対処する
- 経験主義に基づく問題解決のための反復的かつ漸進的な手法
- スプリント - 時間を一定に区切って反復する
スプリントは1週間から長くて1ヶ月。スプリントの最後には「スプリントレビュー」「スプリントレトロスペクティブ」と呼ばれるイベントを行い、計画遂行に対する評価を行う。複雑で変化の激しい問題においては、事前に何を作るべきかがすべて明らかになっていることはない。そのため内容によって工程を区切るのではなく時間によって区切り、繰り返し、少しずつ作成物を積み上げていく。
- WhatとHowにおける検査と適応
検査は、開発の結果としての作成物や開発プロセスに問題がないかどうかをチェックすること。適応は、もし問題があるとすればその解決を図ることでより良い開発を行えるようにすること
- スプリントレビュー
スプリントを通じて何を作り上げることができたのか、あるいはできなかったのかを検査し、その解決を図るイベント
- スプリントレトロスペクティブ
開発プロセスに問題があるとすればそれはなんであったのかを検査し、解決を図るイベント
- スクラムにおける役割
スクラムチームとは何か
- 自己組織化とは
システムダイナミックスの分野において、ある系が自ずから、不規律な状態から規律をもった状態へと、進化、変化していく様を表す
- スクラム文脈での自己組織化
自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。スクラムチームのメンバー全員がチームの理想とする姿を考え、その理想に向かって能動的に学習と成長をし続けている状態。
- スクラムチームのロール
プロダクトオーナー
- プロダクトオーナーは1人
1人にすることで責任を明らかにし、何を作るべきかやその優先順位を確実に決定する
- 開発チームからの独立
開発チームから独立させることで、スクラムチームが作ろうとしてりうプロダクトに妥協せず、かつ価値の最大化に努めることが可能となる
- プロダクトの完成に関わることはプロダクトオーナーだけがステークホルダーとやりとりを行い、作成するプロダクトの内容や要件の優先順位づけについてはプロダクトオーナーの責任で決定する。
- 要件の決定
プロダクトを価値あるもにとするために要件を作成、決定する。要件は優先順位に従って開発チームが作成する。作成されたプロダクトが決定した要件を満たしているか確認する責任がある
- 優先順位の管理
スクラムチームが実現すべき内容の優先順位の決定権は、プロダクトオーナーのみが有する。
開発チーム
- 開発チームとはなにか
プロダクトオーナーが決めた要件を、プロダクトオーナーが要求する順番に従って、プロダクトとして作り上げる専門家集団
- 開発チームは3人~8人
これ以上多いと、コミュニケーションパスが多くなる
- 機能横断的チームであること
機能横断的チームとは、チーム以外に頼らずに作業を成し遂げる能力を持っているチームのこと。
- 全員「開発者」
プログラマ、デザイナといった職種により区別されない。お互いの作業内容に壁を作らずに、協力しながらプロダクトを作り上げる
- リリース判断可能なプロダクトの開発
作成しているプロダクトをブラウザ上のデモとして動作させたり、プログラムの処理結果を表示させたりすることで、プロダクトオーナーにリリースできるかどうかを確認してもらう。
スクラムマスター
- スクラムマスターは1人
- プロダクトオーナーへの支援
プロダクトオーナーの優先順位の更新方法、ビジョン作成のためのワークショップなどを開催し支援する。
- 開発チームへの支援
開発チームが未熟な場合に、品質、自己組織化などをアドバイスする。
スクラムイベント
- 検査と適応で変化に対応する
透明性で明らかになった情報をもとに、問題を検知し対応すること。
スプリント
- スプリントとは何か
スクラムでの開発期間の1単位。スクラムチームは一定の期間のスプリントを繰り返し、その中でスクラムイベントや開発を行う。期間内はスクラムチーム全員がゴール達成に向けて集中することが重要。スプリントの期間は1週間から1ヶ月。もしスプリント期間内に予定していた仕事が完了していなくてもスプリント期間は延長しない。完了した仕事量を計測し続けることで、スクラムチームがスプリント期間で完了できる仕事量を推測できるようにする。
- タイムボックス
1週間のスプリント期間のように固定された期間のこと
- 通常のスプリント - リリース判断可能なプロダクトを作り続けるスプリント
- スプリントゼロ - 開発を始めるための特別なスプリント
開発の前段階を「スプリントゼロ」と呼ぶ- ビジネスモデルの仮説を立てる
顧客の課題を解決してビジネスとして成立するであろう仮説を立て、検証しながら、見込みユーザと関係を作ってプロダクトを育てる土壌をつくる - プロダクトを作る理由と実現方法を明らかにする
- プロダクトを作る背景や理由
- 期限内に達成したい目標
- プロジェクトの関係者とのコミュニケーション手段
- 実現するためのアーキテクチャ
- 目標を達成するための体制
- おおよその予算とスケジュール
- リスクと対策
- チーム作りのワークショップを行う
- 開発環境を準備する
- Pull Requestベースの開発ができる環境
- ユニットテストからエンドツーエンドテストまでの自動テスト環境
- CI環境
- HipChat/Slackなどを使った、人と人、人とマシンのコラボレーションを加速させるチャット環境
- Chef/Pupperなどのインフラ構築の自動化環境
- Capistrano/Fabricなどの自動デプロイ環境
- プロダクトバックログを準備し、完成の定義を決める
プロダクトバックログとはプロダクトで何を実現すべきかを優先順位を決めて一覧化したもの
- ビジネスモデルの仮説を立てる
- リリーススプリント - リリースをやりきるための特別なスプリント
リリーススプリントでは機能の追加や修正は行わない。リリース作業のみ- 各スプリントで積み残したテストの実装
- 各スプリントで積み残したドキュメントの整理
- リリースのリハーサル
- 本番へのリリース
- プレスリリースの発行
- リリース後にスクラムチームやプロダクトを見直す
スプリントプラニング - スプリントの計画を作る
- スプリントプラニングとは何か
スプリント開始時に「スプリント期間内で何ができるか」「どうやって達成させるか」の2点を明らかにさせるミーティング。スクラムチーム全員が参加してみんなで計画を立てる。スプリントプラニングもタイムボックスを設けて実施。スプリント期間が1ヶ月であれば最大8時間、スプリント期間が1週間であれば1~2時間が目安。
- リファインメント - スプリントプランニングの準備
次のスプリントで開発に着手できるように、プロダクトバックログを整理する活動。スプリングプランニングの数日前までに実施。
- リファインメントでプロダクトバックログアイテムの見積もりを行う
※プランニングポーカーは良く利用される
- リファインメントでプロダクトバックログアイテムの内容を具体化する
着手しやすいように手頃なサイズに分解したり、内容を具体化しておく。
- 直近のスプリントで着手予定のプロダクトバッグログアイテムを具体化することができれば、リファインメントは完了
- ベロシティに基づくスプリントゴールの設定
スプリントゴールとはスプリントで達成したいことやプロダクトバックログアイテム。ゴール設定はプロダクトバックログの優先順位の高い順にスプリント期間で完了できそうな範囲を選ぶ。達成可能かどうかはプロダクトオーナーと開発チームで会話。
- ベロシティ
スプリントゴールを設定する際に利用。1スプリントにスクラムチームが完成させられる作業量のこと。過去の実績からベロシティは算出。
- スプリントゴールの合意
完了したスプリントバックログを俯瞰し、達成可能なゴールなのかをあらためて開発チームで判断する。スプリントゴールは、プロダクトオーナー、開発チームの双方が納得いくものにする。
デイリースクラム - 日々の進捗、予定、問題を共有する
- 明るく元気な声であいさつ
表情の明るさや声のトーンはプロジェクトがうまくいっているかの指標になる。元気のないメンバーはサポートする。
- 昨日したこと、今日やること、困っていることを話す
特に困りごとや不安に感じていることを積極的にはなし、協力を仰ぐ。
- 日々のデイリースクラムを通じてスプリントゴールを達成できそうか開発チームで確認する
- 時間内に終わらなければ二次会を開催する
関係者に絞って、デイリースクラムの直後に臨時のミーティングを開く。
- 達成がむずかしい場合は、プロダクトオーナーに相談
スプリントレビュー - スプリントの成果を確認する
- スプリントレビューとは何か
スプリント期間中に作成したリリース判断可能なプロダクトであるインクリメントの確認を行い、フィードバックを得るためのミーティング。スクラムチーム全員で開催。タイムボックスはスプリント期間1ヶ月で4時間、1週間であれば1時間程度が目安。通常、スプリント最終日に実施。
- スプリントで達成できたことの報告
開発チームはスプリントゴールで完成したもの、完成できなかったものを説明する。完成でできなかった場合は、理由と今後の対策も説明する。
- 動くソフトウェアでデモをする
- インクリメントの受け入れ確認
プロダクトオーナーは開発チームがデモしたインクリメントを受け入れるか否かを判断する。受け入れられない場合は開発チームに理由を説明する。
- インクリメントに対するフィードバックを得る
目標達成のために何を優先するか軌道修正する
- 今後のスプリントでつくるものの議論
フィードバックをもとに、プロダクトバックログアイテムの追加、優先順位の入れ替えなどを行う
スプリントレトロスペクティブ - 仕事の進め方を改善する
- スプリントレトロスペクティブとは何か
スクラムチームが自分たちの現状を見直し、次回以降の仕事の進め方を改善するためのミーティング。開発チームとスクラムマスターでスプリントレビュー後に開催する。タイムボックスを設け、スプリント期間が1ヶ月であれば3時間、1週間であれば30分から1時間が目安。
- 仕事の進め方の見直し
スプリント期間中の仕事の進め方をふりかえり、みんなで共有する。「良かったことや続けたいこと」、「困ったこと改善した方がよいこと」に注目して話す。
- 仕事の進めたの合意
話し合いで上がった、良いこと困ったことを受けて改善案を出す。「問題の原因は何か?」「いつ、どこで、誰が、何のアクションをとると困りごとが解消できるか?」を話し合い、次のスプリントで実施する。
プロダクトバックログ - 何を実現するかの一覧
- プロダクトバックログとはなにか
プロダクトで実現したいことの優先順位をつけた一覧。プロダクトオーナーがその内容と優先順位に責任を持つ。
メリット- 開発チームが作成すべき機能の全体象があきらかになる
- プロダクトに必須となる機能から順に完成できる
- 限られた期間の中で作成すべき機能を厳選しやすい
スプリントバックログ
インクリメント
- インクリメントとはなにか
開発チームがスプリントごとに作成するリリース判断可能で利用可能な動作するプロダクト
メリット- 開発チームが作成した機能差分を視認でき、進捗が明確になる
- 実現方法が不透明だったプロダクトバックログアイテムの実現方法が明確に
- 現時点のプロダクトをリリースするか否かの判断を行える
- リリース判断可能なインクリメントの作り方
さて、では、これをどう同人サークルの開発にいかすのか
ネット上で分断されて共有した時間を取ることが難しい同人ゲーム開発について
スクラム開発ツッコミどころ満載になりそうです。
また、これについてはまた記事にできたら。