発注者としての アジャイル開発体験報告 · tfs＋msf for agile software development...
Post on 06-Sep-2019
2 Views
Preview:
TRANSCRIPT
発注者としての アジャイル開発体験報告
株式会社 オージス総研
張 嵐 中川 三千雄
2
株式会社 オージス総研
オージス総研は、コンサルティング、情報化戦略立案からシステムの設計・開発、運用・管理まで、必要とされるソリューションメニューのすべてを提供できるシステム・インテグレータです。
社名 株式会社オージス総研 代表者 取締役社長 平山 輝（ひらやま ひかる）
設立 1983年6月29日 資本金 4億円(大阪ガス株式会社100%出資) 売上実績 ２８８億円（2011年度 単体）
従業員数 １３１７名 （2012年3月31日現在）
事業所 本社/岩崎コンピュータセンター 東京オフィス 千里オフィス 南港オフィス 尼崎オフィス 名古屋オフィス・豊田オフィス
海外法人 米国OGIS International,Inc.
品質 ＩＳＯ９００１認証取得 プライバシーマークの付与認定
3
本日の内容
アジャイル開発と当社の関わり
5
当社のアジャイル開発の取り組み
6
当社の代表的なアジャイル開発の実績年表
小規模はスクラム的、中規模以上は統一プロセス（UP）の形で開発
10人以下
30人以下
30人 超
脱Waterfall 整理定式化 エンタープライズ アジャイル開発
7
オージス総研のアジャイル開発手法
OGIS Scalable Agile Method
開発手法部分
スクラムを基本とする
アジャイルUPで補完する
測定部分
機能規模測定手法「COSMIC法」に基づく測定を活用し、見積もり、契約の問題に対処し、開発をモニタリング、改善する
アジャイル開発に対する期待と 発注者の役割
9
アジャイル開発に期待する効果
期待する効果
要求変更への対応
迅速なリリース
品質向上
弊社のエンタープライズアジャイルセミナーのアンケートの集計結果から
10
プロダクトオーナーは製品の成功に責任を持つ
価値
物
人
顧客、ユーザ、ステークホルダ
との協調
チームとの協力
予算
プロダクト
ビジョンと
ロードマップ プロダクト
バックログ
リリースプラン
プロダクト
これらの責務を一人でこなすのは大変難しい
11
プロダクトオーナーを皆で支える
ここから、弊社の2つの事例を通して、プロダクトオーナーのあり方について考えていきます。
CaseStudy1 CaseStudy2
プロダクトオーナーの得意な専門分野
マネージメント 開発技術
開発の特徴 アジャイル＋ オフショア開発
アジャイル＋ 研究開発
便宜上：発注者 = プロダクトオーナー
CASE STUDY1： アジャイル＋オフショア事例
オージス総研のグローバルデリバリーマップ
13
プロジェクトの概要と課題
アジャイル開発の導入
アジャイル開発の導入効果
プロダクトオーナーへのメッセージ
CaseStudy1の紹介内容
1. プロジェクトの概要と課題
15
考察対象のプロジェクト概要
Elapiz BE v3.4
開発内容 UMLモデリングツールの機能改善、プラグインの追加
開発種類 パッケージ開発（.net）
開発期間 3ヶ月
開発チーム人数 12名
開発規模/
ソースコード規模 30人月/
606KSLOC
開発環境 Visual Studio
C#.net
16
今までのやり方
ミニWaterfall
アジャイル開発のプラクティスを断片的に適用 チケットで要求管理 チーム全体アプローチ KPTによる振り返り
要件定義
基本設計
詳細設計
コード作成
単体テスト
結合テスト
システムテスト
作業依頼
範囲
Start End
重要な機能 残りの機能 変更対応・ 不具合修正
WIP1 WIP2
システムテスト システムテスト
＞１ヶ月 １ヶ月前後 0.5ヶ月
システムテスト
RC
※）WIP(Work In Progress)：中間リリース。動作確認を行う
RC(Release Candidate) ：最終リリース。受け入れを行う
17
顕在化した課題
発注側が感じた4つの課題
品質
変更を柔軟に受け入れる許容度
要求の出し方とオフショア側の
システム利用者の立場から考える力
プロジェクトの可視化
オフショア側の課題
モチベーション
もっと考えてくれたらいいのに
エンドユーザからの新たな要望があった
いわれることだけやるのは、ちょっとつまらない
変更、変更、何のために頑張ったか
エビデンスのために一日中画面のハードコピーを行うのは、私の将来の糧になるのか？
この機能の開発は終わったか？
2.アジャイル開発の導入
知識
支援
信頼
19
導入したもの
プロジェクト管理フレームワーク
•Scrum
技術プラクティス ツール
•Visual Studio 2010+Team Foundation Server（TFS)
•顧客指向 •チームビルディング
•品質 •リリース重視
•オフショア開発支援
20
要件の出し方：プロダクトバックログの作成
発注者
要求を登録する 要求を理解する
優先順位をつける • ビジネス価値 • 実現の難易度 • 見積もり結果
要求の細分化、補足を行う
プロダクトバックログ
見積りを行う
優先順位 高い方は より詳細的
優先順位 低い方は 曖昧のまま
開発チーム
実現の可能性、難易度を検討する
要求一覧と見積り結果を確認する
Team Foundation Server
21
開発の流れとプロダクトバックログの洗練化
初期
要求定義
リリース
計画
・・・・・・
リリース
スプリント
スプリント
0
スプリント
1
スプリント
5
スプリント0 スプリント１ スプリント2 ・・・・・・ スプリント５
変更を柔軟に対応するために
動くソフトウエアやユーザからフィードバックを受け、プロダクトバックログを進化させる
プロダクトバックログの洗練化
22
プロダクトオーナーとの常時コミュニケーション
メール
chat 電話
Skype
TV会議
出張
SOBA
TFS/Wiki
メーリングリスト
有効性
利用頻度 • スプリント計画
• スプリントレビュー
• 振り返り
• 仕様説明
• Q&A
• レビュー結果
• 不具合
• 仕様に関するDiscussion
23
支援ツール
mantis、Trac、mailなど複数のツールを整理し、Team Foundation Serverで一元化管理
自動ビルド・自動テスト
構成管理
IDE Visual Studio 2010 Ultimate
開発
CI
TFS＋MSF for Agile Software Development
PJ管理
継続的なインテグレーション
バックログの管理、テスト管理
Q&A、課題など情報共有 Tracによる要求管理、情報共有
Mantisよる不具合管理
構成管理サーバ
集約
Team Foundation Server
3.アジャイル開発の導入結果
25
品質：不具合が減少
Elapizの不具合曲線
Scrumを導入 段階的にアジャイル
プラクティスを導入
26
品質：不具合は早期検出、早期対応
今までの開発（V3.3)
終盤に集中し、最終盤にピークがある
改修がリリースに間に合っていない
今回のアジャイル開発（V3.4)
開始から、終盤まで平均化している
検出→修正のタイム間隔が短縮
プロジェクト期間
0
5
10
15
20
25
30
検出数
修正数
0
5
10
15
20
25
30
件数
件
数
初期 終盤 プロジェクト期間 初期 終盤
27
仕様変更：対応力が高まった
今までの開発 今回のアジャイル開発
発注時の 前提条件
要求はおおむね確定している
要求は開発と共に進化する
開発の目的 要求を満たすため 要求を最適化するため
変更対応 • 次期開発で対応 • 対応せざるを得ない場合、コストと納期に響く
• 柔軟に対応 • 優先順位の調整を行い、コストと納期への影響を低減
柔軟に変更を対応するため
- • 短い反復 • バックログの洗練化で変更を察知する
28
可視化：プロジェクトの健康状態の見える化
Team Foundation Serverを活用し、リスク、進捗、品質状況が見やすくなる
チームのツール
プロダクトオーナーのツール
技術寄りのプラクティス
管理寄りのプラクティス
スプリント バーンダウンチャート
リリース バーンダウンチャート
スプリントレビュー 継続的なインテグレーション
アジャイルテスト
29
チームのモチベーションと提案力が向上
開発チームの変化
縦割り指示型から自律性の高いチームになった
発注者はチームの一員になり、対等、協力の関係になった
作業項目を自分で選択し、責任を持って動くものを作る
開発者は自分の作品と認識し、製品を良くなるために提案するようになった
離職率は低くなった
プロダクト オーナー
スクラムマスタ
チーム
要求
製品
支援
ビジネス 技術
プロセス
30
課題と今後の方向性
発注側 オフショア側
Scrum • 頻繁なスプリントレビューで疲れた
• ストーリーレベルで仕様を提示し、仕様の説明や確認の時間がかかった
• スプリント毎に動くものをデモするので、プロジェクト終了まで緊張し、疲れた
• タスクの選択は積極的ではなかった
• スプリントレビューの準備不足で、デモ対象の機能が動かなかった
継続的なインテグレーション
-- 大量のレガシーコードに対し、テストケースを一気に追加できない
TFS -- 十分に使いこなせなかった
「個々のプロジェクトで頑張る」だけでは成功は約束されない。 組織からの支援が大切。
4.まとめ： プロダクトオーナーへのメッセージ
よいアイデア！
不具合が確実に減った
エンドユーザからの新たな要望があり、対応してもらおう
TFSでプロジェクトの状況をチェックする
この機能は私の提案だ！
変更？次のスプリントで対応できるかを検討する
今日も○○さんと一緒にペアで作業し、沢山刺激を受けた。このチームが楽しい
32
プロダクトオーナーへのアドバイス
チームと対等の信頼関係を持つ
チームの意見を真剣に受け止め、オフショア側の自主的な活動をサポート
組織からの支援が大切
アジャイルコーチ、技術支援、ツール導入支援
プロマネのスキルが必要
ユーザ調整、リソース配分、プロダクト全体の整合性への配慮等
適切なツールも重要
CASESTUDY2： アジャイル＋研究開発事例
34
考察対象のプロジェクト概要と課題
課題に対する解決策
プロジェクトの結果
アジャイル開発に関する３つの気づき
CaseStudyの紹介内容
35
考察対象のプロジェクト概要
CITK
(Cloud Integration Tool Kit)
開発内容 セキュリティやシステム連携に関するクラウド基盤ソフトウェアの開発
開発期間 8ヶ月
開発チーム人数 4～10名
開発規模 40人月
開発環境 Mule ESB
Open AM
Java
SOURCEFORGE.JPで公開中
http://sourceforge.jp/projects/citk/
36
当プロジェクトにおける課題
研究開発で不確定な要求が多く、それらに対処するために、プロジェクトはスクラムを採用する
一部の開発を委託するパートナー企業は「一括請負」「非アジャイル（ウォーターフォール）」を希望する
１つのプロジェクト内でスクラムによる
アジャイル開発とウォーターフォールによる
非アジャイル開発をどのように併存させるか？
38
アジャイルと非アジャイルの複合チーム体制
開発チームは２チーム体制（アジャイルと非アジャイル）
プロジェクトルームを準備し、チーム全員の同席を採用
アジャイル開発センターは教育面・プロセス面をサポート
リーダー
開発チーム
スクラム マスタ
プロダクト オーナー
開発チーム
アジャイル コーチ
報告・Q&A
成果物送付
仕様・設計伝達
成果物受け入れ パートナー企業
非アジャイル開発チーム(3～5名)
弊社アジャイル
開発チーム(4名前後)
アジャイル開発センター
教育・プロセス 教育・プロセス
非アジャイル（一括請負） 作業の持ち帰りを希望
スクラムを導入
39
プロジェクト開始時点での全体の進め方
開発
弊社
プロジェクト
ルーム
パートナー
企業
[チーム全体]
初期要求の洗い出し （プロダクトバックログ作成）
[非アジャイルチーム]
ウォーターフォール
[非アジャイルチーム]
ＷＢＳ作成と見積もり
[弊社アジャイルチーム]
スクラムを適用
[プロダクトオーナー]
プロダクトバックログの
コントロール、成果物受け入れ
作業の 持ち帰り
初期計画 開発 リリース
40
非アジャイルチームとの作業範囲の合意
プロジェクト全体の初期要求をプロダクトバックログとして 洗い出す
プロジェクトの実施計画をもとに初期要求を洗い出す
非アジャイルチームが持ち帰り可能な要求の選定
プロダクトバックログから要求がハッキリし、他と依存していないものを選択
作業範囲を合意にするためにＷＢＳを作成
１、２週間間隔で中間成果物の確認が可能なタスク粒度
非アジャイルチームは見積もりを実施し、作業範囲を合意して作業を持ち帰る
41
非アジャイルチームの作業進捗の確認方法
日次報告
日々の成果物（ソースコード、ドキュメント等）
定例会議（1回／週）
デモンストレーション
ソースコードレビュー
ドキュメントレビュー
仕様説明
タスク毎に受け入れを実施。
⇒ 指摘事項をフィードバックし、
対応確認後、クローズする
デモンストレーションやレビューを行い、
進捗レベルを共有した。
プロジェクトの結果
43
非アジャイル開発チームが作業を自社に持ち帰り、開発が進むにつれて、問題が顕著に発生
プロジェクトの途中経過
８ ９ １０ １１ １２ １ ２ ３
プロジェクト全体
非アジャイル
チーム
設計／開発
非アジャイル
チーム
テスト／受入
予定
実績 問題
発生
予定
予定
実績
44
非アジャイルチームで発生した問題と解決策
解決策
プロジェクトルームに非アジャイルチームも同席
原因
技術力不足 コミュニケーションロス
発生した問題
日々の成果物が未提出 進捗遅れ
新しい技術
不慣れな技術 作業場所が
異なる
動かして確認
できない 指定した技術が 利用されていない
45
キャッチアップのための対策（アジャイルの導入）
ホワイトボードを使った設計やアジャイルモデリング
ペアプログラミング
文書や対話より
コードは素直に伝わる
46
アジャイルプラクティス導入から約２週間で効果がみられた。
プロジェクト全体は計画当初の予定から１カ月遅れでリリース。
プロジェクトの結果
８ ９ １０ １１ １２ １ ２ ３
プロジェクト全体
非アジャイル
チーム
設計／開発
非アジャイル
チーム
テスト／受入
予定
実績 問題
発生
予定
予定
実績
実績 １２月初旬
同席・アジャイルモデリング・ペアプログラミング
を導入
１２月初中旬 動くソフトウェアを確認しながら開発が行える
ようになった
アジャイル開発に関する３つの気づき
48
１．プロダクトオーナーは、チームの一員になること
プロダクトオーナーは、チームと距離を置くのではなく、積極的にチームの一員になる
チームとの協力関係が成り立たなければ、要求のコントロールも難しい
49
２．同席によるコミュニケーションの効果は大きい
チームの状況が把握しやすい
要求に対する問題や課題のフィードバックが 早いため、問題が大きくなる前に対処できる
動くソフトウェアに目を向けることができ、ソフトウェア開発に注力できる
50
３．個人の能力の差は、チーム力でカバーできる
チームの個々のメンバーの能力は高いにこしたことはないが、最初から高い能力は必要ない
個々の能力のウィークポイントは、チーム力でカバーできる
成功する発注者の心構え
52
アジャイル開発の導入効果の評価（１）
導入前
反復開発
導入後
スクラム
結果
要求変更への対応
抵抗感があった。 対応能力が備わった。
自ら改善案を提示するようになった。
大きく
改善
迅速なリリース
リリース前の不具合改修が間に合わない。
不具合の早期検出・早期対応で計画通り、リリースできた。
大きく
改善
品質向上 リリース直前の不具合検出量が多い。
導入前に比べ、減少傾向。 改善
■アジャイル＋オフショア開発
53
アジャイル開発の導入効果の評価（２）
導入前
ウォーターフォール
導入後
部分的にアジャイル
プラクティスを導入
結果
要求変更への対応
抵抗感があった。 コミュニケショーンで仕事が進むようになり、細かな要求の調整は気にならなくなった。
小さく
改善
迅速なリリース
開発期間中、ソフトウェアの動作確認が不可能だった。
常にソフトウェアの動作確認ができる状態になった。
改善
品質向上 修正毎にデグレートが多く発生した。
テストコードを作成したため、修正時のデグレードが大きく減少した。
大きく
改善
■アジャイル＋研究開発（非アジャイルチーム）
54
発注者の特徴とパートナー企業に与えた影響（１） ■アジャイル＋オフショア開発
発注者の得意な専門分野
プロジェクトマネージメント
発注者が努力した点
開発チームの自主性を尊重
プロマネの経験の活用
発注者がパートナー企業に与えた影響
開発チームのモチベーションの向上
開発チームの作業効率や品質の向上
55
発注者の得意な専門分野
開発技術
発注者が努力した点
パートナー企業に歩み寄り、協力体制を確立
パートナー企業にアジャイルプラクティスを導入
発注者がパートナー企業に与えた影響
動くソフトウェアを見ながら開発が行えるようになった
気が付けば、アジャイル開発を実践していた
発注者の特徴とパートナー企業に与えた影響（２） ■アジャイル＋研究開発事例
56
事例からみた発注者の人物像
57
成功する発注者の心構え
発注者
スクラム
マスター
アジャイル
コーチ
ＰＭ 業務
チーム
開発
チーム
仕様や プロダクトバックログの作成
を サポート
プロセス面、 教育面を サポート
各調整や コスト管理等 をサポート
仕様調整や プロダクトバックログの作成をサポート
プロセス面、 教育面を サポート 技術面を
サポート
ご清聴ありがとうございました。
www.ogis-ri.co.jp
株式会社 オージス総研
top related