スクラム適用報告

1,203 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,203
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

スクラム適用報告

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

×