敏捷的基本关注点- 记录我与公司内敏捷推广者的一次交流

   最近一段时间，因为PO的挑事，我和公司负责Agile推广的VP做了一次深入的讨论。我向她提出了几个在实践中遇到的问题，她也耐心的作了回复，而且回复的详细程度已经到了让我感动的地步。我本身对流程很感兴趣，也曾想过作一个职业的流程推广者，不过每每想到这位VP，我都不由的感慨，作这行得有巨大的耐心和无比坚定的信心。对旧思想的破除是一项非常吃力而且不容易讨好的，短期内很难看到效果的事情。而且，就从我们这边的实行情况来看，还得无奈的面对阳奉阴违的局面。我不知道自己是不是可以说服自己接受这一切，起码，我不会希望自己我只是为了销售而去推广，那就太对不起自己的良心了。

  问题一： point还是duration。这个在我上一篇博客中也提到了。主要的结论是敏捷还是最好用point。point反映的是一个相对大小，是一个团队对一个故事复杂度的认识。它不与任何其他度量单位进行换算，比如代码行、功能点等等，因为它希望强调的是整个团队的认知度。在进行point确认的过程中，整个团队需要进行彻底的讨论，确保每个人都理解团队中的其他人对这个故事的认知。让每个人的认知水平都达到同一个高度。所有的细节都希望能在碰撞中消除。所以，是否有一个好的Plan meeting是一个sprint成败的关键。很多时候，不是说过程中变来变去，而且一开始大家就没有认真的对待。很多时候，开发会觉得这个故事两行代码就搞定了，那么测试会觉得我得准备大量的数据才能完成这次测试，而且之前的case都不能用了。文档会说我得从很多地方找到原先的地方作修改，那么这就产生了对复杂度不同的理解。在这种讨论中，彼此间对他人的工作性质和工作意义有了更深刻的认知。这就是为什么常说敏捷中只有三种角色，scrum master, product owner和team member。没有按照function不同重建我们本身就要破除的silo。当开发理解了测试为什么感觉这么复杂后，她需要思考我如何可以帮助测试呢？在我们之前的一个典型例子就是开发帮助测试写了很多准备数据的脚本，帮助测试批替换了很多数据，避免测试重新构建一批数据。这就是比较好的合作案例。而如果作duration的分析时，我们会让开发评估自己的时间，测试评估自己的，作一个处理就是整个任务的duration了，没有人去关心别人在做什么。

   每个sprint完成的故事的point总和就是一个velocity。这个velocity很有意义的。在作release plan meeting的时候，我们可以根据velocity的大小，估算出我们在N个sprint的时候可以完成多少个故事。对于明显无法完成的时候，PO需要进行筛选，调整scope或者删除一些，最起码优先级要重新认真思考。通常来说我们只能承诺80%的必做任务，20%是最好可以作的。通过这些评估，我们也可以了解这次release任务的一个难易程度。通常我们每5个sprint的时候都需要重新作一个heartbeat plan meeting，重新梳理一下手里的任务。敏捷不相信对太久未来的期许，只希望当下或者三个月内的事情能做到极致就行。

   问题二：开发的idle如何处理。一开始我的问题是这样的。我说针对每一个故事来说，在内部通常会进行开发-测试-文档这样一个小的迭代，那么很多时候开发提交完之后，没什么事情作，尤其是在最后阶段，没有时间开新的故事了，那么idle的厉害啦，可否对下一个sprint的故事做准备，比如写好sql等等。其实，这里我还是在按照传统思路问问题，既然只有team member的概念，那么怎么会还有这么瀑布的事情发生呢？在一个标准的敏捷团队中，既然开plan meeting的时候大家对故事的理解基本达成一致了，那么自然可以同时开工，测试不需要看到界面来写case，文档也不需要等着界面来写文档。开发提交完代码后，也不是说没事了，最起码得完成单元测试，互相之间的代码评审，提醒测试那些地方要特别注意，所有的这一切都是为了保证质量，只有质量提高了才能真正提高开发效率，而不是无聊的redo&debug。我经常跟team member说TQM的精神。质量不是由测试负责的，而是由所有人负责的，如果从一开始PO就没有意识要提高需求质量，一开始开发就没有提高代码质量的意识，再多的测试也保证不了质量。

  问题三：速度还是质量？这个问题答案显然意见，我不必追溯了。我只是和VP发发牢骚而已。

  问题四：设计是看眼前还是尽量多看。其实这是一个不太好问也不太好回答的伟命题吧。 VP的意思，应该还是看眼前，保证眼下的故事按照最佳的设计来做，而之后发生的事情要按照重构的思路来进行。 因为我们对未来没有信心，而且敏捷需要保证最快的反馈。如果让设计尽可能多的涵盖未来的需求，会让当下的代码没有必要的臃肿，减缓完成的时间，浪费了反馈的机会。而这下反馈很有可能会破坏或者影响到你当下的设计，会让你作的自认为很充足的设计成为浪费。所以应该思考如何把握重构才是王道。而且同时应该让代码即使面对当前的需求的时候也要尽量灵活易于修改和扩充，多考虑一些成熟的模式，多创新。

  最后，我给VP总结了一下我们之间的这次讨论，作为一个敏捷的团队，一定要有一个集体荣誉感，凡事都要上升到团队的高度来思考，避免个人英雄主义和为了自己的蝇头小利而对团队造成伤害。VP对我的总结很满意

 

转载于:https://www.cnblogs.com/sammerkong/archive/2010/11/17/1880258.html