Agile開発ツール導入の勘所 #agiletokyo

6,712 views

Published on

2012/7/18に開催されたAgile Conference Tokyoでのセッション資料です。質問n

Published in: Technology

Agile開発ツール導入の勘所 #agiletokyo

  1. 1. 吉羽 龍太郎 Ryutaro YOSHIBA アジャイルコーチ Web: http://www.ryuzee.com Twitter: @ryuzee 認定スクラムプロフェッショナル 認定スクラムマスター 認定スクラムプロダクトオーナー Microsoft MVP for Visual Studio ALM
  2. 2. Scrum Boot Camp
  3. 3. 2013/1/15-16 at Akihabara UDXScrum Regional Gathering Tokyo 2013 http://bit.ly/LtunLe
  4. 4. 環境の変化ビジネスの速度が爆速に – 新しいことを – 競争相手がやる前にチャレンジングな領域が増える – R&D – 新規サービス – それ儲かる?物事の予測の精度は? – 高いはずがない…
  5. 5. 必要なものはなんだろう?
  6. 6. 全てを予測することはできない http://bit.ly/LT89jU
  7. 7. 作り過ぎのムダ手待ちのムダ運搬のムダ加工のムダ在庫のムダ動作のムダ不良をつくるムダ
  8. 8. システムの機能の利用割合 いつも使う 7% よく使う 13 % 45 % たまに使う 16 % ほとんど使わない 19 % まったく使わないStandishの2000年の調査より
  9. 9. http://bit.ly/olku5164%の機能は、使われない
  10. 10. アジャイルマニフェスト2001年に、ケント・ベック、マーティン・ファウラー、ケン・シュウェイバーら、17人によって採択されたAgileソフトウェア開発の原則を指す。
  11. 11. アジャイルマニフェスト1. プロセスやツールより人と人同士の相互 作用を重視する。2. 包括的なドキュメントより動作するソフ トウェアを重視する。3. 契約上の交渉よりも顧客との協調を重視 する。4. 計画に従うことよりも変化に対応する ことを重視する。
  12. 12. アジャイルマニフェスト1. プロセスやツールより人と人同士の相互 作用を重視する。2. 包括的なドキュメントより動作するソフ 顧客満足を最優先し、 トウェアを重視する。 価値のあるソフトウェアを3. 契約上の交渉よりも顧客との協調を重視 する。 早く継続的に提供します。4. 計画に従うことよりも変化に対応する ことを重視する。
  13. 13. 従来型と異なるアプローチリソースと期間で総量規制
  14. 14. Scrum 複雑で変化の激しい 問題に対応するための フレームワーク
  15. 15. プロダクトオーナー スクラムマスター チーム (6±3人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタイムボックス ログアイテムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見積もり プ リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェアをデモ を話合い次に繋げる する す
  16. 16. 組み合わせフレームワークなので、他の方法論を取 り入れることが可能 State of Agile Survey 2011 ©VERSIONONE
  17. 17. 大事なものから先に! 1番目にほしい 2番目にほしい 欲しいものを 3番目にほしい リストにして 4番目にほしい 5番目にほしい 順位をつける。 順位は状況に ・ ・ ・ 99番目にほしい100番目にほしい よって変わる。
  18. 18. スプリント スプリント バックログ 計画会議第1部 計画会議第2部 グルーミング WHAT HOWPOを中心に、製品の開発に POとチームを中心にスプリ チームを中心に選択したPBI必要なPBIを作成したり、更 ントで何を作るか選択し相対 をどのようにこなすのか決め新し、並べ替える 見積を行う。不明点も明確化 実時間で見積もる 開発チームの過去 #1 #1 の速度(ベロシ ティ)をもとに取り #2 #2 組むPBIを決定。 #3 開発チームは内容 開発チームにバッ に関する質問をPO クログを供給する #4 に行う。第2部で のに必要十分なだ 作成したタスクの 実際の作業タスク。 け新たに作成した #5 合計時間がキャパ 何が出来たらタスク り更新する。それ シティを超える場 が完了するか明らか がないと開発チー #6 合は下から除外 にする。個々のタス ムは仕事ができな 受け入れ基準とス クはDoneの定義の該 い プリントレビュー 当箇所を満たす必要 で成果を検証 があるReadyなPBI ReadyではないPBI Doneの定義• 受け入れ基準が明確 • 受け入れ基準が不明確 チームとして定めた「出荷可能な製品」を作• デモ手順を決められる またはない 成するために実施しなければいけないことの• 可能な限り独立 • デモ手順が分からない 一覧。例えば、ユニットテストする、カバ• 見積可能 • 見積不可能 レージN%、リリースノートを書く等。Done• 適切な大きさ • 巨大なサイズ の定義なくしてのScrumはあり得ない。
  19. 19. 開発チームのミッションチームは出荷可能な製品の増分を作り続ける
  20. 20. 出荷可能? ここまでできれば 終わりだと思って これもあれもでき たんだけど… てないじゃない?
  21. 21. 共通理解完了の定義を作り、何をもって出荷可能かを定める。 コード ユニット チェックイン カバレージ レビュー テスト ドキュメント セキュリティ 性能 デプロイ などなど !!!! ツールの助けが必要 !!!!
  22. 22. 毎日何回も本番環境にデプロイできているか?顧客に頻繁に価値を届けられているか?
  23. 23. 継続的デリバリー 継続的デリバリー 繰り返し型の 継続的 継続的 開発 インテグレーション デプロイ継続的デリバリーとは、ソフトウェア全体のライフサイクルを通じて常にソフトウェアが本番環境にリリース可能であるということを意味する。すなわちどのビルドもボタン一発で、完全に自動化されたリリースプロセスを通じてリリースする。それによってビジネス側がビジネス状況に応じてリリース判断できるようになる。
  24. 24. 継続的デリバリー 継続的デリバリー 繰り返し型の 継続的 継続的 開発 インテグレーション デプロイ Scrum Scrum+XP Lean  要求に順位付け  xUnit等による  Just in Timeで  タイムボックス テスト自動化 顧客が必要なも による制御  テスト駆動開発 のを必要なとき  検査と適用によ  コーディング規 に。 る継続的改善 約  サイクルタイム  透明性の確保  ペアプロ等 を測定し改善す  自己組織型チー  常時出荷可能な る。 ム 品質を保持  ビジネス活動そ  技術的プラク  主に技術的プラ のもの ティスの定義な クティスから構  全体最適 し 成される
  25. 25. フィードバックループ短い時間間隔で頻繁に確認と調整を行い製品をよりよくする もちろん仕事の やり方ももっと うまくできるはず
  26. 26. Visual Studio ALM 顧客への継続的 な価値の提供 http://www.microsoft.com/visualstudio/11/ja-jp/products/alm
  27. 27. What’s ALM アプリケーション・ライフサイクル・マネ ジメント(ALM)とは、 ソフトウェア開発・保守を各アプリケー ションのライフサイクルにわたって継続的 にプロセス管理をする考え方である。 ALMは、業務管理とソフトウェア開発の融 合により、要件管理、設計、実装、検証、 バグトラッキング、リリース管理を、 ツールを使用してそれらの促進と統一化を 実現することである。 Wikipediaより引用 http://bit.ly/N3LUbj
  28. 28. 継続的フィードバック  製品価値を高めるために、プロダクト オーナーだけでなく、ステークホルダー からも継続的にフィードバックを受け取る Storyboardingを使って、要求を視覚的に整理し、 フィードバックを得やすくする。 Feedback Clientをイ ンストールすることで 音声、画面ショット等 とともにフィードバッ クするステークホルダーに製品フィードバックを要求し一元管理する
  29. 29. Team Foundation Server Process プロセスベースの クライアント Template アプローチ Team Explorer プロジェクト 管理 Office 要求管理 バージョン Visual 管理 Team SQL Studio テストケース Foundation Server Server 管理 Web ビルド自動化 Access レポート SharePoint
  30. 30. Team Foundation Server Process プロセスベースの クライアント Template アプローチ Team Explorer プロジェクト 管理 Office 要求管理  データが一元管理され、再利用可能でどこからで もアクセスできるプラットフォーム バージョン Visual 管理  プロセス中心のアプローチで、プロジェクト特性 SQL Team Studio Foundation にあわせてどのプロセスを選択するかを決める Server テストケース Server 管理  その上で継続的にプロセス改善を行える Web ビルド自動化 Access レポート SharePoint
  31. 31. プロセステンプレートScrum / Agile / CMMIの3種類のプロセ ステンプレート
  32. 32. プロセスのイメージ http://msdn.microsoft.com/en-us//library/ms400752%28v=vs.110%29
  33. 33. 例) Visual Studio Scrum 2.0 プロセスの実装 Process Template [Scrum]4週間までのスプリントの繰り返し プロジェクト 管理 [Scrum]プロジェクトの妨害事項(Impediments)の管理 要求管理 [Scrum]プロダクトバックログによる要求の優先順位付 バージョン 管理 テストケース [Scrum]スプリントバックログによる作業の分割 管理 ビルド自動化 [Scrum]バーンダウンやタスクボードによる進捗可視化 レポート [XP]バージョン管理とコードの共同所有 [XP]テスト自動化と継続的インテグレーション
  34. 34. 何故XPの概念が混ざっているか? Scrumではフレームワークの定義のみで、テスト 自動化については触れられていない.しかしアジャ イル開発においてはテスト自動化は必須 小規模リリー スのたびに手 動でテストす るとコード ベースが大き くなるにつれ てテストコス トが膨らむ自動化しないとソフトウェア規模に応じて、テスト工数の占める割合が増加してき価値への投資が減少する
  35. 35. 何故XPの概念が混ざっているか? Scrumではフレームワークの定義のみで、テスト 自動化については触れられていない.しかしアジャ イル開発においてはテスト自動化は必須 小規模リリー スのたびに手 アジャイルかウォーターフォールかという話では 動でテストす るとコード なく、現代のソフトウェアのライフサイクルを考 ベースが大き 慮すると、テスト自動化は当然の流れと言える くなるにつれ てテストコス トが膨らむ自動化しないとソフトウェア規模に応じて、テスト工数の占める割合が増加してき価値への投資が減少する
  36. 36. ツール導入アンチパターン全社で標準を作成したので○○を使え!○○で他の会社はうまくいったらしいの で使おう!
  37. 37. No Silver Bullethttp://bit.ly/vj0b0v
  38. 38. http://bit.ly/sygcE9自分たちのプロセスは自分たちで進化させるしかない!
  39. 39. http://bit.ly/sygcE9自分たちのプロセスは自分たちで進化させるしかない!もちろん、現代のソフトウェア開発プロセスの方向性については、知識 を獲得しておく必要はある!
  40. 40. ツール導入のプロセス いまのプロセスがどうなってい るかを明らかにする(現状分析) 改善したいポイントをチームで 整理する ツールでカバーした方がよい箇 所と、それ以外の箇所の整理 ROIの高い箇所から改善してい く(初期、保守、教育のコスト を踏まえる) 複数のオプションがあれば評価 する
  41. 41. 例えば要求の管理に問題? なにが問題なんだろう?なぜ問題なん だろう? あるべき要求管理はどんな方法か? それはプロジェクトに適用可能か? それはツールによってカバーできる? いままでより作業が増えたり、効率が 落ちることはないか? 投資が必要な場合、どのくらいで回収 できる?
  42. 42. 大事なこと ツールによって対面のミーティングがなくなる わけではない
  43. 43. MSにおけるデイリースクラム http://bit.ly/LGDhk6
  44. 44. 改善のミーティング 指標データ 改善に必要なデータを レポートから抽出して、 対面で議論する! (SQLServer Expressでは使えません) http://msdn.microsoft.com/ja-jp/library/dd380678(v=vs.110).aspx http://msdn.microsoft.com/ja-jp/library/dd380674(v=vs.110).aspx
  45. 45. ツール導入を成功させる みんなが分からない状態で の導入は大変 ツールとプロセスの同時学 習のコストへの考慮 導入バックログ(優先順位 付け) 社内外からのプロジェクト 支援体制の確立
  46. 46. とりあえず試してみる 2012年8月RTMとのうわさ!!! http://www.microsoft.com/visualstudio/11/ja-jp/downloads
  47. 47. とりあえず試してみる… https://tfspreview.com/
  48. 48. 最後に伝えたいこと
  49. 49. 方法論もツールも目的達成の道具!!あなたの目的はなんですか?

×