敏捷开发简单整理

最新推荐文章于 2024-10-03 10:28:40 发布

BinBinXiaoYuEr

最新推荐文章于 2024-10-03 10:28:40 发布

阅读量556

点赞数 1

文章标签：敏捷开发

本文链接：https://blog.csdn.net/BinBinXiaoYuEr/article/details/105818111

版权

敏捷开发 — Agile Development

Fly冰冰小鱼儿
Github地址：https://github.com/FlyBingBingXiaoYuEr123
码云：https://gitee.com/flyBingBingXiaoYuEr
简书地址：https://www.jianshu.com/u/6a8258941803
博客地址：https://blog.csdn.net/BinBinXiaoYuEr

工作中有幸接触到一个比较好的开发团队，使用了敏捷开发模式，工作效率有很大的提升，即使同事不在一个城市，也能很好得交流。学习到了一些敏捷相关的知识，所以想要在这里分享记录一下。

使用 Phabricator 管理敏捷开发示例

好的开发流程需要配合好的工具管理，Phabricator 平台可以让项目变得更加可视化，使得每个团队协作变得方便。它提供的各种工具可以方便我们管理敏捷开发流程的各个环节。

Task

Task 是 Phabricator 的基础部件，也是我们敏捷开发中用来管理需求和任务的核心工具。在敏捷开发中，一个 Task 用来记录需求、要开发的功能或者 Bug。
在需求分析阶段，产品经理可以用 Task 来记录大的需求、idea 等，随着分析的深入，将 Task 一步步细化。最终在迭代周期开始前，将需求拆分成小的 Task。

Task 的内容

Task的内容不仅仅是给做这个Task的人看的，对于团队中每个人都是可见的，是团队成员协作的基础和关键，任何人在开发过程中对某个 Task 的需求有想法和问题，都可以在 Task 里面留言沟通。因此写好一个 Task 的内容至关重要，只有 Task 的内容描述清楚了，团队才能基于此开发交流。

一个 Task 内容的范围不能过大，其工作量是一个人可以在几天内完成的任务，过大不利于协作和测试。一个 Task 只有一个主题，不能在一个 Task 里面描述多个需求。一个写的好的
Task 应该是围绕一个需求一个主题展开，内容包含以下几个部分：

任务介绍(Introduction)：介绍这个 Task 要做的功能，描述业务上的逻辑，给出必要的文案、UI设计图等资料。
技术细节(Technical Detail)：描述完成这个 Task 可能涉及到的技术资源，例如需要调用的API接口文档等。
验收标准(Acceptance Criteria)：描述在什么情况下，做什么操作，能够达到什么效果。
一个不好的 Task 描述：
对接 Stripe 信用卡支付
正确的写法：
Introduction:
==========
Android客户端对接 Stripe，让用户可以通过 Visa/MasterCard/JCB 信用卡购买套餐。

用户输入信用卡后自动识别信用卡的类型并展示图标
验证卡号，有效期信息符不合法之后要提示
付款成功之后发送邮件和Push通知消息。文案是：xxx

附件：[UI 设计图] [文案文档]

Technical Detail：

Stripe 文档链接：https://stripe.com/docs/mobile
信用卡支付API
接口：https://api.example.com/api/payment
在线文档：https://api.example.com/document#payment

Acceptance Criteria：

当用户没有输入信用卡信息时，支付按钮为灰色不能点击。
当用户输入错误的信用卡信息时，点击支付按钮后，提示信用卡信息错误。
当用户输入正确的信用卡号时，输入框旁边显示对应卡类型的图标。
…
前面一种写法一般在需求刚提出的时候出现，因为刚提出需求时一切都不明确，只能创建一个 Task 来记录很粗的想法。这样的 Task 是不能交由开发者进行开发的，因为此时团队并未就最终的产品形态达成一致，直接着手开发会导致。需要产品经理进一步分析，将需求细化，最后写出一个可执行的 Task。在细化需求的过程中，开发者需要配合产品经理调研实现方案。

Task 的其它属性

每个 Task 要标注上 Story Points，用来衡量每个任务的难度和需要花费的时间，一般来说 1 Story Point 表示需要一个人天的来完成。标注好 Story Points 之后更加有利于安排开发周期，分配人力资源。
Story (用户故事) 是敏捷开发中用来描述任务的一种方式，Story 在 Phabricator 中对应的就是 Task。参考资料
为 Task 添加不同的标签：有时候不同技术的开发者在各自的项目里面做同样的功能，他们完成任务的内容都一模一样，甚至UI设计图都一样。管理这样需求的时候，很容易想到只创建一个 Task，然后给所有与这个任务相关的人做。就像下面一样：

在这里插入图片描述
有4个不同的开发者都将工作在这个任务上，这样的话这个 Task 的进度很难跟踪，没有人会去关联这个 Task，一个人做完了也不能直接将 Task 拖到Testing里面交由QA测试，因为不清楚其他人的进度。QA 测出一个客户端的问题写到 Task 里面，4个开发很难搞清楚到底是哪个端除了问题，交流容易出现混乱。
正确的做法是将这个 Task 拆分成4个一模一样的 Task，然后打上不同的标签。方便每个端的开发者独立跟踪任务的进程。

Workboard

为了在短期迭代里面快速交付可用软件，我们需要将任务可视化，使整个团队都能理解项目的当前状态，促进团队以一种自发、有动力且互相合作的方式来工作。
敏捷开发有一种实践叫做“任务看板图”，从中你可以对项目的进行状态一目了然。任务看板最初来自于日本丰田的TPS （Toyota Production System）所用的“Just-In-Time”（JIT）生产方式。看板图显示了在本次迭代中要完成的所有任务的当前状态。任务用卡片来代表，状态则由板上分别标有“未做”、“正在做”和“做完”的三个区域来代表。看板图帮助团队理解当前做得如何，以及下一步要做什么，令团队能够自我指导。
在这里插入图片描述
如今各个公司的敏捷的团队都实践了这种方法，所有的敏捷开发管理工具都提供了类似的功能用于在电脑屏幕上展示任务看板。Workboard 是 Phabricator 中管理任务的工具，它可以用作敏捷开发中的任务看板。在 Phabricator 里面每个项目（Project）都有一个 Workboard，每个项目可以创建多个 Milestone 类型的 Subprojects，每个 Milestone 作为一个Iteration。
在这里插入图片描述
因此我们一个项目将会有多个 Workboard，Parent Project 的 Workboard 主要用来给产品经理管理任务。

产品经理收集到新需求之后，将其加入到 Parent Workboard 的 Backlog 里面。在Backlog里面产品经理可以进一步将需求细化，按照优先级排列 Task。在新的迭代开始前，产品经理建立新的 Milestone，名字命名为 Iteration xx，xx代表第几个迭代，将 Backlog 里面准备好的 Task 挪到这个Iteration里面。
Iteration 的 Workboard 作为跟踪Task状态的任务看板。任务看板被分成了 4 列：Backlog、Doing、Testing 和 Done。Backlog 里面是所有这个迭代将要完成的任务，Doing 是开发者正在做的任务，Testing 是正在测试中的任务，Done 是已经完成测试通过的任务。在这里插入图片描述
开发者每次从 Backlog 里面拖一个任务到 Doing 里面，将自己的名字关联到 Task 上面，然后阅读 Task 里面的需求开始工作。开发者写完代码之后，需要过通过Task里面所有列出的 Acceptance Criteria（验收标准），然后放到 Testing 里面等待QA测试。QA 测试如果有问题，将出现的问题写在 Task 里面，然后将任务拖回 Doing 里面等待开发者修改。开发者修改完成之后，再放回到 Testing 里面测试，测试通过之后，QA 将 Task 拖到 Done 里面标记
成 Resolved。
从以上流程可以看出，一旦 Task 进入 Iteration 开发，不再需要任何人来监督进度。开发团队会自发的去完成每个任务，测试每个任务，并且以 Task 为中心来交流开发过程中遇到的问题。从 Backlog 到 Done 的流程，是开发团队将想法落实到实际产品的过程，而保障这个流程的前提是前期需求分析要充分，保证 Task 描述的任务是清晰准确的。

Wiki

在开发过程中，需要将重要的文档都写到 Wiki 里面，让产品知识得以沉淀下来，方便团队知识共享，也可以帮助新人快速熟悉产品。
一般来说有以下几种文档值得记录到 Wiki：

产品的需求文档
复杂业务逻辑的流程文档
项目的阶段计划安排
Release notes
产品的架构，有价值的技术解决方案

敏捷宣言：

个体和互动
工作的软件
客户合作
响应变化

常见问题

1 什么是TDD及其好处？

TDD(Test-Driven Development)测试驱动开发，TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。好处：1.根据测试的点能够更加清晰得理出需要的业务逻辑，避免不必要的逻辑处理。2.在以后重构代码的时候也能自动测试，避免在重构代码的时候不会因为疏忽引起bug。

2 什么是舒适区以及如何跳出舒适区？

舒适区是指一个人的心理状态或者习惯性的行为模式，人在这个状态和模式下感觉很舒适。舒适区禁锢个个人的思想和行为，滋养惰性，消磨意志，所以需要我们跳出自己的舒适区，不断去尝试新的东西，尤其是技术，当我们使用以前的老的框架习惯了以后，我们要学习不断去学习新的框架，新的知识，这样才能有所进步，提升自我。

3 什么是持续集成及其好处？

持续集成是指频繁得将项目代码提交到主干。这样做的好处：1.更加快速得发现Bug,定位B
ug 2.防止分支偏离主干，如果集成不频繁，会造成后期集成难度加大。3.可让产品快速迭代，并保证高质量

4 详述SCRUM的几大要素

1.Sprint : 冲刺，也就是一个迭代，是指一个固定的周期比如两周，团队需要这这个周期内交付可以工作的软件给客户
2. User Story : 用户故事，这个特性是对客户有价值的，所以通过用户故事来衡量功能需求，一个功能点也就是我们的一张卡
3.Point : 故事点数，代表用户故事的工作量大小，也显示团队人员的交付能力
4.Backlog : 待办事项集，产品经理收集各方的需求，期望，诉求等到代办列表里面，还有优先级的排列
5.Sprint Backlog:每个迭代的功能开发列列表

5 详述SCRUM4大会议及其内容和目标

1.Stand Up 每天的站会，是一种团队成员之间快速沟通交换信息的过程，每个成员实时完成的任务的情况可以被相关人员知晓，便于相关人员进行交接和工作的稳定执行
2.Sprint Planning Meeting : 项目开始之前，进行一个规划会议，大家根据不同的功能进行规划时间，并对要做的事情有详细的了解。
3.ShowCase:开发人员定时将开发好的功能向客户展示，这样能够给客户实时提供可工作的软件，便于用户理解产品，有问题也可以及早提出来
4.Retrospective：每个迭代以后进行总结，好的不好的地方都可以总结交流，好的地方可以继续发扬，不好的想办法解决，便于个人的提升和团队的提升

6 说说你对敏捷宣言每一条的理解

1.个体和互动高于流程和工具 : 在开发过程中尊重个体，更加强调人与人面对面的互动。
2.工作的软件高于详尽的文档：尽量短时间内提供交付可工作的软件
3.客户合作高于合同谈判：对待客户不是简单的签合同就好了，要让客户参与到项目的研发中，及时给客户提供可工作的软件，这样能够帮助客户明确需求
4.响应变化高于遵循计划 : 要拥抱变化，需求变化是为了更好的体验更优的产品，为了这个目标，需求变化不可避免，我们要拥抱变化，及时响应变化。

7 你觉得敏捷12原则中哪4条最好及其原因

1.我们最重要的⽬目标，是通过持续不不断地及早交付有价值的软件使客户满意
持续不断地交付可工作的软件可以让客户及时看到产品效果，明确需求，及时更改，在做好产品的基础上尽可能得做到了降低开发成本
2.欣然⾯面对需求变化，即使在开发后期也⼀一样。为了了客户的竞争优势，敏敏捷过程掌控变化。
这个原则可以端正开发心态，需求的变化是为了更好的产品，我们要拥抱变化
3.激发个体的⽃斗志，以他们为核⼼心搭建项⽬目。提供所需的环境和⽀支援，辅以信任，从⽽而达成⽬目标。
团队是由个体组成，能够以人为本，尊重和信任个体，提供需要的环境和支援，个体可以更好得服务团队，也是创建好团队的来源
4.坚持不不懈地追求技术卓越和良好设计，敏敏捷能⼒力力由此增强。
对于技术人员来说，要有不断得坚持不懈得准求技术桌越的信念，这样才能不断得提升自我能力与价值，求知欲得到满足，自我价值得到提升

8 说说你对SCRUM价值观的理解

1.专注：每个迭代只专注于迭代要完成的事情，团队和个⼈的能⼒和精⼒是有限的，在有限的时间内专注于最有价值的事情，以取得好的结果
2.勇气: 要有勇⽓气去⾯面对各种挑战。
3.公开：团队所有的进展，问题，阻碍都是对所有人可视化，透明的。这样的团队才是彼此尊重。同时也能暴露问题。
4.承诺：作为一个⾃自组织团队，在迭代开始的时候做出承诺，并在迭代中全⼒完成。