敏捷开发模式

软件工程类的书本也阅读不少本了，大多是讲述一些软件工程基本的领域知识或者实践方法，唯独邹老师编写的构建之法颇具新意，对于在软件领域的工程师和有志于将来从事软件领域工作的大学生具有相当的意义，书中讨论的许多问题都来自于实战，复杂性和多变性，确实是软件工作者最难以掌控的。 因为时间也紧迫，来不及细细品味，不过在阅读的过程中也想到了一些问题，因为这些年做行业软件比较多，客户满意度和软件需求边界之间的边界让我颇费脑筋，毕竟要让客户满意，交付时间和费用都会上升的比较快，尤其是面对一些客户询问，我想要具备淘宝网上某个同样的功能...，有时候竟然不知该如何回复既能满足客户，也能显得比较专业。第二个问题是关于项目团队成员稳定的，在邹老师讲述的重要紧急象限中，核心程序员离职对项目的打击是比较大的，但是因为目前软件领域竞争激烈，确实存在核心程序员不稳定的情况，在控制成本的前提下，如何做好预案也是我的一个问题，因为采取敏捷开发模式，不太可能有非常详尽的文档来满足接任者的诉求。 路漫漫其修远兮，软件之路充满挑战和坎坷，值得吾辈孜孜以求。 来源： https://www.cnblogs.com/nihilism-zhy/p/11200629.html

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 看板方法起源于丰田精益，最核心的理念就是减少浪费。而精益生产分析技能在敏捷中的体现，就是“价值流程图”工具，可以帮助我们识别 7 大浪费，减少浪费就是在增加价值。7 大浪费如下，可用 WIDETOM 来便于记忆： W - 等待 waiting I - 库存 inventory D - 缺陷 defect E - 额外流程 extra processing T - 运输 transportation O - 过度生产 over-production M - 动态 motion 让我们带着减少浪费的想法，引出和思考敏捷其中的三个概念，看是如何与看板当中的概念相结合的。 概念一：WIP（work in progress）在制品限制 理想的WIP是，5名团队成员WIP为5，即每名团队成员同时只做一个任务。这样有助于： 创造专注高效的工作环境。WIP通过限制团队成员，让团队成员更专注的做当前的任务，避免工作时间碎片化，每一次被打断，都需要浪费时间来重新找回思路，往往结果就是一天都很忙，但是产出不尽如意，容易失误产生 bug。因为多任务的切换，会造成恐怖的 20% 到 40% 的工作浪费，这是跟随 WIP 的指数增长的曲线。 实践敏捷尽早反馈的原则。周一同时开展 3 个任务，周三同时完成，产品经理和测试的反馈时间周期

缘起 2017年3月，应移动事业群智能营销平台项目管理部负责人邀请，我开始支持智能营销平台CRM团队。智能营销平台是阿里文娱广告团队，是阿里巴巴淘外变现的主力军。CRM团队负责开发和维护CRM系统。CRM系统服务于销售和代理商，串起商机管理、客户开发、合同管理、风控审核、账户管理、财务结算等业务链条。CRM系统的质量和交付速度，直接影响销售和代理商服务广告主的效率和体验。 3月初我访谈了销售、产品、开发、测试等团队核心成员，并观察了团队的周会、站会和需求讨论会。当时团队的目标是在3月25日交付框架合同功能，主要工作围绕框架合同功能开展。根据访谈内容梳理出框架合同项目研发过程的时间线如下： 从图中可以看出，这个项目基本按照瀑布模式推进，开发2个月后整体提测，测试1个月后一次性发布。开发2个多月后，业务方才有机会试用产品并给出反馈。 这个项目暴露了瀑布模式的弊端： 1.接力棒的协作模式带来信息差 瀑布模式下，业务、产品、研发三方很少共同参与讨论。需求如同接力棒从业务方传递给产品经理，再从产品经理传递给研发团队。信息每经过一次传递都有损失，业务方、研发团队得到的大部分是二手信息；产品经理成为团队沟通的瓶颈，业务方和研发团队直接讨论可以解决的问题，要经过两轮甚至多轮沟通才能达成共识；业务方和研发团队缺乏相互理解，研发团队不了解需求背后真正的业务诉求，业务方不了解技术方案背后的权衡。 2

传统的瀑布工作模式使用详细的需求说明书来表达需求，需求人员负责做需求调研，根据调研情况编制详细的需求说明书，进行需求评审，评审之后签字确认交给研发团队设计开发。在这样的环境下，需求文档是信息传递的主体，也是一份契约。 然而详细的需求说明书有以下5大弊端： 单向的信息传递，容易出现理解偏差。 文档很正式，我们会误以为它一定是对的，不去质疑它，让我们停止作出判断。 有了详细的文档，我们不会反复讨论它，相互确认。 书面文档不利于团队共享责任，它扮演了证据的角色。Scrum强调团队共享责任，不论是需求人员、开发人员和还是测试员，大家的共同目标是通过讨论、协作，正确理解需求之后把这些需求变成客户真正需要的功能，而不是单向的任务传递。 编制详细的、表达准确需求文档需要花费大量的时间，如果需求变化频繁，维护成本更高。 敏捷使用产品Backlog来管理需求，产品Backlog是一个需求的清单，按照需求的商业价值排序， 高优先级的需求在Backlog的最上层。产品Backlog是一个渐进明细的清单，它有4个主要特点，称之为DEEP： Detailed 合适的详细程度，高优先级需求更加明细，低优先级的需求粒度更大 Emergent 涌现式的，需求是慢慢涌现出来的，渐进明细的 Estimated 经过估算的 Prioritized/ Ordered 根据商业价值排好顺序的 在产品Backlog中