【学习整理】敏捷方法的“神”是什么？
上一篇 /
下一篇 2015-06-18 15:10:14
/ 个人分类：敏捷
在实际实施敏捷方法过程中，相信很多人和我一样都会遇到了“形似而神不似”的问题，那敏捷方法的“神”是什么？ 总结为两条：质量与沟通。
先说质量：
（1）在敏捷方法中，多快好省四个字进行平衡时，首先是要固定质量，在固定质量投入的前提下，再去平衡进度、需求和投入，在剩下的这三个要素中，往往先裁剪的是需求！
（2）质量的含义包含了内部质量和外部质量，外部质量是用户可以感知的，是对需求的符合性。内部质量是开发人员所感知，决定了软件的易维护性。内部质量决定了外部质量，敏捷方法是二者并重的，而并非仅仅关注了外部质量，而传统的方法往往仅关注了外部质量。
（3）质量的管理首先关注质量的投入，质量的投入表现在质量管理的活动上：测试驱动的开发，静态检查工具的使用，结对编程，代码走查等。没有质量的投入就没有质量的产出。敏捷的方法对于质量的投入应该如何投入，给出了具体的实践，而并不是停留在概念上。 （4）提升软件开发效率的最有效的方法是减少不返工，一次做对是提升效率的最有效的方法，因此就要预防错误，预防错误的方法包括和开发人员对需求的理解达成一致，结对设计，测试驱动的开发，结对编程等。
再说沟通：
（1）敏捷方法为什么可以少写文档，因为他通过口头交流的方式替代了文档交流！有哪些具体的口头交流的手段呢：在策划会议上项目组的成员对用户故事做了沟通和讨论，开发人员做了结对编程，每天开了站立会议，用户代表或产品负责人在过程中实时的做功能测试等等，这些手段都保证了在文档比较少的前提下，可以保证产品的方向、产品的具体功能不会偏离用户需求。 （2）在敏捷方法中沟通了什么？首先是需求、其次是设计、再次是进展、最后是经验教训！在需求方面沟通了对需求的理解，需求是否实现了，需求的沟通是重中之重。用户故事是用来讲的，是用户讲给开发人员听的，开发人员是否实现了听来的故事，是需要讲故事的人进行确认与验收的。对于需求、对于进展都要尽早的报告坏消息：需求理解错了；需求无法实现；需求实现错了；需求没有按时实现！
对于每个开发人员都要将上边的两条落实到自身的细节行动上，做这件事情你是否保证了质量，是否通过沟通减少了错误的发生。
收藏
举报
TAG:
