如何做好敏捷式开发?

0 评论 2941 浏览 19 收藏 10 分钟

编辑导语:作为一名UI/UX设计师,在工作中接触到“敏捷”一词时,也会感觉到模式和难以理解。从需求到设计每一步都需要了解清楚,那么敏捷开发这种模式该如何做呢,我们一起来看看吧。

刚接触敏捷时我对这种模式是不能理解的,没有调研没有文档,从需求到设计用的方法和学校里所学的完全不一样,但经过两年的工作后,我的认知开始发生变化,下面我将作为一个UI/UX分享一些我对敏捷式开发的理解。

在互联网行业中,一个项目的完整生命周期都是由一个团队完成的,团队成员也许会变化,但任何一个角色都不可或缺。

为了更好地完成共同目标,团队成员除了在自己负责的领域是专家,还需要了解其他人的工作内容及整个团队的工作模式。工作模式是连接团队成员的一种运作方式,要求每个人都清晰了解,并认同。

一、敏捷式开发宣言(Agile Program Development)

起源于20世纪90年代,由开发程序员提出,是相对于传统软件开发方法(如瀑布流模型)而言的一种新软件开发模式。这里认为该模式不仅仅适用于开发,也适用于团队除开发外的其他角色,因此将它视作为团队工作模式。下图为敏捷开发的价值观。

个体和互动高于流程和工具:人是最重要的因素,敏捷提倡打破部门的概念,人与人之间面对面沟通,交流。敏捷的办公室常常是很热闹的。

工作的软件高于详尽的文档:看文档是一件让人头疼的事,无论是需求或技术文档,撰写和维护都需要耗费大量的人力,文档的不灵活性让其地位在敏捷开发中地位降低,因此这里的文档要尽可能精简,能用软件替代文档的任务首选软件。

客户合作高于合同谈判:客户对产品的需求会随着他自己的认知和心情变化,能从一开始就确定细节的项目实在太少,经常与客户沟通,给予反馈才能促成项目的成功。

响应变化高于遵循计划:和瀑布流中将产品的功能完全规划好后集中开发不同,不断变化的需求让敏捷从业者制定计划时尽可能的简化,这里可以结合MVP(Minimum Viable Product 最小可行性产品)的概念去理解。

每次迭代交付一个可用的最小功能,这个功能时是不完美的、简陋的,只能满足用户最基本的需求,然后通过后期客户的正反馈慢慢完善功能。这种方式试错成本低,能快速应对需求变化。

二、工作流程

这里简单描述自己工作中两周为一个迭代的工作流程。

一个开发阶段称为一个Sprint(冲刺),每个Sprint开始前,都会举行一个Planning Meeting(计划会)来共同规划这个迭代的开发任务,会议主持人一般为PM(产品经理)或PO(Product Owner,产品负责人)。

会上,PO会向团队成员展示列入这个迭代开发的需求。

每一个需求都是一个或多个任务(Task),PO根据优先级安排要开发的任务,描述每个任务要达到的目标,和设计、开发、测试确认,在Scrum Master(敏捷教练,一般为技术大牛)的协作下找到任务处理人并以工时为单位预估任务完成需要的时间。

最后,团队成员之间聊个五毛话题增进感情,Planning Meeting就算结束了。在接下来的两周内,每天上午团队成员要开一个简短的Standing Meeting(站会),每人说明昨天做了什么,完成度如何,如有拖延是因为什么原因,是否需要其他成员帮助,以及今天计划要完成的任务。

一周下来,要开一个半程回顾会,了解开发进度,若有延迟,及时做出对应调整。两周下来是一个全程Review Meeting(回顾会),回顾这个迭代的完成度,并展示实现的功能,现场Demo。

三、部分概念理解

注:这部分示例图来自腾讯敏捷类办公产品Tapd。

1. 需求及任务(Story and Task )

需求由PO建立,是将用户故事(User Story)简化后的产物,描述在什么场景下需要完成什么样的功能,对开发而言就是一个开发任务(Task)。

功能比较复杂的需求往往会被拆解成多个需求,拆分到以用户角度可接受的最小颗粒度功能作为子需求,以父子需求的方式进行关联。开发的角度上看可以由一个开发(Story Owner)接下这个任务,再分配给其他开发人员。

2. 需求池(Backlog)

需求池里记录着待开发的需求及优先级,优先级按照对用户的价值进行排序,高的会先开发。PO在表述需求时往往不会有详细的需求文档,一般会用简短的文字描述在需求详情里,再加上面对面沟通将需求传递给设计或是开发。

3. 故事板(Story Board)

以卡片的形式展示当前迭代的进度,包括任务内容,优先级,处理人,状态等信息。PO可从这里清楚地看到团队的进度,开发也可以通过筛选来了解自己各种状态的开发任务。

4. 工时

工时是影响一个迭代完成度的重要因素,涉及到任务处理人对工时的预估,如果实际工时高于预估,势必会造成任务延期或开发加班,影响整个迭代的完成度,如果实际工时低于预估,便会造成人力资源的浪费,影响效率。

准确的预估工时需要开发人员有丰富的经验,掌握业务逻辑,了解自己的开发能力,此外工时还包括安全时间,以处理特殊情况。

一般每个开发一周有略低于40(5×8)个工时的任务量。处理Bug所用时间不算在工时内,Bug秉承优先解决,谁开发谁解决的原则。

四、成也灵活,败也灵活

敏捷的特点,优点,缺点都是灵活。

优点:

  • 应对需求的灵活性让功能的开发时间缩短,可尽早得到市场的反馈,提高规避风险的能力
  • 人与人之间的直接沟通能充分利用时间,工作效率提高

缺点:

  • 面对面沟通让信息传递的质量随传递人数的增加而降低,从产品到设计到开发再到测试的信息传递会出现偏差,这让敏捷在大项目大团队中的实施变得困难
  • 较少的文档在团队人员过多,人员变动或项目持续时间较长时无法全面了解到产品的全貌,沟通成本增加

五、总结

  • 敏捷是一种理念,原则,价值观,不同的团队在实行这个模式都是不同的。
  • 实行敏捷的目的是为了帮助团队高效地合作沟通,过程中的去文档,去流程,面对面沟通都只是手段,最后还是以结果为导向。切记敏捷流于形式,纠结于步骤!
  • 敏捷要求团队成员有很强的主观能动性,并能主动推进整个项目前进,当他人停滞不前时,PUSH他们。
  • 敏捷团队的建立需要时间和经验积累,当任务出现问题时主动承担责任优于互相推诿,成员间切忌心存芥蒂,这样才能保持团队的凝聚力。

 

本文由 @B端交互设计师 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!