摘要：读了几天的书，教会我们避免schedule game的很多实践，现在我把她们总结出来，并和大家一起在接下来一个一个的深入学习这些实践的方法。这些实践包括：1，使用inch-pebbles进行工作量评估2，使项目组成员的状态可见，促使项目成员及时报告自己的状态，帮助他们解决问题，而不是追问进度。评估任何他们提交的东西，并给予及时的反馈和意见。3，如果必须同时working on多个项目，那么使用一周... 阅读全文

摘要：我们做项目，做模块，做一个功能，甚至是写一个方法，什么叫做完成？什么叫做完成50%？什么叫做完成10%？定义很模糊，基本上基于每个程序员自己的判断。通常，当我们写完所有的代码，编译通过，运行通过，我们认为：完成了；实际上，可能还有40%以上的工作要干。我们做完了一个项目90%的feature，我们说：我们完成了90%的工作；实际上，可能才只完成了50%。为什么？未知最可怕，程序员高估自己的进度是恒... 阅读全文

摘要：以下做法适用于此种情形：你的boss走过来对你说：“Mr Foolish, 我想让你花50%的时间在A项目上，30%的时间在B项目上，20%的时间在C项目上。在有空的时候，你能再看看给大BOSS的报表吗？” 相信你的嘴巴已经张的很大，“我哪来的'有空的时候'”？ 通常这种情形发生是因为管理层没有办法保证交付一个程序或者项目的交付策略，他们不对任何一个... 阅读全文

摘要：以下做法适用于此种情形:大BOSS来电：“把手头儿的活儿放放，这边有个十万火急的项目需要你来处理。”此时，你没有选择的余地，只能往返于两个或多个项目之间，你的项目组成员也一样。最后，什么事情也干不好，没有干成任何一件。一个项目经理同时care两个或多个project，已经被认为是能力的体现，却很少有boss会认识到这其中浪费了多少时间降低了多少效率造成了多少项目的失败。1，... 阅读全文

摘要：以下做法适用于此种情形：项目组和项目的利益相关者达成默契，大家不讨论项目的schedule，项目组告诉boss一切都好，boss也想被告知一切都好，没有人愿意真正的面对现实去解决问题。在老板从不满意deadline（Queen of Denial)那个游戏中，老板总是生活在幻想中，总想得到一个更早一些的release date，但是项目组总是把他拉到现实中；而这里，项目组和boss都主动迷失了。1... 阅读全文

摘要：以下做法适用于此种情形：项目历尽波折终于成功了，boss觉得很不错，因为不管怎么样总是成功了嘛；项目组成员感觉很差，觉得boss不在可信，因为干了很多没必要的事情，耽误了进度和生活。此时，boss还没有认识到问题，也不愿意组织讨论项目中遇到的问题，以便下次避免这些问题。1，为一个特定的realease中的每个feature编号，并制定优先级（高，中，低， not numbers)。2，基于feat... 阅读全文

摘要：以下做法适用于此种情形：不管你说什么，你的manager总是说：只要你肯努力，一定能按"期"完成。而根据你的评估，根本就没有可能。这个时候，你的选择是什么呢？让整个项目组都加班？就像我在(1)中提到的一样，manager之所以会这么做我觉得很大程度上是因为他对项目组的不信任，或者说不足够信任；他们认为如果给出一个更短的期限，那么项目组就更早的完成，他们把这作为一种激励项目尽快完成的手段：事实上他们... 阅读全文

摘要：以下做法适用于此种情形：你手上的项目比你之前做过的任何项目规模都大，使用新的语言，使用新的平台，使用新的操作系统，做的是新的业务领域，并且关系到公司的存亡。此时，对你来说，世界末日要来了。1，判断并写出面临的风险形成风险列表。你可能有技术风险，可能有进度的风险，或者两样都有。2，不要选择瀑布模型进行开发，因为你没有任何经验来做评估，计划，一切都是新的。如果你以前从未接触过这一领域（这一技术），那么... 阅读全文

摘要：以下做法适用于此种情形：你做了N次计划，老板总是觉得不满意，总是想让你做出一个更早完成的计划。也许，他根本就是想给你更大的压力，让你早点儿把事情做完。老板（或者你的上级）如果既没有告诉你他想要什么时候完成，也不告诉你他为什么想要更早些或者真正想要什么。 如果他能够告诉你deadline, 你可能可以告诉他在这段时间内你能做些什么；如果他告诉你为什么他要更早的完成，也许你能给他提供一些解决方案。但是... 阅读全文