我们的敏捷起程

      之前零星听过些敏捷思想，也曾试用过leangoo来进行团队协作，但总只能算是借用了工具和形式吧，蛮久以来对我们的敏捷转型翘首以盼。现在得以真正浸入到敏捷之中，整个团队全面拥抱敏捷，欣喜有了系统的敏捷学习机会。

       Scrum是一个用于组织和管理工作的框架，建立在敏捷的一套价值观、原则和实践之上。谈到价值观，以人为中心，以诚实、开放、勇气、尊重、专注、信任、授权和合作为敏捷的基础，不免有人觉得会有些形而上的论调。但回顾我们的日常工作情况、以及两个多月来的敏捷转型实践，对敏捷的方法步骤是在更好的逐步运用中，但总还感觉我们的信任合作、授权、开放等精神风貌层面，可能还未能完全跳出团队长期固有氛围的笼罩，还未能展现出明显的焕然一新。

       Scrum依赖于快速反馈来进行探索。在敏捷方式中，工作本身是在一些短期、时长固定的迭代中完成的，1周到1个月迭代周期。在每个迭代中，自组织、跨职能的团队完成所有计划的工作，关注交付可以工作、集成好的、经过测试的、具有业务价值的特性，力争更好交付成果。

       首先要建立产品列表——一个按优先级排列的、成功开发产品所需的特性及其他功能的列表。再产品列表的指导下，我们总是先做最重要或优先级最高的条目，形成大家达成共识的迭代计划。但目前的实践中，我们可能也还应该再考虑下，如何使'迭代计划'这件事也同样更敏捷起来。

       在迭代结束时，团队与利益干系人一起评审已经完成的特性，获取反馈。根据反馈，PO/BA和团队既可以对下一步工作内容进行修改，也可以修改以前的工作方式。

       同时，团队也同步采取进一步跨职能，所有团队成员都能不断协调、步调一致，改变之前不同领域的人沟通不畅、不频繁，重要问题有时拖到较晚才讨论的不利情况。

       在改变我们之前固有的瀑布式计划驱动思维中，敏捷的持续响应，要求我们巧用产品开发的可变性和不确定性来产生创新解决方案，积极采用有帮助的可变性，同时及时探讨/及时反馈以减少各种各样的不确定因素。更多的关注闲置工作，而非闲置人员。快速前进、但不匆忙，采用最小够用的仪式，妥善组织工作流程以获得快速反馈。以质量为魂，通过验证工作结果和质量来度量进度。围绕以上Scrum的核心思想，我们作为团队SM有很多的方法需要去探索实践，力求能清除阻碍团队生产率的障碍，探索出高绩效的适应团队的Scrum方式，帮助团队顺利适应敏捷转型过程。