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