很多企业、团队都在提倡敏捷开发、DevOps运动，本人最近也有在了解DevOps的相关知识。结合自己的实践，把对敏捷开发的一些理解，分享予大家，共勉。
敏捷开发强调的首先是人的变化，其次才是工具应用的层面。
一，人的变化（团队），主要思想模式上的变化，比如：
没必要等到全部确定才可以开始。只要大的框架需求、关键点确定之后就可以开始，没必要等到弄清楚所有细节才开始，如果要弄清一切才开始，就是传统的瀑布式开发了，那样产品见面周期长，无法适应需求的快速变化。
不是一次性交付后就结束。敏捷开发，就是要分多个迭代交付，小步快走。
允许有不完美。不要一开始就想着很完美，而且也很难一开始就想得很完美，要清楚这是一个逐步优化的过程。
要拥抱变化。敏捷的目的就是能快速响应变化，以真正满足业务的需求。当然变化是以真正体现业务价值为基础的，不是以某个人的盲目意见为理由。
真诚沟通。与客户建立亲密性，真诚地进行沟通，客户不是“谈判对手”，也不是“上帝”，而是与团队一起共进退的伙伴、合作人。
二，工具应用的层面
以故事场景的形式把需求描述出来，敏捷强调的是从客户的业务场景角度，把需求讲出来，不太强调具体的系统功能需求设计。目的就是为了能真实表达业务的需求和价值。
大目标需要拆分小目标，需要懂得把大目标拆分成各个小目标，缩短成品交付的周期，让系统尽快出来验证业务价值。
迭代交付，每个迭代是一个完整的闭环“计划-开发-测试-体验-发布”。
每日站会，每日站会是为了让团队了解整个项目的情况，知道成员彼此的工作和困难，可以互相帮助。
任务看板，用来跟踪项目进度的，特别是在冲刺阶段特别有效。
定期回顾，回顾是团队一起回顾，是规避，也是学习交流的机会。
具体实践的一些感悟
1，与客户亲密沟通，站在同一阵线，很重要。
能与客户保持亲密沟通，站在一起探讨需求，设计功能，讨论解决方案，是项目走敏捷路线的良好基础。很幸运地，本人负责过很多项目，基本都能做到这一点。我觉得主要有两个原因：
1）接到任何一个项目，我都会专心投入去思考：应该怎样设计才是对业务最有价值的（那怕一开始不清楚业务，也会想办法沟通弄清楚，然后思考）；
2）客户的需求，不会拒绝。而是会去思考，这个需求的价值是什么，如果是有价值的，我们就如实商量实施计划；如果是没有价值的，则会提出我的见解。做到这两点，除非很恶劣的情况，否则一般客户都是会讲道理的。
2，拆解目标需要清晰，可靠。
项目的目标一定要清晰，然后拆解的子目标也要清晰、合理。一般情况下，我会从两个方面考虑：
1）把故事转成全功能目标图；
2）明确业务意愿的时间目标。
以上两点，结合团队资源的情况，按照系统本身特有的特征和客户的意愿拆分目标。确保每个小目标可达。
3，定期回顾总结，反思。
迭代交付，一定要定期回顾，并反思，确保项目方向正确，目标可达，特别是要考虑总体目标也是在计划中可达，如有偏离、或者出现风险，需要及时纠正。定期反思，一般我会考虑：离目标还差多少，交付的需求是否都是有价值的，目前有没有出现隐含的风险等。
如果觉得有用，请点赞支持，谢谢！
请关注@Jobpool卓谱 一起分享职场那些事 #我要上头条# #职场#
