Scrum过程是一种应用于软件开发的敏捷开发方法，基于迭代和增量过程。Scrum是一个适应性强、快速、灵活和有效的敏捷框架，旨在整个项目开发过程中为客户提供价值。Scrum的主要目标是通过保持沟通的透明度、集体责任和持续进展来满足客户的需求。开发开始于对需要建立的东西的模糊概念，开发出产品所有者希望获得的按优先级排序的特征列表。
敏捷的Scrum开发方法
在Mindbowser，一旦项目计划被列出，我们就利用Scrum实践来开发和管理产品。使用敏捷的项目管理方法，我们每2-4周向客户交付新的组件。在一个Sprint中，我们的团队会完成计划中的工作量，并准备好供审查。
每个Sprint包括每日Scrum会议、Sprint Retro、演示日、UAT和代码审查。这意味着每个冲刺都会巩固你的产品，不会留下任何机会。
图- 敏捷项目管理方法
Scrum框架最适合于有计划的功能或对新开发有持续需求的项目。项目遵循时间盒周期，它有一套固定的功能，同时有一个交付日期。
在Mindbowser，虽然我们遵循Scrum框架所建议的流程，但我们也对一些事件进行了改进，使其更加完善。以下是我们在Mindbowser中使用Scrum框架进行项目开发的事件。
1.完成Sprint计划
这是为客户提供的，让他/她初步了解从开发到启动的所有活动的时间表（有确切的日期）。
由于Scrum使用冲刺结构，所以我们只提前估计所有的冲刺和它们的交付日期。这有助于客户获得准确的交付日期，这样他就可以相应地计划他的战略，例如，预售、营销等。
这项工作的产出是一个完整的冲刺计划，其中包括每个冲刺阶段所要涵盖的功能清单。
这个过程涉及整个开发团队。团队决定功能的优先级。功能的优先级是由其复杂性、完成它所需的时间、资源的可用性、对其他功能的依赖性以及最终用户的需求决定的。在这个讨论的基础上，我们准备冲刺，并通过粗略的时间估计，决定每个冲刺的开始和结束日期。
2.冲刺计划会议
这个活动是任何冲刺的实际开始。在这里，所有的利益相关者、开发团队和项目利益相关者坐在一起，并决定首先覆盖哪个冲刺/功能。大多数事情在完整的冲刺计划中已经计划好了，但在这里我们要开会把事情放在轨道上，并计划应对任何新的挑战。
在这个会议上，团队将执行以下行动。
-
- 列出要涵盖的功能。
- 浏览线框图，并进行尽可能详细的讨论。我们试图抓住每一个场景/用例（负面的正面的展位）。
- 将功能分解成用户故事。
- 每个团队成员为每个用户故事添加自己的子任务。例如，一个登录功能需要UI和后端API，所以前端开发将添加子任务来创建UI，应用验证和API的整合等。同样地，后端开发人员会添加子任务来创建所需的API。
- 所有的子任务都是以小时为单位添加的。我们尝试最多只做4个小时的子任务；如果超过这个时间，我们就进一步分解。
- QA增加他们编写测试案例的工作量。
- 一旦所有的用户故事和他们的子任务都被添加进来，我们就根据他们的子任务估计，最终确定所有开发人员的日期。
- 一旦开发人员的日期被确定，QA也可以添加他们最终的阶段性构建测试估计。
- 总的来说，我们最终确定了整个冲刺阶段的交付日期。最后的日期是冲刺阶段的内部演示和客户演示。
- 还有一件很重要的事情，我们要决定QA在一周中的哪一天需要从开发团队那里获得构建。例如，如果我们选择周一（晚上）和周三（晚上）作为构建日，那么开发人员必须在这两天和决定的时间内分享构建，而不是在其他任何一天。这个策略给了QA足够的时间来做质量测试。
- 所有这些用户故事都被添加到JIRA的冲刺中。所有的团队成员都被分配到他们估计的子任务。
图：Jira的项目截图--项目管理工具显示了不同的用户故事和它们的状态。
-
- 一旦我们计划好了所有的任务，我们就开始实际的开发，也可以说我们开始了一个冲刺。
3.每天的Standup会议
这是Scrum中最重要的事件之一。整个团队聚集在一起，每个成员更新他们在上一天完成的任务，他/她今天要做什么，以及他们是否有任何阻碍。
这是做Daily Standup的一个非常标准的方式。
为了跟踪工作，我们要求开发人员从他们的估算（他们创建的子任务）中选择任何8小时的任务，并在JIRA上开始进展。这有助于团队监测估算和实际完成的工作之间的差异。这对开发人员的改进也很有帮助。我们还跟踪所有团队成员的冲刺进度。无论他们是否在轨道上，我们都可以主动采取适当的行动。
4.代码审查
每个开发人员都有一个代码审查员。每隔一天都会向审查员提出拉动请求。评审员对代码进行检查，如果可以改进就提出意见。这种检查的标准不仅仅是检查编码标准或使用正确的架构，而且还包括使用的整体逻辑，如果代码可以进一步优化。一旦所有的检查都完成，那么只有PR会被合并。代码审查也是作为**DevOps**管道的一部分自动进行的。
5.5.CI/CD过程
持续集成（CI）和持续交付/持续部署（CD）是用于构建、测试、打包和部署应用程序的过程。**CI/CD过程**是完全自动化的过程，没有任何人工干预。这种自动化过程为开发者节省了大量的时间。开发人员不需要担心手动生成构建的问题。
图：带有自动代码审查的CI/CD流程
通过Mindbowser的DevOps咨询服务提高软件的质量和可靠性
分支策略
这个过程需要开发人员将他们的代码推送到git repo上，一切都会像魔术一样完成。我们使用Bitbucket作为我们的Git代码管理工具。对于Git仓库，我们遵循一个相当标准的分支策略。
我们确保在Bitbucket repo中有3个主要分支。
- 主分支
- 暂存
- 开发
图：代码的分支实践
开发人员可以从开发分支创建自己的子分支。为了将他们的工作与主开发分支合并，每个开发人员都需要向他们的代码审查员提出拉动请求。只有在审核员批准后，代码才能被合并。
这是检查代码质量和验证良好工作的绝佳方式。
各个分支都有自己的意义。
- 开发分支上的每一个承诺都应该与alpha版本相关联。生成的构建被用于内部测试。
- 对暂存分支的所有承诺都与测试版有关。一旦开发团队在内部进行了测试和演示，暂存版就会与客户共享。
- 对主分支的所有承诺都应与稳定版本相关联。这通常用于生产环境。
开发人员不能直接向这些主分支提交--拉动请求必须向评审员提出，经过批准后，只有他们的工作才能被合并。
如果代码需要改进，评审员可以拒绝拉动请求。评审员可以在必须修改的代码部分加上他们的评论。在这种情况下，开发人员需要按照建议进行修改，并再次提出PR。
CI/CD流程检查这三个主要分支的每一次提交/合并，部署新的更新并生成构建。生成的构建会与QA和团队成员共享。在暂存和生产环境中生成的构建也会与客户共享。
Android的构建（APK文件）通过Firebase App Distribution共享。
iOS的构建通过TestFlight共享。
网络构建被部署在不同环境的专用服务器上。
每次提交/合并完成后，整个团队都会通过一个专门的Slack频道进行通知。Slack频道也会更新构建的生成和部署步骤，并在失败或成功时通知你。
6.内部演示
一旦所有的功能被开发和共享，经过QA的测试和验证，在暂存环境中，我们进行内部演示。在这个活动中，所有交付的工作都由QA向整个团队进行演示，然后每个人都对工作进行反馈。团队成员也可以在他们那头检查对方的工作并提供反馈。
反馈包括bug和改进的建议。根据反馈的变化，我们决定是只做修改，还是把它作为新冲刺的一部分。
最后，构建好的东西就可以和客户分享了。
7.客户演示
经常有创始人抱怨说，他们并不真正知道自己的项目进度在哪里，直到有一天他们看到项目状态有差距，而又来不及修复。
在项目的每个里程碑或主要功能更新时，保持专门的时间进行演示和产品演练。如果你的项目是一个持续的项目，那么你可以**每2-3周进行一次演示**。演示应该通过现场视频分享来进行，同时分享你可以在你自己的舒适环境中玩耍的构建。
在演示过程中，彻底了解并向团队提供反馈。为了避免过多的讨论，我们建议客户保留笔记，并在演示结束后进行讨论。此外，在每个冲刺阶段的开始，应该举行详细的冲刺计划会议，通过端到端的屏幕演练来解决团队的理解问题，以避免进一步的差距和延误。
8.客户反馈
反馈可以帮助你了解客户对工作的看法，我们有机会了解他们的期望。此外，反馈使我们在对话和开发之间保持透明。
我们在项目的每个里程碑或主要功能更新时都会为演示和产品演练保留专门的时间。一旦工作更新与客户分享，我们会分享所有的链接（Web URLs）、APK和iOS的TestFlight更新，以及一份反馈表，我们要求客户提供他们的反馈和他/她所面临的任何问题。
9.冲刺回顾会议
这是Scrum框架中一个非常重要的事件，但有时团队倾向于跳过它，跳到下一个冲刺开发。但在Mindbowser，我们相信对工作的定期评估，而不仅仅是为了开发。
一旦冲刺完成并交付，我们就会对所做的工作进行回顾。这给了我们一个机会去理解正确和错误的东西。
作为这个过程的一部分，整个团队坐在一起，填写一份调查问卷。我们在这个会议上问以下标准问题。
-
- 在冲刺过程中哪些方面做得很好？
- 我们想改变什么？
- 我们怎样才能实现这个改变？
我们还增加了一个问题，以了解学习情况，主要是在技术改进方面。
-
- 在这个冲刺阶段，你学到了什么？
这有助于我们改进，我们采纳每个成员的意见，并尝试在新的冲刺阶段实施所有可行的改变/建议。
图：冲刺计划样本
10.新的冲刺
对于新的冲刺，我们再次召开冲刺计划会议。除了要做的新功能外，我们还要考虑团队成员在内部演示中和客户在**客户演示**中提出的变化/改进。
如果对任何功能有任何疑问，我们会毫不犹豫地与客户联系，在开始新的冲刺前澄清一切。
变化/改进点的列入取决于努力和优先级。
在建立了350多个成功的产品之后，这就是我们的制胜过程。
我们的端到端方法如何帮助您的企业
遵循系统化的工艺方法，使我们能够避免许多其他人可能屈服于的陷阱。整个过程确保了我们开发的应用程序最终不会出现面条状的代码。这使得未来的修订工作变得轻而易举。
我们严格的测试和最佳实践确保了产品的推出没有崩溃和失败。我们优先考虑有一个明确的系统架构，并对我们正在建立的东西有一个清晰的认识。我们利用行业标准的编码惯例和最佳实践来确保可读性和可理解性。
我们一丝不苟的计划、过程和控制导致了可预测的、无意外的软件交付。这帮助我们避免了随着规模扩大而出现的问题，也帮助我们管理我们的技术债务，使之尽可能的低。
阿伦
团队负责人
Arun是一位拥有10年以上专业经验的天才Android开发者。作为一名安卓程序员，他曾在多个领域工作，如SaaS产品、零售、医疗保健和生活方式的应用程序。 Arun是实施AIOHTTP、SQLAlchemy和PostgreSQL的专家。此外，他还熟悉Flask、Redis、MongoDB等。
订阅我们的通讯
通过分享您的电子邮件获得最新的更新。
