总有人问我，
我下了这么大的力气去管理软件开发团队，但依然没有产出想要的产品？
为什么看似非常到位的管理，在内行人看来不过是多边扯皮？
为什么软件配置完善、资金到位，依然没有解决业务问题？
那是因为时代在变，传统的管理模型已经难以适应新时代的软件工程管理。
那么，让我们一起来看看敏捷开发宣言，感受“敏捷”的魅力。
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
【个体和互动】 高于 【流程和工具】
—注重产品本身，而不是形式和流程，文档应简洁易阅读，方便维护和同步。
【工作的软件】 高于 【详尽的文档】
【客户合作】 高于 【合同谈判】
—主动拥抱变化，及时响应，持续交付
【响应变化】 高于 【遵循计划】
—制定可实现的清晰的短期目标，粗略的中期计划，长期的大方向
也就是说，以上对比中，尽管后者有其价值，我们理应更重视前者。
我们最重要的目标，是通过持续不断的及早交付有价值的软件使客户满意。
01 快速迭代
相对那种半年一次的大版本发布来说，小版本的需求、开发和测试更加简单快速。一些公司，一年发布仅2~3个版本，发布流程缓慢，因为它们仍采用瀑布开发模式，而且更严重的是，它们对敏捷开发模式存在误解。
02 让测试人员和开发者参与需求讨论
需求讨论以研讨组的形式展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，并将需求分组并确定优先级。同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，而且大家更活跃，参与感更强。
03 编写可测试的需求文档
开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。
04 多沟通，尽量减少文档
任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。团队要确保日常的交流，面对面沟通比邮件强得多。
05 做好产品原型
建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。
06 及早考虑测试
及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。
扫码关注
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！