スクラム適用報告
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

スクラム適用報告

on

  • 1,481 views

 

Statistics

Views

Total Views
1,481
Views on SlideShare
1,481
Embed Views
0

Actions

Likes
0
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

スクラム適用報告 Presentation Transcript

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