敏捷之实

如今，在软件行业里，敏捷这个已经是被大家说烂的字眼，甚至是在其他行业里，也都在常识性的应用。可是在这些簇拥者里，是否都已经深谙敏捷，对敏捷了如指掌，并能够应用这些知识来提高我们的交付能力，这些都是我们要思考的，甚至是要去摒弃的。
谈到敏捷，似乎成为了管理者去调整项目的一个救命稻草，人人想用，认为敏捷为银弹，有了敏捷，我们可以不加班，按时交付，提高用户的信赖和满意度，促进沟通，实现全面成功。当然，敏捷可以做到这些，这是敏捷的效果，我们看到过这些成效，所以我们才去用，可是怎么用呢？是不是敏捷跟你在玩街机一样，输入一串秘籍你就无敌了？这显然是扯淡。
在和一个朋友谈论他目前的工作状态的时候，我很是担忧这样他所处在的这个团队到底能坚持多久，我大概了解了一下细节。和大多数外企一样，是一个跨国合作的工作模式，他所处在的团队是一个自动化开发团队，之前的状态是在我们的requirements pool 里有大量的需求，关于这些需求的开发工作已经结束并且已经交付使用了，大家每天都是玩命的在看这些spec然后把这些spec转换成可测试点，然后再去开发自动化代码，每天工作到8 9点算是早的，有一天，轰隆一声雷响，敏捷闪亮登场。这个组里的其他member并没有接触过敏捷项目，也不知道什么是敏捷，都很好奇，然后北美一个声音说：it's amazing, you don't need work overtime anymore。 大家从此兴奋了。他们的日常工作中出现了一个task management tool----green house,所有的spec从服务器的文件夹里转移到了JIRA里，每天早上多了一个action---scrum meeting。除了这些东西，生活没有改变太多，并且某些时候，这些撑了所谓敏捷带来的副作用，而敏捷也不再那样让人兴奋。我的朋友很无奈，他做过敏捷的项目，他觉得这个项目组像一个走火入魔的孩子，却无可奈何。
我不禁的想，如果整个项目被分成开发，手工测试，自动化测试，业务需求分析等部分，而这些部分又没能更好的合作的时候，所有的合作仅仅是邮件的话，那么，在团队不断扩张的时候，也是最危险的时候，悲剧的是仅仅自动化在采用这所谓的敏捷。
开发没有单元测试代码，更不用去谈及TDD，开发过程中，dev没有和qa很紧密的合作，QA的介入并没有在项目开始初期，沟通匮乏，BA在编写长篇累牍的spec之时，也没有和dev，qa,automan们一起进行交流和沟通，信息闭塞，自然不用说，那些颗粒度更细的story也是毫无踪影……
你有了JIRA就敏捷了？你有了scrum meeting就成功沟通了？这些在我看来，这种所谓的敏捷无非是一种过重的方法论而已，形式上的敏捷，并不能改善整个项目状况，而我们也不需要这种形式上的敏捷。敏捷不是在白板上贴几张便签，两个人坐在电脑面前看微博，拥有了自动化……如果想改善，请参考：
1. BA在写spec的时候适当的和dev&qa进行有效沟通，把近百页的spec按照priority写成story，当然analysis的过程也可以有QA参与。
2. 开发人员先写单元测试代码，从根本上挖掘市场价值和发现价值，超越实现价值的禁锢，之后写实现代码，直到虽有单元测试代码通过。
3. QA鼓励尽早进入需求分析，尽早进入测试
4. 管理现场化----各个base团队把自己拿到手的spec贴在在分析，在开发，在测试，已完成这几项，项目的状态可以一目了然，JIRA or Mingle虽然可以一时间的解决分布式开发团队上沟通的缺陷，但是信息最直接的反馈是靠我们的视觉，换句话说，我还是推崇卡片墙上那些有序的便签，因为信息的反馈最直接。
5. 结对编程。dev 和 qa， dev 和 dev， qa&qa, qa&ba，各种结对，你要是需要的，有帮助的
6. 摒弃你那些禁锢的思想，QA仅仅是测试，开发仅仅是写实现，ba仅仅是分析，我们需要在必要的时候能扮演各种角色，身为QA，你可以去做开发，写单元测试，做code review， business analysis，coaching……
敏捷并不是我们来给客户看的，也不是给上级看的，是我们用来真正的提高交付能力，提高团队水平的方法论，闲话不说，我们要关注敏捷之实，也要关注敏捷之实，第一个实，是真相，第二个实，是收获。