イノベーションスプリント2011...
TRANSCRIPT
Agile@IGInfragisticsにおける
世界分散型アジャイル開発事例～ communication matters ～
スライド 2
インフラジスティックス・ジャパン株式会社
デビッドクーニング
@dkeuning
いいのかな？
スライド 3
日本語でのプレゼン？Ａｇｉｌｅ？プローグラマー？
ご清聴ありがとうございます。
「おわり」
スライド 4 /4
スライド 5
前ふり
世界初のWPFコンポーネント発売
2007
インフラジスティックス・ジャパンは、設立以来20年以上プレゼンテーションレイヤーのコンポーネント産業におけるマーケットリーダーであるInfragistics, Incによって2006年に設立された日本法人です。
Infragisticsの歴史
日本法人設立
2006Silverlight対応コンポーネント発売
2009
日本にて製品販売を開始
(代理店経由)
1996Microsoft社のためIE の結合レイヤ作成
1995
VBX, OCXコンポーネント発売
1989
Infragisticsの製品ラインアップ
サブスクリプションサブスクリプションを利用して無償で新バージョンをご利用頂けます
JANUARY
FEBRUARY
MARCH
APRIL
MAY
JUNE
JULY
AUGUST
SEPTEMBER
OCTOBER
NOVEMBER
DECEMBER
JANUARY
FEBRUARY
MARCH
APRIL
MAY
JUNE
JULY
AUGUST
SEPTEMBER
OCTOBER
NOVEMBER
DECEMBER
JANUARY
FEBRUARY
MARCH
APRIL
MAY
JUNE
JULY
AUGUST
SEPTEMBER
OCTOBER
NOVEMBER
DECEMBER
1 YEARSUBSCRIPTION
RENEWfor another year at
½ PRICE
2010 VOL. 1
2010 VOL. 2
2010 VOL. 3
2011 VOL. 1
2011 VOL. 2
2011 VOL. 3
2012 VOL. 1
2012 VOL. 2
2012 VOL. 3
オフィス所在地
弊社のビジネスモデルについて
スライド 12
なぜ「Agile」？なぜ今？
• 「Agile」といっても、、、
– Agileの本を使っていない
– “Agile needs to be agile”
• 弊社のプロジェクト
– “Engineering 3.0”
スライド 13
当時の
PP
Tから
生の
SC
RU
M
Release Engineering
「Engineering3.0」とは？
• 製品ラインに沿ったチームの再編成を決定
Engineering QA
Silverlight
WPF
ASP.NET
WinForms
使った本• Agile Software Development
with SCRUM – by Ken Schwaber.
• Crystal Clear – by Alistair Cockburn.
• Lean Software Development – by Mary Poppendieck.
スライド 15
学んだこと• 社内の認識問題
• 開発cyclesでスプリントを使用
• ツールの問題
– TFS導入による成果 （グローバルな開発環境を可能に）
• “Big”な組織変更
スライド 16
その後US本社の移転
スライド 17
スライド 18
Physical変化
スライド 19
Physical変化
スライド 20
Layout 変化
スライド 21
+ +
Equipment変化
スライド 22
Office décorの変化
スライド 23
ツールについて
スライド 24
ツールについて
• Backlog 管理の進化
ツールについて• バックログの管理を TFS と VS 2010 へ移行
スライド 26
ツールについて
• 新しいビルドがいつできるのか分からない
–世界各地に点在するオフィス
• カスタムツールを作成 (TFS の API を使用)
–最新ビルドのモニタリング
–最新ビルドのダウンロードプロセスの管理
スライド 27
インフラジスティックス社員アンケート全世界のインフラジスティックス社員が「Agile」についてどう思っているか？
スライド 28
33%
62%
5%
使ったことがあった
使ったことなかった
分からない/関係ない
Infragistics入社前にAgileを使ったことありますか？
スライド 29
インフラジスティックスはAgile 開発手法に従っていると思いますか？
10%
32% 31%
8%
2%
18%
現職で Agile 手法を使用していますか？
73%
24%
3%
使っています 使っていません 分からない/関係ない
あなたのチームではどの程度□□□を活用できていますか?
スライド 32
…タイムボックス？
6%
17%
32%
2%
43%
あまりよく活用していない やや活用している よく活用している 非常によく活用している 使っていない/関係ない
…複数回の反復 (イテレーション)？
5%
16%
35%
16%
29%
あまりよく活用していない やや活用している よく活用している 非常によく活用している 使っていない/関係ない
…スクラム？
10%
21%
35%
22%
13%
あまりよく活用していない やや活用している よく活用している 非常によく活用している 使っていない/関係ない
…バックログ？
3%
21%
42%
18%
16%
あまりよく活用していない やや活用している よく活用している 非常によく活用している 使っていない/関係ない
TFS のスクラムテンプレート -現在使用していないスクラムは 5 分から 10 分 -手短にする反復、バックログ、プランニング、見積もり -すべての
アクティビティに多くのドキュメントを使用しているが、それぞれが異なる場所に保存されているため、シェアポイント、TFS など、さまざざまなシステムにある各ドキュメントをすべて把握しておくのは難しい。
エンジニアリング
入社したばかりです。
まだ２週間目で、質問に適切に答えられませ
ん。
Agile という言葉を初めて聞きました。開発部署以外にこのアンケートを送ったらどうでしょうか？
スライド 37
Agile と反復(イテレーション)
Agile では各反復の後にミーティングをして、次の反
復で何をすべきかをプランニングします。最終回の反復で開発をすべて完了、完全に機能する製品を顧客に提供し、フィードバックを得ます。弊社では、複数回の反復を含むリリースサイクルで
すべての機能を開発するようプランニングします。ただし、それぞれの反復では顧客からのフィードバックはもらいません。このような手法を真の Agile と言えるのでしょうか？
Agile と UX
Agile は定義済みの開発タスクに最も有効なメソッドです。
UX 開発や UI デザインには適していません。
Agileとマネージメント
Agile はマネージメントが自由に予
定を変更することはできても、開発納期はそのまま、すなわち管理者主体だと誤解されがちです。Agile はそのような手法ではありません。
Agileとプロジェクトの期間
Agile は、コンサルティング業
務ほど短くはないにしても、より長い期間を使用して内部で実践するのがよい。
Agileとコミットメント
ここで重要なのは、会社が Agile の実践に 100 % コミットすることです。これは、こ
の公約を実践するための適切なタスクを作成することでもあります。部分的に使用することにより、開発、QE、ドキュメン
テーション、サポートにより大きな問題を引き起こすことになります。
Agileと見積もり
アジャイルの傾向のようですが、弊社では現在のスプリントのみにフォーカスし、長期にわたるプランニングやゴールは無視されます。従って、スプリントの成果物が最終的なゴールに対するステップになるのに対して、より大きなプロジェクトは遅延していきます。
Agileと品質弊社も例外ではありませんが、リリース日が固定されている場合には、アジャイルは開発サイクルにおいて実装する機能を最初の反復から高い品質に保つ適切な手法です。また、最初の数回の反復で問題が発生した場合に、リリースに含む機能を減らすことも可能になります。
ただし、弊社は各リリースで追加する主要な機能を公表しているため、開発者はクオリティの高い機能を期日までに仕上げる必要があります。これは常に達成できるとは限らないため、品質に影響を及ぼしたり、機能を減らしたりする必要のあるケースが出てきます。このようなケースは、すでに機能を公表している場合に問題となります。
追加機能を公表しないことにより、一定の品質に満たない機能は削除したり、リリース日を明確にしないことにより、必要に応じてリリース日を変更したりできます。
Agileと生産性
アジャイル手法は、正しく機能するソフトウェアのコラボレーションと一貫した開発です。 Agile ソフトウェア開発のトレーニングにより、弊社のサービスチームの生
産性と品質を飛躍的に向上できると思います。
インフラジスティックスのエンジニアリングプロセスを定義できるとしたら
Agileを使用しますか？
はい74%
いいえ5%
わから
ない21%
スライド 46
前ふりが終わる（本論スタート）
スライド 47
Thank you!
本当に「おわり」
スライド 48
Appendix
社内の認識問題
Engineering 2.0
• 「QA」
• QA
– 非Agile
– ドキュメンテーションに過剰な依存
• すべてのミーティングは「テスト資料」について
• 上司がQA
Engineering 3.0
• 「QE」
• QE
– Agileプロセス
• 上司が開発者だと、、、
スライド 50
開発サイクルでスプリントを使用
• 弊社の製品ニーズにマッチ
• 「デイリービルド」の実現
• 反復型の開発プロセスの確立
スライド 51
ツールの問題• 当時は、反復型プロセスはなかった
– 「Engineering 3.0」 の前
• JP の製品はウォーターフォール
• ローカライズが容易ではなかった
– 「Engineering 3.0」 の後
• ビルドプロセスを向上できるツールの導入を実現
• TFS導入による成果
–グローバルな開発環境を可能に
• テスト環境
スライド 52
“Big”な組織変更
• Engineering 2.0 >> Engineering 3.0
– コミュニケーションの重要性が過小評価されていた
– すべての再編成が Agile の導入を成功させる秘訣
• Had to be a shock
– コミュニケーション！コミュニケーション！コミュニケーション！
スライド 53
現在のイシューと今後のチャレンジ
スライド 54
全世界で実現
• 異なるタイムゾーンでスクラムを実現
– タイムゾーンの「痛み」
– テクノロジーの使用 (Skype, HD ビデオ コンファレンス)
• リーダーをグローバルに雇用
– 適切な人材の確保
• グローバルで、優秀な人材
スライド 55
ビジネスプラクティスでAgile を実践
• エバンジェリズム活動に Agileを採用
– タイムボックス化
–スクラム
–成果物のフリーズ (成果物)
スライド 56
弊社のAgile実装によるROI
スライド 57
ROI: より良いQuality• バグの大幅な減尐に成功
– Engineering 3.0では、既存のバグに注力
• 提供するコード量の増加>> バグが減尐
• 開発者のテストプロセスに対する理解の向上
–より品質の高い製品の提供が可能に
• コードを理解することによりテストの質が向上
スライド 58
ROI: より良いDiscipline
Engineering 2.0
– 指示に従って作業を進める
Engineering 3.0
– スケジュールがあまり厳密でない
– スプリントリーダーによるプロセスの見直し
– リーダーによるコミュニケーションの必要性
– 委任、信頼、各個人での決定
• チームプレーヤー(協調性)
• 高い判断・決断能力
スライド 59
ROI: より良い Cooperation
• エンジニアリング>> RE >> QE間のより良いCooperation
• アカウンタビリティの向上• 強固なリレーションシップ/強い信頼
• 開発/テストのコラボレーション– オートメーションテスト
– ASP.NET テストフレームワーク– 膨大な数のプロパティテストケースシナリオ（弊社プロパティのテストシナリオは無限に近い）
– 独自テストフレームワークのアイデア化
スライド 60
ROI: より良いVisibility• マネージメントによる開発サイクルへの理解
– 1 か月サイクルを理解する
– 「問題があります」を（寛容に）受け入れる
• TFSの効果• スクラムを実践
–毎月>> ステータスの確認
スライド 61
ROI: より良いTimely Shipping
• リアルタイムコミュニケーションを推進
• デイリースクラム >>透明性の向上
• Agileでは個人個人の積極性が重要
• 特に日本に影響
スライド 62
日本でのベネフィット
• TFSの利点– すぐれたツールによる恩恵
– 継続的な円滑化
– ワールドワイドな
チェックイン/チェックアウトが可能に
• 反復バージョンによる
品質の向上– 「デイリービルド」の実現
• 月ごとにローカライズを始めることが可能に–反復型でローカライズを開始
スライド 63
http://www.microsoft.com/japan/showcase/infragistics2.mspx
弊社のAgile実装によるROI
スライド 64
ROI: より良いQuality• バグの大幅な減尐に成功
– Engineering 3.0では、既存のバグに注力
• 提供するコード量の増加>> バグが減尐
• 開発者のテストプロセスに対する理解の向上
–より品質の高い製品の提供が可能に
• コードを理解することでテストの質が向上
スライド 65