Agile66 - 新人研修でガチアジャイル

66人の新入社員を相手に、アジャイル開発でアプリ開発トレーニングを実施したときの研修内容や、その結果についての発表です。

Transcript

1. 1 1 1 1 Development Department Architetcutre & Core Technology Section Architect Group Dai Fujihara June 27th, 2010 Agile 66 〜 〜 〜 〜 新人研修 新人研修 新人研修 新人研修で で で でガチアジャイル ガチアジャイル ガチアジャイル ガチアジャイル〜 〜 〜 〜 Development Unit Architetcutre & Core Technology Section Architect Group Dai Fujihara Nov 18th, 2010
2. 2 2 2 2 藤原 大 （@daipresents） アーキテクチャ＆コアテクノロジー課所属 普段は標準化とか、移行とか、 ライブラリとかしています Facebook：Dai Fujihara Web: フジハラボ http://daipresents.com/weblog/fujihalab/ About Agile 自分のチームで、2009年はXP、2010年はScrumなど実践トライアルし ています 2010年にAgile Conference に初参加 「エンタープライズAgile」を模索中
3. 3 3 3 3 今年の新人研修の物語 http://www.flickr.com/photos/nicmcphee/250890495/ どんなことをやったのか？ どんなことが起こったのか？ 歩いた道をふりかえり
4. 4 4 4 4 どんなことをやったのか？
5. 5 5 5 5 位置づけ ビジネス基礎 IT基礎 現場への導入支援研修 ＜＜ ココを担当 OJTへ・・・ 規模 人数：６６名 チーム：１１チームで作業 期間：２週間
6. 6 6 6 6 基礎能力の向上 技術力の向上 サービスマインドの向上 http://www.flickr.com/photos/matsukawa1971/32851645/
7. 7 7 7 7 継続的な改善活動 自己組織化されたチーム 価値にこだわったサービス開発 http://www.flickr.com/photos/soldiersmediacenter/3362000495/
8. 8 8 8 8 １日目 楽天の開発を学ぶ 開発環境を作る ２日目 計画を立てる・見積もる ３日目～９日目 アプリを作る 最終日 研修のふりかえり
9. 9 9 9 9
10. 10 10 10 10 ストーリーを 洗い出す 価値を確認 分割 見積り 優先順位付け
11. 11 11 11 11 タスクボード作成 スケジュール作成 担当決め 再見積りの方法 バーンダウンチャート作成 ポイントは みればわかる事をしない 一気に伝える
12. 12 12 12 12 見積りと実績ができているか？ ストーリポイントや進捗管理表から判断する 健康的な開発ができているか？ アラートメールから判断する 価値を付加出来ているか 動く画面から判断する 品質をつくりこんでいるか？ テスト数（UTと画面）から判断する ホウレンソウができているか？ 報告チェックから判断する
13. 13 13 13 13 Wiki検索アプリケーション
14. 14 14 14 14 開発 開発 開発 開発の の の の流 流 流 流れ れ れ れ 朝礼 デイリーリリース ふりかえり 計画と見積りの確認 リリース報告 日次報告 いつでもデモできるように作るべし リリースは17時までに実施するべし テストはかならずするべし 開発
15. 15 15 15 15 どんなことが起こったのか？
16. 16 16 16 16 参考 参考 参考 参考： ： ： ：http:// http:// http:// http://weathernews.jp weathernews.jp weathernews.jp weathernews.jp
17. 17 17 17 17
18. 18 18 18 18
19. 19 19 19 19
20. 20 20 20 20
21. 21 21 21 21
22. 22 22 22 22 ホウレンソウチェック 0 2 4 6 8 10 12 14 16 18 1日目 2日目 3日目 4日目 5日目 6日目 7日目 8日目 9日目 日数 ミスポイント 報告ミスの数 慣れるまでに時間がかかっ たが、後半は全員が意識す ることにより報告漏れが減少 した。 最終日にミスが出たのが残 念。 •朝礼から日報まですべての報告を行わせ、報告漏れを確認
23. 23 23 23 23 １ １ １ １
24. 24 24 24 24 ２ ２ ２ ２
25. 25 25 25 25 ３ ３ ３ ３
26. 26 26 26 26 ４ ４ ４ ４
27. 27 27 27 27 ５ ５ ５ ５
28. 28 28 28 28 ６ ６ ６ ６
29. 29 29 29 29 予想以上にタスクを 消化できず見積りを 修正。 消化が順調にできる と判断し、タスクを増 やす。 最終日は確実 にコミットを意識。
30. 30 30 30 30
31. 31 31 31 31 開発スピード 0.00 0.20 0.40 0.60 0.80 1.00 1.20 4日目 5日目 6日目 7日目 8日目 9日目 見積り精度 計画と見積りが全体的に弱く、見積りを下回 る日が続いたが、日に日に開発スピードを上 げ、最終日に完了させる意識が強くなった。 •見積の精度は、（実績 / 見積もった量 * 100） で計算し、開発スピードの指標としている •1.0だと見積りぴったりとなり、１より低いと、見積りまで達成していないと判断できる
32. 32 32 32 32 バーンダウンチャート 0 500 1000 1500 2000 2500 合計 4日目 5日目 6日目 7日目 8日目 9日目 実績 •はじめに見積もった見積りにたいして、実績値を測定。最終日にすべての予定が消化できるかを見える化 •青い点線は理想の予定直線 消化予定の作業に関しても、 予定に達することが出来ず、 計画の見直しが多く発生してい た。
33. 33 33 33 33 テスト数 0 50 100 150 200 250 ５日目 ６日目 ７日目 ８日目 ９日目 日数 ポイント テストケース数 •品質を作り込むことに重点をおきたいので、単体テスト（UT）のテスト数を計測 単体テスト数は順調に増加。最終 日前に全チームがテストを作成し、 １時間ごとのビルドにて品質を確 認することができた。
34. 34 34 34 34 開発初期から安定するまで時 間がかかったが、その後、 ソースコードが安定させること ができている。 一時的にビルドが失敗してい るが、アラートメールによって すぐに対応・リカバリに成功し ている。 ソースコードが安定しているかどうかグラフ
35. 35 35 35 35 アラートメール数 0 5 10 15 20 25 30 35 40 45 ５日目 ６日目 ７日目 ８日目 ９日目 日数 ポイント アラートメール数 •いつでもリリース可能なアプリケーションを作成出来ているかを、CIサーバを利用して確認した •CIサーバ上でビルドを定期的（１時間に１回）に実行し、失敗したときにメールで通知。失敗メールをアラートメールとしてカウント ビルドの失敗が徐々に改善さ れていき、アラート数は減少し ていった。 ただし、コミット時の競合＞ マージに慣れておらず、結合 時のミスは定期的に発生して いた。
36. 36 36 36 36 リリーストラブル 0 1 2 3 4 5 6 7 4日目 5日目 6日目 7日目 8日目 9日目 トラブル数 •開発期間中、毎日リリースを実施させ、トラブルの発生状況を確認 リリースを安全にするため、機能追加を抑えて実行す るチームもあったが、積極的にリリースを行ない、随時 改善しているチームもあり、全体で見ると緊張感を持っ て作業している印象があった。 しかし、最終日に全チームリリース成功は達成できず。
37. 37 37 37 37 0 30 60 90 基本動作（ホウレンソウ） 計画と見積り力 チーム力 サービス力 品質
38. 38 38 38 38 価値のリリース 毎日、FBを得る 毎日、改善する 毎日、価値がリリースされる 次ページよりその例
39. 39 39 39 39 価値 価値 価値 価値の の の のリリース リリース リリース リリース１ １ １ １
40. 40 40 40 40 価値 価値 価値 価値の の の のリリース リリース リリース リリース２ ２ ２ ２
41. 41 41 41 41 価値 価値 価値 価値の の の のリリース リリース リリース リリース３ ３ ３ ３ 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文 タイトル タイトル タイトル
42. 42 42 42 42 価値 価値 価値 価値の の の のリリース リリース リリース リリース４ ４ ４ ４ 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文 タイトル タイトル タイトル タイトル タイトル 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文
43. 43 43 43 43 価値 価値 価値 価値の の の のリリース リリース リリース リリース５ ５ ５ ５ 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文 タイトル タイトル タイトル タイトル 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文
44. 44 44 44 44 価値 価値 価値 価値の の の のリリース リリース リリース リリース６ ６ ６ ６ タイトルタイトル タイトルタイトル タイトルタイトル タイトルタイトル
45. 45 45 45 45 価値 価値 価値 価値の の の のリリース リリース リリース リリース７ ７ ７ ７
46. 46 46 46 46 価値 価値 価値 価値の の の のリリース リリース リリース リリース８ ８ ８ ８ リリースノート Release Release Release Release 1 1 1 1 [Feature] Top Page. Release 2 Release 2 Release 2 Release 2 [Modified] Top Page Design. Release 3 Release 3 Release 3 Release 3 [Modified] Top Page Design. [Feature] Search result page. [Feature] I'm Feeling Mickey search. [Feature] View Hit number. [Feature] View Highlight. Release 4 Release 4 Release 4 Release 4 [Feature] View search result contents. [Feature] New register page. Release 4.1 Release 4.1 Release 4.1 Release 4.1 [Modified] Search Result Page. [Modified] View Highlight. Added “AND search” [Feature] Search result number setting for top page. [Modified] Layout bugs. [Modified] Added JUnit test case. [Feature] Paging. [Feature] Blank search. Release 4.2. Release 4.2. Release 4.2. Release 4.2. [Modified] Search result page. [Modified] View Highlight. Added “AND search” [Modified] Search result number setting. [Modified] Layout bugs. [Modified] Added JUnit test case. [Modified] Paging. [Modified] Blank search. Release 4.3 Release 4.3 Release 4.3 Release 4.3 [Feature] Useful article ranking. [Feature] Search result number setting for result page. [Modified] New register modify page. Release 5.1 Release 5.1 Release 5.1 Release 5.1 [Feature] Bookmark. Release 5.2 Release 5.2 Release 5.2 Release 5.2 [Feature] Bookmark category. [Feature] Useful article ranking search. [Modified] Useful page design.
47. 47 47 47 47 たくさんのブログ（報告書） たくさんのコメント
48. 48 48 48 48 本日の学びは、ストーリーの洗い出しにおいて、 単にブレストのように意見を出し合うだけでなく、 そのストーリーがユーザーにどのような「価値」を 与るのかという点に着目できた点です。これによ り短時間で生産的な議論ができるようになったと 思いました。
49. 49 49 49 49
50. 50 50 50 50 歩いた道をふりかえり
51. 51 51 51 51 http://www.flickr.com/photos/bigtallguy/2492489993/ 動機
52. 52 52 52 52 http://www.flickr.com/photos/bigtallguy/2492489993/ 動機 未知数の若者６６人 想像と現実のギャップ 研修は厳しくて楽しい 伝えたいことの本質
53. 53 53 53 53 http:// http:// http:// http://agilemanifesto.org/iso/ja agilemanifesto.org/iso/ja agilemanifesto.org/iso/ja agilemanifesto.org/iso/ja/ / / /
54. 54 54 54 54 http://www.flickr.com/photos/augustinbrunault/1346791148/ 工夫や悩み
55. 55 55 55 55 http://www.flickr.com/photos/augustinbrunault/1346791148/ 工夫や悩み 工夫 周囲の理解 チームのサポート 悩み どこまで必死にさせることができるか？ どこまで必死になることができるか？ 予期せぬトラブル
56. 56 56 56 56 Next Step http://www.flickr.com/photos/kirtaph/2206974242/
57. 57 57 57 57 Next trap http://www.flickr.com/photos/jronaldlee/4558908367/
58. 58 58 58 58 Next Trap http://www.flickr.com/photos/jronaldlee/4558908367/ 選択の自由 Agile or Waterfallではない 改善する価値と何のために改 善するか 理想と現実のギャップ
59. 59 59 59 59 だから、種をまいてみた http://www.flickr.com/photos/samcatchesides/3346652611/
60. 60 60 60 60 未来を選べ http://www.flickr.com/photos/gcode/2898511015/
61. 61 61 61 61
62. 62 62 62 62 http://capsctrl.que.jp/kdmsnr/diary/20100225.html
63. 63 63 63 63 ドキュメント 佐賀県庁でもできる！プロジェクトファシリテーション 実践知のリーダシップ～スクラムと知の場作り @ @ @ @kawaguti kawaguti kawaguti kawaguti @ @ @ @nawoto nawoto nawoto nawoto @ @ @ @kakutani kakutani kakutani kakutani @ @ @ @hiranabe hiranabe hiranabe hiranabe @ @ @ @kuranuki kuranuki kuranuki kuranuki
64. 64 64 64 64 × × × × Have Have Have Have a good development! a good development! a good development! a good development!