Team work
43
-
Upload
pei-tang-huang -
Category
Technology
-
view
189 -
download
1
Transcript of Team work
WE ARE A TEAM
2
?
Working Group or Team?
Working Group
• 強勢、聚焦清楚的領導人
• 個人的責任
• 團體的目的和更廣大組織的使命相同
• 個人的工作成果
• 開會很有效率
• 用間接方式評估團體的成效，像是衡量這個團體對其他事項(例如事業單位的財務績效)的影響
• 討論、決定和授權
Team
• 成員分攤領導人的角色
• 個人和共同的責任
• 由團隊自行提出的特定團隊目的
• 集體的工作成果
• 鼓勵開放式的討論，開會時主動積極解決問題
• 直接用評估集體工作成果的方式，來衡量績效
• 一起討論、決定和實際執行工作
3 瓊．卡然巴哈、道格拉斯．史密斯，團隊力，《哈佛商業評論》 2007年11月號
Jon R. Katzenbach and Douglas K. Smith, The Discipline of Teams, Harvard Business Review, July – August 2005
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
A Team?!
5 http://www.imdb.com/media/rm2088680704/tt0117060
A Team!!
6 http://trakt.tv/show/mission-impossible-1988
Another Team!!!
7 http://www.toptenz.net/top-10-strangest-fan-fiction-stories.php/sailor-moon
ONE CONTEXT
8
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!
9 Chad Fowler, The Passionate Programmer, p. 69 – 71, Pragmatic Bookshelf, June 2009
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!
10 Andrew Hunt and David Thomas, The Pragmatic Programmer: From Journeyman to Master – ch. 1, Addison Wesley, October 1999
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
11 Andrew Hunt and David Thomas, The Pragmatic Programmer: From Journeyman to Master - Tip 44, Addison Wesley, October 1999
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!
12 Jared Richardson and William Gualtney Jr., Ship It!, p.79 – 80, Pragmatic Bookshelf, May 2005
ONE RULE
13
One Preferences, One Style
• File / Import… / General / Remote Preferences
– http://10.144.113.114/eclipse/taxclipse.epf
14
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
Revision Control “Blame”
16
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/
// 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.
18 Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship, p. 68., Prentice Hall, August 2008
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
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
Test, and Then Test More
• 出來跑，不論做過什麼，遲早要還！
–倪永孝 《無間道》
• Just do it!
21
ONE WAY
22
When Eclipse meets Maven
• 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
mvn test-compile
No More “Run As…”
• Install the “Eclipse Runner Plugin”
24
• Official Site: http://code.google.com/p/eclipserunnerplugin/
• Update Site : http://eclipserunnerplugin.googlecode.com/svn/trunk/EclipseRunnerSite/
ONE LIST
25
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.
26 Andy Hunt, Pragmatic Thinking and Learning, p. 124, 134 , Pragmatic Bookshelf, November 2008
Work to The List
• Redmine as the List
– Publicly available (better through Mylyn)
– Prioritized
– On a time line
– Living
– Measurable
27 Jared Richardson and William Gualtney Jr., Ship It!, p.61, Pragmatic Bookshelf, May 2005
Issue Tracking Best Practice
28 https://github.com/csnover/TraceKit
Issue Tracking Best Practice (cont’d)
29 https://github.com/csnover/TraceKit
Valuables Derived From the List
• Wiki them down!
– Easier to share.
– Easier to find.
– Easier to update.
30
ONE SOURCE Revision Control Every Single Line of Code
31
Comment Every Commit
• Avoid comment which says nothing at all!
• Be precise and exhaustive
– In the optimal case, I shouldn’t need to read your code.
32
XXX026W updated by beta @2011/12/6
http://www.iovene.com/21/
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
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
ONE TARGET Automatically Build, Continuous Integration
35
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
Rule #1
Never Fail the Build
37
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
38 John Ferguson Smart, Jenkins: The Definitive Guide (Creative Commons Edition), p. 202 – 203., O’Reilly Media, July 2011
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
ONE GOAL
40
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 http://www.slideshare.net/srikanthps/scrum-in-15-minutes-presentation
ONE QUESTION?
43
