如何在小公司实施软件工程瀑布模型和敏捷开发模型各有优缺点，各自的适用场景不同，总的来说，瀑布模型适合需求比较明确，确定性因素比较多的的场景，敏捷开发恰恰相反。
在小公司里面，适合使用哪种？坦率来讲，小公司不确定因素太多了，业务不确定，有什么业务就做什么业务，能养活公司就行；用户需求不确定，经常变更，让你改，你就得改，而且要马上改；公司员工也不确定，一人身兼多职，什么都干，压力大，待遇低，流动性大。咋眼一看，似乎，敏捷开发很适合，然而，如果前提条件不具备就匆忙上马敏捷开发，结果会让你大吃一惊，开发效率反而降低了，问题反而更多了，大家反而都更迷茫了，只好又走回原来的老路。
为什么会这样？原因就是实施敏捷开发有一个很重要的前提条件，人的素质要高，能够自偶驱动和自偶管理。然而，小公司的高素质人才绝对不会很多，一个敏捷开发的小组都是这样的人基本上不太可能，这也就意味着敏捷开发的一些理念无法落地，比如确定产品列表，如果PO(产品负责人)不强，这个环节就会出问题，需求描述不清，跟真实需求南辕北辙，项目开发还没开始，就已经失败了。又比如确定迭代开发列表，每个开发人员自己评估开发工作量，如果经验不足，开发工作量评估不准确，为了赶进度，只能牺牲开发质量，后期测试发现bug不断，不能按时发布，整个项目都不得不延期。又比如每日站会，本来是为了大家交流工作，更好的沟通，如果大家责任心都不够，各人自扫门前雪，哪管他人瓦上霜，最后就变成了形式主义，应付差事，最后不了了之。
中国人的文化和小公司的现状，决定了敏捷开发团队里面强调平等的原则是不能的，人人都强，才可能地位平等，你让老虎跟羊平等相处，显然是不可能，但是如果人人都是老虎，估计问题更大，谁都不服谁，时间都耗在内斗上，项目估计也完蛋了。中国的开发团队，必然是头狼+一群狼，确定头狼的地位，让他去指挥狼群。
所以，要想在小公司推行敏捷开发，不能全盘照搬敏捷开发的东西，要做些修改，让他能接地气。比如推行里程碑评审+敏捷开发，在需求环节、设计环节、测试环节都加上评审，集中公司里面的牛人当评委，小公司人再少，估计2,3个牛人还是能找出来的，否则这小公司估计也活不了多久。PO得兼项目经理，维护产品列表和项目计划，负责产品规划和项目管理，开发团队得有一个开发负责人，负责评估任务工作量和任务分配，解决开发中碰到的技术难点。
这样下来，开发过程基本上就比较顺了，敏捷开发的一些关键点也能得到落地，比如说二个星期一个版本迭代，最强的应该能做到一个星期一个迭代，需求能够快速迭代，质量也能够保证，当然，如果公司没几个牛人，估计啥也干不了，敏捷开发还是瀑布式开发就别折腾了，活下来再说。