L7 敏捷产品开发
L7 敏捷产品开发
瀑布产品开发
下面两张图是软件开发领域的瀑布流程，供参考。
（带色彩的还是好看一些）
假设我们要搭建一个积木空间站模型。
- 需求收集：项目启动阶段专注于从利益相关方处收集需求。这一过程包括明确产品的需求与目标。
空间站要多大？包含哪些舱段？放几个宇航员进去？颜色有没有要求... - 系统设计：需求收集完成后，开始规划系统架构与设计。该阶段需要根据收集的需求创建详细的技术规范。
要给出整个设计对象的描述（比如详细的积木拼接图纸）。每个舱段使用哪些积木？如何搭建和连接结构... - 实施阶段：设计方案确定后，开发团队开始按照设计阶段制定的规范构建产品。此步骤包括编写代码、测试独立组件、并将其集成至系统中。
严格按照图纸来搭建空间站，不能跳步骤，也不能随意发挥。 - 测试阶段：实施阶段结束后，产品需经过严格测试以发现并修复缺陷或问题。测试内容包括单元测试、集成测试、系统测试、以及用户验收测试(UAT)。
对拼接好的空间站进行测试，比如拿起来晃一晃，会不会散架？如果要让宇宙飞船和空间站对接，接口能不能接上而且对准？
如果发现了问题，标记了一处地点，然后可能需要拆掉一部分进行修复。 - 部署阶段：当测试完成且产品被确认稳定后，即可部署至生产环境。此步骤涉及将产品开放给终端用户使用。
通过测试之后，就可以把模型展示出来给大伙看看。 - 维护阶段：产品部署后将进入维护期，在此期间会解决部署后发现的各种问题或故障。同时根据用户反馈或需求变更，可能实施更新与功能增强。
如果展示的时候，有奶龙捣乱导致零件掉了，需要进行修复；或者有人想加一个机械臂什么的，可以进行一个小升级。
在瀑布模型中，各阶段通常按顺序完成，阶段间几乎不存在重叠。
这意味着开发进程会像水流倾泻而下般稳定地逐阶段推进，因此得名“瀑布模型”。
-
优点：
- 结构清晰，每个阶段都有明确的目标和产出（联想到lecture 1的stage-gate），方便管理者追踪进度；
- 强调文档，每个阶段都要写详细的技术文档，适合需要严格记录和追溯的项目（比如歼击机的弹射座椅，要是设计不好，要弹射测试的时候飞行员出不来，设计人员提头来见）。
-
缺点：
- 非常缺乏灵活性，比如如果某个阶段客户的需求发生重大改变，或者有新的竞争对手出现，导致需要大幅调整功能，瀑布模型难以进行大改；
- 风险后置，因为直到测试甚至部署阶段，用户才能看到产品，如果对客户需求理解错误，或者设计有重大缺陷，那么后期修复成本很高。
比如说，我在坎巴拉里面，设计了一个地球低轨道空间站，而且所有舱段都打上去了。然后突然C教授表示“诶你这不对啊，我要的是月球高轨道空间站”。那我咋办？凉拌！ - 交付周期长，用户需要等到所有阶段完成，才能拿到最终产品，没办法拿到早期工程样机，测试功能并提供反馈；
- 沟通障碍，不同阶段是由不同团队负责的（参考上面软件开发的瀑布流程），这样在传递用户需求和其他信息的时候，可能发生信息失真或者遗漏。
敏捷原则在软件、硬件和产品开发中的运用
`敏捷'产品开发模式的起源
- 瀑布式开发模式批判：传统瀑布模型强调开发的线性阶段划分，因其僵化性与适应性不足而受到质疑。
- 迭代与增量式开发：迭代与增量式开发理念的兴起，为应对需求变更提供了灵活性与响应能力。"迭代开发"这一术语由巴里·伯姆在其著作《软件开发的螺旋模型与增强》中首次提出。伯姆的螺旋模型着重强调了迭代周期与反馈循环机制。
- 1990年代：诸如Scrum和极限编程（XP）等方法开始受到关注。Scrum由杰夫·萨瑟兰和肯·施瓦伯在90年代中期正式确立，而XP则由肯特·贝克、沃德·坎宁安等人在同一时期开发。
- 敏捷软件开发宣言（2001年）："敏捷"这一术语的确立源于2001年一群软件开发者共同制定的《敏捷软件开发宣言》。该宣言阐述了敏捷开发的核心原则，强调协作、灵活性和客户满意度。
• 虽然这些事件是敏捷方法论发展历程中的重要里程碑，但必须认识到敏捷原则是通过各种影响和实验逐步演变的，其起源远早于且不限于软件开发实践（参见臭鼬工厂等案例，强调快速、灵活、小团队、减少官僚主义）。
• 敏捷在软件开发领域得以迅速普及，归因于其快速且低成本的开发、原型设计与测试能力（无需物理原型或测试、标准化工具与框架、极高的测试执行速度）。
敏捷产品（软件）开发宣言
我们通过实践和帮助他人实践，正在发现开发软件的更好方法。在这个过程中，我们逐渐认识到以下价值：
- 个体与互动重于流程与工具
人的创造力、沟通和解决问题的能力是成功的关键。优秀的团队用普通的工具也能成功，但是如果给你先进的项目管理流程和工具，但是团队里全是奶龙呢？ - 可工作的产品（软件）重于详尽的文档
改软件比改硬件还是快多了，你不需要等加工，代码改完，跑个自动化测试完事。
而且在软件开发领域，文档要有，但是它还是服务于产品的开发和维护的，而不是目的。 - 客户协作重于合同谈判
把客户当成合作伙伴，进行持续的沟通、反馈。 - 响应变化重于遵循计划
市场需求、技术进步、用户反馈，都要求软件开发中，对开发计划进行灵活的调整。
也就是说，虽然右侧条目有其价值，但我们更重视左侧条目。
价值观驱动开发
所有现代组织都是价值观驱动的。价值观反映文化。这些价值观源自（并反过来影响）产品开发实践。
- 如果“安全第一”是波音的核心价值观，那么在开发实践中，他们就不会为了快速推出产品，牺牲必要的安全测试、飞行员培训、设计修改等环节。
文化及其价值观必须凌驾于规则和流程之上。理想情况下，强大且功能健全的文化应体现为最简规则集。
- 一个拥有良好正向文化的团队（比如信任、开放、勇于承担），其成员会自觉做正确的事，这样就不需要太多死板的规则约束。
每制定一条新规则，务必至少废除一条旧规。
- 警惕流程僵化和官僚制度！
典型价值观：简洁性、明确性（意图与功能的）、尊重——警惕价值观泛滥！
- 公司里面那种口号写多了，其实也就没有意义了。应该让价值观真正融入日常工作。
敏捷原理
解读：
- 价值驱动：客户满意、欢迎变更、频繁交付，前三条原则表明，希望尽快、持续地为客户带来看得见摸得着的价值，交付的不是一堆技术文档，而是可以用的软件。
- 协作沟通：业务开发合作、信任个体、面对面沟通，强调了人和互动的重要性，希望打破部门墙，建立信任和高效的沟通渠道。
- 务实度量：可工作软件是度量进度的标准。
- 可持续性和卓越发展：可持续开发、关注技术，提出既要保持稳定的节奏，避免团队”燃尽了“，也要持续提升技术水平，确保产品的健壮性和可维护性。目标是提升长期的敏捷性，或适应变化的能力。
- 精简和自组织：简洁、自组织、反思改进，推崇简单就是美（避免过度学习、其他不必要工作）；信任一线团队最了解工作细节，给予他们自主决策权；通过定期反思，实现持续学习和优化。
敏捷开发
这里的sprint可以理解为“冲刺”，也就是一个敏捷迭代周期。
increment可以理解为“增量”。
sprint retrospective意思是“冲刺回顾”。
当然这个图对于朋友们可能不是很好理解，因此我找了几个中文的图，请结合文字进行理解。
说明一下敏捷开发中scrum框架的特点：
- 迭代：scrum的核心是冲刺/迭代（sprint），其时间长度是固定的，到期必须结束并交付成果。
- 增量：交付什么成果呢？是一个可工作的、潜在可交付的产品增量，也就是说是一个用户可以感知到甚至使用的，而且每一次增量，都向最终的成品前进一步。
（比如说我们手机上的app，隔不久就要升级一次，每次升级都是一个增量，比如更新了某个功能、解决了闪退问题等。） - 透明（transparency）：产品订单、迭代订单、每日站立会议、迭代复审和回顾会议等等，都是为了让工作的进度、遇到的障碍、产出的成果，对所有人可见。
- 检视（inspection）：不同于gogo里边的按F检视蝴蝶刀，敏捷开发鼓励团队频繁地审视工作和过程。
- 适应（adaptation）：基于检视的结果进行调整，比如每日站立会议调整日计划，复审会议调整本周期内工作，回顾会议结果用于改进下一个冲刺周期流程等。
- 角色分工：产品负责人(product manager, PO）关注“做什么”（增量要实现的价值）；开发者（Developer）关注“怎么做”；项目经理（scrum master，简写好像不是很能过审...）关注“流程顺畅”（引导开发团队、帮助沟通和移除障碍）。
混合方法 - 真正的敏捷
• 每个团队都各不相同（可参考贝尔宾团队角色理论），且运作环境各异（资源条件、动机因素、客户关系、技术可供性、产品类型等）。
• 根据敏捷范式，每个团队都必须基于自身特定情况来塑造运作方式。虽然已知方法论中的许多要素和运作方式都具备适用性，但最佳解决方案（需考虑帕累托最优性，而不必追求某种全局最优）通常会是这些方法的混合体，而非严格遵循单一范式。
• 若条件允许，最理想的方式是通过团队实践经验"探索"出工作模式（形成自主权），而非被动接受强加的方式。
- 首先，是不是所有的开发需求都是会发生变化的？
其实在航空航天领域，我们给定某个飞行器的任务需求和主要设计指标之后，一般都不会变了；而且对总体的预期时间有要求，所以用瀑布开发更容易把控进度，而且输入输出产物更明确。
这和互联网、软件开发领域的思维不一样，比如这些天几个电商平台搞外卖，这是一个新需求，需要开发团队在已有软件上，以最快的速度把外卖功能这个增量加上去，所以敏捷开发更适合这种情境。 - 瀑布一定很笨拙而且迟缓吗？
只要有足够的测试人员，瀑布开发完全可以每完成一个小模块，就对一个小模块进行测试，这就像两种方法的混合。 - 敏捷和团队的关系？
一个是，整个团队要统一思想，特别是领导自己要搞清楚，什么情况用敏捷比较好，什么时候没必要；团队成员要搞清楚，自己的职责有什么变化，为什么，有什么好处。
二个是，如果团队人比较少、稳定、容易达成共识，用敏捷开发会比较好，因为沟通很直接而且容易；
如果人很多，而且人员变动比较频繁，可能瀑布流的明确步骤和产出、要求技术文档这种会好一点。 - 切记，我们的初衷是交付更好的产品，所以不要被限制死在某一种开发模式，或者团队自行探索更适合的方式。
浙公网安备 33010602011771号