IBM Agile Practice

relha

　　好吧，本人承认很狗血，标题比较唬人。不过怎么说本人已经在IBM服务超过5年的时间。从07年开始大规模的Agile以来，也参与了一些Agile的项目。不过可能跟本人所在部门有关，如果伤及无辜，希望各位同仁手下留情，勿拍砖。
　　关于Agile是什么不想赘述，其实能够实现Agile的方法论有很多，不过在IBM更推崇Scrum的方式（个人推断可能是因为大多数的问题项目是由于沟通不顺畅或者有问题所导致），其Scrum会议的内容页很固定。一般要回答3个问题：

• 你昨天做了什么
  
• 你今天要做什么
  
• 什么阻碍（blocker）
  

　　而从实践角度讲，大家除了需要在会议上汇报状态，还需要通过扑克游戏的方式，对每个任务进行权重点数评估。扑克牌是根据费波纳奇数列派生，最小是0pt，最大可以是∞。大家都是根据任务的复杂度对项目的权重进行衡量。当然，权重越大，代表任务越复杂。其实原理和玩法很简单。接下来我来说说我在IBM所经历或者看过的相关项目是怎么玩Agile的吧。
　　由于本人在IGA工作过，而欧美业务一些项目团队数量都很小。而大家又都一窝蜂的玩Agile。那么基本上有几种玩法

• 项目成员很小（<3)，这类项目开Scrum基本上都是亚历山大，人员是在太少了，加上项目经理才3个人，开scrum的话既不现实。还不如改成TDD或者User Story Driven来的好。Agile理论体系在此项目更是形同虚设。基本上就是挂名而已。
  
• 项目成员适中，但是坚决不通过正规渠道开Scrum会议。这类项目基本上都是通过聊天工具进行群聊方式开Scrum，当然最大问题就是效率问题。本人曾经经历和了解过开Scrum会议,开了2-3个小时的。狗血的是这种srum会议每天都开啊，估计都闲聊了
  
• 项目人员适中，Agile理论很正规。严格按照Agile理论体系进行
  

　　本人曾经一度怀疑过Agile在IBM是否真的会执行的很好。不过，本人有幸，现在的项目是倍儿标准的Agile项目。不但会议时间卡的很准，而且就会议类型就能够显示出Agile使用的专业程度。那么先分享一下项目的会议有哪些：

• 首推Scrum，15分-30分，大部分情况15分钟肯定搞定，每个人必须通过电话会议参加，并且把最终客户代表拽进来，听项目进度，有啥问题直接提。沟通无障碍，很有效率。30分钟的scrum会利用前15分钟进行状态汇报，后15分钟针对存在的问题进行原型的展示，以获得客户的认可
  
• 中期检查会议，这类会议一般也只有30分钟，主要将项目组的本次迭代的任务都过一遍，有问题的抓紧时间调整。面者后面提交的时候延期
  
• 迭代结束会议，这类会议一般也只有30分-40分钟。这类会议主要是针对本次迭代所完成的任务情况进行讨论，看看是否有一些任务需要挪到下一个迭代进行开发等等。
  
• 迭代计划会议，这类的会议都很长，每次大约2小时，可能持续3天左右。主要针对本次迭代所要开发的内容进行讨论，大家也会参与进来，对相关的任务进行权重打分。当然，也会把最终客户代表引入帮助明确需求。
  
• 功能演示及面对客户的总结类型的会议，这类会议一般会有1个半小时，功能演示主要是针对上一个迭代所开发出来的成果进行展示，让最终客户了解已经有多少功能实现了，并且能够直观的展示出最终的效果是什么样子。紧接着还会根据开发团队的上一个迭代的情况进行总结。包括每个成员花费的时间，面对的主要问题等等。让客户清晰明确的了解开发团队成员的具体情况。
  
• 针对开发团队的总结类型会议，这类会议一般1个小时。主要是总结项目中存在的问题，比如bug的多少，都是由于那个模块引起的，属于数据问题还是需求问题等等。
  

　　以上便是我现在的项目的会议的情况，其实不难看出，现在项目会很紧密的把最终客户包含进来。从沟通渠道上来讲，是很顺畅的。值得一提的就是在开发时候我们现在所用的一些工具感觉很顺手。在此声明，本人不是做广告哈，不过在实际过程中，使用RTC（Rational Team Concert)的确能够提高工作效率，有利于版本控制。我们项目所有的开发任务都是通过RTC进行分配，每个开发所对应的修改，也都关联到RTC相关的任务上。在实际部署和提交的时候，完全可以按照任务进行提交，不用担心代码提交不全等问题。相对于CVS，SVN等老牌版本控制工具，这么做的确是太舒服了。
　　以上便是我在IBM所经历的一些关于Agile的琐事供大家分享。特此声明：以上观点，纯属个人观点，不针对于任何企业和公司。