Recommended
More Related Content
What's hot
Viewers also liked
Viewers also liked (20)
Similar to スクラム適用報告
Similar to スクラム適用報告 (20)
More from Eiichi Hayashi
More from Eiichi Hayashi (20)
Recently uploaded
Recently uploaded (8)
スクラム適用報告
- 1. アジャイル開発手法 スクラム適用報告 2008/06/29 セントラルソフト株式会社 システム２部 システム開発課 課長 林 栄一 1 1
- 2. 自己紹介 • システム２部、システム開発課 課長 • 勤続１２年ほど • 前職：楽器メーカー、陶磁器の卸、鉄道関 係の研究開発 • オブジェクト指向型開発 １５年ほど • 教育のプランニング、ＰＭ、アーキテクト • 興味のあること：要求開発、アジャイル、 チームビルディング、Scala 2
- 3. アジェンダ 1. 適用プロジェクト概要 2. スクラムの適用範囲 3. やったこと 4. 効果 5. できてないこと 6. 課題 7. 対策 8. やってみたいこと 3
- 4. プロジェクト概要 4
- 5. プロジェクト概要 • 広告代理店の販売管理業務 • 規模は１５人月ほど • ５月から詳細設計開始 • ５月の後半から実装開始 • ７月末に結合テスト完了予定 5
- 6. さて、スクラム 6
- 7. やったこと 7
- 8. やったこと スクラム 7
- 9. やってないこと 8
- 10. やってないこと スクラム？ 8
- 11. どこからがスクラムで、 どこまでがスクラム でないのか？ 9
- 12. 以後のプレゼンを見て みなさんに 判断していただきたい！ 10
- 13. スクラムの プラクティス 11
- 14. スクラムのプラクティス •スプリント 一ヶ月のイテレーション 。いつでも納品。 • デイリースクラム 毎日定時に15分間のミーティング、朝会 • プロダクトバックログ 業務視点で優先順位付けされたリスト • スプリントバックログ スプリント（イテレーション）で実現する作業リスト • スプリント計画ミーティング スプリントバックログを作成するミーティング • スプリントレビュー スプリントの終了時に行う振り返り 12
- 15. スクラムの ロール 13
- 16. ロール • スクラムマスター 外部との折衝、チームを雑音から守る ミーティングをファシリテート スクラム推進のキーパーソン • プロダクトオーナー 業務の視点で、ＲＯＩからプロダクト バックログの優先順位を管理 • スクラムチーム 開発を行う。スプリントにコミットする。 14
- 17. スクラム適用の 状況 15
- 18. スクラムの適用 • 前述の本社プロジェクトで部分適用 • 詳細設計がおわって実装にはいるタイミン グから適用。 • 単体テスト（画面機能単位）完了までを２ つのスプリントにわけて実行 • １スプリント３週間 • 現在、第１スプリントが終わったところ 16
- 19. 適用している役割 • スクラムマスター 私 • プロダクトオーナー 外部設計をおこなったＩ君 次期フェーズの外部設計を兼任 • スクラムチーム 本社開発メンバー 17
- 20. 適用しているプラクティス • スプリント計画ミーティング • 工数再見積（見積ポーカー） • デイリースクラム • スプリントバックログ • バーンダウンチャート • スプリントバックログ • ニコカレ • スプリントレビュー 18
- 21. スプリント計画 • ＰＧ工数再見積（見積ポーカー） 設計の画面をみながら 全員で一斉にカードで見積を だす。 ちがっている人の意見 を聞いて、ナレッジを共有 化。 19
- 22. システム2部での適用状況 デイリースクラム 20
- 23. デイリースクラム • スクラムマスターがファシリテート →挨拶重要 • 各自のタスクの状況と残工数を報告 • 開始するタスクカードにサインナップ • 終わったタスクカードにはかかった工数と見積 と違ったらその理由を明記(工数少なかった場 合と多かった場合両方) • 各自の共有化すべき情報をシェア • 終わり＝作業開始の挨拶→重要 21
- 24. デイリースクラム • スクラムマスターがファシリテート →挨拶重要 • 各自のタスクの状況と残工数を報告 オリジ • 開始するタスクカードにサインナップ ナル！ • 終わったタスクカードにはかかった工数と見積 と違ったらその理由を明記(工数少なかった場 合と多かった場合両方) • 各自の共有化すべき情報をシェア • 終わり＝作業開始の挨拶→重要 21
- 25. デイリースクラム • タスクカンバンの前で輪になって行う 22
- 26. タスクカード 実績工数を記入 見積との差異の理由や ノウハウなどをメモ 23
- 27. システム2部での適用状況 スプリントバックログ 24
- 28. スプリントバックログ 通常のイナズマ線もそ のままで、ハイブリッド 25
- 29. システム2部での適用状況 残工数の合計値 バーンダウンチャート に記入 26
- 30. スプリントバックログ • バーンダウンチャート 27
- 31. ニコニコカレンダー • ついでにニコカレもやってみた 28
- 32. ニコニコカレンダー • 毎日変えるまえに、模造紙に気分を貼る • 赤：ＧＯＯＤ！ • 黄色：ＮＯＲＭＡＬ • 青：ＢＡＤ！ • チームの気分を見える化 29
- 36. スプリント レビュー （振り返り） 33
- 37. スプリントレビュー ←要するにこれです。 この本のいろいろを やってみた。 34
- 38. スプリントレビュー 1.場を作る 2.情報あつめ 3.対策の検討 4.終了 35
- 39. スプリントレビュー 1.場を作る 遅れから萎縮し ているメンバーがいた らより重要 1.あいさつ重要 2.大変だったメンバーをねぎらう 3.チェックイン 見積精度、 4.テーマの宣言 効率化、 主要課題の対策 36
- 40. スプリントレビュー 2.情報集め 1. 見積との差異が大きい機能を洗い出し 2. マインドマップを書きながら各自の問題や課題をシェア 3. スプリント１をバーンダウンチャート上で時系列でトレース 4. 詳細設計のプログラム構造についての記述が書きにくいという 点がわかってきた 5. 人月当たりの平均生産ステップ：４３００step/人月 6. スプリント１だけで1人月強、超過 • 細かい不定期なチーム要員追加、スタートアップコスト大（最大８名） • みためにわからない予想外の複雑さ 37
- 41. 情報集め バーンダウンチャートやニコカレ上で タイムラインレビュー 要員増えた、仕様 変更、etc 発生した事件記入 タスクカードに記 入した情報を転記 機能ごと見積と実績の差異分析表 38
- 42. スプリントレビュー 声が大きい人だけの 3.対策の検討 意見が通るのを防ぐ 1.５５５(Triple Nickels) 2.対策に関してのブレスト 3.次ぎに行う対策を決定する 39
- 43. ５５５(Triple Nickels) 最初の意見 カードをまわして 他の人が意見を追記して いく 40
- 44. ブレストwithマインドマップ スプリントレビュー 議論の構造が見え る状態を維持しながら ブレスト 41
- 45. スプリントレビュー 2.終了 1.各自の感想と成果 2.振り返りの振り返り 42
- 46. スプリントレビュー きまったこと 1. 実装のリスクがある機能のＰＳレビュー、方式確認を数人で行う 2. テストケースは実装前か実装しながら行う 3. 実装上の課題はＷｉｋｉで管理 4. 朝：ニコカレ＋情報共有＋会社からの連絡、 夜：進 確認 5. ＰＪ途中で入ってくる７月からの新人の作業を明確に。 • ＳＰ２の後半で新人投入のリスク回避 • テスト自動化ツール調査、サンプル作成 43
- 47. スプリント１ 終了後 お客様にＤＥＭＯ 44
- 49. スクラムの効果 46
- 51. できていないこと 48
- 53. 課題 50
- 54. 課題 1. スクラム以前にチームファシリテーションのスキルが必要 →笑顔、ねぎらい、傾聴、見える化、重要。 2. 依然として見積精度低い。 特に大きい機能ほど標準の便 利機能が使えなくなって ドラスティックに工数が増えてし まうことがある。 3. 自由度のある契約 4. 細かい要員追加により特定メンバーへの負荷の集中 51
- 55. 対策 52
- 56. 対策 1.スクラムマスターのトレーニングとファシリ テーションのトレーニングを同時に行う 2.見積精度の向上は、なるべく同一のアーキテ クチャーでの開発を行う 3. それぞれのアーキテクチャーでの見積知見 をナレッジ化する • ただし、同一アーキ、同一チームでの開発が ２回以上行われること は現実問題として多くないという問題あり。 53
- 57. 対策 (Cont.) 4.いつでも納品できる体制の確立と同時に、ス プリント単位での見積と契約。 5.大きい機能であるほど、処理イベントごとの タスクを分解して開発を行う 6.複雑な機能について処理構造検討会を少人数 で開く。 • 処理方式設計は一人よりも複数で検討したほうが正確、早い。 54
- 58. やってみたいこと 55
- 59. やってみたいこと アジャイルな契約モデル 1. 最長スケジュール最大コスト 2. 開発が始まっていない機能は同規模の機能と入れ替え可能 3. 機能の優先順位は変更可 4. スケジュールと予算が許す限りお客様による機能追加可能 5. プロジェクトの残り残高が２割に収まればお客様による早期解 約可能 6. スプリント単位での契約あるいは、検収 7. 成功報酬などのＷＩＮＷＩＮな契約 8. あるいはＬＯＳＴＬＯＳＴ 56
- 60. 最初の命題 どこからがスクラムで、 どこまでがスクラム でないのか？ 57
- 61. さて、われわれは スクラム をやったのだろうか？ 58
- 62. 気づき 1.スクラムのなかでどんなプラクティスも追加 可能 2.一部分でも使えるプラクティスがある。 3.その環境で使えるところから使うことでも効 果を得られる。 4.徐々にスクラム度を増していけばいい。 5.ただし、契約の問題は大きい。 問題の構造が見えない ままカイゼンの検討 は経験が必要 6.実は振り返りにＫＰＴは難しい。 59
- 63. 準・スクラム ぐらいはいけたかな？ 60
- 64. 結論 61
- 66. Q&A 63
- 67. ご静聴ありがとうござ いました。 64