Post on 08-Jul-2015
description
1
2014年11月25日
ＧＭＯインターネット株式会社
次世代システム研究室
藤村 新
アジャイルな
オフショア開発
KPT ～現場をより良くするためにやっていることを3つの観点で振り返る「KPT発表会」～
2
現状の問題点
1度のやり取りで完成しない
オフショアチームの見積もり精度が低い
その結果
遅延を繰り返す
モチベーションが下がる
スケジュールが信頼できなくなる
相手を信頼できなくなる
3
現状の問題点
オフショアチームで品質を担保できない
その結果
日本側の担当者(プロデューサー)の負荷増大
明らかなバグから細かいバグまで全て確認し、指摘す
る必要がある
4
現状の問題点
あとちょっとの修正も、修正を依頼するためのコストが
結構かかる
その結果
95%完了から完成までしばらく時間がかかる
改善施策
頑張っても 効果が薄い事は 諦める
一度のやり取りで期待通りのアウトプットが出てこない
一度のやり取りで期待通りのアウトプットが出てこない 時間をかけてもっと詳細な仕様書を準備する
一度のやり取りで期待通りのアウトプットが出てこない 時間をかけてもっと詳細な仕様書を準備する
一度のやり取りで期待通りのアウトプットが出てこない 1度のやり取りでの完成を諦めた初回ザックリ開発
見積もりの精度が低く、完了予定が見えない
見積もりの精度が低く、完了予定が見えない 時間をかけて見積もりの精度を上げてもらう
見積もりの精度が低く、完了予定が見えない 時間をかけて見積もりの精度を上げてもらう
見積もりの精度が低く、完了予定が見えない ザックリ開発工数だけ見積もってもらい、実見積もりは係数を使って算出
95%完了から先が長い
95%完了から先が長い 再度指示書を書いて、完成してもらう
95%完了から先が長い 再度指示書を書いて、完成してもらう
95%完了から先が長い 最後の5%は日本側で完成させる
これら改善施策を 盛り込んだ 開発モデルを 考えてみた。
Rough Fill Closing
ベースは リーン開発の カンバン
Rough Fill Closing
26
ザックリ開発するフェーズ
7割程度の完成度を目指す
Backlogの時点で、ストーリーはレディ(着
手可能、仕様記載済み)な前提
ストーリーをタスク分割時に、オフショア
側開発者に工数を見積もってもらう
Roughのレビューフェーズで、専任担当
は完成までに必要な仕様を詳細に伝える
Rough Fill Closing
28
Roughフェーズでのアウトプットの完成
度を上げるフェーズ
9割以上の完成度を目指す
Rough Fill Closing
30
完成させるフェーズ
日本側の発注者(エンジニア)が対応する
Roughフェーズの見積もり日数、実際にか
かった日数、完成までに要した日数(サイク
ルタイム)等のメトリクスを収集
サイクルタイム÷見積もり日数で完了係数を
算出し、計画づくりに使用する
33
Keep(導入時)
見える化が進んだ
各タスクのステータスがひと目で分かる
Trelloの効果も大きい
タスクがレビューステータスの際は、次のタスクを自
ら取って進めるなど、自己組織化が促進した
ラフ見積もりの精度は想定通り高く、完了形数のバラ
付きもそれほど無かった
チームが慣れれば、計画づくりに使えると感じて
いる
34
Keep(現在)
受け入れテスト時の品質向上
2014年3Q：85%→2014年4Q：100%
レビューを複数回実施しているため
作業ペースは早くなってきている
体感ベース
引き続き自己組織化促進
Backlogに積んでおくと、タスク分解、ブランチ作
成、実装、ラボ内レビューまで自発的に実施
メンバー間のレビュー精度向上
35
Problem (導入時)
ラボ専任担当の負荷増大
Rough仕様作成
Roughレビュー
Fill仕様作成
Fillレビュー
Closingタスク
ラボ専任担当がボトルネックになるケースがあった
レビュー待ち、Closingタスクの増大
スケールしない構造
36
Problem(現在)
期限に対する意識が低い
Due date になってもサラッと遅延
遅れることが問題ではなく、共有されないことが
問題
完了係数をそもそも活用できていない
メトリクスの集計が手間
37
Try(現在)
完了係数の活用
Trelloプラグイン(RFC for Trello)検討
完了係数自動集計
Due date × 完了係数から受け入れ予想表示
受け入れ予想がSprint期限を過ぎる場合は警告
RFCモデルを他のプロジェクトへ展開
パターン・ランゲージ化
敷居が高い…
導入マニュアル整備
ラボ専任担当のWIPを制限する仕組み
38
おわり