进行网站建设视频教程,网站建设初学者教程,比特币网站做任务,学校网站建设调查表近期因为疫情的影响#xff0c;不少互联网公司开始尝试远程工作。也出不了少如何做好远程工作的方法#xff0c;我认为不管是场地办公还是远程办公都依赖于原来的产品开发流程。我曾经遵循CMMI5的流程管理过15人左右的跨国/语言/文化团队#xff0c;也遵循敏捷Scrum管理过9人… 近期因为疫情的影响不少互联网公司开始尝试远程工作。也出不了少如何做好远程工作的方法我认为不管是场地办公还是远程办公都依赖于原来的产品开发流程。我曾经遵循CMMI5的流程管理过15人左右的跨国/语言/文化团队也遵循敏捷Scrum管理过9人的小团队还针对一个从4人发展到近30人的团队尝试过各种方式的项目管理方法这其中有2C和2B的产品也有平台/生态型产品。 最后在自己创立公司的5人小团队场地和远程办公融合方式中摸索出了我认为最适合中小企业产品开发流程与管理方法。今天我们聊聊产品开发流程与管理。我们通过对Scrum的改造利用Gitlab的issue对需求、开发和测试进行可视化管理。应该来说能够适应绝大多数的中小企业和团队当然再好的流程也会因不同的人来落地执行而产生不一样的效果。定义产品 首先我们要确定开发的是产品而非项目。产品和项目的区别是什么与此对应的另外一个问题是产品经理和项目经理的区别是什么 后面的问题我们不在此篇中讨论产品和项目的区别主要在两方面体现生存周期和目标。项目的生存周期比较短从启动、策划、执行、监控到收尾。验收交付给用户之后项目就结束了。而产品不存在结束的说法因为产品是不断更新的直到被新产品替代生存周期才结束。 项目的目标是在规定的时间内利用有限的资源高质量的完成某个特定用户的需求。而产品更多是为了满足一些用户的通过用需求。当然项目和产品之前存在很多的关联如果产品按迭代开发每个迭代有时候像极了一个项目。项目和产品有时候是协同发展的。中小公司团队我们这个流程更适合小公司和团队但是中型的公司如果资源比较紧张的时候也适用。小团队的特点通常是可能没有专职的UI设计或者比较少、没有专职测试人员 或者比较少。没有那么规范的管理流程有人身兼多职。所有该流程的目标是希望追求高效的团队产出同时兼顾产品的长期发展。敏捷开发流程对产品开发的影响产品开发成什么样是由产品经理设计的能不能满足用户的需求会不会给公司带来利润很大程度上都依赖于产品经理。俗话说把所有的宝都押在一个人身上是很危险的因为产品本身需要满足的是一群人的需求以及产品经理对需求的挖掘和理解各有差异敏捷开发很大的一个出发点是通过延迟设计和实现来规避这个风险。MVP最小可行性产品的思路来自于《精益创业 》 敏捷开发中“迭代iteration的思路跟MVP的思路基本一致我们在进行敏捷开发中很重要的环节不是你的流程执行的对不对而是迭代需求有没有拆分好否则不可能在用户那边过关。 这个重点环节需要Master和PO(Product Owner) 以及技术Leader一起来完成。不能按开发任务的整体性来安排迭代任务这里的标准是每一个迭代完成之后应该交付给用户完整可用的产品。对于2B特别是大B用户类的产品迭代周期可以长一些多预留一些测试时间待产品足够稳定之后再上线。UserStory需求优先级评估一个UserStory是一个完整的用户需求结合自身团队的情况以及需求的难易程度可以在每次迭代计划会议的时候来确定下个迭代要开发哪些UserStory。这其中团队需要对如何挑选UserStory有一个明确的定义。我们采用 KANO模型法基本型需求 期望型需求兴奋型需求 ) 满足核心业务的投入产出比最大的需求优先ROI最大化 组合评估。在KANO的基础上优先处理基本需求也可以称之为核需求在核心需求依然很多需要排序的时候采用核心需求投入产出比最大化原则进行排序 。P0-NP1-N, P2-N P0为基本核心需求P1为期望型需求P2为兴奋型需求N为ROI评估为1到5数字5的ROI最大得此组合6永远优先做P0-5的需求。ROI的评估大抵是以研发投入为成本用户价值和公司价值作为回报来评估。希望各位开发人员以后机智一点不要直接跟产品说这个需求做不了。而是问“你这个需求为用户带来了什么给公司带来了什么” 改良版ScrumFeature/UserStory- 用户需求(我们团队叫Feature是受历史遗留影响Task - 开发任务Bug - 缺陷 角色Master Product OwnerDeveloperTester角色职责 Master保证Scrum流程的正确执行以及以下会议的纪律 迭代计划会议每日站会迭代回顾会议 Product Owner清晰定义每一个UserStory确保 DevOwn以及测试对UserStory的正确理解定义UserStory优先级同步 UserStory文档及原型的变更 确保 UserStory 得到拆分以及执行Project Management项目管理验收 UserStory Dev作为Dev Owner 正确理解需求从技术和实现角度与PM沟通需求协助改进需求将UserStory拆分为Task 将开发代码的合并请求关联到Task Tester 正确理解需求从测试和用户体验角度与PM沟通需求协助改进需求 测试UserStory与Bug管理 验证Bug目标以企业能够承担得起的成本来做可持续发展用好文档重要的文档一定要有高效协作 可以用文档沟通的方式就不要开会 实用主义不要花太多时间写测试用例培养团队 在允许的范围内充分授权团队自己决策与执行TL与管理者应该更多地辅导。定义UserStory: 只是一句话的需求描述什么角色需要什么样的功能并不是详细的功能设计。架构方案设计: 指的是那些重大的框架性的调整需要有人专门设计和开发好之后其它开发人员才可以在此基础之上开发。属于基础建设之类的比如开发框架消息队列处理之类的通用组件和功能。TL要评估这个事情能不做的就留着给DevOwner去做TL进行辅导。产品原型只包含本迭代内的UserStory的详细设计测试用例并不是非常详细的测试用例更像是check listDevOwner: 每一个UserStory会分配一个DevOwner通常是自己主动承担的会比Dev多一些项目管理的职责。可以培训开发人员的项目管理能力但是需要Leader或者Manager来给予辅导 。主要流程PO 定义UserStory 放入Catelog 需求池只有有这个想法了或者用户提出来了就放到需求池。提前一个迭代对UserStory 进行排序计划下一个迭代的UserStory。开发测试在做本迭代开发任务的时候 产品经理进行下一个迭代的产品详细设计产品的详细设计出来之后直接将文档发给整个团队进行线下阅读。TL和测试分别进行技术架构方案和测试用例的编写。技术方案和测试用例的评审可以是通过文档线下来进行不需要开会产品原型的评审也是可以由线下进行不开会。组织迭代计划会议可以提产品原型中的问题。给每个UserStory分配好DevOwnerDevOwner线下拆分TaskTL离线异步评审Tester 测试UserStory填写bug Dev 修复 bug 进入Bug管理流程必须要开的会议只有一个迭代规划会议、每日站会、迭代回顾会议。其它的会议尽量通过文档的形式离线解决。与主流Scrum的主要差异 需求UserStory的StoryPoint由技术Leader一个人给出即可主要用来大致评估成本开发的Task是由开发人员自己按小时评估工时。(Scrum建议都按StoryPoint来估给UserStory 排优先级的时候不需要团队所有人员参与多数情况是产品经理和技术Leader决定就可以了 Scrum建议团队所有人员在估算会议一起参加 添加了产品详细设计与测试用例设计和评审的过程优先鼓励通过文档异步的方式来评审评审/演示会议由产品经理示情况进行线下验收还是在会议上由开发自己来演示 用gitlab issue来做可视化管理 单独对Bug管理的流程进行了补充定义 可视化管理敏捷开发中非常强调公开、透明、直接有效的沟通这也是“白板”在敏捷开发中如此重要的原因之一。通过“白板”让所有人直观的看到所有任务的状态、问题、以及任务之间的流动 。当然用白板和便利贴来管理任务会更有趣但不是每个团队都能玩好。工具是给人用的只要抓住背后的核心诉求大多数的工具都能达到效果。我之前用的是Teambition来做的可视化管理现在的公司使用Gitlab Issue功能它跟开发的代码评审结合的更紧密所以我利用issue管理的功能和它的BoardMilesontes和 Labels功能结合起来就可以很好的对UserStoryTask和Bug来进行管理 。以下我们创建UserStoryTaskBug在Gitlab里面都是issue只是我们打上了不同的标签。 需求池单独新建一个需求池的Board把所有包含Feature(UserStory) 的标签列出来。这里Doing就当前迭代的需求ToDo是下个迭代的需求。Open是所有待完成的需求。 UserStory需求由产品经理创建之后将相关的一些文档和原型地址都全部汇总到描述中如果需求有变更需要同步更新。在迭代会议的时候指定开发负责人DevOwner由DevOwner对需求进行进一步的详细分析之后拆分任务并创建Related Issue并指派具体的开发人员Task开发的任务中关联了对应的UserStory和相关的代码commit、merge request等。通过开发任务就可以直接找到与这个任务相关的代码。燃尽图Scrum在给所有的task打上StoryPoint之后根据每天剩余未完成任务StoryPoint的总和绘制图表就得到了燃尽图。理想的燃尽图应该是像下图中的虚线那样规律性的下降直到0所有任务开发完成通过这个图就可以看到在这个迭代内任务被关闭的情况用来分析开发团队的实际产出。Bug缺陷管理 传统的开发-测试流程造成了很多问题开发写完代码之后对自己的任务甚至不做基本的检测就丢给测试。测试也没有精力去做一些自动化的工作。中间测试-开发还常常出现推诿反复的情况。 开发也没有机会去加强自己的测试sense和技能。最后只能造成双输的局面。理想丰满现实骨感Scrum以及敏捷开发提出来依靠测试驱动自动化单元测试、集成测试来达到内建质量的提倡当然是非常好的。但是国内大多数中小团队都达到不这样的条件这样做。我们只能退而求其次在满足用户要求的产品质量的基础之后逐渐培养开发人员的测试能力以及测试人员自动化脚本能力。建立和持续改进机制我们现在10个人的团队中有一个测试人员来建立和巩固基础测试流程、维护通用测试用例、 对开发人员对于测试技能培训、 以及进行迭代bug回顾和观测来达到持续改进的目的。基础测试流程基础测试流程与传统的测试流程大致相同这里主要的变化是将测试用例写的足够简单以便于让开发理解和快速校验。我们在开发提交功能给测试之前需要自己先走一遍测试之前提供的该功能的用例确保每一项是通过的。 保证你写的代码能运行正常是每一个负责任程序员的基本素质。 测试人员从一开始就深度参与到这个迭代开发的每一个环节加上对于开发任务的可视化管理。测试在打开bug的时候直接assign给对应的开发人员。不需要leader再额外的approval。标签管理以下是在gitlab labels中额外添加的一些标签用来在后面迭代回顾的时候更好地统计bug进行质量改进分析。Priority 优先级 HighMediumLowSeverity 严重级别 Critical 致命Major 高Minor 中 Low 低Resolutions 关闭原因Fixed 最后确认是bug并且修复了Deferred 是bug但是延期再修复 Duuplicate 重复了As Designed 设计就是这样不是我的锅 Cannot Reproduce 不能重现 这些标签可以可通过gitlab 的scoped标签父标签::子标签的形式来管理比如Priority::High, Prioirty::Medium, Priority::Low。测试用例我们的测试用例与标准的测试用例有很大的区别基本上我们是不写测试步骤的。只写简单的用例描述和预期结果当然这个预期结果会尽量包含所有的分支。开发人员需要在提交测试之前自己确保这些功能都是正常的否则我们会定义为严重的不负责任。Bug回顾 没有回顾就没有持续的改进 。在每一个迭代结束之后我们都要将这个迭代产生的bug进行统计汇总、团队一起分析并与之前的迭代bug统计进行对比。gitlab没有比较方便的统计图表功能所以我们会把有bugs标签的issue导出到excel再进行分析。按严重级别进行汇总按人员进行汇总按关闭原因进行汇总常见问题总结通过加强开发自测试和建立持续改进机制我们逐渐让测试人员有一些时间从质量管理更宏观的层面去做改进也让测试有一些时间去建立自动化体系。结语流程只是整个产品开发管理中很小的一部分。流程为人服务而不应该是徒添负担。 除了流程我们还需要建立完善的团队奖惩机制、员工培训和晋升机制整个团队才会有活力。由于篇符有限可能有些地方会有遗漏还请各位海涵图书推荐如果大家想对Scrum和敏捷开发有更多的了解有兴趣的同学可以看看下面两本书。我在上篇文章说建议大家多学一些除了代码之外的东西。我是个说到做到的人。
