摘要：我以前做的上百人一年多一个的大项目，完全按照CMMI Level3规范来控制需求变更的。起初有双方签字的经过评审的需求基线，以后需求变更的时候有需求变更委员会（CCB）或专门负责的角色（通常由客户方需求人员来收集和评估最初需求并提交给QA，QA牵头需求变更流程）来处理需求变更；现在公司做的项目规范较小，完全按照CMMI的规范来有点多余，所以我们基本上类似于敏捷开发的模式。敏捷编程是拥抱变化，持续重构和改进，迭代开发，频繁交付。在需求变更管理上我们还没有一套完整的合适的流程。 阅读全文

摘要：通常的做法是通过更多的单元测试 (Unit test) 和code review，使得我们在开发阶段发现更多的问题，从而减少bug数。的确，开发人员经常单元测试，具有良好的测试和编程习惯，在每次check-in之前，或每次打baseline之前，项目组都有代码cross review，同级或跨级评审，自己代码每日评审能大大保证代码质量，在提交给测试组之前就消除大量的bug。但往往发现更大多数的bug是我们通过 Unit test和code review所不能发现的。为什么？ 阅读全文

摘要：做好一个软件，只靠技术好是很不够的，必须要有一套好的研发流程和配套的支持工具。微软所有产品的研发都遵循同样的研发模式、使用同样的研发工具来进行管理。在所有的工具中，我最佩服的就是其Bug管理系统Raid（现在叫Product Studio）。可以说，遍布全球的微软研发人员能够保持统一的思维模式、做事及语言习惯，与整个研发流程的配套工具密不可分，其中最重要的就是通过Raid把整个产品的研发有机的联系起来。阅读每个 Bug，你可以详细的看到大家讨论解决该问题的完整思路。 阅读全文

摘要：小A在上海，小B在大连，同一个公司和项目。小A负责通信子系统的开发，小B负责文件下发子系统的开发，小B的系统要依赖小A的通信子系统进行集成和测试。话说项目进行到9成,小A和领导说基本跑通了，只有些后期完善和提高稳定性的工作了。小B从他的领导那儿得知了这个消息，就要求把小A的系统拿来集成测试，从而更好的测试它的文件下发子系统。可调试了一个礼拜... 阅读全文

摘要：软件工程的事实与谎言，关于人，工具，项目估算，重用，需求，设计，编码，测试，代码检查，维护，质量，可靠性，以及性能。 阅读全文

摘要：软件质量对软件公司来说是生存之根本，而我们都知道，bug越早发现越好；发现产品中存在的问题越早，开发费用就越低，产品质量就越高，软件发布后维护费用就越低。开发人员如何把bug消灭在最初的时候？ 这就要依靠单元测试，依靠开发人员的编程习惯、质量意识（单元测试意识）和测试方法。最后探讨了国内程序员为什么不写单元测试的问题。 阅读全文

摘要：Mostly, a lead's work is communication and helping to solve problems, rather than giving orders. If you want to motivate people, either directly or by creating a helping environment, you must first convince them that you care about them, and the only sure way to convince them is by actually caring. People may be fooled about caring, but not for long. That's why the second version of the Golden Rule says, "Love thy neighbor", not "Pretend you love thy neighbor." Don't fool yourself. If you don't 阅读全文

摘要：My experience with code reviews has been a mixed bag. One of the problems seems to be that nobody wants to spend the time to really understand new code that does anything non-trivial, so the feedback is usually very general. But later, when someone is working on the code to either add functionality or fix bugs, they usually have lots of feedback (sometimes involving large hammers), but then it may be too late to be effective; the programmer may not even be around. I think it might be useful to h 阅读全文

摘要：每个人表达的方式不一样，有的善谈，有的善听，有的善行。善于交谈不等于有效沟通，对于个人、企业和社会来说，评价有效沟通的标准应该取决具体的沟通是否有利于问题的解决；是否对人的发展及企业和社会有贡献。而沟通的目的和意义，对于企业和个人来说，他认为最终目的就是为了解决问题，通过解决问题做好企业和社会中的事。从一个项目管理培训小游戏谈到项目管理中的有效沟通，包含基本沟通模型，项目经理常见的沟通坏习惯， 以及增强沟通质量的方法，文章最后讨论了项目经理如何帮助团队成员以最佳的状态完成工作的问题。 阅读全文

摘要：因为工作关系，经常去德国出差，对德国IT技术人员有些了解。下面谈谈我眼中的德国IT技术人员，主要是想比较和思考一下两国技术人员的差异，看看有哪些地方需要我们中国人学习和借鉴的地方，文章最后比较了一下行业氛围和环境的问题，做了一些思考。 阅读全文

摘要：一个好的软件开发人员应该具备一定的基本功/专业素养，例如数据结构，算法，操纵系统，语言知识等等；然后还应该具备良好的素质，例如团队精神，创新精神，专业精神，和产品意识；本文分这两个方面讨论了一个好的软件开发人员的标准。欢迎大家探讨和补充。 阅读全文

摘要：每个人表达的方式不一样，有的善谈，有的善听，有的善行。善于交谈不等于有效沟通，对于个人、企业和社会来说，评价有效沟通的标准应该取决具体的沟通是否有利于问题的解决；是否对人的发展及企业和社会有贡献。而沟通的目的和意义，对于企业和个人来说，他认为最终目的就是为了解决问题，通过解决问题做好企业和社会中的事。项目管理中沟通非常重要，既有项目成员之间的沟通，上下级之间的沟通，还有Team之间的沟通，以及和老外的沟通问题。如果沟通不畅，就会导致需求的误解，目标的偏移，项目的delay或失败，甚至更严重的导致人员的离职，因此在团队和项目管理中值得我们引起足够重视。本文探讨了团队管理中如何有效沟通的一些个人看法。 阅读全文