以下文字中的渐进式开发是否指迭代式开发
渐进式开发的魅力
现在称作敏捷开发的开发方式不仅是大部分软件项目，也是很多不同类型的产品开发的最佳做法。
构成敏捷开发的依旧是拉动式原则，而不是推动式原则。
在敏捷或者迭代的软件开发中，拉动来自于项目期间不断的反馈—从每日构建的测试和可用性实验室的结果，内部的“阿尔法”测试员（吃自己的“狗粮”），以及外部的其他测试员。
项目团队开始时只有一个粗糙的计划，然后随着开发的进行不断地修改产品设计。尤其对于超过少数人团队的挑战，就是使得每个人所做的变化都能同步。这跟用一个以上的人来编辑同一份文档是同样的问题。改变的编辑需要有一个登记的过程，同时也需要有人来控制“主要的”文件。
另一种办法就是事先计划好所有的编辑工作，把文件的特定部分分派给不同的人，不允许其他人编辑或者改动团队其他人已经编辑完成的部分，最后把不同的部分集成起来。
总之，当一个团队为同一个产品进行开发，特别是团队由于各部分是相互依赖而需要协调的时候，渐进式的开发过程就具有重要的优势。
项目成员在并行工作的同时要经常对他们所做的事情进行同步，这样各部件就能保持兼容（或者术语保持一致）。
当开发经理把一个大型而复杂项目分成小的子项目和更小的产品时，协调并稳定开发中的部件似乎就变得简单多了。
在产品开发领域最专业的工程师和学术研究者，特别是在软件方面，现在认为在缺少明确的子系统和零部件的界限，而设计整体的系统是一个过时的做法。
过于严格地遵循最初的计划，然后等到项目结束才试图集成所有部件来测试不同的部分是否能一起正常工作的做法也同样是过时的。
人人都得干活
在一个小团队里，你需要的是干活的人，而不是监工。每个人都得做事，没有人可以袖手旁观 。
这意味着你在招聘中要避免招到监工型的人物，这些人喜欢对别人谆谆教导。对于小团队来讲监工型的人就是累赘。
监工们还喜欢把人拖去开会。实际上，会议是监工们最好的朋友，因为只有在开会时才显得出他们的重要。
感想：为什么会有办公室政治，那就是因为这个公司里有一部分人不干活，不做事，于是，他们就有大量地时间开始胡思乱想，他们花大量的时间不是想怎么去做事，而是想自己怎么更容易的打垮别人得到上面的认可，从而得到晋升。在大公司中这样的情况会比Startup的公司多得多。所以，如果你不想滋生办公室政治，那么你需要干两个事，第一个是最好不要变成大公司，第一个是让每个人都在实干。我最近看到其大公司，虽然很多东西不规范，而且很多东西在野蛮生长，有些事情也有点土，但绝大多数人都在实干，所以，只要每个人都在实干，就算干的方式不好，干出来的东西有问题，也比那些滋生办公室政治的公司强上几百倍附一段在酷壳上看到的文字共勉：
编程就像登山一样，越往上爬人越少，所以，在我这个年纪还有想法，对编程还有热情的人不多了，基本上都是转Manager了。其实，什么职位，Title都是虚的，公司没了什么都没了，只有技术才是硬通货。而且，越是这个年纪还在玩编程玩技术的人，其实其经验和能力都是比较强的，都是中坚力量，如果还有其它这个年纪和我一样的人，求交往
