0530-3433334

网站建设 APP开发 小程序

知识

分享你我感悟

您当前位置>首页 >> 知识 >> 软件开发

我对敏捷式开发的理解,要求每个人都清晰了解

发表时间:2023-09-26 08:04:58

文章来源:炫佑科技

浏览次数:155

菏泽炫佑科技

我对敏捷式开发的理解,要求每个人都清晰了解

当我**次接触敏捷时,我无法理解这个模型。 没有研究或文档,从需求到设计的方法与我在学校学到的完全不同。 但工作两年后软件开发,我的认识开始发生变化。 变化,下面我将分享我对敏捷开发作为 UI/UX 的一些理解。

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

为了更好地完成共同目标,团队成员除了成为自己职责领域的专家外,还需要了解他人的工作内容以及整个团队的工作模式。 工作模式是一种将团队成员联系起来的操作方法,需要每个人都清楚地理解并认同。

1. 敏捷开发宣言(Agile)

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

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

可工作的软件高于详细的文档:阅读文档是一件令人头疼的事情。 无论是需求还是技术文档,编写和维护都需要大量的人力。 文档的不灵活性使得其在敏捷开发中的地位较低。 减少我对敏捷式开发的理解,要求每个人都清晰了解,所以这里的文档应该尽可能精简,能够替代文档的软件是任务的首选。

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

响应变化而不是遵循计划:与瀑布流中产品的功能经过充分规划然后集中开发不同,不断变化的需求让敏捷实践者可以尽可能地简化计划。 这个可以结合MVP(*小可行产品)概念来理解。

每次迭代都会提供一个*小可用函数。 该功能尚不完善且简陋,只能满足用户*基本的需求。 后期通过客户的积极反馈慢慢完善功能。 这种方法试错成本低,能够快速响应需求变化。

2. 工作流程

这里简单描述一下我的工作流程,迭代两周。

开发阶段称为(冲刺)。 每次启动前都会召开(规划会议),共同规划本次迭代的开发任务。 会议领导者通常是PM(产品经理)或PO(owner、产品负责人)。 。

在会议上,PO将向团队成员展示本次迭代开发中包含的需求。

每个需求都是一项或多项任务。 PO按照优先级安排要开发的任务,描述每个任务要实现的目标,并确认设计、开发和测试。 在Scrum(敏捷教练,一般是技术大牛的配合下)找到任务处理者并在工作时间内估算完成任务所需的时间。

*后队员们聊了一个50美分的话题,增进了感情,就结束了。 在接下来的两周内,团队成员每天早上都会举行一次简短的(站立会议)。 每个人都会解释他们昨天做了什么,完成程度如何,延迟的原因是什么,是否需要其他成员的帮助,以及今天做了什么。 计划要完成的任务。

周末会召开中途评审会,了解开发进度。 如有延误,及时做出相应调整。 这两周将是一个完整的过程(评审会),回顾本次迭代的完成情况,展示已实现的功能和现场demo。

3. 部分概念理解

注:本部分样例图片来自腾讯敏捷办公产品Tapd。

1. 要求和任务(故事和任务)

需求由 PO 制定,是简化用户故事的产物。 它们描述了在什么场景下需要完成什么功能。 对于开发来说,这是一个开发任务。

功能相对复杂的需求往往被分解为多个需求,以用户角度可接受的*小粒度拆分为子需求,并以父子需求的形式关联起来。 从开发的角度来看,一个开发人员(Story Owner)可以接管这个任务,然后将其分配给其他开发人员。

2、需求池()

需求池记录了需要开发的需求和优先级。 优先级按照对用户的价值排序,优先级高的优先开发。 PO在表达需求时往往没有详细的需求文档。 他们通常使用简短的文字来详细描述需求,并使用面对面的沟通将需求传递给设计或开发。

3. 故事板

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

4. 工作时间

工作时间是影响迭代完成的重要因素。 它涉及任务处理者对工作时间的估计。 如果实际工时高于预估,势必造成任务延迟或开发超时,影响整个迭代的完成。 如果实际工作时间低于预估,就会造成人力资源的浪费,影响效率。

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

一般来说,每个开发周的任务工作时间略少于40(5×8)小时。 处理bug所花费的时间不计入工作时间。 错误首先被解决,而开发它们的人将解决它们。

4、成功时灵活,失败时灵活

敏捷的特点、优点和缺点都是灵活性。

优势:

缺点:

5. 总结

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等

相关案例查看更多