第3回RxTStudyで発表させていただいたRedmineを使ったタスクマネジメントの事例資料 http://atnd.org/events/22006 SpeakerDeck : http://speakerdeck.com/u/daipresents/p/redmine-redmine-applied-for-energized-team

1. チームに
Redmineを
適用せよ
Redmine Applied for Energized Team
Architecture & Core Technology Section, Rakuten, Inc.
Architect Group, Dai Fujihara, RxTstudy, Feb 4th, 2012

2. @daipresents
Dai Fujihara
lRakuten, Inc.
lJava Engineer => 標準化 =>
Team Leader => Agile Coach
l箕面出身, 趣味は離島めぐり
lWeb : http://daipresents.com/

3. http://enterprisezine.jp/author/287

4. http://daipresents.com/

5. http://codezine.jp/devsumi/2012

6. 諸注意
l 標準語ですが、東京に魂
を売っていません
l 海外の人向けに一部なれ
ない英語を使っています

7. チームに
Redmineを
適用せよ
Redmine Applied for Energized Team

8. 2008 2009
60
45
30
15
0イントロ 08’ ~ 09’ 10’ 11’ Now Future

9. 3 members
l 2008 July No Name
l Work : Standardization
l Practice : None
l Tool : Memo, Note
l Problem : Communication

10. Problem
l No Task
Management
l Selfish Team
l No Goal

11. 3 7 members
l 2009 Niko Team
l Work : Library Release
l Practice : XP
l Tool : Redmine, ReviewBoard,
Wiki, CI, Source Search

12. Problem
l Member++++++
l Need more
Leadership
l ばらばら感（ Lack of
Coherence）

13. All Time Team
Plugin
l Check this in the Weekly MTG
l 働いていない人を見える化
(Visualize a person
who has not worked)
http://daipresents.com/2009/redmine_all_time_team_plugin/

15. Result
l 進捗の見える化に成功
l 飲み会++++
l出費++++

16. 2010
60
45
30
15
0イントロ 08’ ~ 09’ 10’ 11’ Now Future

17. 6 7 members
l 2010 A-Team
l Work : Refactoring, Challenge
l Practice : XP + Scrum
l Tool : Redmine, CI, Automation

18. Problem
l Poor Task
Management Skill
l Doneしないタスク増加
l 運用作業の圧迫

19. Parking Lot
Chart Plugin
l Success!!
l Share to Business Team
l Locale = DE, EN, JA, KO
http://daipresents.com/2010/redmine_parking_lot_chart_plugin/

24. l 工数管理は途中で止めた
l データ統計を出せば課題点を見つけることができる

26. Result
l 成果の見える化に成功
l 時間コストの見える化に
成功
l 徐々にRedmineが浸透
l チーム力増加

27. Users 1000
600
100

28. 2011
60
45
30
15
0イントロ 08’ ~ 09’ 10’ 11’ Now Future

29. 6 20 members

30. No Redmine
l Because of
lDouble Cost
lHands on Training
lLow Cost

31. 徹底的に見える化！
Visualization

34. Result
l Good Meeting
l Motivation Up
l Self Organization
Team

35. No Redmine
l Because of
lTrackingログが大切だった
l開発ノウハウはWikiになった
lあとはソースとテストで十分

36. Task Size
l Every thing is different
l My Team => 2 Weeks
l Story => Max 2Weeks
l Task => 3 4day

37. Reference
l 1weekに１回ふりかえりをする場合
タスクは１∼２日で定義
l 毎日の朝礼で、一人１つが終わるのが
理想。宣言になる
l １日以下の作業ははりつけない
l どんどんDONEになる動き見たい

38. Now
60
45
30
15
0イントロ 08’ ~ 09’ 10’ 11’ Now Future

39. lFrom Jan, 2008
lIssues 160,000 over
lProjects 2500 over
lUsers 4100 over

40. トレーニング！
l Ruby + Agile
l New Team Leader
l Continuous Delivery

41. What is Task?
lView
lSize
lMeanings
l...

42. http://www.slideshare.net/hiranabe/now-past-and-future-of-agile-development-and-xp

43. http://j.mp/urN1fF

44. Task Size
Feature イテレーション リリースできる
Release Cycle
リリース 最小サイズの
ソフトウェア
有効な
Development Cycle
製品パーツ
Resource : Jeff Patton Passionate Product Ownership http://www.agileproductdesign.com/

45. What is Task?
l Feature = Release * X
l Release = Iteration * X
l Iteration = Task * X
l Task

46. Redmine
lFeature => Project?
lRelease => Project?
lIteration => Version
lTask => Issue

47. User Story Mapping 無敵説

48. @kdmsnrさん最強
http://www.slideshare.net/kdmsnr/20111022-userstoryfirstgeneration?player=js

49. ユーザーストーリー
l As a <user type>
l I want to <achieve a goal>
l So that I can <get some value>
l きっかけとなるもの
l 対話からストーリーを洗練
http://www.slideshare.net/SukusukuScrum/no01101suc3rum20100225

50. スプリングボードストーリー
Amazon.co.jp： ユーザエクスペリエンスのためのストーリーテリング -よりよいデザインを生み出すストーリーの作り
方と伝え方 -: Whitney Quesenbery, Kevin Brooks, UX TOKYO: 本 http://amzn.to/yzax3r

51. リリースを自動化せよ

52. リリースを自動化せよ
1日10回リリースせよ

53. Future
60
45
30
15
0イントロ 08’ ~ 09’ 10’ 11’ Now Future

54. Recommend
l Redmineにあわせることも
l 使い方と考え方のレクチャー
は必須
l 捨てるときは潔く

55. Future
l To Tool Suites
l 問い合わせや、やり取り系管理は
残っていくだろう
l 価値あるソフトウェアへの探求の1
つとしてタスクを考えていく

56. 個人と対話が重要
Individuals and interactions over processes and tools
http://agilemanifesto.org/

57. なんですけど
プロセスやツールも
軽視できない（と思うよ）
But I think process and tool is important too.

58. どの？よりも
どう？よりも
なぜ使うか？
Why do you use is important to us
than how or what kind of tool do you use.