第一次听到敏捷Scrum这个词的时候，觉得这是一个非常高大上的东西，我听不懂，也看不懂，一切都是云里雾里的；后来再次提到敏捷Scrum这个词，觉得这就是一个工作流程，列计划，估算工作量，完成工作，一切都按部就班，日复一日；最近重新接触敏捷Scrum这个词，我似乎有了新的认识，新的理解。
什么是敏捷Scrum?从这个词语我们就可以看出来，敏捷就是快速响应、快速交付、用以提高客户的满意度和认可度。曾经无论是生产行业还是软件行业，盛行的是传统的瀑布模式，但随着社会经济的发展，客户了解度、参与度的加强，需求变化频率的加快，似乎瀑布模式不大适应这种节奏，敏捷也由此诞生。敏捷可以快速响应、及时调整，带来成本的降低、成果的显著，从而使得客户满意、投资高回报。
在敏捷的整个流程中，与我最为相关的是什么呢？是迭代，也是每一个迭代会议。很多人认为会议是一件浪费时间的事情，说实话，任何一次会议都需要时间为代价，但是这个代价是否值得，是否能够带来效益才是关键，失之东隅收之桑榆。如果一个不能带来效益的会议那就是浪费时间，如果一个能够带来效益的会议那就是值得的。下面我想浅谈的是我对敏捷会议的理解。
梳理会：
以前作为一个研发人员，在接受到研发需求的时候，往往得到的是一个需求文档，一份需求列表，但是我们真的能够理解这个需求、清楚这个用户场景吗？大部分情况下，我们是不了解的。在功能研发的过程中，我们需要不断地讨论需求，不断地沟通确认，不断地来回修改，这也是一种时间成本。
而现在梳理会解决了这个问题，梳理会可以关注用户的使用场景，将不清楚的需求了解清楚，这样研发人员在开发时具有清晰的目标与方向，节省研发时间，避免功能的反复修改。测试人员在测试时有明确的验收场景，提高产品质量。
迭代计划会议：
凡事预则立，不预则废。计划会议就是在一个迭代周期内，团队计划与承诺能够完成的工作和任务。从而明确该阶段的目标，全身心地投入到工作中，为了一个目标而冲刺。用志不分，乃凝于神，目标多了也就没有目标了，精神不够集中也就没有效率了。
计划会还有一个关键就是对于时间的估算，我们经常只关注于一个功能我们做完没有，很少去关注一个功能所花费的人力成本，时间估算可以让我们很清楚的了解一个功能的人力成本。
而估算时间后，研发人员也会全力在规定的时间内完成任务，言必信行必果，这是研发团队的承诺，有承诺就必须履行。长此以往可以提高响应力，提升客户满意度。
每日站会：
一日之计在于晨，早晨是一个需要承前启后的时间，每日站会就是一个承前启后的短会，总结前一天的工作、计划当天的工作、指出遇到的问题。每日站会可以及时掌握迭代进度，增强团队成员间的合作沟通，更好的保障迭代的进行、计划的完成。
每日更新燃尽图不仅可以清晰的了解迭代的进度，每一天工作完成情况，还可以调动团队成员的工作积极性，可视化的让团队成员了解自己对团队的贡献。
验收会议：
验收会议是一个检视和调整的过程，在我看来验收会议有两个主要的目的：一是增强研发团队和市场、方案等其他团队成员的沟通，有利于产品的改进、优化和提升。二是增加团队成员的自信心和积极性。
每一个迭代的验收会议，可以让市场方案团队成员及时了解研发进度和功能实现情况，并适时指导开发方向；也可以让研发团队了解产品的业务和市场，有助于功能设计及研发。迭代验收会议还可以让每一研发成员之间互相了解彼此的工作，增强对产品的整体理解。
软件开发人员成就感来自何处？来自功能调通的那一刹那，也来自演示讲诉的那一瞬间。曾经我们在每一个研发阶段，很难找到一种成就感，每天只是日复一日的写代码，我们常戏称自己为“码农”。验收会议是一个团队成员向外展示自己研发成果的时间，可以让团队成员了解自身工作的价值、提升自我的成就感，从而增强自信心和积极性。
回顾会议：
吾日三省吾身，我们虽然不必每天检视团队，但是当一个迭代结束的时候，还是需要总结和反省。总结团队在该迭代中做的好的地方继续保持，反省团队在迭代中做的不好的地方加以改进。故不积跬步，无以至千里，不积小流，无以成江海，只有不断地改进，团队才能成长，才能进步。
每一次回顾会议的改进项不能多，罗马不是一天建成的，我们的改进项要有渐进性、持续性，不能急于求成，这样反而会加重团队的负担，使得改进项无法执行下去。
以上就是我理解的敏捷会议应该带来的效益，如果我们能合理的控制会议时间，达到会议应有的效果，那么会议就不是一件浪费时间的事件。培根有一句名言：“合理的安排时间，就等于节约时间”。
我们走在学习敏捷的道路上，对于敏捷我们还要不断地学习、实践、反思、改进。
路漫漫其修远兮，吾将上下而求索……
（PS：如何主持迭代会议的感想留到下次再写吧，不然一次写完，下次就没得写了）
