20130320 agile pm

1,647 views
1,443 views

Published on

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,647
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
1
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

20130320 agile pm

  1. 1. アジャイルプロジェクトマネジメント研究会 準備プロジェクト (株)アットウェア 木村 事例発表 2013/03/21 ©2013 atWare,Inc
  2. 2. Copyright© 2010 atWare,Inc. All rights reserved.2
  3. 3. 自己紹介 株式会社 アットウェア 木村 卓央 KIMURA Takao tw_takubon http://facebook.com/kimura.takao
  4. 4. ひとつの案件について ©2013 atWare,Inc
  5. 5. 導入のきっかけサービスのリリースまでに時間が掛かる ©2013 atWare,Inc
  6. 6. 導入の進め方アジャイル開発プロセス導入支援組織•⽬目標設定•定例例会議(毎週)•個別ヒヤリングアジャイル開発プロセス導入プロジェクトアジャイル Sprint  0 Sprint基礎研修•アジャイル基礎研修 •インセプションデッキ作成 •スプリント計画ミーティング•スクラム基礎研修 •ストーリー収集 •デイリースクラム•ワークショップ •ストーリーマッピング作成 •開発作業 •開発プロセス •ストーリーの⾒見見積もり •スプリントレビュー •TDD •環境構築 •ふりかえり •プランニングポーカー •技術検証(スパイク) •アーキテクチャ選定 •Doneの定義設定 準備期間(1w) Sprint0(2w) Sprint(2w)※目標設定で設定した目標に対して、定例会議にて定期的に評価して頂きます。 ©2013 atWare,Inc http://www.atware.co.jp/agilecoach/
  7. 7. プロジェクトスケジュール 準備 スプリント0 スプリント開始 スプリント0 スプリント1∼• PO • KickOff • 開発開始 • インセプションデッキ • インセプションデッキ共有 • ストーリー収集 • ストーリーマッピング共有 • 画面デザイン検討 • PO & 開発チーム • リリース計画 • 全体ストーリー見積もり • 開発チーム • Doneの定義を決定 • 開発環境構築 • スパイク(技術検証) • PO(デザイナー含む) • ストーリー収集 • 画面デザイン作成 ©2013 atWare,Inc
  8. 8. 準備フェーズ ©2013 atWare,Inc
  9. 9. 開発プロセスはスクラムを導入 The Scrum TeamThe Product Owner The Scrum Master The Development Team ©2013 atWare,Inc
  10. 10. 体制プロダクトオーナー 開発チーム デザイナー お客様 スクラムマスター ©2013 atWare,Inc
  11. 11. アジャイルソフトウェア開発宣言 ©2013 atWare,Inc http://agilemanifesto.org/iso/ja/
  12. 12. mの 概要S cru janBNZ flick r - Dam ©2013 atWare,Inc
  13. 13. 我われはなぜここにいるのか エレベーターピッチ パッケージデザイン • [潜在的なニーズを満たしたり、• 大事な理由その1 潜在的な課題を解決したり] したい (プロダクトの名前)• 大事な理由その2 • [対象顧客] 向けの、 • [プロダクト名] というプロダクトは、• 大事な理由その3 (素敵な写真) • [プロダクトのカテゴリー] です。 • これは [重要な利点、対価に見合う説得力のある (最高のキャッチコピー) 理由] ができ、 <このプロジェクトの根幹に • [代替手段の最右翼] とは違って、 (ユーザーへのアピールその1) (ユーザーへのアピールその2) 関わる理由を1つ、ここに書く> • [差別化の決定的な特徴] が備わっている。 (ユーザーへのアピールその3)やらないことリスト プロジェクトコミュニティは... やる やらない (ほげほげ部門) (他のチーム) コアチーム (○○グループ) あとで决める 関係者全員を! インセプションデッキ ...思っているよりもずっと大きい!技術的な解決策の概要 夜も眠れなくなるような問題は何だろう? 期間を見極める • もし起きたらこわーいこと、その1 リリース! • もし起きたらこわーいこと、その2 構築 受入テスト トレーニング 3ヶ月 1週間 1週間 • もし起きたらこわーいこと、その3採用する技術: あくまで推測であって、確約するものではありません。* <プログラミング言語>* <ライブラリ> ←リスクがある箇所* <ツール>* <その他の要素技術> ←今回は対象外トレードオフ・スライダー 俺たちの Aチーム 典型的なフォース 人数 役割 強みや期待すること MAX MIN 機能をぜんぶ える(スコープ) 1 アナリスト 必要な分だけ必要なときに分析するスタイルで働ける。 テストも喜んで手伝える。 MAX MIN 予算内に収める(予算) 素早い繰り返し型の開発スタイルで働ける。 2 開発者 C#、MVC.NET、jQuery、SQL MAX MIN 期日を死守する(時間) ユニットテスト、リファクタリング、TDD、 継続的インテグレーション MAX MIN 高い品質、少ない欠陥(品質) 0.5 マネージャ 顧客と直接顔を合わせてのコミュニケーションを担当する。 上記以外で重要なこと 状況報告、スコープ調整、予算管理、レポートラインへの報告 MAX MIN 簡単に使える MAX MIN 考えさせない! MAX MIN 詳細な証跡(なんでもログを取る) MAX MIN (などなど) ©2013 atWare,Inc
  14. 14. ストーリー収集•ストーリーの書き方の説明•ビジネス価値の重要性•まずは一緒に書いてみる ©2013 atWare,Inc
  15. 15. ペルソナそれっぽい名前 コンテキスト: アプリを使い始めたきっかけこの人の情報について 影響または価値• どこに住んでいて • 価値がありそうな機能• 趣味はどんなことやっていて • 製品の特徴などを書く• 普段はどういう生活をしていて s am ple ©2013 atWare,Inc
  16. 16. Kick Off ©2013 atWare,Inc flickr - Sum_of_Marc
  17. 17. 我われはなぜここにいるのか エレベーターピッチ パッケージデザイン • [潜在的なニーズを満たしたり、• 大事な理由その1 潜在的な課題を解決したり] したい (プロダクトの名前)• 大事な理由その2 • [対象顧客] 向けの、 • [プロダクト名] というプロダクトは、• 大事な理由その3 (素敵な写真) • [プロダクトのカテゴリー] です。 • これは [重要な利点、対価に見合う説得力のある (最高のキャッチコピー) 理由] ができ、 <このプロジェクトの根幹に • [代替手段の最右翼] とは違って、 (ユーザーへのアピールその1) (ユーザーへのアピールその2) 関わる理由を1つ、ここに書く> • [差別化の決定的な特徴] が備わっている。 (ユーザーへのアピールその3)やらないことリスト プロジェクトコミュニティは... やる やらない (ほげほげ部門) (他のチーム) コアチーム (○○グループ) あとで决める 関係者全員を! インセプションデッキの共有 ...思っているよりもずっと大きい!技術的な解決策の概要 夜も眠れなくなるような問題は何だろう? 期間を見極める • もし起きたらこわーいこと、その1 リリース! • もし起きたらこわーいこと、その2 構築 受入テスト トレーニング 3ヶ月 1週間 1週間 • もし起きたらこわーいこと、その3採用する技術: あくまで推測であって、確約するものではありません。* <プログラミング言語>* <ライブラリ> ←リスクがある箇所* <ツール>* <その他の要素技術> ←今回は対象外トレードオフ・スライダー 俺たちの Aチーム 典型的なフォース 人数 役割 強みや期待すること MAX MIN 機能をぜんぶ える(スコープ) 1 アナリスト 必要な分だけ必要なときに分析するスタイルで働ける。 テストも喜んで手伝える。 MAX MIN 予算内に収める(予算) 素早い繰り返し型の開発スタイルで働ける。 2 開発者 C#、MVC.NET、jQuery、SQL MAX MIN 期日を死守する(時間) ユニットテスト、リファクタリング、TDD、 継続的インテグレーション MAX MIN 高い品質、少ない欠陥(品質) 0.5 マネージャ 顧客と直接顔を合わせてのコミュニケーションを担当する。 上記以外で重要なこと 状況報告、スコープ調整、予算管理、レポートラインへの報告 MAX MIN 簡単に使える MAX MIN 考えさせない! MAX MIN 詳細な証跡(なんでもログを取る) MAX MIN (などなど) ©2013 atWare,Inc
  18. 18. Doneの定義何をもって完了かを定義する ©2013 atWare,Inc
  19. 19. Doneの定義•作業の完了について共通の理解•ストーリーのDoneの定義、スプリ ントのDoneの定義、リリースの Doneの定義•スクラムチームの成熟度によって変 わる ©2013 atWare,Inc
  20. 20. ストーリーの完了の定義 ソースコード・テストコードがコミットされている事 コードレビューが完了していること リファクタリングされていること 全てのユニットテストをパスしていること 全ての受け入れテストが用意され、それにパスしていること サーバーにデプロイされていること 討 済 ©2013 atWare,Inc 検
  21. 21. スプリントの完了の定義 全てのストーリーの完了の定義が満たされていること 全てのバグが解決しているか、対応時期が決定されていること 未解決の問題に対して方針が決まっている事 ステークホルダーにも確認出来る状態にある事 討 済 ©2013 atWare,Inc 検
  22. 22. 本番リリースの完了の定義 以下のドキュメントが作成されていること デプロイ手順書 障害復旧手順書 全てのテストがパスしていること 負荷テストに合格していること セキュリティテストに合格していること マーケットアップの準備が整っている事 リポジトリーにリリース用のタグ・ブランチが切られていること 検 討 要 ©2013 atWare,Inc
  23. 23. スプリント開始 ©2013 atWare,Inc
  24. 24. スプリント 月 火 水 木 金10:15 デイリースクラム 15分10:3013:00 スプリント 火〜火の1週間 レビュー スプリント 1時間14:0014:10 スプリント レトロスペクティブ スクラムイベント15:10 1時間 を火曜日に集約15:30 スプリント プランニング1部 1時間16:3016:40 スプリント プランニング2部 1時間17:40 ©2013 atWare,Inc
  25. 25. スプリント計画ミーティング ©2013 atWare,Inc flickr - d.mosher
  26. 26. デイリースクラム ©2013 atWare,Inc flickr - TomNatt
  27. 27. スプリント・レビュー ©2013 atWare,Inc flickr - Improve It
  28. 28. スプリント・レトロスペクティブ ©2013 atWare,Inc
  29. 29. 見える化(スクラムボード他) ① ③ ② ④ ⑤ ⑥ ©2013 atWare,Inc
  30. 30. 見える化(タスクかんばん) ⑦ ⑧ ©2013 atWare,Inc
  31. 31. 採用プラクティス• インセプションデッキ・・・写真③ • このプロジェクトのゴールは何か?等を明確にする• CI(継続的インテグレーション) • 自動ビルド&テストを実行することで、デグレートを防止し、品質を確保 する• ペアプロ• ペルソナ • 仮想のユーザーを定義し、サービスの利用者を想定する• 見える化 • タスクかんばん・・・写真⑧ • タスクの進 状況を見える化する • ストーリーボード・・・写真② • ストーリーの進 状況および優先順位を見える化する • バーンダウンチャート・・・写真⑤ • スプリントの進 状況を見える化する• インピーディメントリスト・・・写真④ • 作業を進めて行く上での問題点を見える化する ©2013 atWare,Inc
  32. 32. 採用ツール•Git•Jenkins•JIRA•TestLink ©2013 atWare,Inc
  33. 33. ベロシティ50"45"40"35"30"25" ( )"20"15"10" 5" ▲新規メンバー参画 ▲新規メンバー参画 0" Sprint1" Sprint2" Sprint3" Sprint4" Sprint5" Sprint6" Sprint7" Sprint8" Sprint9"Sprint10"Sprint11" print12" print13" print14"Sprint15" print16"Sprint17" S S S S ©2013 atWare,Inc
  34. 34. POの暴走! POの思いつきを抑える必要があります。 デザインをもっと この人はこんな使 こうしたいなぁ い方しますか?ここをこうした こんな機能も 本当に必要 優先順位を いなぁ 欲しいなぁ ですか? 考えて下さい 係 ! 頼 関 の 信 O と P PO TEAM SM ©2013 atWare,Inc
  35. 35. 開発チームの暴走•リファクタリングの時間で作りなお して壊したままに。。。•PBLの優先順位を意識しないで開発 ビジネス価値を•完了していないストーリーがリリー スに含まれている 第一に考える•タスクを消化する事が目的になりが ち 開発チーム SM ©2013 atWare,Inc
  36. 36. 難しいと感じた•デザイナーとの共同作業 http://msdn.microsoft.com/en-us/magazine/dd882523.aspx ©2013 atWare,Inc
  37. 37. 見学者たちの声こんなクリエイティブ 本で読んだだけでは、な会議初めて見ました わからないですね実際にやってるん 是非、ですねw うちでもやってみたい! ©2013 atWare,Inc
  38. 38. Agile Project Management ©2013 atWare,Inc
  39. 39. マネジメントの観点•プロダクトの責任はPO •リリース計画等はPOが検討 •当然、サポートはします•チーム •バーンダウンチャート、スクラム ボードで見える化 •基本的には自己組織化 ©2013 atWare,Inc
  40. 40. 品質からの観点•完了の定義により何を持って完了と するかを定義する•出来る限り自動化 •Jenkinsによる自動テスト•コストが高いUI部分についてはリグ レッションテストを実施•毎回結合、毎回テスト ©2013 atWare,Inc
  41. 41. アットウェアのアジャイルへの取り組み ©2013 atWare,Inc
  42. 42. アジャイル開発実績• 2007-2008 • ECサイトリプレイス • 開発チーム 最大40名 • 主にXP• 2010 • 基幹システムリプレイス • サブプロジェクト担当 最大12名 • 主にScrum• 2012 • Androidアプリ(端末-Web) • 開発チーム 4名 • Scrum • Androidアプリ(端末-Server) • 大規模プロジェクトの1部をScrumチーム(開発チーム4名)として(2013.03) • 社内の各部署横断的にPOチームを設立 • Scrum• 2013 • Androidアプリ(端末) • 開発チーム 4名 • Scrum ©2013 atWare,Inc
  43. 43. 契約形態•80%一括請負契約 •期間を短く設定 •成果物が変更される事は事前に合 意済み•20%準委任契約 •期間を短く設定 •残業が当り前の現場だとタイムボ ックスでの作業に異論が出た ©2013 atWare,Inc
  44. 44. アットウェアの取り組み•アジャイル導入支援•開発プロセス改善コンサルティング•アジャイルでの受託開発 ©2013 atWare,Inc
  45. 45. アジャイル導入支援顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供出来るチームを作る •役割について説明 •開発プラクティスサポート プロダクトオーナー 開発チーム •役割について説明 •ストーリー収集サポート •役割について説明 •振る舞いについてサポート スクラムマスター アジャイルコーチ ©2013 atWare,Inc
  46. 46. 初期導入(例)アジャイル開発プロセス導入支援組織•⽬目標設定•定例例会議(毎週)•個別ヒヤリングアジャイル開発プロセス導入プロジェクトアジャイル Sprint  0 Sprint基礎研修•アジャイル基礎研修 •インセプションデッキ作成 •スプリント計画ミーティング•スクラム基礎研修 •ストーリー収集 •デイリースクラム•ワークショップ •ストーリーマッピング作成 •開発作業 •開発プロセス •ストーリーの⾒見見積もり •スプリントレビュー •TDD •環境構築 •ふりかえり •プランニングポーカー •技術検証(スパイク) •アーキテクチャ選定 •Doneの定義設定 準備期間(1w) Sprint0(2w) Sprint(2w)※目標設定で設定した目標に対して、定例会議にて定期的に評価して頂きます。 ©2013 atWare,Inc
  47. 47. 開発プロセス改善コンサルティング開発プロセスのムダを無くせるとしたらどうですか お客様のこうなりたいと⾔言ったビジョンをお聞きします 現状の開発プロセスについて、現場の⽅方々にイ ンタビューさせて頂き、現状の開発プロセスの 把握を⾏行行います 現状の開発プロセスとお客様のビジョンとのギャップを洗い出します。 お客様のビジョンとのギャップについてお客様にご呈⽰示させて頂き、今後の 改善案についてご提案させて頂きます。 現在の開発プロセスに疑問を持っているお客様に対して、現状の開発プロセス の問題を洗い出し、改善案をご提案いたします。 ©2013 atWare,Inc
  48. 48. 作業例現状調査した結果を、貴社ビジョンに基づき改善策を検討します。現場のメンバーにもディスカッションに参加して頂く事により、より精度の高い改善策をご呈示する事が出来ます。•ビジョン確認•定例例会議(毎週)現状調査 改善策検討 •現場ヒヤリング •改善策についてディスカッション 最終報告 •現場確認 •改善策調査 •現状調査結果についてディスカッション •改善策についてディスカッション •最終報告書を ご呈⽰示 現状調査(2w) 改善策検討(2w)※目標設定で設定した目標に対して、定例会議にて定期的に評価して頂きます。 ©2013 atWare,Inc
  49. 49. アジャイルでの受託開発 アジャイル経験値の高い弊社開発チームとお客様と 連携して開発を行います •ヒアリング •ストーリー収集 •アジャイル基礎講習 •ストーリーマッピング作成 •スプリント期間の設定 •インセプションデッキ作成 プロダクトオーナー •スプリント計画ミーティ (お客様) ング •ストーリーの⾒見見積もり •デイリースクラム •技術検証(スパイク) •バックロググルーミング •アーキテクチャ選定 •スプリントレビュー スクラムマスター •Doneの定義設定 •スプリントレトロスペク ティブ 開発チーム 準備期間(1週間) Sprint0(2週間) Sprint1(2週間) アジャイルコーチより良良いサービスを提供したいと考えているお客様に対して、アジャイル経験値の⾼高い弊社にてアジャイル開発を実施いたします。もちろん、お客様にも積極的に関与して頂きますが、アジャイルコーチのサポートや、弊社のプロダクトオーナーと共にプロダクトオーナーチームを編成する事も可能です。※アットウェアでは、アジャイル開発プロセスとしてスクラムを採⽤用しています。 ©2013 atWare,Inc
  50. 50. 百聞は一見に如かず ©2013 atWare,Inc

×