敏捷无敌-第14部分
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
“可也不能天天吃冰淇淋啊！”小宝补充道。
“要不然谁迟到，就让他交5块钱吧，钱多了，我们可以在每次回顾的时候，买些瓜子、零食什么的。”大民的建议很具有可行性。
在大家纷纷表示赞同的时候，阿紫又抛出来一个问题“我觉得，我们的Plan会议、演示会议、回顾会议，谁迟到，也都应该罚款。”阿紫是团队的CFO，负责每次的Team Building的筹划和费用的计算，看来她想通过这个方式多收点钱！
“那有点太严格了吧？”经常迟到的小宝为了自己的钱袋子首先表示反对。
“要不这样吧，Daily Standup Meeting除外，其他Meeting，迟到三分钟以上，再罚款5块，如何？”阿捷看这次大家没有异议，把这两条记到本子上。
“我还有个问题，是关于Product Backlog的，从Scrum的角度来讲，都是由Product Owner负责的，别人不应该干涉，不应该修改Product Backlog。我经常会有一些想法，是关于产品的功能的，觉得应该加入到Backlog中去，可又不能直接修改Backlog； 我就只好记到别处，时间久了可能就忘记了。要是往Backlog中加吧，就得天天地打扰Product Owner 李沙，那他也烦啊！”大民提出了一个很关键的问题。
小宝马上表示赞同：“是啊是啊！我也有同感！”
“我和阿朱也讨论过，要是我们也能随时添加就好了。”阿紫瞅着阿朱，阿朱点了点头。
“我们不是在每个Sprint中间，不都是跟Product Owner有一次会议，Review Backlog吗？”阿捷满怀疑问地问道。
“是有，但是不够及时，事情都等到那次会议，搞得会议也挺紧张的。”大民接着说。
“可要是我们每个人都能修改，都能添加的话，Product Owner也受不了啊！”小宝替李沙担心。
“嗯，是啊！咱们好不容易才劝说了李沙来当这个Product Owner，没有他就没有人维护Backlog，咱们这个Scrum也就不能算是真正的Scrum了”！阿朱皱着眉头说。
“要不然这个事情放一放，哪天跟李沙一起讨论讨论，可能更好些。”阿捷提议道。
“嗯，也行，咱们自己也不能定。”大民一脸的无奈。
“还有一个就是Review的问题，我发现我们的Review工作，一直都不能按时完成，这在每日例会上，就能看出来，总有人说我的Code做完了，自己也测试过了，但是还没有人没给我Review ments，所以还不能Deliver。”阿捷又提出一个令大家尴尬的问题，有些人不好意思地低下了头。
“其实吧，有时候也不是大家不想Review，现在不是讲究快跑嘛，就是都挺忙的，顾不上。”小宝首先打破了沉默，替大家圆场，不过也是实话。
第9章 没有规矩，不成方圆（3）
阿捷点了点头，“是啊！这是我们实施Scrum以来出现的一个新问题，以前有大块的时间用于Coding，所以Review也不会像现在这么急，所以需要大家发表一下意见，看看我们有没有什么好的办法。”
“在做Sprint计划的时候，针对每个需要Review的文档或者代码，给需要Review的每个人都预留出来一定的Review时间，这样大家应该就不会紧张了。”小宝说道。
“让别人Review的时候，应该给出最晚回复时间，要不然别人也不知道紧迫性。”
“被邀请Review的人，如果不能及时Review，应该提前告诉对方。”
“最好是做一个邮件模板，把需要Review的内容，如文档或者代码的存储位置、修改原因、最迟答复时间等，都放在里面，这样信息集中。”
大家七嘴八舌地提着建议，看来这个问题还是比较容易解决的。
“好，那我们就按照上面大家提的意见试验一段时间。”阿捷总结道。
“还有一个非常关键的问题，就是关于Burndown Chart的。大家都知道，想让这个Burndown Chart反映出我们项目的真实状况的话，那我们每天对每个任务剩余工作量的估计，就应该准确及时。可我发现，有时候我们中总有人忘记更新，譬如在 Daily Standup Meeting上说某个任务已经完成了，但看Sprint Backlog，该任务的状态还是In Progress，还有一定的剩余时间。”
“呵呵，这好办，忘记更新的接着罚款。”阿紫这个CFO时时不忘增加收入的机会。
“有时候也不是故意不更新的，一忙就忘记了。”小宝好像不更新的次数最多，赶紧出来解释。
“要不这么着吧，我们就留三次免罚机会吧。”阿捷建议。
“每个人三次？总共才三个礼拜的Sprint，这样下来还是不能反映实际状况。”大民立刻表示反对。
“就是就是！”阿朱也表示赞同大民的意见，“要不然，咱们就给整个Team留三次免罚机会，如何？”
“这个方法可以，跟100米赛跑的规则差不多，虽然不太公平，但可行。”大民表示赞同，小宝、阿紫等人也都没有异议。
“好！这个问题也有解决方案了，看看大家，谁还有啥建议？或者还有哪里需要改进？”
大家一片沉默，看来都没有什么话题了。
“好！我们今天的成果还是挺丰富的，我下去整理一下，把我们今天讨论的这些东西跟以前的总结到一起，形成咱们自己的Scrum Rule！那今天就到这！”
大家边走边聊，陆陆续续走出“桃花岛”。
阿紫说：“大家觉得我们下次Team Building去哪里玩比较好？”
“我提议去打真人CS，非周末的时候，平均每人100多些。”阿捷这个CS迷，本性不改。
“我觉得去爬爬香山也不错，好久没去了！”阿朱提议。
“去后海吧！先划船，然后泡吧、杀人！”大民这个*分子，每次的提议都很奢侈。
小宝插了一句：“去打Golf吧，我都建议了好几次了！”
“好啊！好啊……你请客我们就去！”阿紫开始起哄。
大家吵吵呼呼地回到格子间，引来其他Team的一阵侧目。阿捷这个团队的传统一直就是这样，人不多，但每次开会都能听到他们的笑声。
回来的路上，阿捷顺路到产品经理李沙那里，讨论了一下关于Product Backlog条目更改的问题。让阿捷没有想到的是，李沙认为这个问题根本不是问题，只要大家添加新条目的时候，利用ScrumWorks工具软件里面的主题功能，对每个新条目施加一个“Not Reviewed”的主题即可，这样李沙就知道这些新条目了。但是，李沙还是重复强调，对于其他已经存在的Backlog条目，一定不能修改，特别是先后顺序。
阿捷回来重新整理了一下Scrum Rule； 然后分发给大家。
1．每日站立例会迟到，罚款￥5。
2．对于未及时更新任务状态和剩余工作量的，整个Team留三次免罚机会，以后再有人违反，则罚款￥5。
3．对于Sprint计划会议、演示会议和回顾会议，迟到超过3分钟，罚款￥5。
4．进行任务细分时，每个任务估算最大不能超过18小时（三个工作日）。
5．在Sprint计划会议上，认领了一项任务的人，可以对该任务估算做出不超过50％的调整。
6．对于复杂任务的估算和分解，采用“DELPHI”方法。
7．每个人都可以添加新的Product Backlog条目； 但必须标示为“Not Reviewed”，以方便Product Owner审议。
8．为提高Sprint回顾会议的效率，在Sprint回顾会议之前，每个人应该给出“我们做得好的地方、需要改进的地方”。
9．在Sprint计划会议上，我们应该预留10％的估算时间作为缓冲，以应对突发事件。
10．在Sprint计划会议上，我们应该进行关键路径、风险、外部依赖的分析。
11．对于Review，发出Review的人必须给出截止日期，参与Review的人，必须在截止日期前给出答复。
第10章 持续集成（1）
Nothing in the world is difficult for one who sets his mind to it。
世上无难事，只怕有心人。
——吴承恩《西游记》
“目标管理（MBO）”的概念是管理专家德鲁克（Peter Drucker）1954年在其名著《管理实践》中最先提出的，其后他又提出“目标管理和自我控制”的主张。德鲁克认为，并不是有了工作才有目标，而是相反，有了目标才能确定每个人的工作。所以“企业的使命和任务，必须转化为目标”，如果一个领域没有目标，这个领域的工作必然被忽视。因此管理者应该通过目标对下级进行管理，当组织最高层管理者确定了组织目标后，必须对其进行有效分解，转变成各个部门及各个人的分目标，管理者根据分目标的完成情况对下级进行考核、评价和奖惩。
目标管理提出以后，便在美国迅速流传。时值第二次世界大战后西方经济由恢复转向迅速发展的时期，企业急需采用新的方法调动员工积极性以提高竞争能力，目标管理的出现可谓应运而生，遂被广泛应用，并很快为日本、西欧国家的企业所仿效，在世界管理界大行其道。Agile公司作为美国最大的通信公司之一，也毫不例外地采用了这一管理实践。
目标管理指导思想上是以Y理论为基础的，即认为在目标明确的条件下，人们能够对自己负责。具体方法上是泰勒科学管理的进一步发展。它与传统管理方式相比有鲜明的特点，可概括为如下所述。
1．重视人的因素
目标管理是一种参与的、*的、自我控制的管理制度，也是一种把个人需求与组织目标结合起来的管理制度。在这一制度下，上级与下级的关系是平等、尊重、依赖、支持的，下级在承诺目标和被授权之后是自觉、自主和自治的。
2．建立目标锁链与目标体系
目标管理通过专门设计的过程，将组织的整体目标逐级分解，转换为各单位、各员工的分目标。从组织目标到经营单位目标，再到部门目标，最后到个人目标。在目标分解过程中，权、责、利三者已经明确，而且相互对称。这些目标方向一致，环环相扣，相互配合，形成协调统一的目标体系。只有每个人员完成了自己的分目标，整个企业的总目标才有完成的希望。
3．重视成果
目标管理以制订目标为起点，以目标完成情况的考核为终结。工作成果是评定目标完成程度的标准，也是人事考核和奖评的依据，成为评价管理工作绩效的唯一标志。至于完成目标的具体过程、途径和方法，上级并不过多干预。所以，在目标管理制度下，监督的成分很少，而控制目标实现的能力却很强。
阿捷觉得MBO跟Scrum在思想上是相通的，所以对这个管理方法具有无比的好感。在Agile公司，目标管理有固定的一套程序或过程。它要求组织中的上级和下级一起协商，根据组织的使命确定一定时期内组织的总目标，由此决定上、下级的责任和分目标，并把这些目标作为组织经营、评估和奖励每个单位和个人贡献的标准。为了更好地检查目标完成情况，上级和下级要定期会晤，讨论进展和问题，在Agile公司，这种定期会晤称为“One to One Meeting”，是经理跟员工一对一的会议。
阿捷自从接管TD这个团队后，跟员工制定并讨论MBO，已成了他每个季度的必修课。因为团队正在实施Scrum，阿捷给阿朱设定的目标之一就是“如何做到测试的敏捷化”。
第10章 持续集成（2）
阿捷率先开头：“我们之前也做过几轮MBO的One to One了，你对这个会议本身有什么建议吗？”
“嗯”，阿朱略微沉思了一下，“Review要及时，目标设定要随时调整。其实我对以年为跨度的Objective Setting和Performance Review的最大困惑就在于两者的严重脱节。”
“哦？”阿捷示意阿朱继续。
“实际上，这样长跨度的目标设定，更倾向于一个Career Plan而不是Objective Plan。而拿一个Career Plan作为年终Performance Review的依据，似乎不怎么合理。”
“嗯”，其实阿捷也有同感，之前几年，都是袁朗跟阿捷One to One的，最终都沦为了形式，阿捷也准备做些改变。不过阿捷还是鼓励阿朱说下去，“你觉得应该怎么变化更好些？”
“我是这么想的，我们实施敏捷开发有一段时间了，一个Sprint的周期基本是3个礼拜左右，那么我们每人的短期目标完全可以跟每个Sprint结合起来。因为每个Sprint的目标都很明确，再落实到每个人头上就会非常实际。但这样，就得加强Review的频率，以及时调整目标。”
“你的意思是说我们把每个季度一次的One to One，改成每个月一次？”
“对！”
“嗯，你说得非常有道理，我也有同感。可以把每年的Objective Setting，作为员工个人的Development Plan。怎么样？”
“不知道别的员工怎么想，我觉得这样做，会更有价值。只不过，你就得多花些时间在这上面了。”阿朱笑着说。
“这倒没关系！关心并帮助每个员工向前发展，本来就是我的责任。我会再做一个调查，了解一下其他人的看法。你今天提出来，非常好！”阿捷抬头看了一下墙上的表，还有半个小时的时间，得赶紧讨论这次的主题了。“我们接下来看看我们上次提到的敏捷测试，你有什么最新进展吗？”
“我这几天思考了一下，我觉得我们的项目有必要采用XP的持续集成。”阿朱针对自己的“敏捷测试”目标，提出了自己的想法。
“为什么要持续集成？”阿捷问。
“你看，我们现在的开发模式是项目一开始就划分模块，然后等所有的代码都开发完成之后再集成到一起进行测试，随着软件需求越来越复杂，软件已经不能简单地通过划分模块的方式来开发，需要项目内部互相合作，划分模块这种传统的模式的弊端也越来越明显，由于很多 Bug 在项目的早期就存在，到最后集成的时候才发现问题，我们测试人员需要在集成阶
