sprint

　 　转载自 LANCEYAN.COM 　　说起敏捷开发，并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了，这个东西并不是神器，实施了就可以解决所有软件公司的问题，而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 　　大家都知道，创业公司刚开始需要研发出一款产品并且能够使公司赚钱的产品，不过大部分创业公司没有那么容易一下就能做出来，很多公司还没有成功的产品资金链就断掉了，公司也死掉了。我们公司是这样一个状况，有一条产品线可以维持公司开支并仅仅刚够盈余，要扩大高速发展还不够，一直维持就没有创业的意义。另一条线是做技术创新为未来能够开发一款人气爆棚的产品摸索着，但是又不能饿着肚子去开发。我们是如何结合自身的特点实施敏捷开发的呢？一个难题，很大的难题！ 　　我们技术团队人员是这样的配置：1名技术总监、2名资深开发工程师、1名高级开发工程师、2名潜力开发工程师、1名前端开发、1名测试。技术总监需要处理很多团队管理、客户管理的工作，能够参与项目的时间最多每天二分之一。2名资深开发需要负责给其他工程师做导师，参与新项目开发时间大概有80%。高级工程师要预留项目学习时间，参与项目的时间大概有90%。潜力开发工程师需要有一些时间学习技术和项目，但是基本可以做到70%的时间投入项目。前端开发和测试哪里有需要就在哪里革命，属于机动部队。 　　现在总共有六个老项目在维护

在软件开发中花了很多时间等待事情发生。这种形式的浪费很容易在大多数开发团队中被发现。新的Scrum团队发现自己在一个Sprint中等待很多事情，包括： 允许做某事 完成需要一个漫长的过程 从一个团队或个人中脱离 运行测试或者完成验证 访问所需要的资源 与团队之外的人员合作 比等待Scrum团队的效率低下更加糟糕的是客户和企业需要花费时间等待软件集成、打包和交付。这个问题随着开发组织的规模增长而增加。随着更多的开发人员或团队加入到一个项目中，他们的工作集成到单个产品的成本也随之而增加。 Scrum中最长的等待是Sprint迭代时间。作为所有Scrum活动的容器，对Sprint持续时间的唯一要求是一个月或更少。这就限制了等待软件的工作增量为不超过一个月的时间。大多数Scrum团队更频繁地交付可工作的软件增量。 一个公司有六个Scrum团队正在开发一个庞大而复杂的软件产品。每个Scrum团队专注于特定的功能，并通过主Product Backlog在协同工作。每个Sprint迭代周期是是三周，包括整合所有开发团队的工作。 在此之前，每一个Sprint迭代周期是两周，但是随着产品的功能不断增加，开发的复杂性越来越高了。随着新的Scrum团队的加入，他们需要更多的时间来工作，所以根据集成活动的需要Sprint迭代周期增加了。 三周现在被称作整合周。将新功能集成到主程序中是在此期间的主要活动

在看板方法中第一步需要将一个团队的实际工作流程可视化。这是实现精益的“看到全貌”原则和需要看到实际的工作流程，而不是用文档来描述一个理想的版本或者使用其他什么模型来描述工作过程。一个有用的可视化模型表达了什么将会实际发生。 一旦可视化的工作存在，工作过程就可以用它来追踪。一个典型的入口（stage-gated），或瀑布模型，开发过程可以被在过程中使用如下几个特征所展示。 Scrum团队已经使用多年的可视化工作流程来展示Sprint的工作。在Scrum开发团队中最常见的可视化工作流程形式是Scrum的“任务板”或简单的“Scrum Board”。这种可视化模型使用起来比上述的模型简单，并且看上去也符合下面的模型。 这种典型的工作流可视化的形式受到Scrum跨功能开发团队规则的强烈影响。关注跨职能开发团队是Scrum框架的一个定义特性。跨职能团队拥有在每一个Sprint迭代中交付完整的可工作的软件增量所需要的所有开发能力。团队成员同时进行多项软件开发活动。 跨职能团队可以一起做一些事情，因为他们一起实现一个功能。这是与计划驱动的模型有很大的差别的，其中专家专注于在一次做所有的活动。此外，跨职能团队的成员可能有专业特点，但所有团队成员为交付所需要的软件而在一起执行常规的工作活动，无论这些活动是否属于个人的专业领域。跨职能的软件开发团队倾向于表现突出的专家团队。

1: 选择其它人的一个 task，点击clone 2: 改变summary 3：more>create sub-task. 来源：博客园 作者： 1367356 链接：https://www.cnblogs.com/liyafei/p/11491488.html

敏捷，简单的释义，即灵敏、快捷。 「合理的任务规划」 能让团队的工作即饱和而又能够有良好的应变能力（灵敏），团队需要时刻保持着良好的应变能力，因为我所了解的开发团队一直都面对着一个不确定因素——需求变化快。 「专注」 能够有效提升效率（快捷），当人在多件事情之间来回切换的时候，效率就会显得低下而且心情还很容易变得糟糕。 接下来将带给你如何使用敏捷的工具之一 Scrum 帮助你完成「合理的任务规划」和如何「专注」 。 一张图看懂 Scrum Scrum 工具包括：3个角色、3个工件、5个活动和5个价值观。 3个角色 01 Product Owner： 职责： 🔘清楚知道产品的愿景，分为近期和远期。 清楚愿景才不至于被干扰带偏道路，才可以清楚的区分重要紧急、重要不紧急、不重要紧急、不重要不紧急事件。我们可以集中精力于重要不紧急事件，这样就能减少重要紧急事件的发生。 🔘获取外界的诉求并进行整理成 User Story。 外界：用户、运营部门、其他业务方 User Story：需要实现的功能，以客户的角度，描述「我需要功能A，来达到我的什么目的」。 🔘对整理好的 User Story 所需要的资源进行各方协调并得出「是否可行、什么时候可行」的结论。 一个功能的实现，有时候牵涉各个业务系统，往往各个业务系统所对应的Team排期是不一样的，就需要提前进行沟通

　　软件开发嘛，总是免不了要去修各种各样的bug。一个好的软件不是单单依靠码农就可以搞出来的，设计，测试等小伙伴们的工作也必不可少。比如之前的工作中只是在乎分配给自己的bug，修好了就不管了，也没怎么考虑过为什么要这样一个流程。今天正好在公司加会儿班，想着把这些总结一下。由于有的项目已经过去很久了，只能靠我的回忆，所以可能有不规范或者错误的地方。或者各位看官有更好的方案还望不吝赐教。 　　 开发流程 　　目前我经手过的项目基本是这样一个流程。老大们和客户谈好，根据客户实际的需求，帮助他们设计出一套完整应用的构想。这个时候设计团队的小伙伴们会参与进来，把这些构想做出正式的Design，一般是以PPT的形式，展示整个应用的UI设计，配合一定的文字描述来介绍具体的功能。设计小伙伴们做好之后，会和开发团队的领导进行确认，据狗子观察，这里主要是和前端团队进行确认有一些设计是否好实现，是否需要进行更改。这个时候开发团队也会对这个软件的工作量进行估算，大概需要多少人天来完成。然后根据公司的假期安排，确定一个具体的交付日期。大致是把项目的功能具体分解，比如这里要插入一条数据，这个是一个单独的功能点。把这样大大小小的功能点分隔出来，分配给具体的开发。然后每人再跟进自己的Task来估算一下需要多少时间做完。这里想到我刚进公司时总是担心自己做不好，给人家留下不好的印象，所以总是尽可能少的估计时间

产品经理对于如何做版本迭代规划，有时总会产生无力感，要么是计划难以确定下来，要么是制定好的计划无法执行下去，这个问题的原因很复杂。在项目初期，我们缺少对产品的全局概念和整体把握，内部意见很难统一；再者，没有一个完整的用户体验或者价值流导向，对于每个迭代无法合理定制出可交付产品增量。 之前我们讲过如何构建 产品路线图 ，路线图可以给PO和团队整体方向的指导，但更具体的内容，需要用户故事地图的方式，通过横向的框架和纵向的任务，将一个产品完整的展示出来。然后，再通过故事点估算和优先级的排序，来确定版本迭代计划。 版本迭代其实是一个路线图，展示了将要实施哪些功能以及何时完成这些功能的期望。通常遵照团队自己的节奏，有的是一个Sprint 一个Release，有的将多个Sprint归为一个Release中，如下图所示。还有的在每个功能完成后立即发布，这也通常被称为持续部署或持续交付。 ​ ​ 根据产品开发的策略，它可以由功能驱动，目标是一旦开发出预期的功能模块就发布; 或者由日期驱动，过了预定的检查点就发布。 具体如何做呢？我们可以分这个步骤来完成。 1. 创建用户故事地图 和客户一起，厘清产品的用户角色，并尽可能多地写出用户的行为，以及每个用户行为下需要做的事情，然后按照用户行为从左到右讲故事。当大家把自己所能想到的故事地图都放上去之后，再合并增减故事，最后会形成一个二维故事地图。 ​ ​

作者简介 俞鋆，携程机票前台敏捷教练。 每日站会，日常敏捷中的最重要的团队活动，作为一名敏捷教练，2年多时间共服务过8个团队，大概主持了接近1000场的每日站会。站会各种的状况基本上都有遇到一些，基本的解决方法总结下来就是：让会议变得有用有效。 作为敏捷教练，虽然不太可能让开站会变成像刷牙洗脸那样的习惯，但是让团队感到：一天不开站会像少了什么一样的不习惯还是能得到些许的满足。以下是我总结的一些站会实践经验分享给新手SM或者转型初期的团队，希望对大家有用。 什么是站会 “每日Scrum站会是以15分钟为限的事件，开发团队成员在这里分享各自的工作情况，并为接下来的24小时制定计划。这需要检视上个每日站会以来的工作和预测下个每日工作之前所能完成的工作。每日站会在同一时间同一地点进行来降低复杂度。会议上，每个开发成员都需要说明： 昨天我为开发团队达成Sprint目标做了什么 今天我准备如何帮助团队达成Sprint目标 有什么事情阻碍了我帮助团队达成Sprint目标 以上文字引自《Scrum 指南》中文版的官方说明。网上有很多对于站会目的的诠释，基本上可以总结为：进度跟踪，信息互享，风险控制，信息透明。 虽然会议目的明确，内容简单， 但是我们总能听到一些质疑声，怀疑会议存在的意义。 如何让大家接受每日站会 最常见的不想开站会的理由： 1、管好自己就行，别人的任务和我无关，不想关心 2

全球各行各业逐渐意识到，要想真正地实现盈利与企业发展，关键在于变革和创新能力。因此，创新速度越快，投产速度也随之加快，从而更快地从竞争中脱颖而出。 Symbio 的 Design Sprint 方法是根据 Google Design Sprint 最佳实践开发的，它使我们能够与客户、开发人员和关键专业人员协作，在短时间内构建和测试概念。通过快捷的设计和创新，我们的客户能同时节省时间和资本。通过让开发人员加入概念创作工作，我们可以为实际的产品或服务开发创建具体原型和实时估算。 快速开发 = 更好的决策 快速的概念开发需要密切的关注和敏锐的意识，始终关注核心目标。客户可通过遵循 Symbio 的 Design Sprint，清楚地了解创新型解决方案的内容和制定方法。 设计前工作： 1.明确业务目标，包括用户需求和技术功能 2.选择一项挑战 3.组成团队并执行工作，解决挑战 4.在设计周期结束期间设定截止期限和进行用户测试的计划 如果冲刺是上一个周期的延续，应审查原型/经验教训并根据需要进行调整！ 5 天冲刺： • 第 1 天 – 冲刺团队下载与挑战相关的所有已知资源 • 第 2 天 - 团队成员草拟多种风格的概念（大胆冒险！） 团队酌情选择第一个概念，但务必在落实前进行批 判性思考 • 第 3 天 - 评审所有选择，选出 1-3 个概念来制作原型。 在决策中纳入项目标准、依赖约束等