スクラム開発の要点まとめ
2013年12月03日
勉強仕立てで、まだ纏まり悪いですが最近流行りのアジャイル開発の一つスクラム開発を勉強しました。
少しづつでも業務に適用できればいいと思います。
概要
軽量なアジャイル開発技法の1つ。 チーム開発技法の枠組み(フレームワーク)
メリット
- 定期的にリリース可能なアウトプットを出せる。(スプリント)
- 変更に柔軟になる。(ならないと出来ない)
- 進捗や予実管理がし易い。
- シンプル。フレームワークなのでカスタマイズしつつ導入が可能。
デメリット
- 受注開発には適用しづらい(顧客の協力が必須)
- プロジェクトが水物であることを許容するため開始時に終了予測が立たない。
- チームが少数精鋭でなければ回らない。(SE + PGをこなせないとオーバヘッドがかかる)
役割
チーム
- スポーツチームのように各メンバーが協力し、全体としてゴールを目指す。
- リーダーマネージャーに責任を押し付けず、セルフ・マネジメントを行う。
- プロジェクトマネージャーからチームへ権限を委譲する。
- チームの人数は3〜10が適当。
- 見積、計画、設計、実装、テストを行い製品に責任を持つ。
スクラムマスター
- チーム内外の障害を取り除く(調整役)
- チームの一歩外から見守る相談役(チームのコーチ役)
- チームメンバーではなく、一歩引いた立ち位置
- チームがパフォーマンスを発揮できるよう支援する。
- プロジェクトマネージャー的役割だが、必ずしも技術知識は無くても良い。
- プロダクトオーナーとチームの中立ち
プロダクトオーナー
- 製品の総責任者。(サービス企画担当、顧客の責任者等)
- チームに優先順位を付けてバックログを通して情報を渡す(方向性を決める)
- チームに指示をしない。
- スクラムマスターとの兼任は認められない。
プロジェクト
プロジェクトを2週間〜4週間の期間に分割する。 単位をスプリントと呼ぶ
プロジェクトの工程
- リリース計画レビュー
- 製品基準の調整・レビュー・配布
- スプリント
- スプリントレビュー
- クロージャ
3、4を繰り返し実行する。顧客に製品の機能や品質が十分と判断されるまで繰り返される。
スプリント
- 実際にソフトウェア開発が行われる工程
- スプリントの期間は決して延長しないこと。
- スプリント毎にバックログを入力する。
- スプリント完了時に、実装/テスト/ドキュメントが完了していること。
- リリース可能なプロダクトである事。
バックログ
プロダクトバックログ
- 製品に必要な要素を項目に起こした一覧。
- ユーザーストーリー(要件)に優先度を付けて記載したもの。
- プロダクトオーナーが顧客視点で記載する。
- チームが大まかな工数(ポイント)を付ける(例 大:3、中:2、小:1)
スプリントバックログ
- プロダクトバックログを元にスプリントで実現する仕様をまとめたもの。
- チームがプロダクトバックログを分割し、工数を見積もって実装できるタスク単位とする。
- スプリント内で受け入れポイントを予め決めておく(20ポイントまで)
デイリースクラム(朝会)
スプリント期間中、チームは毎日朝会を開きチームとスクラムマスターに共有を行う。
毎日同じ時間にチーム全員が以下の3点の報告と質疑応答のみを完結に行い、15分以内に終わらせる。
- 昨日行った内容
- 今日何をするか
- 問題(障害)はあるか
質疑応答次第では、即座に関係者のみで別の会議を開催する。
- 問題発生時、スクラムマスターが意思決定を行い。すぐに解決出来ない問題はバックログに追加する。
- 障害が外部要因の場合、スクラムマスターがその解決の責任を負う。
スプリント終了時
- スプリント終了時に、次のスプリントに反映するために「振り返り」を行う。
有効な技法
- テスト駆動開発(TDD)
- 単体試験
- 受け入れ試験
- リファクタリング
- 継続的インテグレーション
対応ツール
参考
blog comments powered by Disqus