type
status
date
slug
summary
tags
category
icon
password
前面写了两篇关于敏捷开发的文章，
敏捷开发｜遇到的一些流程问题和技术质量问题 和敏捷流程中，如何应对需求变更 ，主要是从执行层面和技术质量层面来写的。
在长期的敏捷流程之下，还会存出一些团队层面的挑战。
RoadMap和长期视角的缺失
敏捷开发强调的是“及早和持续性交付”，意味着产品需求会被切分成很多短期可交付的迭代版本。从用户价值出发，更快的交付给用户更多的价值，这本身没什么错误。
但是研发的任务被且分成一个又一个的scrum，会陷入到迭代的细节中，更多的关注在 我这个scrum需要完成的故事点数和下个scrum可能的安排，从而渐渐失去了对产品RoadMap的关注和长期视角的感知。当一个研发团队只关注在这周有哪些用户故事要排、下周有哪些用户故事要排，而不再关注产品的长期Roadmap，是非常可怕的。
技术得不到长期规划，研发也不会再问“为什么”。
团队士气低落，每天的工作是为了user-story，而不是为了“理想”。
“Roadmap缺失”不是敏捷开发导致的，而是团队leader的规划意识导致的，但是敏捷开发会让这个问题“内心合法化”，从而更缺少解决这个问题的动力。
也没什么好的解法。
- 作为研发团队负责人，至少要有两个Roadmap，包括产品roadmap 和 技术roadmap，然后及时把roadmap宣贯下去，更及时的信息同步，跟团队讲更多的why；
- 目标制定上，除了周scrum，还要有长期目标。比如 我们的长期目标就是“做行业领先的教育知识图谱”，所有的技术演进和规划 都回到这句话上来。每个季度会有一个技术目标，目标讨论的过程 就是roadmap建立的过程，也是技术理想的建立过程。
低头赶路，抬头看天。
工作计划的不确定性
敏捷研发鼓励对变化的快速响应，“及早和持续性交付”，就意味着鼓励拥抱变化，可能导致需求的频繁变动，给团队成员带来不确定性，影响长期规划和个人职业发展规划。
这个解法比较简单，三方面来看，在变化中寻求相对的确定性：
- 还是先要有roadmap，有了roadmap才能有相对明确的长期规划。当然，roadmap也是会变化的，但是他的变化频率可能是季度，甚至是年，如果频繁变化，就应该去回想一下roadmap的制定过程是不是科学的；
- 就单个需求来说，分1稿、5稿、9稿，需求风险前置，在敏捷流程中，如何应对需求变更 里讲过；
- 就单个scrum来讲，如果使用scrum流程，需要预留buffer时间来应对变更，如果使用Kanban流程，支持变更 但是 评估变更的成本和收益。
对新成员不甚友好
新加入的团队成员可能难以迅速适应敏捷开发的节奏和文化，尤其是在没有充分培训和指导的情况下。
如果一个新的研发同学加入到一个scrum团队，他对原来的业务不熟悉，对已有的代码不熟悉，对团队的研发规范、研发流程不熟悉，无法估算出正确的故事点数，甚至可能对于团队正在使用的scrum流程都不太了解，一方面是很不友好，一方面是对新同学的融合和适应也是很大挑战。
对于一个新人，想要完全了解一个团队，大概时间需要3个月，真正能发挥自己全部的能量，也需要差不多4-6个月。团队变动的成本就是这么大，也是这么神奇
在scrum团队中，对于新人，一定要有一个mentor，跟着mentor一起做需求，或者是 给一些零碎的、不需要硬排scrum的需求。新人降临的核心目标是 熟悉业务、熟悉代码、融入团队，而不是快速的产出，更不是按照scrum标准交付。
跨部门协调挑战
产品研发并不是孤立的过程，有些theme比较大，会涉及到多个研发团队的横向协作，每个团队都有自己的scrum周期，如果团队陷入scrum的“敏捷陷进”，应对变更的策略单一，就可能难以应对多变的挑战。甚至，如果研发交付上，影响到的干系人包括了运营、市场、增长、分析等等多个团队，沟通和协调上的挑战很明显。
敏捷是一种思想，scrum是敏捷的落地框架之一，“及早和持续的交付用户价值”才是敏捷的精髓。研发团队如果将自己固化在“scrum延期率、燃尽图、故事点数”等框架指标上，就会陷入“敏捷陷阱”，从而给跨部门协作带来巨大挑战。
无论我们采用什么研发流程，核心目标还是创造客户价值。当发现团队士气下降、协作方对我们评价平庸时，做为研发团队负责人 可以试试问自己：
- 下一阶段的Roadmap是什么，阶段和规划是怎样的，每个人都知道团队的roadmap、自己接下来要做的方向、面对的挑战吗？
- 如何激励团队不仅仅是完成backlog，而是坚持长期价值，守住敏捷理念？
- 如何将战略视角、Roadmap、敏捷、技术质量相结合？
目前想到这么些。这篇写完，敏捷系列就差不多了，刚开始写第一篇的时候，也没有做过三篇文章的内容规划，就想到哪儿写到哪儿了，读者多担待。