精简版最小可实现维度的敏捷开发

敏捷开发是一种面临迅速变化的需求进行快速开发的能力,非常适合需求产出快、变化频繁的产品研发,可以快速的响应需求的变更并拥抱这种变化。很多人认为敏捷开发只是开发团队走敏捷的模式,这是一个误区,实行敏捷开发不仅要求开发的敏捷,也要求测试的敏捷,产品的敏捷,即整个产品的研发过程都需要敏捷起来,才能真正意义上实现敏捷。

在产品研发过程中,从需求管理到最终的产品运营,全过程应用敏捷的思想,让产品研发团队成为产品的主人和管理创新的驱动者。当产品研发团队自发的去持续优化产品,不断提升产品质量和研发效率时,整个团队的工作效率就提升了,产品的迭代周期自然会缩短,团队会树立更高的目标去挑战,当他们持续地周而复始时,卓越就成为了团队的习惯。

在敏捷实施的过程中,从产品经理的角度来说,要关注产品需求以迭代的方式去产出,合理的按照实现价值去安排每个迭代需求的优先级,这可以保证每个迭代开发人员在实现的都是优先级最高的需求。从开发人员角度来讲,对每个迭代任务的需求理解和工作量安排是他们所要关心的,合理的分配每个开发人员的任务,以达到最大化的效率利用,进而保证每个迭代的高效产出。

敏捷开发实施的四个关键因素:

第一是强调面对面的沟通,也就是说沟通很重要,人和人的相互交流胜于任何流程和工具;

第二是要把精力集中在可执行的程序上,也就是强调了原型、Demo等的重要性;

第三个是团队合作和团队激励,敏捷开发能将产品、设计、开发、测试、运营等全部团队成员融合成一个整体,大家都是一条线上的蚂蚱;

第四个是快速适应需求变化的能力,适应变化胜于按部就班,敏捷开发的特点就是快速;

施行敏捷开发的团队就好比一支橄榄球队:他们有明确的最高目标,而且每时每刻都朝着目标努力;他们熟悉最佳实践,高度自我管理,高度协作,高度灵活地面对各种挑战。大量的调查统计表明,敏捷开发确实大大提高了产品研发效率和质量,并更利于团队中的个人成长。

正规的敏捷开发流程如下图所示:

敏捷开发流程

敏捷开发流程

整体流程稍显冗长,对于刚接触敏捷开发的团队来说,实施起来是有难度的。考虑到各个团队的不同现状,对于敏捷开发模式的采用需要更关注效率而不是形式,对整体的敏捷流程做了优化,优化后的流程如下:

minjiemoshi

精简版敏捷流程

 

产品敏捷的职责:

  • 需求列表的维护。产品端要保证每个迭代开始前都已经把下一个迭代的需求列表全部准备就绪,并等待评审或者已经完成评审。这就需要需求池中时刻都有新需求的产出并适应每个迭代工作量的需要。
  • 需求优先级的评定。产品端要确保每个迭代的任务都是当前需求池中最优先的任务,需要提前和各方确认好需求的优先级,最好有价值验证和可量化的衡量标准。
  • 需求产出的提前量。产品产出需求后,后面还有设计、前端的实现,要有一定的提前量,尽量保证在迭代中,设计、前端、开发、测试相互之间不受任何一方延误的影响。
  • 需求实现过程的跟进。产品端要尽量参与到整个敏捷团队的每日站会中,跟踪需求实现的过程,及时响应过程中的对需求的疑问和需求变更的问题。

开发敏捷的职责:

  • 需求的任务拆分。开发根据需求评审的结果和排定的优先级,将划分到当前迭代的需求拆分成个体可实现的任务,拆分的依据一般是:一是每个任务都是可以单独测试验证并上线的;而是每个任务都是可以在单个迭代内完成的。
  • 任务的工时评估。开发人员集体估算每个任务的工作量,直到所有任务的估算工作量加起来达到迭代周期内团队的工作量总和为止,一般会留一小部分时间来做为缓冲。
  • 任务的合理分配。需要根据团队中每个人的能力来进行任务的分配,量力而行,并确保资源投入在高优先级的任务上,保质保量的完成迭代任务。
  • 迭代进展的跟踪。要在每日站会中跟进团队成员各自负责任务的工作进展,随时跟进解决问题,确保相互之间的任务管理不受影响。
  • 相应需求变更。需求变更是很难避免的,若需求或者技术方案发生变化时,敏捷团队要从需求的紧急程度来考虑,紧急的需要团队内部讨论,如果能在缓冲时间内完成的就完成掉,如果不能则需要从已安排的任务当中挪出一部分到下个迭代。

测试敏捷的职责:

  • 迭代任务的及时测试。开发将需求拆分成单个可独立验证的任务后,测试可以跟进做单个任务的测试,每开发完成一个任务,就会送测一个。因此测试要保证每个任务的测试用例都是提前完成的,能够在开发送测的时候进行及时测试。
  • 全程参与迭代。从需求评审、迭代计划制定到迭代过程当中,测试人员需要全程参与,并根据迭代的安排完成相应的测试任务,保证迭代完成时测试任务也全部完成,达到可上线的状态。
  • 质量和效率的平衡。敏捷测试强调从用户的角度来测试产品的功能,重点关注持续迭代过程中测试新开发的功能,保证可用性和完善性,而不再强调传统测试过程中严格的测试阶段,需要额外排任务进行完整测试,如性能测试等。

从以上关于产品、开发、测试的职责当中可以看出,这中间有几个角色和环节比较重要。要推行敏捷开发,有两个重要的角色不可缺少,那就是产品负责人和敏捷专家。

敏捷开发中的产品负责人(Product Owner),即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。产品负责人需要把握产品整体的需求功能列表,清楚每个需求功能和其所产生的业务价值。

敏捷开发中的敏捷专家(Scrum Master),即熟悉敏捷开发模式及敏捷实施流程的人员,一般可由敏捷团队当中的开发负责人担任,部分能力很强且懂技术的产品经理也可担任这个角色,因涉及到工作量评估和分派等工作,最好都是由技术能力较强的人员担任。该角色需要接受敏捷开发模式的培训,要非常熟悉敏捷开发的流程。

由产品负责人来保证需求的安排,由开发负责人来保证迭代任务的拆分、工作量评估、任务分配和执行,这样在敏捷开发的不同阶段,可以由相应的人员的来负责落实。

敏捷开发流程当中有四个会议比较重要:

需求评审会:在迭代开始前要把每个迭代的需求进行评审,由产品负责人进行需求讲解,在会议上需要排列需求的优先级;

迭代计划会议:在每个迭代开始前,由开发团队进行任务拆分、工时估算、任务分配的计划会议。 在会议上需要分析和评估产品需求列表的工时,并确定当前迭代的完成目标。

每日站会:团队每天进行沟通的内部短会,一般只有15分钟且站立进行,团队成员通常会在会议上讲述如下3点内容:1) 昨天我做了什么;2) 今天我计划要做什么;3) 我遇到了什么问题,妨碍了我尽可能有效地工作。开发负责人记录会议上提出的问题,但是不要在会议上讨论和解决问题,而是要会后在找相关人员进行讨论和解决。

迭代评审和总结会议:在迭代结束前给产品负责人演示本迭代开发完成的功能并接受评价,在迭代结束后召开团队持续改进的会议,围绕如下三个问题进行讨论:1) 本次迭代有哪些方面做得好;2) 本次迭代在哪些方面还能做得更好;3) 下次迭代准备改进哪些方面。团队确定问题优先级,并讨论问题的解决措施,分配责任人进行跟踪。

敏捷开发的过程不仅仅是一个项目快速完成,而是对整个产品需求的高效管理;敏捷不仅仅是简单的快,而是短周期的不断改进、提高和调整;敏捷不仅仅是开发完成就快速上线,而是快速形成原型、全员测试反馈修改提高;敏捷不仅仅是一个版本只做几个功能,而是突出重点、果断放弃当前的非重点;敏捷不仅仅是随时增加需求,而是每个迭代周期对需求的重新审核和排序。

  • 重点明确,及时调整。通过分析需求的紧急性和重要性,做出优先级的判定,优先级排列没有重复;迭代中严格按照优先级顺序开发,即使最后时间不够,也能保证最需要的功能开发完成;每次迭代前重新调整需求的重要性,及时加入重要的业务需求和用户需求,将重要性不高的需求往后调整。
  • 倾听用户的声音。在迭代中充分关注已发布版本用户的使用反馈,在当个迭代或下个迭代快速优化;通过对用户反馈的及时响应获得用户的认可和口碑。
  • 勇于创新、小步快跑。在迭代中勇于创新,快速实现创新想法,并在后续的迭代中不断优化。
  • 持续不断地发现问题,解决问题。通过团队在每日立会上做出的描述,测试和验证功能的开发程度,对于功能的实现第一时间给出反馈,并能快速调整,而不会像瀑布模式那样要等到开发末期才发现实现上的问题。
  • 持续提升整个团队的能力。团队面向一个产品领域,持续优化用户体验和产品流程,通过迭代的持续保持团队的用户和市场敏感度,提高团队的产品意识,伴随业务而成长,获得更高的成就感。

敏捷的核心是“以人为本”,因此实施敏捷的阻力也主要在于人。要想推行敏捷模式,必须要上下一心,建立起敏捷的相关考核和评估机制,确保敏捷的实施不受外部因素干扰,才有可能真正实现敏捷。



无觅相关文章插件,快速提升流量

“精简版最小可实现维度的敏捷开发”3 条评论

jufan | 2015-12-15 10:47 |
commenter

这个可以有!

15564916 | 2016-01-5 09:28 |
commenter

看看!

zst8366@126.com | 2016-02-28 18:23 |

看一看来瞧一瞧,这个博客真是好!