技术服务
敏捷
一种在不确定和混乱的环境中为了达到成功而具有的一种创造和适应变化的能力。
敏捷软件开发
敏捷开发是一组基于敏捷宣言中表达的价值和原则的一系列方法和实践。
它是利用在自身的背景下的实践经验,通过自组织、跨团队之间的沟通合作来不断优化的解决方案。
敏捷Scrum&kanban
敏捷是一种工作过程改进的思想,根据对不同项目的特性和场景,从实践中抽象出来的具有可借鉴性的工作方式。
敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行工作。在敏捷开发中,软件项目或者产品在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,也可以理解为把一个大项目分为多个相互联系但又可独立运行的小项目,并分别完成并尽早验证成果,在此过程中软件一直处于可使用状态。

大家所熟知的敏捷开发的工具箱,包括最近流程的Scrum,kanban,以及具较多实践的XP,TDD,CI等。

1.以客户的价值为最主要的工作任务
2.拥抱变更:对客户的需求以及计划的变更持有乐观的接纳态度,以适应客户的最大利益及市场变化。
3.增量交付:产品是在每个迭代周期结束时被逐步交付使用(交付的意思是,可以部署并被实际的用户使用)。
4.开发团队和用户反馈推动产品开发。敏捷开发方法主张全员参与整个开发过程,包括利益相关方(如客户、用户),并从他们实际的利益出发得到直接的反馈意见,也鼓励开发团队提出建设性意见。
5.持续集成。尽可能频繁的进行产品集成,以较早来发现产品中的问题并提前修正。
6.开发团队自我管理。人是敏捷开发的核心,要发展团队的能动性和主动性,建立人为主动参与产品开发的全过程的机制,而不是被迫的听命令。

敏捷适合的场景,是那些些需求不明确,需求多变并快速需要验证的一些产品项目。
瀑布模式适合那些有明确需求、利益范围明确的项目。
两者也并无矛盾,在传统的项目中,也可以实施敏捷。

总的思想是,持续性的交付可用的产品,并快速的响应客户的需求变化,同时让客户积极的参与进来,形成利益共同体,并在这个过程中不断总结、改进以此来提高自身和团队的能力水量。
以上是实施过程中的原则,是最佳的实践,可以在过程中来进行对照。

它将开发的过程分成软件计划、需求分析、软件设计、程序编码、软件测试和集成测试上线阶段,并依据上一阶段的交付物展开一下阶段的工作。
为种模式适用于中大型、合同制、需求明确的软件开发过程。但如果需求调研不清楚、或者需求变更过度,会在后续的阶段造成极大的重复工作,从而产生成本上升或者项目失败。

它是以定制一定段时间的计划为目标,在特定的周期内完成一个小目标的方式。
迭代模式中会有三个角色:产品经理,Scrum Master,和Team。
一个迭代通会有四种会议:计划会议、每日站会、评审会、总结会。
首先产品经理和Scrum Master会在迭代启动之前召开计划会议,会议由项目经理来根据他所负责的产品backlog中选择优先级最高的需求,并排到迭代backlog中,同时会向所有的人员讲解每一个需求的价值和业务逻辑,团队成员对这些需求提出疑问并由产品经理做出解答;团队成员根据迭代backlog中的内容并根据优先级认领任务并对之进行估时,并根据总体估时的总量来达到这个迭代的负载。当团队成员对所有的需求都了解清楚,并合理的安排了这个迭代的内容,迭代即可启动。
在迭代进行的过程中,通过Scrum Master组织每日站会,通过每个团队成员说明当前的工作进展和问题以此了解迭代过程中碰到的问题并进行协助协调处理。同时Scrum Master也需要关注迭代的燃尽图来了解迭代是否存在计划上的偏差。
当迭代的任务都完成,Master需要召集相关方,组织本次迭代任务的交付评审,以验证本次迭代的成果是否满足要求,并由相关方给出意见和结果,以决定本次迭代的工作是否完成。
迭代完成上线工作后,Master可以组织对本次迭代的一个总结会议,以此来总结本次迭代哪些做的好,哪些做的不好,讨论具体的action并从中选择几条认为最急迫、最重要的来进行下次改进,指定负责人跟进。

产品负责人:产品负责人需要一定的自主权而不是更多的干预,以让产品负责人更好的发挥自己的作用;1:为产品的ROI负责,2:拒绝迭代的结果,3:优先级进行调整。
Scrum Master:更多的关注团队能够效率的工作,并解决团队出现的一些困难和问题; 0:迭代计划的按时进行,2:资源利用率,3:保证各个角色能够良好的协作,4:团队的部人保证团队按计划进行而不受到干扰,5:有效组织迭代的日常工作,6:与产品经理紧密的沟通用交流,允许参与backlog的优先级调整等。
Scrum团队:具有不同特长的团队成员,参与 Sprint计划和达成结果的演示;高度的自我管理能力(如履行承诺,保证质量);向PO演示迭代成果;对产品的具体成果进行说明。

product backlog:由产品经理来进行负责,确认客户的需求以及价值并对产品做整体规划以及近期的计划。对产品backlog根据价值和重要程度进行排序。产品的backlog并不一定来自于业务方,也有的可能会来自于团队内部。
sprint backlog:Scrum 团队在当前Sprint必须完成的任务清单。在做迭代计划的,需要整个团队一起参与,由产品经理讲解需求点,团队成员需要对这些需求的逻辑、如何实现、风险点都要有一个清晰的认知,并对它们做出预估的投入资源,确认每一个故事的完成标准并对迭代计划做出承诺。
燃尽图:是整个团队,特别是Scrum Master需要密切关注的,以此了解这个迭代以及在执行过程中的进度上的风险。Master需要根据这个关键性指标,具体深入的了解执行计划的时候出现问题,并提供帮助;一般的问题都可以从燃尽图中发现,通过燃尽图也可以做深入的分析此进行过程上的改进。

计划会议:明确这个迭代的内容和目标,全员参与,如果有条件,客户也可以参与进来。
每日站会:确认每个人的每日工作进度,以及碰到的问题。一般问题会由scrum master进行记录,在会后协调资源给予支持。
评审会:是对迭代的成果进行验收,全员参与,同时也希望真正的用户也参与进行并给出一些意见。评审会需要达成一个目标,即是否肯定这个迭代的成果。当然会议中有提出的一些问题也需要做一些评估,是否在本次迭代内改进,还是放到下产品backlog里面去。
回顾会议:主要是为了总结这个迭代过程中做的好的,做不不好的,并对做的不好的进行分析,同时列明优先级并对top的问题订制action,指明负责人,在下次迭代中进行改进。
产品梳理会:产品经理可以不定期的进行组织,人员包括相关利差方;如果产品backlog经过长时间的积压,有些需求已经长时间未加入迭代,可能这些需求点已经没有价值,需要从backlog中清除掉。另外,也要以backlog里面的内容根据新的产品规划做优先经以调整,以达到保证客户的需求的价值能够按优先级进行排序;同时也减少对订制sprint backlog的干扰。

承诺– 愿意对目标做出承诺,并主动承担责任。
透明– 自己的工作情况以及进展都开发给别人。
尊重– 团队之间相互的尊重,对出现的问题要予以进行帮助,而不是指责。
勇气– 对自己所做承诺需要想尽一切办法并达成,而不是过多的依靠团队。
协作– 敏捷核心是以为人本,但也强调相互的协作和帮助,以达到团队人员共同进步。

监控迭代的执行情况,以发现问题及时进行调整控制;燃尽图一般会通过story的故事点、任务数、预估时间的燃尽情况来进行观察是否进度和成本指数有较大的偏差;当然更应该实际深入通过站会等方式来了解具体的计划执行情况。

资源使用率是迭代质量的一个核心指标,提倡更多的资源利用在有价值的事情上。但是较高的资源使用率也有可能说明团队的负载情况过重,或者没有太多的分享、交流、学习的时间,也不利于团队的成长 。

容易出现的问题,包括迭代计划质量不高、任务不明确、风险认别不足,导致迭代过程中分析成本过高;任务是分派制而不是认领式;迭代容易前松后紧,质量容易出现问题;迭代周期内拒绝变更;临时任务的处理;以及个人关注整体需求不足等。

Kanban模型是一个加速价值流动的模式,它通过客户端的价值体验为源头,不断向上流进行需求拉动,并通过限定在线制品数以此产生挤压效果,从而减少各种资源的浪费。

中心原则来自于及时生产,生产刚刚够用的产品。通过库存,快速反应,零等待、零缺陷减少过程的浪费,以此达到需求和产出的平衡。

精益思想,就是根据用户需求定义企业生产价值,按照价值流组织全部生产活动,使要保留下来的、创造价值的各个活动流动起来,让用户的需求拉动产品生产。

减少浪费,包括减少没有价值的工序并在工序中尽可能多的增加价值。

制订较为合理的流程,减少不必要的中间环节;根据实际需求调整最做强的WIP值,以此产生高效的挤压效果;同时在各个环节中设定交付标准并严格执行;通过不定期的反馈并对流程进一步优化;通过关键性指标来考核过程改进的实际效果,如leadtime,吞吐量等指标。

leadtime:即需求产生以及到实现的过程周期,时间越短越能较早的体现价值。
吞吐量:当资源固定的时候,吞吐量可以了解生产能力是否在到了平衡,数字越小或者越大或者会说明需求与产生产了不平衡。
上线占比:直接上线数越多越能说明我们的更有价值,因为我们把更多资源投入到更能体现价值的事情上。

kanban也需要master组织每日站会,并观察看板中的任务分布及执行情况,并根据站会中反映的问题给予协助、协调,达到任务更为顺畅的执行。
需要不定期的组织需求规划会议,并要求全员参加以增加所有团队成员才业务能够有一个全面综合的掌握,并在工作中相互的支援。
还需要不定期的组织总结会,并分析kanban的各类指标,分析过程并进行改进,以提高效率。
另一个重要的会议是运营会议,需要根据业务的运行情况了解我们工作任务的收益情况,并让团队也参与的产品运营中来。

与Scrum一样,kanban在实践过程中也会发生一些问题,比如:节奏和稳定性的把控、过程的作假、团队工作时间会有明显的碎片化、团队lead的领导力等。