|
很多人认为，每天开站会，有固定时长的迭代，有自己的“Scrum Master”，就是在开展敏捷实践了，其实不然 具备敏捷之形的团队有很多，但是，真正掌握敏捷精髓的，却并不多见。这是因为，敏捷方法属于 simple but not easy（简单但并不好做）。与其说敏捷是一场研发方式的变革，不如说是一场思维方式的变革 为什么引入敏捷？敏捷的特点，就是小即是美（Small is beautiful）。这个小而美，体现在人、事、时间三个方面：
总体来说，就是用小团队在小块时间，做出小块的东西来，并且周期性地集成组装 引入敏捷，原因很简单，就是想要发布周期更短 痛点一：发布时间不可控（快速的增量交付）每个月可以跟内部客户一起做 Sprint 计划及 Review 演示。这种做法，给我们带来了哪些改进呢？
另外，可以在 Sprint 3 之后，临时安排了一个小的 Sprint，用来快速地将“潜在可交付”变为“真正可交付” 痛点二：摆脱“接力综合征”（从对抗走向协作）经过仔细地观察和总结，团队各个角色之间的协作方式仍然存在着一些问题，这叫作“接力综合征”。虽然交付周期变成了每月一次，但大家却仍然在按照过去的方式工作。具体表现有以下两点： 1. 宁愿选择等待 每个人都等着上一环节的人把东西弄好送到自己面前来，才能开始工作。比如，经常听到这样的说法：“需求文档还没理清楚，急啥？”“接口设计文档还没确认，怎么做啊？”这种情况，在传统的项目管理中是很正常的。但是，这些空耗的时间，并不能给产品带来直接的价值 2. 角色间泾渭分明 每个人都觉得，只要把自己份内的事做完就行了。比如，开发把工作做完了，也不管做得效果咋样，心想：“反正要丢给测试，我先撤了，测出问题再说。”测试测出来 Bug，心想：“等开发全部修完，我再接着测，反正我都测完了。” 在这种情况下，各角色之间是有一定的对抗的。项目中的任何一件小事都有可能造成冲突。最终大家都耗在那儿，每个人更在意的是“这是你的问题，不是我的问题”，却没有把焦点放在达成整体目标上 在传统的项目管理中，项目经理的很大一部分工作就是要厘清各方责任，界定权利与义务，疏通对抗情绪，并解决随之而来的突发问题。但在敏捷的情境中，更加快速的交付压力，使得这种等待和界限变得越来越不可接受，不得不改变思路 敏捷的打法，就好比是打橄榄球，所有队员都时刻关注着场上的比分。虽然彼此之间有分工，但作为一个 team，进球才是最关键的。敏捷也是一样。从敏捷思想中得到启发，开始进行一系列的改进 首先，开发和测试把位置搬到了一起，并且设定了共同的 Sprint 目标和完成标准 其次，从“你完成 - 我开始”，到我们一起完成 在敏捷团队中，开发干得热火朝天的时候，测试也没闲着，测试代码与开发代码几乎是同时在写的。往往代码刚“出炉”就测上了，而且只有在测试结束并确认没有 Bug 的时候，开发的工作才算结束 这些措施打破了角色之间相互切分和推诿的局面，共同的目标让我们变成了一个价值共同体。毕竟，只有协作，才能达成目标 痛点三：需求理解不一致 （面对面澄清及估算）至此，团队的力量得到了很好的凝聚。在复盘会上，大家畅所欲言，共同讨论了下一个待改进项，那就是是需求理解。这应该是技术类项目的一个共性问题 如果团队没有专职的策划，开发人员在理解需求时，经常会感到非常困难。可以打开敏捷宝箱，找到了一条重要的价值观“个体与交互 > 过程与工具”。相比于更多、更长的需求文档，我们决定采用更多的面对面交流来解决这个问题！ 迭代计划分成了两个部分：
团队估算的过程，其实是个双向互动的环节，可以帮助团队和产品负责人共同加深对条目的理解。同时，产品负责人也会根据大家的反馈，及时修改条目，完善条目 具体估算时，为了避免干扰估算结果，当所有成员选择好代表自己估算值的纸牌后，大家同时亮牌。同时亮牌的好处是，不会有人跟风出牌，每个人的估算都是经过独立思考得出的，这也是扑克估算的精华所在 如果估算值差距明显，代表大家对该条目的工作量没有获得共识，团队需要对该条目的评估结果进行讨论，由最大值和最小值的牌主，分别说明自己的估算理由，并重新讨论，确定最终的评估结果 面对面的需求沟通及评估，至少带来了以下三方面的好处： 1. 需求探索更深入 在计划会上，团队会直面一线用户，需求可以得到面对面的交流和澄清。另外，团队估算其实也是一个团队共同探索需求的过程。因为只有到真正考虑要花多少成本去做的时候，才会有各种各样的问题暴露出来。这个方法对于在早期进一步挖掘需求细节，特别有帮助 2. 估算结果更加全面、细致 在传统的项目管理中，也做估算。比如，WBS 分配好了任务，然后每个人估算自己的。因为每个人都只对自己的那部分任务比较熟悉，估算时往往会有欠考虑，而团队估算，就很好地补足了这一点 每一个故事都会由全员出牌，各方从自己的角度出发想问题，可以互相补充。比如，在估算时，测试的成本也会被考虑进去。对于测试成本高的功能点，开发会主动想办法加强单元测试等白盒测试手段，这样一来，估算结果自然更细致、全面 3. 找到了更优的整体解决方案 由于各方共同参与估算，前端、中间层、后端、测试的思路可以在一起交流碰撞，这样就非常利于找到最优的解决方案 团队的这一系列敏捷尝试，始终都是围绕着项目中切实的痛点展开的。从最开始缩短发布周期、经常交付可工作的软件，到应对“接力综合征”，提升团队的整体目标感和协作效率，再到探索更加有效的需求理解及团队估算方式，在增进团队交流的同时，又保障了需求质量 敏捷实践的应用，带来了诸多好处： 1. 提升客户体验
2. 提升管理者体验
3. 提升团队体验
对于敏捷方法，并不是拿来即用的。所采用的这些方法，大多是以敏捷思想为指导，以敏捷方法为基础，在实际场景中不断演化，一点点改进出来的。实际上，没有任何一种方法、工具可以放之四海而皆准，每个人都需要在自己的场景中思考 真正决定一个团队是否敏捷的，不在于是否应用了那些实践，而在于实践背后是否体现了敏捷精神。通过的长期实践和观察理解，从中提炼出了实战中三项最重要的敏捷精神，那就是：快速可靠交付，用户价值驱动，持续自发改进 希望你能坚持敏捷精神，而不是僵化地套用特定的做法。在团队中实践应用敏捷时，也应该遵循小而美的原则，每次一小步，挑一个痛点去集中解决，小步快跑，不断尝试和优化。只要你做到了以上三点敏捷精神，那么，你的团队就是一个敏捷的团队，你的组织就是一个敏捷的组织 |
|
|
来自： conscience6487 > 《待分类》
