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