Scrum概要

2013/2/1 Ryutaro YOSHIBA

http://www.flickr.com/photos/18091975@N00/3654141771/

13年2月1日金曜日

吉羽 龍太郎

アジャイルコーチRyuzee.comTwitter: @ryuzee

Ryutaro YOSHIBA

13年2月1日金曜日

Agile研修やオンサイトコーチングの提供

こちらからは営業しませんw13年2月1日金曜日

•これから超大事なこと言います！

http://www.flickr.com/photos/32397140@N00/37444389

13年2月1日金曜日

2013年2月に

Scrum Boot Camp

の本が出ます！

13年2月1日金曜日

2013年2月発売先行予約受付中定価：2520円

http://www.seshop.com/product/detail/15395/

#scrumbcbook13年2月1日金曜日

•大事な話おわり！

http://flickr.com/photos/99174151@N00/2976156645

13年2月1日金曜日

State of Agile Survey 2011 (c)VersionOne

手法の利用割合

13年2月1日金曜日

本当に必要なものがわかるか？

13年2月1日金曜日

13年2月1日金曜日

期待のマネジメントに失敗

13年2月1日金曜日

システムの機能の利用割合

7%

13%

16%

19%

45%

Standishの2000年の調査より13年2月1日金曜日

システムの機能の利用割合

7%

13%

16%

19%

45%

まったく使わないほとんど使わないたまに使うよく使ういつも使う

Standishの2000年の調査より13年2月1日金曜日

あなたの開発はムダだらけ？

•作りすぎのムダ•手待ちのムダ•運搬のムダ•加工のムダ•在庫のムダ•動作のムダ•不良をつくるムダ

13年2月1日金曜日

コストの見積りは正しいか？

•不確実性コーン13年2月1日金曜日

予測主義 vs 経験主義

http://www.flickr.com/photos/iain/353671249/

13年2月1日金曜日

予測主義 vs 経験主義

•ウォーターフォール型の開発手法(予測主義)は、先のことまで見通した正しい計画が作れることを前提にしている。これは大丈夫か？

•アジャイル開発は経験主義に基づく。経験した事実を踏まえて計画を修正し続ける。修正範囲にはスコープも含まれる

http://www.flickr.com/photos/iain/353671249/

13年2月1日金曜日

Scrumとは

•可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのもの

•複雑で変化の激しい問題に対応するための仕事の進め方

•既知のことより未知のことが多い領域に向いている

•作業・成果物・会議体を定めている13年2月1日金曜日

Scrumの特徴

•軽量•理解が容易•習得は結構大変

13年2月1日金曜日

従来型と異なる点

•リソースと期間によって総量規制をかける•総量をあふれる要求は実現されない•もしくは必要な機能を作り終わるまで期間が延びる

13年2月1日金曜日

大事なことから始める

•欲しいものをリストにして順位をつける

•リストには項目が追加されたり、削除される

•この順番は定期的に見直す•優先度ではない！

1番目に欲しい2番目に欲しい3番目に欲しい4番目に欲しい5番目に欲しい

99番目に欲しい

100番目に欲しい

...

6番目に欲しい7番目に欲しい8番目に欲しい9番目に欲しい

13年2月1日金曜日

【 成果物1】 プロダクトバックログ

http://www.flickr.com/photos/38793485@N00/3600409147/

13年2月1日金曜日

【ロール1】プロダクトオーナー

•プロダクトバックログの管理者•優先順位の意思決定の最終決定権限をもつ

•プロダクトの責任者(結果責任)•プロジェクトに１人必ず必要•プロダクトの価値を最大化する

13年2月1日金曜日

【ロール2】開発チーム

•モノを作る•３人～９人で構成•全員揃えばプロダクトを作れる能力が揃う•上下関係なし

http://www.flickr.com/photos/jurvetson/43922369/

13年2月1日金曜日

自己組織化

•最良のやり方を自分たちで決める•一番やり方をしっているのは現場の人

13年2月1日金曜日

一定のリズムで仕事する

•一定間隔で意思決定と作業と確認を行う•最大４週間の固定の期間•これをスプリントと呼ぶ

2週間 2週間 2週間 2週間 2週間◎同じ長さに区切って繰り返す

2週間 4週間 1週 2週間☓期間の長さが変わってはいけない

1週

13年2月1日金曜日

【会議1】スプリント計画会議

•スプリントで開発をするためには計画が必要

•プロダクトオーナーは何をほしいか（第一部）

•開発チームはどれくらいできそうか（第一部）

•開発チームはどうやってそれを実現するか（第二部）

1番目に欲しい2番目に欲しい3番目に欲しい4番目に欲しい5番目に欲しい

99番目に欲しい

100番目に欲しい

...

6番目に欲しい7番目に欲しい8番目に欲しい9番目に欲しい

13年2月1日金曜日

【成果物2】スプリントバックログ

•プロダクトバックログを具体的なタスクに分割する

•後から増えることもある•１タスクは１日以内のサイズ

1番目に欲しい2番目に欲しい3番目に欲しい4番目に欲しい5番目に欲しい

99番目に欲しい

100番目に欲しい

...

6番目に欲しい7番目に欲しい8番目に欲しい9番目に欲しい

タスク タスク タスク タスク タスクタスク タスク タスク タスク タスク

タスク タスク タスク タスク タスクタスク タスク タスク タスク タスク

タスク タスク タスク タスク タスクタスク タスク タスク タスク タスク

13年2月1日金曜日

【成果物3】出荷判断可能な増分

•開発チームは出荷判断可能なプロダクトの増分をつくる

13年2月1日金曜日

出荷判断可能

•部品だけでは出荷判断できない•小さくても使えるものを作る

13年2月1日金曜日

完了の判断

ここまでできれば終わりだと思ったんだけど

あれもこれもできてないじゃない！

13年2月1日金曜日

完了の定義

•完了の定義を作り、何をもって出荷判断可能かを定める

•スプリントでどこまでやるか決めるコードレビュー

チェックイン ユニットテスト

カバレッジ75%

ドキュメント 性能 セキュリティ デプロイ

結合テスト 受け入れテスト

クロスブラウザ

静的解析

13年2月1日金曜日

開発をすすめる

•開発チーム全員で仕事をすすめる•特定の誰かに特定の責任が付与されるわけではない

•外部からやり方は指示しないhttp://www.flickr.com/photos/globalgamejam2009/3241345650/

13年2月1日金曜日

【会議2】デイリースクラム

•開発チームの状況を毎日検査する

13年2月1日金曜日

【会議2】デイリースクラム

•開発チームがスプリントゴールに向かって進んでいるかを検証。残作業を追跡する

•毎日、同じ場所で同じ時間に開始•15分間で延長なし•たった３つの質問•開発チームのための会議で部外者は口出しなし

13年2月1日金曜日

スプリントゴールへ進む

•スプリント開始時点で決めたスコープを外圧によって変更してはいけない

13年2月1日金曜日

【会議3】スプリントレビュー

•開発チームの成果物をプロダクトオーナーが確認し、受け入れ可否を決める

13年2月1日金曜日

デモを確認し受け入れを判断する1番目に欲しい2番目に欲しい3番目に欲しい4番目に欲しい5番目に欲しい

99番目に欲しい

100番目に欲しい

...

6番目に欲しい7番目に欲しい8番目に欲しい9番目に欲しい

13年2月1日金曜日

デモを確認し受け入れを判断する1番目に欲しい2番目に欲しい3番目に欲しい4番目に欲しい5番目に欲しい

99番目に欲しい

100番目に欲しい

...

6番目に欲しい7番目に欲しい8番目に欲しい9番目に欲しい

頼んだ通りなのでOKです

13年2月1日金曜日

デモを確認し受け入れを判断する1番目に欲しい2番目に欲しい3番目に欲しい4番目に欲しい5番目に欲しい

99番目に欲しい

100番目に欲しい

...

6番目に欲しい7番目に欲しい8番目に欲しい9番目に欲しい

頼んだ通りなのでOKです

これクリックした時の遷移先が違うのでNGです

13年2月1日金曜日

デモを確認し受け入れを判断する1番目に欲しい2番目に欲しい3番目に欲しい4番目に欲しい5番目に欲しい

99番目に欲しい

100番目に欲しい

...

6番目に欲しい7番目に欲しい8番目に欲しい9番目に欲しい

頼んだ通りなのでOKです

これクリックした時の遷移先が違うのでNGです

なるほど。今回はOKだけど次のスプリントで機能追加しようか

13年2月1日金曜日

デモを確認し受け入れを判断する

•厳密に判断する

1番目に欲しい2番目に欲しい3番目に欲しい4番目に欲しい5番目に欲しい

99番目に欲しい

100番目に欲しい

...

6番目に欲しい7番目に欲しい8番目に欲しい9番目に欲しい

頼んだ通りなのでOKです

これクリックした時の遷移先が違うのでNGです

なるほど。今回はOKだけど次のスプリントで機能追加しようか

13年2月1日金曜日

短いフィードバックサイクル

•短いスプリント単位で頻繁に確認と調整を行いプロダクトをよりよくする

•もちろん仕事のやり方ももっとうまくできるはずなのでカイゼンを繰り返す

13年2月1日金曜日

【会議3】スプリントふりかえり

•スプリントレトロスペクティブとも言う•人、関係、プロセス、ツールなどの観点で今回のスプリントを検査する

•うまくいったこと、今後の改善点を整理する•今後のアクションプランを作る

13年2月1日金曜日

KPTをはじめ様々なやり方

http://www.flickr.com/photos/magnus_d/5121009259/

13年2月1日金曜日

繰り返す

•タイムボックスを繰り返して•POがほしいものから順に•出荷判断可能なプロダクトを届け続ける•うまく届けられるように改善し続ける

2週間 2週間 2週間 2週間 2週間

13年2月1日金曜日

•このプロセスがうまくまわるようにする

•妨害の排除•支援と奉仕（サーバントリーダーシップ）

•教育、ファシリテート、コーチ、推進役

【ロール3】スクラムマスター

13年2月1日金曜日

13年2月1日金曜日

Scrumまとめ

• 欲しいものを作る順番に並べ替える。その順にモノを作ることで成果を最大化する(価値を基準)

• 短い時間に区切って繰り返す(タイムボックス) • 現在の状況や問題点を関係者の間で常に共有(透明性) • 定期的に進捗状況や作っているモノが正しいのか、仕事の進め方に問題がないかどうかを確認(検査)

• 問題があったりもっとうまくできる方法があれば、やり方を変える(適応)

13年2月1日金曜日

XPと組み合わせる� �

?7;/F�

���$�

,-'&-�

869%�#��

=0<D�

B;/27BE3�

4F:+!�����

���1E83CF5@E�

YAGNI�

"��

�!�

����+!��)�

>AF�

���*!=F6�

69FBF���

BBF6 ��

(�.869�

��BBF6�

13年2月1日金曜日

アジャイル失敗の理由

•失敗の定義はなんだろう？13年2月1日金曜日

アジャイル失敗の理由

•失敗の定義はなんだろう？

組織変革が必要なことを理解してなかった

13年2月1日金曜日

アジャイル失敗の理由

•失敗の定義はなんだろう？

組織変革が必要なことを理解してなかった

組織文化や哲学がアジャイルの考えとあってない

13年2月1日金曜日

Scrumで大事なこと

•Scrumで問題は分かるかもしれない•でもScrumが解決するわけじゃない•解決するのは現場の皆さん自身

http://www.flickr.com/photos/rowanbank/8066004236/

13年2月1日金曜日