很多企业、团队都在提倡敏捷开发、DevOps运动,我最近在了解DevOps的相关知识。结合自己的实践,把对敏捷开发的一些理解,分享予大家。

敏捷开发强调的首先是人的变化,其次才是工具应用的层面。

敏捷开发的项目管理

一,人的变化(团队),主要思想模式上的变化,比如:

没必要等到全部确定才可以开始。只要大的框架需求、关键点确定之后就可以开始,没必要等到弄清楚所有细节才开始,如果要弄清一切才开始,就是传统的瀑布式开发了,那样产品见面周期长,无法适应需求的快速变化。

不是一次性交付后就结束。敏捷开发,就是要分多个迭代交付,小步快走。

允许有不完美。不要一开始就想着很完美,而且也很难一开始就想得很完美,要清楚这是一个逐步优化的过程。

要拥抱变化。敏捷的目的就是能快速响应变化,以真正满足业务的需求。当然变化是以真正体现业务价值为基础的,不是以某个人的盲目意见为理由。

真诚沟通。与客户建立亲密性,真诚地进行沟通,客户不是“谈判对手”,也不是“上帝”,而是与团队一起共进退的伙伴、合作人。

二,工具应用的层面

以故事场景的形式把需求描述出来,敏捷强调的是从客户的业务场景角度,把需求讲出来,不太强调具体的系统功能需求设计。目的就是为了能真实表达业务的需求和价值。

大目标需要拆分小目标,需要懂得把大目标拆分成各个小目标,缩短成品交付的周期,让系统尽快出来验证业务价值。

迭代交付,每个迭代是一个完整的闭环“计划-开发-测试-体验-发布”。

每日站会,每日站会是为了让团队了解整个项目的情况,知道成员彼此的工作和困难,可以互相帮助。

任务看板,用来跟踪项目进度的,特别是在冲刺阶段特别有效。

定期回顾,回顾是团队一起回顾,是规避,也是学习交流的机会。

具体实践的一些感悟

1,与客户亲密沟通,站在同一阵线,很重要。

能与客户保持亲密沟通,站在一起探讨需求,设计功能,讨论解决方案,是项目走敏捷路线的良好基础。很幸运地,本人负责过很多项目,基本都能做到这一点。我觉得主要有两个原因:

1)接到任何一个项目,我都会专心投入去思考:应该怎样设计才是对业务最有价值的(那怕一开始不清楚业务,也会想办法沟通弄清楚,然后思考);

2)客户的需求,不会拒绝。而是会去思考,这个需求的价值是什么,如果是有价值的,我们就如实商量实施计划;如果是没有价值的,则会提出我的见解。做到这两点,除非很恶劣的情况,否则一般客户都是会讲道理的。

2,拆解目标需要清晰,可靠。

项目的目标一定要清晰,然后拆解的子目标也要清晰、合理。一般情况下,我会从两个方面考虑:

1)把故事转成全功能目标图;

2)明确业务意愿的时间目标。

以上两点,结合团队资源的情况,按照系统本身特有的特征和客户的意愿拆分目标。确保每个小目标可达。

3,定期回顾总结,反思。

迭代交付,一定要定期回顾,并反思,确保项目方向正确,目标可达,特别是要考虑总体目标也是在计划中可达,如有偏离、或者出现风险,需要及时纠正。定期反思,一般我会考虑:离目标还差多少,交付的需求是否都是有价值的,目前有没有出现隐含的风险等。