boot sprint 项目结构_敏捷项目管理（一）概述

在学习敏捷管理之前，印象中听到敏捷，直觉是经常上线，一两周做完从产品设计到上线，感觉特别理想化，没办法落地，一直想打破自己固有的观念，因此系统的学习了敏捷项目管理，想深入虎穴一探究竟。

所以第一个问题，真的是实现了一两周做完从设计到开发到上线就是敏捷了么？其实不是，敏捷是一整套围绕核心价值观的方法论。

首先我们先聊聊我们团队在过去这些时间里组织架构的演变。

在早期加上测试和研发只有不到二十个人的时候，整个研发加测试都归属于技术总监直接管理，做的比较成功的一点在于能够很好的落实每日站会，但有个特点是直接在工位上站着说，分享自己昨天做了什么，遇到什么障碍，今天准备做什么，团队中的每一个人都能知道其他人在做什么，遇到什么问题，团队中的透明度极高，建立和维持了团队之间的信任，以及每一个研发都是按照全栈的方式开发。

但也埋下了很大的伏笔。
1、首先没有很全面的测试体系，团队成员虽然都是全栈的开发，没有很强的代码逻辑约束力，研发潜意识中会把业务逻辑放到了前端，而没有放到后端，一些权限判断也是，直接导致后期大量的代码整理和逻辑迁移，形成了很多技术债务
2、第二，没有完善的持续集成的体系，这个时间客户数少，业务量也不大，基本上就是做完功能测试完就上线，线上产品十分脆弱，动不动就出线上bug。
伴随着业务的增长，人数的上升，首先出现问题的是每日站会，每个人讲几分钟，整个例会就会超过半个小时，而且每个人不一定都能记住别人都干了啥，有一定的疲劳感出现。技术总监需要直接管理二十个人，有些分身乏术，因此演变出三个业务小组及专门的测试组。
这样的组织结构持续了一年多，后面伴随着测试的完善，逐步改善刚才提到的测试体系问题，定期上线，bug分级，测试流程规范，带来的好处是线上产品相对稳定，bug数逐渐变少。
每日的站会也变成按业务分组，参加的是对应业务的产品研发测试，人数控制在十人以下。用专业术语讲，当前的结构叫混合型强矩阵型加项目型。

项目型结构带来的好处是
1、各组相对独立，遇到小问题能够自主解决
2、每个项目都有固定负责人，方便和其他部门互动
3、组内沟通频繁，共同任务能够互相协调，方便组内资源的平衡
伴随着业务量的指数级增长，系统逐渐不堪重负。之前因为分组的关系，前后端的代码没有能统一和复用。经常会遇到组组之间资源潮汐式的不平衡，有时候实在忍不了了需要借人。
所以这个时间点迎来了新的调整，将业务组打散，统一按照职能划分，能够较好解决知识和资源的流通，弱化了项目组，带来的好处是增加了职能组内部的沟通，让跨业务的资源流动更加顺畅
从客户价值来说，职能的统一有助于系统细节的统一，从产品设计到前后端的统一，甚至后期的跨业务线的统一都能够让客户从细节中体会到这些流畅感。
在产品迭代过程中还遇到了很多问题，最让技术困惑的是如何衡量有deadline的需求和客户反馈的问题，以及还有一个老生常谈的问题，答应客户在某个时间点能开发，但总是迟迟开始不了，以及到底现在开发团队的状态怎么样，加班是否真的有助于需求的早日上线？
在分享后面的内容之前，我先让大家思考一个哲学问题，为什么世界上还有那么多人饱受饥饿，人类还要花那么多钱探索太空，这个出处直接搜索能搜到，在这里，我是想让大家举一反三到刚才的第一个问题，需求和bug如何衡量。
我们先简单看一下过去传统的这些开发模式。
首先是瀑布式开发模式，简单的说就是一次性做完所有需求，前提是需求明确，开发体验非常爽，缺点是开发周期长，需求不会变动，无法适应多变的互联网模式以及及时满足客户需求，但对一些传统行业，比如金融产品的研发。
然后是非常常见的增量开发模式，一般常见于互联网C端产品，产品提出需求或者从用户反馈中找到共同需求，然后制定一些功能的需求，开发完成就上线，一般没有特定时间限制。
相比传统瀑布式开发，开发周期短，开发体验好，现在很多互联网公司都是采用这样的开发模式，但经常遇到对开发速度没概念的管理层，大概指定一个上线时间，导致产研经常性加班，甚至到后面变成习惯性加班。
接下来是敏捷开发模式，简单的说就是制定一个固定周期，通常是一周或者两周，也有三周或者四周，在这个周期内完成产品需求的设计到开发和上线，同时得知开发速率，及时复盘，保证开发速度的稳定，在团队内部形成一个高度透明、高度信任的氛围，让成员有足够的成就感。
当然实际情况不会是这么完美，通常会结合现有的组织架构，会有几种开发模式并存。
接下来讲讲为什么敏捷开发模式非常适合企业Saas服务的团队。
toB的业务，本质是服务，只有服务好客户，客户的续费和新客户的签约都有了保障，当然这个服务不是单单得指客户服务部门，还有产品本身所提供的服务能力。
而且Saas本身不会给客户提供定制化服务，而是做出产品化。如何界定定制化，通常是客户按照他们公司的工作流程提出需求，团队自身不会做一些判断，直接堆功能上去。产品设计和开发在局部是最优的，短期内对团队来说是轻松的，但通常这样的开发惯性下去之后，业务增长需要靠堆人，开发效率极低，技术债务极高，业务无法指数级增长，最后一点点陷入死循环，没有足够的增长和利润，也无法招聘到足够优秀的人。
产品化是需要在设计和开发时需要考虑足够长远的规划，能够在比较少的人数下完成支撑指数级增长的系统。这个时候就需要在精益开发思想框架下的敏捷管理，精益是衍生自丰田生产方式的一种管理哲学，一句话概括就是just in time，只在需要的时候，按需要的量，生产所需要的产品。
往往我们的本能会觉得加人力加工时能够让产品尽可能早上线，但真的是这样的么？996换个角度讲就是让9个女人在一个月内生出孩子，而且长期996之后团队的整体效率是直线下降的，举个例子讲就是如何跑马拉松并且跑出一个比较好的成绩，不是一上来就慢满度跑，这样跑不了几公里就没体力了，后面就只能走，而是全程保持一定的速度区间，维持在一个六七成速度的状态，偶尔加速，偶尔降速，整体成绩还特别好。
因此我们如果可以保持一定的开发节奏，既能让团队内部充满信心和信任，也及时满足客户期望。
我们在现在的开发模式下遇到的问题：
1、任务的deadline和bug时间冲突了怎么处理，都很重要，怎么优雅处理这个问题？
2、怎么判断团队的开发速度和开发状态（交付周期）来得知问题
3、客户无法准确得知需求何时上线，怎么更好让客户得知功能上线时间？
先说说价值观，刚才提到敏捷是围绕一个核心价值观的方法论，那都有哪些价值观：

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观： 个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。

不是我们流程完全按照敏捷设计了就是敏捷了，而是需要不断反思我们是否按照这个思想在实践了才是符合敏捷思想的核心。
换一个角度，其实和我们组织的价值观是一致的。
主人翁意识；追求卓越；
空杯心态；思变创新；
以客户为中心；真诚直接

通常项目管理，我们直观上会关注这三个点，时间范围成本，这仨共同决定了质量如何，但这个指标只能判断产品是否满足目标，但有没有给客户提供价值就无法体现出来了。

敏捷三角，所以我们在流程上应该首先关注的是否能够为客户创造价值。
介绍一下一个敏捷的scrum流程是怎么样的。
在敏捷团队中，通常是制订一到两周为一个sprint周期，在这个周期开始之前，先预估这次sprint团队能够开发多少story points，然后从backlog中按每个story的story point的值放到开发todo中，当然高优会优先考虑，以及上次sprint发现的没被发现的缺陷，当然现实情况，一些着急的bug不会跟着sprint上线一起，单独上线走了，在sprint结束之后，团队开始进行复盘，review在这个sprint中，有哪一些做的不错需要继续保持，哪些没做好，有什么改进的措施，下次sprint会看措施有没有实施，几个sprint之后的复盘会中还会让对应的负责人进行产品的演示及相关人员的验收。

上图就是完整的scrum流程实例。
回到问题1，上线时间一般都是固定在一个sprint周期内，不存在冲突的情况，当然特殊情况下有些bug肯定要第一时间解决。
而问题2，当sprint时间固定下来了，整个团队的开发速度就得以计算，一个sprint到底能做多少需求，这些需求都有固定规则的story points计算，当速度上升了或者下降了都得以及时发现和调整。
问题3，相比之前的开发模式，我们的客户往往只是知道需求大概是啥时间开发，但具体上线时间又不得已得知，sprint固定之后，在sprint开始前让客户知道之后，一般情况下都能够在这个sprint结束之后上线验收。再换个角度来说，虽然我们现在是一周一次上线，但对客户来说，可能需求是一两个月才上一次。
讲讲每日例会，例会本身的目的是及时监控项目进度，如果遇到障碍及时提出及时解决，以及及时预警，所以例会中每个人要回答3个问题：
1、昨天做了什么
2、遇到什么障碍
3、今天计划做什么

小组内部固定一个时间，可以是每天下班时或者每天上班之后，一个小组成员包括对应的产品设计测试和开发，大家围绕在物理看板前，依次对着自己的便利贴回答那三个问题。
可能想问，既然已经有了jira这一类的电子看板，为啥还要一个物理看板？在我们过去的经验中发现，如果只有电子看板，不够直观，电子看板目前也没有特别好的方式能够在每日例会的时候让大家能够参与进来，也不是所有的事都有jira卡片。
当然电子看板也有其他好处，对于一些无法现场参与例会的同学可以通过电子版查看，也不会有物理看板上的贴纸掉地上的情况，计算团队速率等图标可以直接生成，对应数据都得以记录。
所以通过结合两者，来互相弥补劣势，物理看板用于每日例会小组内部能够相互介绍和了解，电子看板用于记录和后续的一系列交付流程。

小组内现有的看板，这里有一些细节：
1、每个人都有各自微信头像的磁铁，能够直观看到当前都在做什么
2、不同人物类型有不同颜色的卡片
看板能带来什么？
1、有很大提升的是基本上让所有任务都会呈现在小组内部，有些任务没有jira，可能不会出现在这个jira内部，所以能够让原本隐藏的任务无所遁形。
2、让小组内每个人都了解当前小组都在做什么遇到什么问题，也能直观看到任务都在哪个阶段囤积了，及时作出反馈。
3、及时控制同时进行的任务数量，人的精力有限，同时做两三件事以上时会顾此失彼。
4、及时回顾发现之前暂停的任务。
5、及时监控需求和工程优化及bug的比例。
现在看板还有没做好的地方：
1、缺少产品进度
2、缺少进入下一个阶段的标准，尤其是从开发完成到待测阶段，列出标准能够提醒写完代码还需要做的事
3、完善的user story描述
4、遗漏了jira卡片id
5、没有预估的完成时间
6、一些杂项，比如导数据，调查数据，没有特别的颜色卡片
说到user story，其实我们现在写的user story缺少一个固定的格式，虽然有详细的写在wiki里的需求描述，但通常描述和细节过多而无法深入人心，在标准中，通常是
作为【角色】，我想要【功能】，已得到【价值】
User story及对应的story points会在之后再详细展开分享。
分享一个最近几个需求的看到的流程上的问题，这一类的高优且固定上线时间的需求，占用了几乎80%的人力需求，加上人员请假，虽然需求都为这个需求绕道了，但还是导致了需要确认的缺陷和高优的缺陷无法及时反馈，导致团队敏捷度急速下降，客户的感受也是下降了很多，虽然及时上线了，但也付出了很多的隐形的代价。
通常是完成一个sprint之后，很重要的一个会是回顾会议，回顾会议主要流程是
1、收集团队成员在过去这个sprint中的一些事，不管好事还是看到的问题
2、表扬好的事，调出一两件没做好团队认为需要改进的问题
3、分析问题，知道找根本问题，确定下一步行动，以便下一次回顾会议审查
4、回顾回顾会议，是否有可以改进的地方
当然敏捷还有很多细节可以讲，第一次分享就先分享这些，回顾一下和敏捷相关的知识点
1、敏捷核心价值观
2、完整的scrum流程
3、每日例会和看板
4、回顾例会
最后总结：
引用一句名言：

Think BIg， Start Small， Learn Fast

希望团队内每个人都能够参与到团队内部流程的优化中，最终的目的是
1、建立持续改进的内部力量
2、系统思考整个开发过程
3、为创新建立安全的试错环境
参考：
《敏捷实践指南》
《看板实战》https://insights.thoughtworks.cn/forget-agile-at-scale/