Download as PDF, PPTX
XP祭り2016 - SWチームとHWチームがスクラムを組んだら
- 1.
- 2. 自己紹介 2 はじめに 川口 順央（かわぐちまさてる） ライフロボティクス株式会社 CORO®開発プロジェクト プロジェクトリーダー 関心事：良いソフトウェアをいかにしてつくるか？ 形式手法とか http://www.itmedia.co.jp/business/articles/1608/24/news004.html 飯田 一輝（いいだ かずき） ライフロボティクス株式会社 CORO®開発プロジェクト ハードウェアチームリーダー 関心事：ハードウェア開発に使える軽量なプロセスとは？ 高速試作/試作レス
- 3.
- 4.
- 5.
- 6. なぜスクラムなのか？ － 不確実性のコーン6 プロジェクト計画で考えたこと プロジェクトの不確実性は 不可避
- 7. なぜスクラムなのか？ － 見通しは早い方がいい7 プロジェクト計画で考えたこと 0 50 100 150 200 250 300 350 400 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 plan actual !? ? 早い段階の方が 打つ手は多い 終盤では もはや打つ手なし
- 8. なぜスクラムなのか？ － まとめると8 プロジェクト計画で考えたこと 不確実性に直面する状況においても 合理的なゴール設定に基づいてプロジェクトを進めたいから 1. スプリントごとにベロシティ（完了したストーリーポイントの合計）を計測できる 2. ベロシティは4スプリント（1スプリント2週間だと2か月）くらい回すと安定する 3. ベロシティから残りのストーリーを全部こなすのにあと何スプリント必要か計算できる 4. 得られた見通しをもとに最適なゴールを設定する
- 9. なぜHWチームと一緒のチームにしたのか？ 9 SW,HWの枠を超えて協力して行う作業が見込まれていた – 展示会の準備とか。別々にプロジェクト管理すると同期をとるのが難しい、または重い スクラムを採用したねらいは、HW開発でも有用なはず – HW開発にも不確実性は伴う 一度試してみたかった – SWはHWのおまけだと思われているような組み込みのプロジェクトだと、ガントチャートにHWのこ としか書いてなかったり。そういう悲劇をなくすにはひとつのチームにするのも一策 プロジェクト計画で考えたこと
- 10. HWとアジャイルって相性どうなの？ 10 1. 部品が揃わないと作れない。ウォーターフォール的な進め方となる 2.部分的なゴールの設定が難しい 3. さらにスプリントでのゴール設定が難しい 4. 製造とテストに大規模な設備が必要。外注を使うことが多い プロジェクト計画で考えたこと
- 11.
- 12.
- 13. HW開発とアジャイルをどうやってFitさせたか？ 13 プロジェクト計画で考えたこと 細かく分解した作業を１つのユーザーストーリーとして扱う 回路設計のストーリー、外注に作業を依頼するストーリー、etc… ストーリーポイントの見積もりや、ベロシティの考え方はソフトと同じ ユーザーストーリーの扱い ベロシティとＳＰの見積もりがあるから、むしろガントチャートによる進捗管理がやりやすい 外注にボールの渡ったストーリーは、いったんバックログに戻す。 もしくは外注にボールを渡すまででストーリーを区切る ガントチャートとの折り合い ハード開発とマッチしないプラクティスは諦める 継続的インテグレーションなど
- 14. 組み込みでの難点をどうやって克服したか？ 14 プロトタイプ機を使ってSW開発をする SWから見てプロトタイプ機と互換性があるHWにしてもらう 実機がなくてもホストで開発、テストできるようにスタブをつくる HW依存による順番の制約を解消する プロトタイプ機から変更になる部分は協議して決める プロトタイプ機との差分は簡単に変更できるようにパラメーター化したり、抽象化したりする 結合後の問題についてHWかSWか切り分けやすいようにアーキテクチャ上の下位レイヤから順にテ ストできる仕組みをつくる 並行開発するゆえの手戻りを少なくする プロジェクト計画で考えたこと
- 15.
- 16.
- 17.
- 18. 調達が間に合わない – 原因分析と対策18 実際の運用と結果 調達計画をつくった。調達するもののリスト、締め切り、予想される納期をあげる 各々の調達は調達用のストーリーを切ってスプリント計画に組み込む。 ストーリーポイントは0。待ちが多いが、実質的な作業は少ないことが多いので。 進捗が分かるようにかんばんに追加 調達は、選定、見積もり、発注、納品と検収という流れ。見積もり待ちや納品待ちで待たされて 必要な期日に間に合わないことがあった
- 19. スプリント計画どおりに完了できない – 原因分析と対策#1 19 実際の運用と結果 ストーリーゴールを記述する。ユーザーストーリーのテンプレートの代わり。その ストーリーが完了したときに、内部・外部問わずステークホルダーが何をできるよ うになっているべきかで記述する 各々のストーリーについての認識の差があり、現実に合わない楽観的な見積もりだったり、必要 のない無駄な作業を行うことがあった ストーリーはなるべく小さくする 着手後に大きいなと思ったら分割もできるようにする ストーリーが大きすぎて2週間でおわらないレベル
- 20. スプリント計画どおりに完了できない – 原因分析と対策#2 20 実際の運用と結果 ベロシティをもとに計画する。ベロシティを上限とする そもそもオーバーコミットメント 3時会。午後3時にかんばんのまえに集合してすべてのストーリーの進捗をなめる （朝会とは異なる軸でなめるのがミソ） いったんストーリーに着手すると目の前のストーリーで頭がいっぱいになってうまくペース配分 できない
- 21. 結果はどうだったか？ 21 1. 実績をもとにした計画修正。展示会3ヶ月前にベロシティをもとにやることを約1/3にまで削 ぎ落としたのが効いた 2.部分的なゴールの達成のために、HWの完成を最優先。HWがないとSWがあっても製品とし て成立しないので、HWを完成させるためにSW/HWの垣根を超えてHW完成に注力した。ひ とつのチームであったからこそ、その注力ができた。 スケジュール通り出荷判定合格！ 実際の運用と結果
- 22.
- 23.
- 24.
- 25. HWから見てアジャイルどうだったか？ 25 振り返ってみて アジャイルのプラクティスの多くがハード開発でも活かせる（びっくり！） ベロシティとSPによって、実現可能な計画を立てられる 今までは「最後は残業と品質の妥協でどうにかしよう…」だった アジャイルの考え方は、人に変化を促す 体育会系開発手法から脱却しよう ハード屋さんがアジャイルに慣れていない 社外設備や協力会社の都合でオーバーコミットメントせざるを得ないことがある 仕方ないとはいえ、罪悪感を感じる…
- 26. SWとHWが一つのチームでスクラムをやる利点と課題 26 振り返ってみて 繰り返し開発がもたらす合理的なゴール設定への寄与は活かせる SW, HWの協力で進める仕事があるときは計画が立てやすい 一つのチームという意識が芽生える。互いに尊敬できる関係を築ける 利点 HWはインクリメンタル開発ができない。部分的に実装がおわったもの をリリース可能にできない。 スプリント計画でのリソースの配分が難しい。単純なストーリーポイン トだけを気にしては負荷バランスがとれないことも 課題
- 27.
- 28.