作者:叶朝萍 [1499392921893_7114_1499392923068.png] 背景 在近几年比较火的敏捷开发大背景下,我们的项目团队的需求管理,也一直在探寻着敏捷开发的轻量化管理的原则 下面就来谈谈,咱们浏览器项目需求管理那些事 ~ 需求管理1.0 时代 --- FT 自管理+excel 规划表 我们知道,敏捷价值观中有一个是关于文档的,认为: [1499393074848_4910 我们的项目需求管理1.0 时代,就是用excel 列表的方式来轻量化去管理需求,通过项目群来同步版本需求规划。 [1499393465904_7859_1499393466807.png] 项目需求管理2.0时代 --- TAPD集中管理+需求评审 1、 需求的工具化管理:变excel的人工维护,为TAPD集中管理方式 当然,敏捷项目需求管理的方法,我们仍在不断总结和迭代优化中,希望大家也一起来多探讨更好的管理模式,期待更优的需求管理4.0 时代的到来!
理论上Issue管理员和开发人员都可以进行创建,什么样的Issue可以有开发人员来创建? 现在团队的管理方式有了些调整,也可以顺便解答下上面的几个问题。 在上篇《敏捷,每个人都有自己的理解》中提及到了团队现在在使用腾讯的Tapd,虽然是阉割版,但也够用。下面说说落地后的需求管理方法和分支使用的调整。 分支管理 现在的任务管理模式和之前Merge Request最大的区别是,现在是以需求为导向,而之前是以任务为导向。 管理员负责在Tapd中进行需求、迭代的管理,需求负责人负责Gitlab上的操作,并通知该需求的参与人员应该使用哪个分支进行开发,最终由管理员进行代码的合并。 总结 对于敏捷,每个团队有自己的理解和实践,可以个性化,但一定要在敏捷原则的指引下前行,下面是敏捷开发宣言提出的十二条原则: 1、通过早期和持续交付有价值的软件,实现客户满意度。
敏捷使用产品Backlog来管理需求,产品Backlog是一个需求的清单,按照需求的商业价值排序, 高优先级的需求在Backlog的最上层。 Leangoo领歌是一款专业的敏捷开发管理工具,它覆盖了敏捷项目研发全流程,包括小型团队敏捷开发,规模化敏捷SAFe,Scrum of Scrums大规模敏捷。 提供端到端敏捷研发管理解决方案,涵盖敏捷需求管理、任务协同、进展跟踪、统计度量等。我们可以通过Leangoo领歌敏捷工具来管理敏捷需求。 如何使用免费的Leangoo领歌敏捷工具做敏捷需求管理首先注册登录Leangoo系统,新建一个Scrum敏捷开发项目,在项目内新建一个产品Backlog看板,填写好看板名称,如下图:图片需求看板创建完成后 图片通过上述的方式,我们就可以很好的管理敏捷需求了。
为了协助大家找到合适的需求管理工具,我们选择了国内外几款款工具作比对:Leangoo领歌敏捷工具Jama SoftwareVisure RequirementsIBM DOORS NextReqSuite SAFe敏捷工具,敏捷项目管理,敏捷研发工具)Leangoo领歌是一款专业的敏捷开发管理工具,提供端到端敏捷研发管理解决方案,涵盖敏捷需求管理、任务协同、缺陷管理、进展跟踪、统计度量等。 其主要功能/解决问题的价值包括:1)能够支持多种场景,如:敏捷研发管理、敏捷项目管理、工作流管理、轻量级项目群管理、任务管理等。 /Excel的紧密集成、风险管理、测试管理、错误跟踪、需求测试、需求质量分析、需求版本控制和基线、强大的报告和ISO 26262、IEC 62304的标准合规模板,IEC 61508、CENELEC 50128 Visure 是一种易于使用且全面的需求管理工具。 它集成了同一环境中的其他流程,例如风险管理、测试管理、问题和缺陷跟踪以及变更管理。比较可惜的是不支持在国内使用。
在敏捷开发中,需求变更是常见的挑战之一,尤其是在面对快速变化的市场需求和客户反馈时。 尽管敏捷方法强调灵活性和应对变化的能力,但频繁的需求变更可能导致项目进度受阻、团队士气下降以及资源浪费等问题。 对于需求变更带来的影响,团队可以深入分析根本原因,并讨论如何改进需求管理和变更响应的策略。 4、敏捷合同和客户管理 对于涉及客户或外部供应商的敏捷开发项目,合同中应当明确需求变更的管理流程和条款。 例如,可以设置一个基于时间的调整机制,使得频繁的需求变更能在不影响项目整体进度的前提下得到管理。 在项目初期就要明确客户对项目的期望,并与客户共同商定项目的可交付成果和需求的优先级。 频繁的需求变更有可能导致代码和架构的臃肿,因此团队需要在开发过程中留意技术债务的积累。 定期的代码重构和技术债务管理可以确保项目的长期健康,避免因为频繁调整导致代码质量下降或难以维护。 8、应对需求变更的工具和技术 使用现代的需求管理工具(如JIRA、Trello、Azure DevOps等)可以帮助敏捷团队清晰追踪需求变更的来源、优先级以及状态。
敏捷项目管理与敏捷宣言 说到敏捷项目管理就不得不提到那十分出名的敏捷宣言。这篇文章我们就来简单地了解一下敏捷项目管理的出现和敏捷宣言说的是什么。不要有太多的压力哦,这篇文章还是非常轻松的。 传统项目管理 对于传统项目管理和敏捷项目管理的不同,我们可以列一个非常大的表出来,不过,这样列出来其实挺没意思的。 到最后我们学习完了敏捷相关的知识后,大家可以自己再回过头来想一想敏捷和传统项目管理的区别和联系都有哪些,这样对大家知识的掌握才更有好处。 VCUA时代 在敏捷中,有句名言:唯一不变的就是变化。这句话非常有意思,只有变化本身是我们这个世界上唯一不会发生变化的东西。要搞明白这个事情,我们还是再看下传统项目管理和软件开发中的问题。 总结 今天这篇文章我们从传统的项目管理说起,通过 VUCA时代 这样一个时代现象来引出敏捷出现的必要性,最后介绍了敏捷的灵魂:敏捷宣言。当然,敏捷宣言很简单,就四句话,也可以概括成四个词。
针对微服务平台在需求管理上所面临的严峻的挑战, 建议微服务平台在需求管理上, 应遵循下列的原则: 1. 因此, 市场、产品管理的负责人, 微服务平台的架构师, 应负起责任; 从产品市场与微服务平台架构的面向, 制订微服务平台需求管理的规则。 2. 微服务平台在需求管理决策上所需的面向 (纬度) , 应要能尽量的精简; 简单而不简化。以使微服务平台的需求管理决策, 能高效且精准的完成。 基于微服务平台在需求管理上的原则, 微服务平台在需求管理上的作法, 建议如下: 1. 市场、产品管理的负责人在每个版本, 需制订各类产品的重要性权重。 微服务平台需求分析人员, 再运用微服务产品级敏捷中的 “场景分析” 的工程实践, 与微服务平台的骨干人员, 举行 “价值业务场景切片” Workshop; 识别各类产品需求中 “有价值” 的 “业务场景切片
早期,针对敏捷开发的实践,让大多技术管理者尝到了甜头,不再拘泥于三月两月一次发版,有些创新类研发项目已经可以做到一月半月乃至以周为单位进行投产。 从研发生命周期管理来看,开发侧有敏捷开发,测试侧有自动化测试,投产侧有一键部署能力,运维侧有自动化运维,也就最前面的需求侧能力还未提升。 而敏捷需求采用敏捷建模方法,可以很好地把研发链路上各个角色都统一在敏捷建模上面,以原型为抓手,兼容流程、规则、数据等模型,以及需求全过程管理中的缺陷/问题/解决方案、进度/评审/验收、讨论/评论/评价等一站式一体化呈现 ,大大提高了需求的质量管理、审批管理、资产管理等能力。 、需求质量等需求管理一站式服务,提供需求结构化、组件化等需求资产一体化运营,是构建敏捷需求体系大航船在蓝海敏捷航行的整体框架。
瀑布和RUP 强调结构化方法与重型的管理策略,往往在内心中拒绝变更,把变更作为被管理甚至被“管制”的对象;而为了尽可能避免变更,常常要求开发之前的需求获取、分析与定义要完整无误且精确。 、测试人员,其他相关的角色有项目管理者等。 这些文档除表明需求本身外,更多地是一种管理控制的角色,比如,对于变更。 敏捷过程并不是由文档主导、支撑和控制变更。 3.5 综合以上的陈述,对敏捷需求分析归纳如下表 (角色职责的变化也是一种重要的对比,请参见表1,此处不赘言) 角度 传统需求分析 敏捷需求分析 需求分析时机 更多地集中在项目早期 近乎均匀地贯穿于项目的整个生命周期 更多强调通过自动化功能测试用例来跟踪系统需求。(对于组织过程资产管理要求,可以在此基础上形成可阅读可理解的轻型文档)。
引言:敏捷绝非某一种特定的开发方法,它只是一种应对快速变化的需求的一种软件开发能力。敏捷本身只包含了《敏捷软件开发宣言》和《敏捷软件的十二条原则》两份文档。 敏捷的起源: 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 这样的项目管理很混乱。 敏捷开发流程是一个标准的项目管理流程,是不能适用于所有的公司,但是适用大部分的公司,公司根据标准化流程去进行优化,不管是新增还是减少,只要适用于自己的公司那就是贵公司的敏捷流程。 ,但是这样利于项目管理,一个团队共同为一个目标去奋斗。
需求文档和敏捷中的Epic,User Story, Task之间是什么关系以及如何将需求文档转换成敏捷方式的描述,指导开发人员。 商铺管理场景 建店申请 提交申请 查询所有申请 查看单个申请 。。。。。。 ------------------------------------------------------------------------ 一、如何将需求文档的内容转化成敏捷中的术语 上面这种格式文档对于敏捷开发团队来说可能是比较生疏的 那么需求改如何变成敏捷术语中的Business Epic,Feature,User Story和Task呢? 基于常规的敏捷框架,SAFe 定义了一个可扩展的敏捷框架模型,它适用于大型团队的合作开发,可以帮助提高团队之间的协作性,降低团队管理的复杂性。
二、Scrum实施过程中常用的5大Scrum管理工具/软件 敏捷开发中非常强调公开、透明、直接有效的沟通,这也是“可视化的管理工具”在敏捷开发中如此重要的原因之一。 通过“可视化的管理工具”让所有人直观的看到所有需求池、UserStory、Task、燃尽图和Bug的状态及之间的流动。为使团队成员快速适应敏捷开发流程,将流程标准固化到可视化的管理工具。 这里分享国内外的5款顶级敏捷开发管理工具。 1、国内顶级 Scrum 管理工具PingCode 这是国内最好用的敏捷开发Scrum工具之一,曾在2021年获得由36氪发布的研发项目管理榜TOP1,被广泛用于敏捷开发项目管理。 在Scrum 项目管理方面具备如下能力: 需求管理:史诗/特性/用户故事三级体系,根据优先级、故事点形成待办列表 产品规划:根据产品目标及项目需求排期,有序规划产品路线图、迭代和版本 迭代管理:将需求和
在快速发展的软件行业,需求变更几乎已成为常态。尤其在敏捷开发模式下,业务方会根据市场反馈、用户数据和竞争态势不断调整优先级与功能细节。 本文将系统探讨敏捷测试应对需求变更的方法论,从流程设计、自动化实践、团队协作及智能化手段四个维度展开,旨在为测试团队提供可落地的策略与启发。 “活文档”管理采用Wiki或轻量化文档平台,将测试用例、检查清单等以模块化、可复用形式组织;配合版本控制和变更记录,保持文档与代码、需求同步。 七、总结在敏捷高频迭代环境中,需求变更不可避免,而测试的使命是为变更保驾护航。 未来,随着智能化技术的深入应用,敏捷测试将进一步迈向“自适应”、“自优化”的新时代,成为持续交付的坚实保障。
对团队或企业来说,敏捷能够通过快速迭代、改进来更好地为客户或终端用户交付价值。但有些团队在引入敏捷项目管理模式之后,团队管理层看了看埋头工作的团队,“唉? 实际上,产品的增值过程是分布在从需求到设计、研发、测试、运维等多个阶段中的,而不是仅在某一个阶段中存在。 二、怎样进行价值流管理?在敏捷项目中,我们应该如何减少浪费,实现利益最大化?这个问题的关键在于“价值的流动”。价值流管理是敏捷中的一个十分重要的实践,更是团队在持续改进、优化过程中的一项基本工作。 进行广告需求分析,用时1天;设计创意方案,用时2天;等待小组评审方案,用时1天;等待创意总监评审方案,用时2天;等待方案拍摄启动,用时1天;开始广告拍摄,用时4天;进行广告剪辑,用时3天;等待小组评审广告视频 所以通过价值流管理,我们可以度量实际的价值流动效率,并提出改进目标,来推动整个项目管理过程的持续改善。
风险管理 在 PMP 中,风险是一个重要的章节,并且有许多的过程,比如说我们要识别风险、进行定性定量分析、应对风险等,工具方面也有决策树、敏捷性分析等,最后还有一个风险应对和机会应对(PMP认为风险和机会是对应的 同时,在项目进行的过程中,也需要不断地管理风险,并追踪风险管理的成效。 对于风险管理这一块,其实我们可以借鉴 PMP 中的一些技术,比如说 风险概率矩阵 ,它就是根据风险的 等级 和可能出现的 概率 来制作的一张表。 这个东西其实有点偏财务和管理学方面的内容,在之前 【敏捷3.1】价值与价值驱动交付https://mp.weixin.qq.com/s/Dw763UK9Dy_jH8gYthBsZw 这篇文章中有提到过一点 风险的严重程度 其实呢,在敏捷中,风险管理其实是工作进度的一个驱动因素。因为团队会将高风险的活动移到迭代的早期,并将风险的缓解这些活动放入待开发项中。
敏捷项目管理架构 Release(发布,单位为月) Sprint(冲刺,单位为周) Issue(问题)类型 Epic( 史诗) Story( 用户故事) Task(任务) Bug(故障
第三课需求管理 1需求管理是什么 1.1需求挖掘:看四块,自己行业,总体趋势,未来方向,商业模式。最直接的需求一定来源于用户,用户访谈,用户反馈,调查问卷,社交平台。 1.2需求匹配:需求挖掘解决发现和确认需求问题,需求匹配解决要不要做的问题。 知彼:了解市场,了解用户,了解需求 知己:知道公司的资源是什么,公司的资源以及经济能不能够完成个人对业务的设计,公司处于什么样的一个阶段,身处所在的行业处于什么样的一个阶段 1.3需求排序 2行业阶段 3.需求收集的原则和方法 标签墙 用户意见渠道 奖励机制 原始需求的管理 归类 统计 用户反馈分类 需求列表–原始表格 意识:时间管理四象限 GTD工具 4.需求评估 4.1:KANO法
需求管理是项目管理的基石,根据我的经验,项目失败或者延期的原因十之八九都源于需求管理没做好。 需求划分方法因项目不同而不同,以软件类项目为例,需求分为9类: 流程性需求、 数据性需求、 接口性需求、 界面性需求、 权限性需求、 表单性需求、 报表性需求、 功能性需求、 非功能性需求。 其中非功能性需求指的是性能、吞吐量及批处理等。 需求计划 为了把控需求收集的进度,需求撰写计划中要安排几个检查点。 举个例子,假如需求撰写的排期是1个月,那么就可以设置3个检查点。 每到一个检查点,各个需求撰写人需将成果汇总到项目经理手里做review,根据review的意见或建议迅速调整或整改。 需求变更 需求变更控制简单的说就是控制需求尽量不要发生变化,但不绝对。 需求变更控制最简单的方法,就是提高变更的代价,比如通过制定需求变更的模板及很长的审批链条来控制变更的频率。如果需求变更没有代价,那么用户提需求的时候就容易草率,对项目管理百害而无一利。
一、已完成的故事点 在敏捷项目里面,更多的度量数据是故事点(Story Point),在每一个迭代周期开始之前,会让团队人员评估每个需求的故事点。 这就相当于是传统项目里面的评估工时(一个需求完成需要多少时间)。 迭代时长:从需求到团队手上开始,到部署完成所花的时间。 功能交付市场:从需求在需求池到部署完成所花的时间。 市场交付时间:从市场提出需求到部署完成所花的时间。 【Kevin聊敏捷】敏捷项目管理之Scrum三大支柱 08.【Kevin聊敏捷】敏捷项目管理之Scrum价值 07.【Kevin聊敏捷】敏捷项目管理之Scrum 06. 【Kevin聊敏捷】项目生命周期之预测型生命周期 02.【Kevin聊敏捷】项目管理的四种生命周期 01.【Kevin聊敏捷】传统项目管理VS敏捷项目管理对比-各模式的发展历程
前言 MOMO云敏捷项目管理,融合了敏捷、DevOps思想,打通了整个从需求、研发、测试、运维、运营的端到端敏捷。 在实践中通过运维自动化,将Scrum敏捷团队开发的产品快速上线,并通过及时的运营,反馈给敏捷团队进行方向调整。 准备阶段 选择一款合适的敏捷项目管理工具。我们使用JIRA做项目管理,创建Scrum流程项目,加入项目成员和创建好面板和泳道配置。 会议重点在于分析问题根因,并识别出管理、流程、技术、工具上可落地的改进点。而且这些问题都要求最近的一个迭代中,执行落地,以避免问题再次出现。 总结 敏捷需求管理是一种文化,在敏捷实践中,每一个团队都有自己的特质,可以根据实际情况选择适合自己的敏捷流程和实践,才能够达到高质高效开发协作模式。