This document discusses the differences between a working group and a team. A working group has a clear leader, individual responsibilities and goals that align with the larger organization's mission. Performance is indirectly assessed based on impact to other areas. A team shares leadership, has collective responsibility and goals determined by the team. Performance is directly assessed based on results. Effective teams encourage open discussion to actively solve problems together. The definition of a team is provided as a small group with complementary skills committed to a common purpose, goals and mutual accountability. Examples of successful fictional teams are shown to illustrate.

1. Team Work
中華電信研究所 黃培棠
beta@cht.com.tw
2011/12/08

2. WE ARE A TEAM ?
2

3. Working Group or Team?
Working Group Team
• 強勢、聚焦清楚的領導人 • 成員分攤領導人的角色
• 個人的責任 • 個人和共同的責任
• 團體的目的和更廣大組織的 • 由團隊自行提出的特定團隊
使命相同 目的
• 個人的工作成果 • 集體的工作成果
• 開會很有效率 • 鼓勵開放式的討論，開會時
• 用間接方式評估團體的成效， 主動積極解決問題
像是衡量這個團體對其他事 • 直接用評估集體工作成果的
項(例如事業單位的財務績效) 方式，來衡量績效
的影響 • 一起討論、決定和實際執行
• 討論、決定和授權 工作
Jon R. Katzenbach and Douglas K. Smith, The Discipline of Teams, Harvard Business Review, July – August 2005
3
瓊．卡然巴哈、道格拉斯．史密斯，團隊力，《哈佛商業評論》 2007年11月號

4. The Definition of “Team”
• A team is a small number of people with
complementary skills who are committed to a
common purpose, set of performance goals,
and approach for which they hold themselves
mutually accountable.
– Jon R. Katzenbach and Douglas K. Smith
4

5. A Team?!
5
http://www.imdb.com/media/rm2088680704/tt0117060

6. A Team!!
6
http://trakt.tv/show/mission-impossible-1988

7. Another Team!!!
7
http://www.toptenz.net/top-10-strangest-fan-fiction-stories.php/sailor-moon

8. ONE CONTEXT
8

9. Be Passionate!
• Why are you here?
– You thought programming might pay well?
– Your parents encouraged you?
– You couldn’t think of a better major in college?
• Love It or Leave It!
– Go find a job you’re actually passionate about.
• Work because you couldn’t not work!
Chad Fowler, The Passionate Programmer, p. 69 – 71, Pragmatic Bookshelf, June 2009 9

10. Be Pragmatic!
• Put yourself in the larger context
• Take responsibility for everything you do
– Never let cat ate your source code.
• Work outside the vacuum
– Communicate!
Andrew Hunt and David Thomas, The Pragmatic Programmer: From Journeyman to Master – ch. 1, Addison Wesley, October 1999 10

11. Don’t Programming by Coincidence
• Always be aware of what you are doing
• Don't code blindfolded
– Rely only on reliable things.
– Don't guess; actually try it.
• Don't be a slave to history
Andrew Hunt and David Thomas, The Pragmatic Programmer: From Journeyman to Master - Tip 44, Addison Wesley, October 1999 11

12. Don't Reinvent the Wheel
• Wheels everywhere
– Bright young developers rarely encounter a
problem they can’t solve
– But the problems they solve have usually already
been solved by someone else.
• Show people your wheels frequently
– Coordinate and communicate every day.
– Daily meetings!
Jared Richardson and William Gualtney Jr., Ship It!, p.79 – 80, Pragmatic Bookshelf, May 2005 12

13. ONE RULE
13

14. One Preferences, One Style
• File / Import… / General / Remote Preferences
– http://10.144.113.114/eclipse/taxclipse.epf
14

15. Sign Your Work
• For pride!
– Responsible to the whole team.
– Make others easier to blame to.
• Get your personal account if you hasn’t one!
15

16. Revision Control “Blame”
16

17. Comment Your Code
• Write comments as if they were for you
– As soon as a line of code is laid on the screen,
you’re in maintenance mode on that piece of code.
• Comment your code with tags, if necessary
// FIXME 不做會挫起來的事情
// TODO 不做有損我大師風範的事
• Let your code speak for itself
17
http://www.devtopics.com/13-tips-to-comment-your-code/

18. // Commented-Out Code
• // Don’t do this!
– // There was a time, back in the sixties, when
// commenting-out code might have been useful.
• // Nowadays, just delete the code
– // We won’t lose it. Promise.
– // Revision control system will remember it.
Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship, p. 68., Prentice Hall, August 2008 18

19. Eliminate Every Warning
• Warning means something
– Bugs came from something
– 魔鬼都藏在細節裡
• Eliminate every warning in Eclipse
– Open your [Marker] View
– Quick Fix (Ctrl + 1) is your best friend
– Exclude those raised by the limit of tools
judiciously. e.g. JSP page or JavaScript code.
19
http://en.wikipedia.org/wiki/Software_bug

20. Separate Test from Main Code
• Bad smells
– System.out.println(),e.printStackTrace()…
• Redirect them to logger (with meaningful message).
– Local resources
• Bundle them as class-path resources.
– Hard-coded variable values
• Move them to database, properties, or anywhere.
– main() method
• Replace it by one or more test cases.
20

21. Test, and Then Test More
• 出來跑，不論做過什麼，遲早要還！
– 倪永孝 《無間道》
• Just do it!
21

22. ONE WAY
22

23. When Eclipse meets Maven
mvn test-compile
• Most “clean”s are just a waste of time
– Prefer Eclipse “clean” than the Maven one
– Only perform Maven “clean” if you get in trouble!
• Always run “test-compile” phase only
– Never run “package” or “install” phase manually.
23
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference

24. No More “Run As…”
• Install the “Eclipse Runner Plugin”
• Official Site: http://code.google.com/p/eclipserunnerplugin/
• Update Site : http://eclipserunnerplugin.googlecode.com/svn/trunk/EclipseRunnerSite/
24

25. ONE LIST
25

26. You Can’t Recall
• The palest ink is better than the best memory
• List everything important
– Trust ink over memory.
– List is the most natural way.
Andy Hunt, Pragmatic Thinking and Learning, p. 124, 134 , Pragmatic Bookshelf, November 2008 26

27. Work to The List
• Redmine as the List
– Publicly available (better through Mylyn)
– Prioritized
– On a time line
– Living
– Measurable
Jared Richardson and William Gualtney Jr., Ship It!, p.61, Pragmatic Bookshelf, May 2005 27

28. Issue Tracking Best Practice
28
https://github.com/csnover/TraceKit

29. Issue Tracking Best Practice (cont’d)
29
https://github.com/csnover/TraceKit

30. Valuables Derived From the List
• Wiki them down!
– Easier to share.
– Easier to find.
– Easier to update.
30

31. Revision Control Every Single Line of Code
ONE SOURCE
31

32. Comment Every Commit
• Avoid comment which says nothing at all!
XXX026W updated by beta @2011/12/6
• Be precise and exhaustive
– In the optimal case, I shouldn’t need to read your
code.
32
http://www.iovene.com/21/

33. Commit Logical Changesets
• Commit early, commit often!
– Commit as soon as your changes makes a logical
unit.
• Make sure your change reflects a single
purpose
– If your SVN comment looks like “Fixing bug #4321
and correcting typo in debug string” then you
should’ve used two commits.
33
http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html

34. Never Ever Break the Trunk
• What if my build failed after updating…
1. Keep going, nothing can stop me!
2. I am glad to fix it for you!
3. Are your tired, should I massage you for a while?
• 己所不欲，勿施於人
34

35. Automatically Build, Continuous Integration
ONE TARGET
35

36. Jenkins As Your Butler*
• Build your every commit
– Run raw build and test after every commit
• Life or die within 3 minutes
– Run static analysis after the raw build succeed
• FindBugs, PMD, CPD, Checkstyle…
• Do something boring for you
– Auto deploy to Maven repository
– Auto deploy to test Application Server
36
* http://jenkins-ci.org/content/hudsons-future

37. Rule #1
Never Fail the Build
37

38. What If I Fail the Build
• Culprit(s) will be notified. Verify and claim it
– To ease anger from others
• Fix it as soon as possible
John Ferguson Smart, Jenkins: The Definitive Guide (Creative Commons Edition), p. 202 – 203., O’Reilly Media, July 2011 38

39. Honor to Static Analysis Results
• Fix every FindBugs high priority bug
• Shape your trend graph
– Test Result and Code Coverage graph growing
– All others decreasing until they reach zero
39

40. ONE GOAL
40

41. Continuous Improve Yourself
• Code productively
– Incorporating pair-programming.
• Verify judiciously
– Automate every tests.
– Find a reviewer to sing-off your modification.
• Commit proudly
– Then pick next feature from the list and start over.
• And… go home early
41

42. 42
http://www.slideshare.net/srikanthps/scrum-in-15-minutes-presentation

43. ONE QUESTION?
43