项目管理体会之三:比别人早一个小时到办公室
提前到一个小时,提前把当天的任务安排好;否则如果准点上班的话,在你做安排的时候别人就不知道今天有哪些事要做。
提前到一个小时,提前把当天的任务安排好;否则如果准点上班的话,在你做安排的时候别人就不知道今天有哪些事要做。
机器不会犯错,人则容易犯错。人会健忘和粗心。 项目管理的工作之一,就是克服人类的这些缺点,使之像机器一样严谨。 在处理高风险的事情时,更要注意这一点。 具体来说: 1.与日期/时间有关的事情是风险比较大的,这种事情一旦弄错,搞得合同出问题,那所有的辛苦都要白费。所以 对日期/时间要反复核实,不但要拿到口头的消息,还要尽量拿到书面确认。 2. 一些高风险的任务,只发邮件是不够的。 而是一定要面对面或者电话说一下,得到对方的实时反馈方可。
如果你要发出的邮件是长篇大论,那就不要急着马上发出去: 1.篇幅长的文章难免会有错别字、语法、通顺等问题,最好再重读一遍自己的邮件再发出去。 2.写邮件前你有五件事要说,但写着写着,到最后可能会漏掉一两件事,因为遣词造句需要高度注意力,可能会搞得你忘了一两个要点。 所以写完邮件后,再稍微想想,自己的文章是否完整。
文章的原名是 ‘The Costs and Benefits of Pair Programming’, by Alistair Cockburn & Laurie Williams 这里把最后的Summary摘录一下: 成本:据研究, 开发时间并不会增加一倍,而是增加15%; 并且这 增加的15%的时间会在以后的阶段省回来(如测试、维护、客户支持等) 收益:很多。 1. 在开发阶段就发现问题。这种问题比在QA阶段发现的问题更容易解决。 2. PP实际是持续的代码检视。这种持续性可以使缺陷率更低。 3. 设计会更好,代码会更简单。 4. 解决问题 的效率会提高。因为多一个人就会多许多思路。一个典型的例子就是:在研究难查的Defects时,两个人会比一个人更有灵感。 5. 互相学习。既学习设计与编程,还能学到有关系统的知识。 6. 由于知识共享的程度比较好,即使核心工程师走人,项目也没什么风险。 7. 大家水平普遍提高, 团队的工作能力提高。 8. 一起工作,铸造团队。团队不再是一盘散沙。 9. 心情更舒畅。因为你相信PP时缺陷率会更低,并且有人与你同担风险。
很简单,一句话: selenium.selectWindow(null);
From ‘Beautiful Code’ 1. Start from Smoke Test 2. Then add Boundary Tests 3. Go on with other tests for a complete coverage (random tests etc.) 4. Finally, add some tests for performance P.S. : Try to do random tests by generating numerous random values
Adopt XP one practice at a time 1. Pick your worst problem 2. Solve it the XP WAY 3. When it’s no longer your worst problem, repeat. The two obvious places to start are testing and the Planning Game Don’t underestimate the importance of the physical environment!
No side should dictate. If biz people are in charge, there will be missions impossible. If tech people are in charge, they will do a lot of things for fun(cool tools, technology, etc.), which are risky. Let the biz people tell what they want, and let the tech people tell what the price …
Notes on XP — No.11: Business People V.S. Technical People Read More »
The Planning Game Players: Business People VS Development People Pieces: Store Careds Moves: 1. Find out what new things the system could do Write a story(Biz) -> Estimate a story(Dev) -> Split a story if development can’t estimate 2. Choose the most valuable subset of requirements Sort the …
The Iteration Planning Game is similar to the Planning Game. Player: Individual Programmers Pieces: Task Cards Moves: 1. Find out what tasks there will be. Do splitting if necessary. 2. Accept and Estimate tasks. Y = Ideal Engineering Time * load factors 3. Keep everything in track.