-
Notifications
You must be signed in to change notification settings - Fork 56
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #136 from kaola-fed/blog-bot-archive-264572740
auto-archiving for issue #135
- Loading branch information
Showing
1 changed file
with
167 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,167 @@ | ||
--- | ||
title: 并行任务(二)—— 工作流程 | ||
date: 2017-10-11 | ||
--- | ||
|
||
本文主要介绍开发者工作流程的相关内容。 | ||
希望能让你,明白流程的重要性,并对自己的情况对当前流程进行微调。 | ||
|
||
--- | ||
工作中,我们已经接触到了很多很多的流程,比如:请假流程、报销流程、任务评审、交互评审、等等。 | ||
**那么,** | ||
**流程的基本定义是?** 无论我们干什么事,无论在生活、休闲还是工作中,都有一个“先做什么、接着做什么,最后做什么”的先后顺序。 | ||
|
||
**流程的目的是?** 流程的最终目的是提高工作效率,通过消除工作过程中多余的工作环节、合并同类活动,使工作流程更为经济、合理和简便。 | ||
|
||
**总体来说:** 针对一件经常发生的事情,通过分解步骤,按照一定的先后顺序有节奏地去执行,最终达到提高工作效率的作用。 | ||
|
||
不知,大家在平时的工作中,有没有对现有的流程进行过梳理或者思考,思考过流程在我们工作中是否起到了作用。 | ||
|
||
接下来,将从以下3点来进行讲述流程 | ||
|
||
>1. 3个主要流程介绍 | ||
>2. **排期最为关键(*自认为精华加星*)** | ||
>3. 流程可以改变调整,适合自己的才是最好的 | ||
--- | ||
|
||
# 正文 | ||
|
||
## **一、3个主要流程介绍** | ||
|
||
>* 交互稿【产品】 | ||
>* 开发过程 | ||
>* 提交测试【QA】 | ||
> | ||
>每个流程从步骤、目的、违背的坏处、注意点,4个部分来介绍 | ||
### 1. 交互稿 | ||
步骤: | ||
- 交互稿自评(寻找需要修改的点以及遗漏的点,带着疑问) | ||
- 交互稿评审(和产品确认修改和补充) | ||
- 交互稿定稿 | ||
- 中间有变动应及时更新交互稿同时通知QA | ||
|
||
步骤对应目的: | ||
- 了解交互稿的内容以及不足,罗列好问题,能减少在评审时的时间,以及避免对交互稿内容的部分遗漏。其中了解下涉及到的业务逻辑也是很有必要的。 | ||
- 在评审时提出自己的疑问,以及更适合的交互方案。减少在开发过程中的返工以及避免和交互稿有歧义。 | ||
- 根据评审结果,确保产品修改交互稿至最新。因为QA是根据交互稿来进行测试。 | ||
- 有逻辑变动时,需要通知产品和QA。确保交互稿和测试用例一致。 | ||
|
||
违背的坏处: | ||
- 延长交互评审的时间 | ||
- 在开发过程中碰到交互问题需要花费额外的时间去理解以及解决 | ||
|
||
注意: | ||
**!** 交互稿定稿后,原则上不再接受新增逻辑和功能。交互稿较大变动,需要发邮件说明并抄送相关人员。同时,开发时间需要适当进行延长。 | ||
|
||
### 2. 开发过程: | ||
步骤: | ||
- 评估任务开发量人日 | ||
- 确定排期 | ||
- 前后端定义接口 | ||
- 前后端分离开发 | ||
- 联调 | ||
- **提测前对照一遍交互** | ||
- **反思任务** | ||
|
||
步骤对应目的: | ||
- 开发前精准地估算出整体的开发工作量,是的之后的排期能更精准。 | ||
- 根据工作量,合理地计算出任务排期,保证开发质量。同时排期是对各方的承诺。 | ||
- 根据技术方案进行提前确定前后端接口与数据交互,减少在开发阶段互相讨论所占去的时间。 | ||
- 在底打扰的环境下开发,提高开发效率。 | ||
- 在真实环境下进行前后端接口联调。 | ||
- 查漏补缺,避免低级错误。 | ||
- 任务完成后需要对开发过程中有一个反思的过程,从中吸取工作经验。 | ||
|
||
违背的坏处: | ||
- 把控不了整体的进度 | ||
- 开发时间评估不准确会给别人一种不专业的感觉 | ||
- 不定义接口,开发过程中变化的情况需要额外时间去进行代码修改 | ||
- 频繁地和人交谈沟通,降低开发效率 | ||
|
||
注意: | ||
!当开发有风险时,要尽早提出来,通知各方,寻找解决方法。如果有能力尽量在开发中期提出来。杜绝在开发末期才发现风险。 | ||
|
||
### 3. 提交测试: | ||
步骤: | ||
- 用例评审 | ||
- 开发冒烟,提测 | ||
- 集中修复bug | ||
- 产品验收 | ||
|
||
步骤对应目的: | ||
- 用例评审过程中,产品、开发、QA对交互的理解达成一致。同时对于一些交互上的改动进行同步。以及帮助开发发现遗漏点。 | ||
- 在测试环境上冒烟,保证开发质量,走通主要流程。减少打断QA测试过程的情况。 | ||
- 把一些次要bug放在1个时间段内修复,提高效率。 | ||
- 产品应该尽早介入。产品有时候会提些改动需求,避免上线风险。 | ||
|
||
违背的坏处: | ||
- 开发、QA、产品对需求的理解不一致 | ||
- QA测试过程中会出现更多的bug | ||
|
||
注意: | ||
!当交互或者视觉稿有改动的时候,一定要通知到QA | ||
|
||
--- | ||
|
||
**以上的流程如果有什么不正确的地方,欢迎指正** | ||
|
||
--- | ||
|
||
## **二、开发前的排期,最为关键** | ||
对于开发者,任务排期一定不会陌生。 | ||
因为所有的任务都需要进行排期后,才能进入实质地开发阶段。 | ||
|
||
排期,顾名思义就是“排列日期”,由一个个日期(时间节点)组成的。 | ||
|
||
开发者的排期,简单来说由3个时间点组成:**开始开发时间、开始联调时间、任务提测时间**。 | ||
通过排期,合理安排3个时间点之间的时间段,同时在开发过程中和各方配合,最终按照预定目标完成任务。 | ||
|
||
为什么说排期是最为关键的一环? | ||
这是因为,在整个工作流程中,排期有着**承上启下**的作用: | ||
>- 之前的需求评审、技术评审是为了能更精准地预估出详细的开发时间。 | ||
>- 之后的具体开发提测阶段,则需要遵守先前排期上的时间节点来完成。 | ||
>- 现在进行任务版本化,准确的排期能为之后的任务排期减少风险。 | ||
和其他任何事情一样。好的排期能带来好的效果(比如促进开发效率),反之,不好的排期则会引起各种灾难。 | ||
那么,怎样得出一个好的排期? | ||
简单的一句话概括:**尽可能地细分需求成一个个耦合性不高的模块,评估每个模块的开发时长。同时不要忘记给自己预留缓存时间。** | ||
|
||
**排期就像分生日蛋糕。把每个不同的模块当做分发蛋糕的对象。切出来的每一块蛋糕代表细分后的时间段。** | ||
下刀之前,我们需要确定要分给几个人。 | ||
尽可能地了解每个人对蛋糕的喜欢以及胃口,喜欢吃的多分点,不喜欢的则少点。方便能切出合适的大小。 | ||
因为下刀之后,没有像电视的回放功能那样可以重新切分。 | ||
|
||
另外,排期是一种承诺。在工作中,亲口给出的承诺一定需要做到,要给他人靠谱的感觉。 | ||
因此,对于整个流程,由于合作方的关系导致任务有风险。在这个过程中,我们有义务去推动进程,有责任主动去告知每个关系方遇到的风险。 | ||
|
||
--- | ||
|
||
## **三、流程不是不可改变,适合自己的才是最好的** | ||
|
||
流程是不断完善的,每一个人都可以提出自己的建议,来完善当前的流程。使得流程能适应更多的场景,让整个部门的工作能够愈加顺畅。 | ||
同时,根据每个人不同的情况,对其中的一些流程进行适当修改或调整,使得能更符合自己的开发习惯。 | ||
比如:开发一个后端代码复杂,前端逻辑简单的任务。 | ||
可以把交互稿流程改成: | ||
1、交互稿自评 | ||
2、私下找产品确定交互稿细节 | ||
|
||
**TIP:** | ||
流程不仅仅用来规范我们的开发步骤,同时我们也可以通过流程来解决碰到的阻碍。 | ||
比如: | ||
1、当2个任务碰撞在一起的时候,可以把两边的产品拉在一起让产品确定开发优先级 | ||
2、当QA测试时间不够的时候,可以和产品、QA、开发一起制定分批提测 | ||
|
||
--- | ||
|
||
# 总结 | ||
|
||
读完这篇文章后,如果能使您: | ||
对现有的流程有自己的思考和理解, | ||
同时能激发你的积极性,即使只有一点、两点。 | ||
|
||
那么,便达到了这篇文章的目的。 | ||
**自我思考是工作中一个很重要的技巧。** | ||
|
||
by jiangren |