关于敏捷

原写于2010-11-07

 

题记：老大开始在团队推行敏捷。记录目前自己理解的优点，还有敏捷不适应问题。

 

一、自己理解的敏捷

 

1.风险分散。这点，我是非常肯定的。亲身的体会，jim负责A模块，以前做法：项目经理pety，在A模块快提交的前期去和jim沟通模块的完成情况。现在做法：每天jim向prty汇报自己的进度情况和问题。帮助pety对项目的可控性提高很多，风险也能尽早的暴露出来。带来的问题：必须对A模块进行更细的任务分解，如何分解？时间如何评估？谁来评估？（团队做法：由jim自己细分A模块，再与pety确认计划，此时pety可以给出自己的意见，共同来评估时间。）

 

2.可视化。同意这点。之前做法：每天发邮件周知大家进度情况；团队目前做法：看板（贴每个人具体细分的任务），每天汇报具体的进度和遇到的问题。其实两种做法的目的是一样，都是想让别人知道自己的进度和问题。但第二种方法优点：a.阅读邮件，是每个人独立的行为，是分散的，看板上任务的汇报是大家在一起的，此时面对面的沟通是更高效的；b.对于我的感觉，看板比邮件更加可视化；c.基于看板，后期的后顾和总结也更加方便。

 

3.团队化。jim负责A模块，jeny负责B模块，当A模块jim可能存在跟多问题（前期没有评估到），希望jeny可以帮jim完成其中的部分。问题：jeny根本不熟悉A模块，熟悉A模块所花费的时间，以及对B模块的影响，都是需要评估的。自己的理解：对于多人同时开发的项目，此方法还是可以试用的；但是对于单兵作战的日常，大家的精力都是有限的，很难说A做大一半的时候，让B来帮忙。这也是目前大家争论的焦点。

 

二、团队目前的做法

 

1.细粒度的任务分解。比如：搜索页面智能导航，分解的任务：a.了解接口需要的参数，以及返回的结果的格式 b.请求参数处理  c.返回xml结果解析 d.后期根据业务逻辑的处理。整个任务肢解的力度非常细，对项目风险的把控更加有好处。

2.看板。分为：任务、开发中、done（三部分）。根据每天大家反馈的情况，更新项目剩余需要的工时（细粒度到时间）。

3.晨会。早晨站在看板前，每个对着看板，说自己“昨天干了什么&是否遇到什么问题、今天准备做什么”，对应的调整看板的内容和任务所需时间。

4.总结。这点目前做的不够好，不是大家都来提建议，可能整个团队还是“一个大脑”，只是一个人在想问题（当然这与团队的氛围是有关系的）。

 

三、难点

 

1.个人的积极性和参与度

敏捷是需要团队的每个人都以主人公的态度参与进来的，当然团队也要能够给予他认同，这是软实力的问题；比如：相互提建议，但是这首先需要团队安全的环境，对老大说的话，大家可以提出不同的意见，否则始终是“一个脑袋”在思考，大家习惯于去服从；同时也要克服养成的“中庸之道”，当然也要注意提建议的方式。

2.任务的细分和工时的评估

需要项目经理对团队成员有很熟悉的了解，才能合理的安排任务。根据不同的人确定不同的工时，大家都能在一种被尊重和快乐的氛围中工作，此时的效率肯定是高。

3.团队的成就感

需要自下而上的，获得的成就是每一个人的，而不是简单是他的或者我的。每个人都能找到被认同的感觉，乐于分享自己的收获，此时整个团队的每个人都会成长，团队的战斗力肯定也会大大提高。

 

总结：发现难点的地方，还是团队软实力的建设。