Agile的培训已经结束了，经过自己的努力也拿到了公司颁发的Agile Coach Certificate。在这里我想简单的总结一下，一个新的团队如何可以简单快速的开始Agile实践。
Agile是一种团队合作开发的工作方式，可以先通过建立以下一些Agile的基本事件来开始Agile实践：
Agile 的一些基本事件
-
Sprint 会议
也可以叫IPM(Iteration Planning Meeting) 我现在所在Team定的Sprint周期是一周，每周一早上，我们Team开完每天的Standup Meeting之后，会开始一个IPM会议，这个会议主要做三件事情：-
回顾上周计划的完成情况
如果上一个Sprint目标没有完成，需要统计一下，上周的任务还差多少，还需要多少Effort去做。并且计算一下上一个Sprint的团队速率是多少。
-
估算接下来需要做的Story的efforts
我们按照Story的优先级排序，从优先级高的开始估算effort。我们采用“纸牌估算法”来对每个Story进行估算。这个我们是还没有做好的，由于我们没有纸牌（昨天晚上我DIY了一些纸牌，下一个IPM会议上可以用上），前几个IPM会议上，我们都是拿贴纸写的。
这样有几个问题：第一，大家可能很容易看到其他同事写的，会对自己的估算产生影响；第二，大家忘了纸牌估算法有些数值是没有的（只有0.5、1、2、3、5、8、20、？等，我虽然跟大家解释过，但是真正估算的时候，我自己也忘记了）。
纸牌估算法，每次我们介绍完某个story的大致情况后，大家把自己估算的纸牌反过来放在桌子上，等团队中所有开发人员估算完成后，翻开所有的纸牌，如果大家估算的数值不一样，需要大家解释自己的估算的原因，然后再重新估算，可能经过几次之后，大家达到一个相同的数值，就是这个story的effort了。 -
制定当前周的Sprint计划
简单统计一下团队这周的resource，主要问一下这周有没有同事要休假。
现在我们是这样做的，我们团队有七个人，这周我们加起来就是：7 * 5 = 35 Man/day。减去上周遗留的6 points：35 - 6 = 29 Man/day。上周的Defects预计需要4天处理：29 - 4 = 25 Man/day。上周我们的速率大概是50%，所以再打一个折扣：25 * 0.5 = 12.5 Man/day。
最终，我们这个Sprint能做的Story加起来就是12.5 Points。我们根据优先级把前面加起来小于等于12.5的Story放在这周的Sprint 计划里面。
这样算一下，你会感觉每周能完成的东西好少，在我看来，假如没有这样的Sprint计划，团队这周实际完成的东西会更少。主要就是团队缺乏目标和紧迫感。估算的不准没有关系，通过长期的这样做，团队成员会更准确的估算Story需要的Effort，并且团队成员会更愿意为自己做出的承诺付出更多的努力。
-
-
Code Review
之前我们团队是每周安排一次一个小时的团队开发人员一起做code review。前几天我们也改成了daily code review。每天review前一天所有的新提交的代码，大家把发现的一些坏味道说出来，然后拍照，每个团队成员把自己需要改的照片放在自己的folder下面，改之前，有一点需要强调的，先要看看是否有较好覆盖的unit test。改好之后，修改照片的文字。下一次做code review的时候，会看是否真正重构好了，如果改好了，在照片名字那里标记一下。
这几次的daily code review，我们都花了一个小时才review完前一天的所有提交的新代码，主要是因为我们提交的代码存在太多的坏味道了。虽然每天花了好多时间来做这个事情，但是这是非常必要的，因为假如我们不通过review去发现这些问题的话，我们后面继续提交的代码质量还是这样，随着代码量越来越大，系统会越来越难以维护。前期我们花多一点时间，但我相信，随着review的次数增加，review的时间会越来越短。最终，整个团队会形成比较统一的代码风格和较高的代码质量。
-
Retrospective
我们是定了每2周的星期四一个小时。Retro帮助团队一起回顾和总结上两周团队的工作。需要帮助和引导团队制定出具体可行的Actions。
Retro也会review上一次retro的Actions是否完成。
几次的Retro后，我发现通常Owner是一个团队成员的Actions会更容易完成。所以Actions的owner最好具体到某一个成员。
Retro也是团队中非常重要的一件事，可以让我们一起思考一起去直面团队中存在的一些问题，然后一起想办法解决，最终提升自己和团队。
-
Sprint 评审会议
这个我们目前是还没有做的一件事，评审会议就是在每个Sprint快结束的时候，大家一起对完成的Story进行一个showcase。这样主要有两个好处：
- 给大家一个展示自己做的功能的机会；
- 团队中其他成员也可以了解其他的一些功能。
-
Daily Standup Meeting
我们团队定在每天早上九点准时开始站会，固定的时候和地点很重要，这样，大家可以提前安排好自己的时间。
每个成员站在团队的看板前面说一下昨天帮助团队做了什么，遇到什么困难，今天继续帮助团队完成Sprint目标做什么。更新看板上面卡片的情况，并且会在站会上找到今天结对编程的partner。
还需要统计Story完成情况，更新燃尽图数据。
看板
看板上分为：Backlog、To DO、Dev(In Dev/Done)、QA(In QA / Done)、Deploy
有些栏目上我们设置了一个WIP(Work in Process)：
To Do(WIP: 4)、Dev(WIP: 4)、In QA(4)
WIP就是指最大的卡片数量，每个栏目下面的卡片的数量不能超过设置的WIP。
我们团队的成员都拿了自己的一张一寸大小的头像照片，我们会把自己的照片贴在某一张卡片上面，确保每个人同一时刻只做一件事情，而且大家可以一目了然看到大家正在做的事情，或者有resource空闲出来了。
看板就放在团队工作的旁边，大家要有一致的目的，想办法快速的把看板上面的卡片移动到Done的为止。哪个环节block了，就需要快速响应去看能不能提供帮助。看板的及时更新信息，我们还需要更加及时一点。
Agile 的基本要求
-
Pair Programming
这里不讨论结对编程的好和坏，要鼓励大家多结对编程，并且更多的Switch Pair Programming。
-
Unit Test
没有单元测试的代码是不安全的。单元测试是一个基本的要求，必须要把所有的逻辑代码用单元测试覆盖到。其实好的单元测试会减少很多人工测试的时间。为代码重构提供保护。
大家在实际开发工作中，还是不太习惯去加一些单元测试，会觉得很麻烦。但其实，没有单元测试，改代码和测试都会变得更加麻烦。自己也不会很有信心对自己完成的story。
目前团队还是有一些没有单元测试覆盖，结对编程的时候，partner一定要互相提醒。
Agile 追求的目标
-
Code Quality
通过结对编程，单元测试，重构提升代码质量，有了这些之后，bug和defects会更少。
-
Clean Code
提升代码可读性，减少以后维护系统同事的痛苦（很可能是我们自己维护）。当然，也是作为一个有追求的程序员的自我要求。
团队还需要再做的，可以进一步提升的事件
以下这几个事件，个人认为，团队Agile转型的初期可以先不做，初期可以先把上面的一些基本的做好。当基本的大家已经很习惯之后，可以慢慢的加入下面的这些事件：
-
Code Dojo
团队通过一起做一些练习，来提升团队中每个人的技能。可以通过Code Dojo那本书上的例子，也可以找一些团队中需要重构的代码或者需要做的story都可以。
-
Feedback
这点我觉得是非常重要的，大家在工作中，对自己的认知可能都是自己感觉的，很少有人会告诉你哪里不足，哪里可以提升。其实，如果没有一个好的feedback文化的话，随便给其他同事提意见，其他同事也不一定高兴和接受的。所以，团队经过一段事件的合作后，需要建立一种feedback文化。
什么是好的feedback？好的feedback需要恰当的提出其他同事的做得不够好的，并且帮忙给出好的具体可行的actions，以及一段时间后的review。
怎么建立好的feedback文化呢？首先，团队中所有同事都必须知道feedback的重要性；大家知道他人给自己的feedback，是帮助自己提升之后，大家需要有一颗勇于接受其他同事给自己的feedback，如果有误解，或者其他同事不了解的，可以详细互相聊聊。
-
Learn & Sharing
活到老，学到老。特别是在变化快速的软件行业里面，每个人都明白持续学习的重要性。在团队中，每个同事，最好能有一专多长。个人觉得，分享的前提还是需要大家先在某个领域有一定的高度，或者对自己分享的内容有较深的理解，这样其他团队中的其他同事才更愿意花时间去听。
当有人愿意分享，有人愿意听，团队的分享就达到目的了。所以，个人认为，建立团队的分享之前，先建立团队的学习氛围。
总结
以上就是一个敏捷团队需要做的一些很基本的东西，但是真正做好每一个事件并不容易，而且假如把以上的每一点都做好了，对团队就会有很明显的帮助。希望刚开始Agile实践的团队，可以先坚持，然后再反思，再改进。
网友评论