Actionary

A man is valued by his works, not his words!

2B青年欢乐多之敏捷扫盲

其实,我有自知之明,我并不是最合适回答这个问题的人,因为现在大师有很多,不管是李奎也好,李鬼也罢,反正就是很多。也因为真假莫辩的原因,搞得圈里圈外各种叽叽喳喳。这不,要想在圈里圈外出个名什么的,要么旗帜鲜时的挺个流派,或者倒个敏捷,或挺或倒,一定要言辞凿凿,越激烈,越极端,就越容易博得点击量,当然,这是有风险的,要么名声大振,要么声誉扫地。其实我是挺偑服那些人的,多有勇气啊,而我就不行,只能闷头干活,不敢过多言语,为什么?怕讲错啊,万一被哪个神经病缠上,就我这压力承受能力,还不直接被K.O了。况且,就我这水平,能让自己搞明白就已经不错了。

可是,可是…由于工作的原因,最近我常常遇到不明真相的群众,直呼我张老师,然后请教诸这般那般。其实叫我张老师,我应得也自然,因为曾经当过老师,也乐得学生这么叫我。就我个人而言,我更愿意广义意义上就敏捷这个基础上就事论事。

讨论敏捷,肯定会提到敏捷宣言等等各种资料、引用、权威著作等等。但是这里水太深,一般人一时半会儿还真理解不了。那么,我想从我个人的理解试着说说,如果读者朋友觉得我说错了,也请给个comments,提醒一下,当然以后就称我为编程教练好了,如果你赞同的话,那以后就叫我为敏捷教练好了.

我觉得在敏捷里一个比较重要的概念就是Inspect&Adapt,检视并适应。如果理解了这个概念,顺着往下理解,就很容易了。这里举个例子,有汽车驾驶经验的人一般都知道,从一个驾驶新手到熟练驾驶这个周期不会太长,一般每天上下班开车的话,一两个月就够了。作为在全国第二拥堵城市开车的我来说,从新手,到自认为老手,也就不到两个月,为什么会这么快呢?前两个月还战战兢兢,过两个月就敢跟别人卡车位,原因出在上班路上有太多的锻炼机会,从家里到单位,红绿灯几十个,十字路口N个,加上咱们国家特有的着急文化,路上状况百出,极其复杂,这样,给了我们学习足够的频度进行锻炼。另一个原因,汽车驾驶中,从做出每一个驾驶动作,到驾驶员获得反馈时间非常短,这样一个高频度快反馈让我们很快获得了汽车驾驶能力的提升,因为,我们在驾驶过程中不停地做InspectAdapt。另一个例子是驾驶海上货轮,学习成本明显比汽车要高出许多,加上海上也没见多少红绿灯啊,频率低,货轮入港时的转舵,反馈周期长,也些原因决定了学习轮船驾驶要比汽车驾驶困难许多。由于不确定性因素,根据不断变化的情况,对反馈进行检视,然后对下一步的行动做出调整,以适应后续发展,快速的反馈减少我们应对单一反馈周期里的成本。应对不断变化的不确定因素,反馈是获得改进的唯一方式,这就不难理解"别人给你feedback是对你好"这句话了。

Alt text

以此,我们对应软件开发中,软件开发常常碰到的问题是不确定因素很多,客户随时可能改变需求,这有点像开车,路况总是处在变化中,软件研发团队提交产品给客户,而客户将反馈给研发团队。如果想有效地应对来自客户的变化,那么保持一定频率的反馈及快速的反馈时间将有助于及时让团队做出调整,这样,不断的调整改善,对团队而言,就是一个持续改善的过程。我们试着问,要不断从客户那边获得反馈,前提就是要可持续地提交产品给客户,就这引入了Continuous Delivery的概念(我们不再这里深入更多细节),要做好Continuous Delivery,我们必须做好持续集成Continuous Integration,要做到持续集成,我们可以通过ATDD保证需求是可迭代的持续验证,并且同时做好测试自动化。要做好持续集成,咱们得做好持续开发编译,要做好持续开发编译,咱们都做好TDD,Pairing… 随着一步步向下挖掘,我们发现,可以将很多工程实践,放到里头,如果想保证这些事情能够顺利地做好,我们定义了不同的角色,不同的check list,backlog,这样就很容易地顺着这个思路去自圆其说了,:p。当然,这时还一个概念就是迭代周期,迭代周期就是开发团队用于Inspect & Adapt的节奏。迭代周期多长合适呢?

从产品开发的这条线走,如上所述。那么要开发产品,团队很重要,从团队角度又可以引申到哪些概念呢?如团队建设要做到Continuous Improvement,那么我们是不是得做好Retrospective,然后是Daily Meeting, working agreement …

Alt text

把这些想通了,再去顺着想别的概念就容易多了。当然,这不是敏捷的全部,否则做个大师就太容易了。这里只是想写个引子,帮助大家站在自己的角度来思考问题,希望能对大家有所帮助。对了,写到这里,我是不是得问几个问题:

  1. 敏捷的开发方式好,还是传统瀑布模型好, 为什么?
  2. 如何在硬件研发中使用敏捷,为什么?
  3. Lean与看板是什么关系,为什么?
  4. Scrum好,还是Kanban好,为什么?
  5. 极限编程又是什么东西,为什么?
  6. 自组织是敏捷的前提还是结果,为什么?

是不是觉得这些问题经常遇见,那为什么呢?习惯问为什么,并顺着往下想,下一篇博客你来写。

注:文中图片是用keynote画的,只是个草图,如果有兴趣,大家帮忙给规整规整

祝好

Comments