相关主题
天天Deadline
什么叫天天Deadline？早上一来办公室，布置任务，明天交活。这就是我这几天的工作状态。说实话，这是一种很高效的工作方式。高中的时候，每周要交两篇周记，很痛苦，往往都要拖到周日一下写两篇。天天deadline就象老师每天布置的作业，明天一定要交，没有procrastinate的可能性。
对于一个项目的管理，除了长期计划，更需要把工作细化，使之在短时间段内可以监控。细化的粒度越小，可控性越强，效率越高。同时，阶段性的成就感也能抵消一部分工作压力。
细化工作存在风险，预期时间的单位量越小，和实际完成时间产生误差的机会和偏差量就越大。以周计算的工作，一周内的各项工作之间有所调整，可以缓冲由某部分工作超过预期带来的偏差。如果以天来划分工作，一天内工作量估计的不足往往没有回旋余地。
如何在提高效率和降低风险之间找到结合点，可能就是项目管理的艺术了。
itunes 账上有钱 
[...] 五一放假结束后的第一周，在一位经验丰富的美国同事带领下进行了一周的敏捷开发实践。在此之前的半年时间里也试过scrum，并且体会到了一些好处，但那一周不仅让我们体会到了好处，可以看到了敏捷开发的力量。很多书本上早读过的观点和方法在他的帮助下确确实实为我们解决了实际问题，很让人兴奋。 此后将近一个月的时间里，我们尝试延续第一周的方法，必须承认我们还不是实施敏捷开发的专家，但还是取得了以前无法想象的成果。下面是一些体会： 1。短而递进的开发周期。我在以前也提过，现在能比以前更好的采用分而治之的方法。对于一个需求，如果需要十二天来完成，那么两天我们能完成到一个什么程度，或者是一个简化的需求，或者是这个需求的一部分，只要实现的完成度可以拿出来衡量，我们就制定一个两天的计划，两天后验收，然后一步一步做下去而不是“这是需求，十二天后见！”。 2。更准确的估计工作量。估计工作量对我来说一直是一个难题。当这次我又对一个work item给出不很确定的估计时，我被反问“哪些不确定因素造成了这些不确定地工作量”，我回答那里那里可能有潜在的问题可能会导致工作量的增加，“那么如果目前不去考虑这些潜在的问题，你对工作量的估计是多少？”，我的答案马上变的确定了。对于不确定的问题，我们只需要把它记下来，在问题浮现或者变得确定后再解决，而不是把它变成包袱背在身上。能绕过这个槛是我这次最大的收获。 3。分清什么是需求，什么是实现。工程师在讨论问题的时候很容易陷入细节，以至于忘记了事情的根源，即需求。我不止一次的被提醒“你现在讨论的是需求还是具体实现”，在回答了这个问题后，很多诸如“做什么”“怎么做”的问题自然就得到了答案。 4。unit test。没有UT就不是敏捷开发，不光是为了测试，有时候只有UT才能确定你工作是否完成，才能使短而递进的开发成为可能。在这一点上我还欠缺不少。 教训也是有的，最大的教训就是我们把计划定得太激进以至于经过这三个星期我们越来越不敏捷了。40小时每周是敏捷开发的核心，此话一点不假。 最后是同事发给我们的一副图片，最真实地再现了我们的工作： Tags:agile, pm [...]
You may be agile, but you are still dog…
呵呵