敏捷开发沉思录

 

最近,看到一朋友的BLOG,里面提到了敏捷的一些代表性问题,也看到有的文章
中讨论的热火朝天(比如:<<为什么敏捷不能成功>>http://coolshell.cn/articles/5044.html),这里,选一下一个朋友

的BLOG上,他提出的问题(原文见:http://www.blogjava.net/pengpenglin/archive/2011/06/01/351552.html)
,他的问题如下:
  
A. 敏捷是不是站立式会议，是不是把项目切分成几个小阶段就是迭代了？
 
 B. 敏捷的团队规模要多大？10个人还是4，5个人？

 C. 敏捷团队中的人员如何配置？是不是要水平相当，经验相当？

 D 当团队中出现短板时，敏捷的结对编程会不会变成致命的缺陷？

 E 敏捷团队中全功能团队和去角色化(尤其是没有PM这个角色)，会不会让项目失控？

 F. 敏捷不是完全抛弃文档，但是文档要去到什么级别？ 和传统的文档又有什么区别？

 G. 敏捷开发扁平化的结构，如何保证不会出现扯皮和纠缠不休？

 H. 站立式会议如果避免沦为流水账汇报，如果让大家清楚得知道你在干什么，遇到什么问题？

 I. 敏捷开发究竟适合哪些业务场景？项目or产品？(同行倾向于项目，说是产品经常要改，可是敏捷的宣言不就是拥

抱变化吗)

 J. 敏捷开发中，成员分工要如何进行？横向划分或者纵向划分？

 K. 敏捷开发和管理中，如何让后进来的新人尽快熟悉产品和架构？

问题比较典型,下面个人尝试去回答下,肯定有不全面的地方,请各位指教:
  A. 敏捷是不是站立式会议，是不是把项目切分成几个小阶段就是迭代了？
  答:当然不只是站立会议,之所以要站立,是为了尽可能能在15分内解决问题,尽可能简短,
假如有这个思想,即使大家是坐着开会的话,主持人把握好了,也一样是敏捷了.而把项目切成
几个小阶段,不一定等于迭代哦,要看你在每个阶段是否很好地应用了XP的思想和方法，否则跟传统的RUP没分别

  B 敏捷的团队规模要多大？10个人还是4，5个人？
    答：一般来说，人为一个敏捷团对4-6人是很高效合适的，因为人一多，管理起来就麻烦，意见也多，当然如果
你的团对都是由敏捷精英组成的话，那个恭喜你，10人也行（但不要忘记，三个和尚没水吃的道理哦），但问题
是，你如何管理这10个敏捷精英？再拆分为2组吧！另外，如果项目规模小的话，2-3人，其实都可以敏捷了，
不要形而上学。

  C 敏捷团队中的人员如何配置？是不是要水平相当，经验相当？
    答：我认为，如果比如要实施结队的话，水平还真的是相当好点，否则就是初学在一边看，高手在教学，
大家没思维的碰撞和互动。但一个团队中，倒不一定要求太多人有敏捷经验，有小部分人没敏捷经验，
有时反而是好事，所谓当局者迷，旁观者清。还有，要注意人员配置中，性格的相融性，让他们互相相处的好，
这就涉及人际关系学了，那时另外一个学问了。

   D 当团队中出现短板时，敏捷的结对编程会不会变成致命的缺陷？
   答：个人一直认为结对编程要谨慎用，特别是在国内的情况下，包括结对的环境，水平，制度，都要很小心，
否则真是有可能成为障外呢

   E  敏捷团队中全功能团队和去角色化(尤其是没有PM这个角色)，会不会让项目失控？

    答：敏捷的BA和scrum master等角色，其实也都承担了部分PM的角色了，当然也有不少由SQA去做
scrum master的，这看各公司的人力配置，也可以依然用PM这个角色，因为可能团队中，scrum master
可能由那些对过程改进更有能力更有兴趣的人去做，反而更好，PM依然做PM的角色，做点管理进度的，这时的PM
其实职能已经是跟传统的PM有点不大一样了，等于把"scrum master"的角色一分为2了。

    F. 敏捷不是完全抛弃文档，但是文档要去到什么级别？ 和传统的文档又有什么区别？
    答：敏捷的文档，我认为要做到“用的时候团队能看的明，执行时正确理解，交接时能顺利交接”就可以了，
  甚至在代码中都可以搞进很多重要的文档，把注释提升一个层次。但要是交付用户时，用户要一套传统文档，
那就要提前准备，安排专人去搞了，所以，文档一定要有的。

  
      G. 敏捷开发扁平化的结构，如何保证不会出现扯皮和纠缠不休？
         答：这个问题有点大，个人认为，无论什么开发方法，之前一定要把制度落实，严格执行，
团队达成共识，大家心中都敏捷了，思想目标认同了，才有继续工作的动力。

   
     H. 站立式会议如果避免沦为流水账汇报，如何让大家清楚得知道你在干什么，遇到什么问题？
      答：时间上规定，其次，有人记录，记录模版要简单，不要传统会议那些麻烦的记录格式；
严格按照SCRUME的，昨天做了什么，遇到什么困难，今天打算如何做和解决。主持者在之前一天，摸好底
大概心中有数，指定站立会议要大概什么话题。 理想中的每日立会

团队成员陆续到达办公室，收收邮件，看看信息。立会时间到了，团队成员来到了白板前。大家先打了个招呼，开个

玩笑活跃了气氛。然后团队成员依次站到白板面前给团队描述他昨天完成的、今天计划的和遇到的障碍。气氛轻松，

完成的好的团队表扬，遇到障碍的团队七嘴八舌快速落实了会后哪些人将参与这个障碍的解决。才6分钟左右，会议就

开完了。大家站在一起，“123xx团队是最棒的”，作为会议的结束。
 
     I. 敏捷开发究竟适合哪些业务场景？项目or产品？(同行倾向于项目，说是产品经常要改，可是敏捷的宣言不就

是拥抱变化吗)
      答：应该说，都适合吧，但好象大家实践项目的多点，
  
     J. 敏捷开发中，成员分工要如何进行？横向划分或者纵向划分？
    答：感觉其实按scrum的划分方法就足够了。必要时再调整下，但感觉产品经理，还是要设置这个职能，当然
有些可以兼职淡然。
    
   
 K. 敏捷开发和管理中，如何让后进来的新人尽快熟悉产品和架构？
   答：个人感觉，还是要看新人是否愿意敏捷，不愿意，从骨子里喜欢传统的话，不要让他入敏捷团队了。
 其次，搞好培训，把团队的气氛搞好，多激励，有时不妨搞点传销的气氛。培训要导师制，旧人带新人。
让新人也能多发表自己的意见，旁观者清，让新人从心理上先融入敏捷中去。要是一些技术强的新人，可以让其
快速轮岗，比如作为需求，规划，架构，编码，测试的观察员，快速让其都跟踪一次流程，不要认为一拿到新人，
就当其牲口，让其去干活。