摘要：（五） review和重构 说到review，有些筒子可能立刻就想到了：吵架。确实，有的时候review真的可能演变成吵架，但是我们为了项目的成功，这个风险一定要冒，慢慢成熟以后，被人批评的次数多了，脸皮厚点儿就好了。；）玩笑归玩笑，review确实是需要技巧的：在review别人的代码时，要注意你的话语有时会伤害别人的自尊心，让别人觉得你是在鸡蛋里头挑骨头；在别人review你的代码时，同样的你也会觉得别人是在鸡蛋里头挑骨头，伤害你的自尊心。这里我也没有太多的技巧可言，一句话，换位思考，脸皮厚点儿吧。哈。 Review可能分成以下几种： 1，设计的review。说起review大家更多想到的 阅读全文

摘要：（三） 我们需要哪些文档，工具和努力 软件项目肯定离不了文档和管理工具，如果您的项目还没有它们，那么请从现在开始。那么文档是不是越多越好呢？老话说的好，合适的才是最好的。小而精的文档和工具会让我们事半功倍，大而全的文档会让我们疲于奔命，最后迷失在文档的海洋中。 我们写代码的都知道，错误的注释比没有注释更可怕；同样的，没有及时得到更新的文档比没有文档更可怕，因为文档就是项目的注释。那么我们是否有必要去更新那些我们根本没有用到的文档呢？很显然，那是非常没有必要的，是对资源的浪费。文档说起来其实就是一个工具，是一个让我们开发时有依据，可以追溯开发过程以及记录开发结果的工具。我们只有用到它，它才有存在 阅读全文

摘要：引言 谁应该对项目进行管理 项目管理的的文章和书籍到处都是，我也不敢在这班门弄斧。所以以下的文字主要关注从没有管理到开始对项目进行一些管理这个过程，通常没有进行管理或者很少进行管理的项目也不会特别大，所以本文并不一定适合大型项目。本文也不完全符合某一流程或者标准，其中一些只是我个人的一些浅见，如果能抛砖引玉，那就再好不过了；如果哪里说的不对，肯定各位筒子们尽管拍砖。 作为项目组的成员之一，不论你是开发工程师，测试工程师还是数据库工程师，你都对项目管理负有责任。在工作中，工程师应该精通自己的部分，优秀的工程师还应该熟悉别人的部分，实际情况中的工程师通常还需要在必要的时候（有人离开）顶上去做任何. 阅读全文

摘要：读了几天的书，教会我们避免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, 你可能可以告诉他在这段时间内你能做些什么；如果他告诉你为什么他要更早的完成，也许你能给他提供一些解决方案。但是... 阅读全文

摘要：作为一个即将转型的程序员，我也谈谈我对项目管理的一些看法，这些看法极有可能非常的不成熟，所以请大家尽管排砖，使劲儿拍，越使劲儿我越高兴。：）我认为一个合格的项目经理在项目管理过程中应该主要关注以下几方面的东西：1，以验收项目为目的。所以，一切都应该是可验证的。把项目划分为若干个任务的同时，也应该已经为这些任务制定好了完成的标准，即做到什么程度为止。 我们做项目，为的是什么？你要非说我为社会主义祖国... 阅读全文