敏捷实践简单分享补充

一、体现产品价值—项目立项会
项目立项的价值和意义,不用说应该大家都能理解,对于研发是成本部门,我们希望把更多的资源和资金投入到有价值的事情上,带来更大的回报。作为公司会衡量诸多项目中,进行项目集管理和项目组合管理,合理的调配资源和资金。项目立项评审,让大家想清楚项目开展的要做的事项,对项目价值有更清晰的认识。
1.产品必要性及依据;
(1).产品的市场分析、竞品分析、市场潜力、前景和收益;
2.产品目标和研发内容;
(1).产品的定位、价值、技术储备、产品功能结构脑图;
3.产品主要交付路线图;
(1).产品用户故事地图、主要的交付路线、重大里程碑;
4.产品市场运营分析;
(1).产品运营方案、上线推广、运营活动、生产问题反馈机制;
5.产品投入产出分析;
(1).产品的成本预算、产品的营收和利润、投入产出比、市场风险评估;

二、达成团队共识—项目启动会
产品前景很诱人,项目立项成功,那么就开始干吧。在项目具体实施之前,还需要做最重要的一件事情,组织团队共识的项目启动会。团队需确保我们对项目开展有相对清晰的认识,对相关问题思考到位,才能保障项目相对平稳的开展。
1.产品愿景
(1).目的:主要是讲解产品的市场前景和项目的意义,让团队认识到我们努力工作的价值;
(2).如何:部门总监介绍产品的背景、前景和价值,让团队意识到该项目的重要性;
2.产品路线图
(1).目的:主要是讲解产品的主要交付路线,产品主要需求的优先级,以及大致上线时间点;
(2).如何:产品经理讲解产品交付路线,需求优先级,以及上线时间点;
3.项目总目标
(1).目的:主要是对产品路线的补充,对交付功能模块的细化,项目完结交付的所有功能点;
(2).如何:项目经理基于产品路线和需求进行模块拆解,澄清所有功能点;
4.项目里程碑
(1).目的:主要是对总目标功能点的里程碑设定,以及每个里程碑各个职能组完成的主要任务;
(2).如何:项目经理基于总目标和IPD流程,设定里程碑,明确相关交付产物和主要任务;
5.团队成员职责
(1).目的:主要是基于项目功能,明确团队成员和职责,让团队对每个人所负责有概念认识;
(2).如何:项目经理基于功能和IPD流程,明确团队成员和职责;
6.团队协作方式
(1).目的:主要是对项目开展的相关环节的必要说明,大家共同遵守的团队规则章程;
(2).如何:项目经理基于项目,明确团队共识的协作方式,前期可项目经理内定再讨论,后期可以团队决策;
7.项目测试计划
(1).目的:主要是对测试工作计划安排的清晰化,更好的协调安排测试人员,明确主要交付物;
(2).如何:项目经理基于里程碑和迭代交付节奏,安排测试计划和相关性能测试策略,确定每个阶段的事项和产出物;
8.项目风险管理
(1).目的:主要是对项目开展存在的风险,明确负责人以及应对方式,提前安排工作;
(2).如何:项目经理基于项目需求,提前分析存在的风险问题,团队也可提出风险供分析讨论;

项目管理的精髓是预防大于管制,凡事预则立不预则废。
做好各项计划安排和共识决议,提前分析思考可能的风险,明确责任人和应对方式,莫要变成救火队长,项目经理会觉得很累,团队会觉着项目很混乱,很多事情难以开展或开展缓慢。

三、提升研发效率—管理工具
一个团队共识的启动会组织成功,那是不是我们就可以很放手的开始干了。为了确保共识计划得到落地执行,团队保持高效交付,那么就需要借助一些研发管理工具,辅助我们进行项目开展实施。
1.项目管理工具
(1).目的:主要是高效的管理产品需求、项目任务、测试Bug,可以支持报表数据统计分析;
(2).如何:将产品需求、项目任务、测试Bug以及其他事项都及时录入到项目管理工具,持续跟进、督促、检查;
(3).例如:迭代开始前产品经理将梳理的细化需求录入项目管理工具,项目经理将拆解的任务录入项目管理工具,及时催促跟进;任务计划时间尽可能早于真实计划时间,让大家尽快及时交付;争取将所有事务录入项目管理工具,包括未被考虑的事情,让团队自己给自己建任务。
2.项目看板
(1).目的:主要是将团队的任务进度和风险暴露,直观清晰的看到团队的现状和瓶颈,及时处理解决;
(2).如何:根据项目和团队实际情况设计看板内容,需求用绿卡流动、任务用蓝卡流动、Bug用红卡流动;
(3).例如:针对团队情况,定制了看板内容,进行相关事项的暴露和跟进,所有事项都已卡片方式呈现。
3.项目迭代日历
(1).目的:主要是确保项目按计划清晰的实施,一些关键的工作事项开展的工作提醒,确保任务提前开展;
(2).如何:根据项目和团队实际情况设计迭代日历,可以使用Foxmai的日历功能,将关键事项计划维护好,提前提醒开展;
(3).例如:设计优化迭代日历,把项目迭代相关会议和关键事项进行计划安排,以便提前开展,做好充分准备;
4.项目每日立会
(1).目的:主要是向团队成员告知个人任务进度和安排,以及需要支持的相关事项,及时暴露风险和问题;
(2).如何:根据项目和团队实际情况设计每日站立会,向团队昨天做了什么、今天要做什么、碰到什么问题和需要什么支持;
(3).例如:已改为团队成员轮值主持站立会,团队成员讲述昨天做了什么、今天要做什么、碰到的问题和需要的支持;
5.项目开展周报
(1).目的:主要是确保团队对项目现状有清晰的认识,对项目本周工作完成情况和下周工作安排计划;
(2).如何:根据项目和团队情况设计周报,大致包括总目标、里程碑、协作方式、本周完成情况、下周计划安排、问题风险解决方式;
(3).例如:每周发布周报,发送项目团队成员,澄清总目标、里程碑、协作方式,本周各职能组完成情况,下周各职能组任务安排,本周碰到的风险问题以及应对措施,可作为项目的经验总结,以便后续提前处理。
6.项目风险管理
(1).目的:主要是对项目开展的风险和关键事项进行管理,包括已知、未知,及时登记、及时跟进、及时处理;
(2).如何:将每日站立会暴露的问题和支持事项,项目开展的关键事项,明确责任人、截止日期、处理进度、完成情况等。
(3).例如:通过Excel将站立会或日常沟通需要协助解决的问题,登记跟踪,也可使用项目管理工具。
7.项目迭代交付产物
(1).目的:主要是根据团队迭代交付节奏,明确迭代交付功能和主要输出产物,使团队对项目有整体的认识;
(2).如何:由产品经理或项目经理,根据功能交付优先级梳理迭代交付功能、主要开展事项、主要交付产物;
(3).例如:根据项目里程碑梳理团队迭代交付物,包括迭代交付的功能、关键事项、相关产物;

曾经听说过一句经典的话,项目经理的时间就是项目的时间,一定要做好和加强时间管理。
不知道这句话是否正确,但还可有几分坚持,这7个工具可以很好的提醒、督促、辅助我们落地美好计划,让团队管理更加透明,让项目实施更加具体、让项目风险更加可预期。

四、加速交付节奏—敏捷迭代
有了研发工具的辅助,在项目实际开展中采用敏捷迭代开发,将加速团队功能交付,保持团队平稳的交付节奏,后续可评估团队的能力。
通常敏捷开发,项目迭代周期根据项目周期设定,项目周期小于1个月,以1周为1个迭代;项目周期大于1个月,以2周或1个月为1个迭代。
1.迭代规划会
(1).目的:主要是对本迭代交付的功能进行需求讲解,让UI设计、开发、测试对需求理解到位,确保开发正确的产品;
(2).如何:迭代开始前,明确要交付的需求,进行需求细化,需求相关工作项拆解分工;在会上进行需求宣讲、工作项分工安排;
(3).例如:对该迭代交付的功能,在迭代开始前产品经理完善好相关原型和项目管理工具需求录入,项目经理拆解为工作项,UI设计可优先开始界面设计;在迭代会议上讲解产品原型、项目管理工具需求、部分UI界面,对需求模糊或UI交互不对的提出修改,确保团队对需求理解到位。
2.迭代内相关评审
(1).目的:主要是对本迭代交付的功能,一些核心技术问题和重大风险点进行评审,集体决策,共同决议;
(2).如何:UI设计评审、架构设计评审、数据库设计评审、接口设计评审、核心解决方案评审、测试用例评审等等;
(3).例如:在必要时组织相关产物的评审,前期数据库和后台接口设计评审,中期对测试用例评审,后期对UI改版设计评审。评审简版就是团队成员私下一起讨论定方案,项目经理要督促跟进影响。
3.迭代内测试验收
(1).目的:主要是对本迭代交付的功能进行验证,进行冒烟测试、功能测试、回归验证、产品经理验收;
(2).如何:需求提测发邮件通知,本迭代进行冒烟测试,上迭代进行功能测试和回归验证,产品经理终验(或迭代评审会);
(3).例如:迭代功能提测发提测邮件,告知哪些功能可以测试验证,本迭代进行冒烟测试验证,上迭代进行回归验证。可以项目组自己把握发布测试的频率,可能紧急发布,也可能保持节奏发布(两周一发布),建议保持一定的节奏发布,这样团队节奏感更好些。
4.迭代内回顾会
(1).目的:主要是对本迭代工作开展的复盘,反思总结哪些做的好的、哪些做的不好、确定改进改善事项;
(2).如何:给每个人话语权,不记名开放写出本迭代工作开展做的好的、不好的,可以使个人、团队、公司,最后确定5条改进事项;
(3).例如:每人分别用绿色和红色便利贴,写1条做的好的和不好的,项目经理读给大家并归类,确定5条改进事项在后面迭代改善。项目经理也可再加上,你在整个迭代中看到的、要和大家分享的事情,认可团队的付出和成绩,罗列风险和不足,下一迭代的简单计划。
5.项目部署上线
(1).目的:主要是对项目部署上线提前做充足的准备,确保按计划进度上线,用户体验灰度发布;
(2).如何:提前准备生产环境,梳理相关配置,准备程序部署包,查找依赖和冲突,明确可能的风险和应对等等;
(3).例如:细化产品发布版本管理,提前准备部署程序包,明确部署方案和步骤,分析可能的风险和问题;
6.项目结项总结
(1).目的:主要是分析总结项目经验为以后项目开展提供借鉴,认可和激励团队;
(2).如何:展示项目成果以及开展过程、告知项目成效、认可和激励团队、分析总结项目经验;
(3).例如:将项目所有的产出物说明,回顾项目开展过程,大家在对应节点完成的任务,进行项目整体的感受和分享交流;
7.项目产品运营
(1).目的:主要是项目上线后产品试运行、产品运营推广,确保产品真正的运用起来;
(2).如何:上线问题解决跟进、产品反馈收集、产品体验改进、产品运营推广;
(3).例如:细化产品运营方案,配合市场的一些方案,产品相关问题的跟进反馈机制确定;

这些会议多取自敏捷Scrum模式的会议,项目经理需要根据项目需求进行裁剪,由项目经理把握。
因为会议太多,太浪费大家的时间,对项目工作进展没有太多实质性的帮助,所以根据项目情况裁剪调整。
例如:我们项目组,迭代规划会必开,因为要宣讲需求;迭代回顾会,一个月组织一次;迭代评审会,根据项目需要组织。
还需知道,高效利用团队,减少浪费和等待,项目中各个职能组是可以并行开展工作的,只是有些工作要尽可能提前。
例如:我们项目组,在迭代规划会后,根据宣讲的需求,UI进行界面细化和调整,前端进行界面搭建,后端进行接口设计,测试进行测试用例编写;继续开展,前端根据UI调整后的设计图修正前端界面,根据后台的接口调试相关功能,测试再根据提测的功能进行相关测试工作。

五、打造高效团队—领导方式
打造的团队:执行力强,任务下达,排出困难去解决;凝聚力强,没有旁观者、推诿者,共担解决;能力强,独挡一面,人人都是神枪手。
1.服务团队
(1).如何:对团队提出的各种需要支持的事务,跟进及时处理解决,为团队工作开展扫除障碍;
(2).解决:领导只是排计划,紧急催促,却对团队项目开展没有任何实质性帮助,对项目放任大撒手。
2.引领团队
(1).如何:清晰目标方向,告知团队相关事项的开展,更加条理的督促团队及时完成对应的任务;
(2).解决:在项目开展中,团队会出现迷茫,不知道还有哪些事情要去处理,不知道下一步工作如何开展。
3.守护团队
(1).如何:保护团队免受打扰,保持团队专注,减少任务切换的浪费和低效;
(2).解决:团队成员工作总是被打断,不能专心工作,思路拉回也需要时间,还可能产生很多Bug;
4.放手团队
(1).如何:充分信任团队能力,不与团队争论技术细节,相信团队有能力把事情做到最棒;
(2).解决:干涉团队工作细节太多,形成干扰,把握主线不偏离,不必要的小细节不纠结,也可解放项目经理。
5.锻炼团队
(1).如何:授权团队培养独立协调资源解决问题能力,搞不定及时上报,项目经理要定期督促询问;
(2).解决:团队独立解决问题能力较弱,很多问题让项目经理去解决,对项目经理依赖性太强,团队战斗力不足。
6.激励团队
(1).如何:认可团队成果,及时给予认同,鼓励团队成员,我们是最棒的团队组合;
(2).解决:团队对项目的认可感,对团队的归属感,对个人价值的体现,看到自我的成长和亮点,形成自我发掘。

标注:承接前一篇博客《敏捷实践简单分享

时间: 2024-11-07 19:18:38

敏捷实践简单分享补充的相关文章

敏捷实践简单分享

一.项目启动会 无论是传统项目管理还是敏捷项目管理,项目启动会是让团队成员对整个项目全局的认识,尽管在项目实际开展中一些共识可能会调整.俗话说,好的开端是成功的一半,一个好的项目启动会决定着项目的成败.既然项目启动会如此重要,那么我们在项目开启动会的时候,重点澄清哪些内容?大致包括下面8点,由领导阐述产品愿景并授权项目经理,由产品经理阐述产品路线图,由项目经理阐述剩余相关点,团队必须对这8点达成共识.如有争议,及时提出调整,当然,项目开展中项目经理也会根据项目实际情况进行相关内容的调整. 1.产

敏捷实践(3)-用户故事

用户故事如何划分?如何落实到工作中? 用户故事的INVEST原则我是非常赞成的.(搜索了一个相关的说明,http://duweizhong.blogbus.com/logs/112151436.html) 但是要做到INVEST,实际上还是很不容易的.我接触到的常见问题是 1.不知道如何划分,无从下手 2.不知道划分的是否合适,是否满足INVEST原则 3.划分好后,如何跟踪story的进度 实际上这也是我刚接触敏捷时遇到的问题,这些问题,我个人的体会是"按照一些优秀实践的分享,自己亲自参与并实

Scrum 敏捷实践中的三大角色

在我过去的近两年工作中,我们一直在应用 Scrum 敏捷项目管理方法来开展工作,今天,我先从它的角色划分来讲起,毕竟这可是它最鲜明的特征. 首先,为什么这种项目管理方法叫 Scrum ? Scrum 是一个引申词,原义是橄榄球场上的并列争球.橄榄球号称是美国的国球,受关注度最高,我们经常听到的超级碗 Super Bowl(/b??l/)就是它的年度冠军赛. 就像橄榄球运动极度强调团队协作一样,它是用于开发和交付软件产品的一个框架,且过程是增量和迭代的. 好,我们回到 Scrum 的角色划分. 基

敏捷开发学习分享

程序员都很懒,你懂的! 敏捷不是快,而是拥抱变化(不断反馈的一个过程). 简单的说,敏捷开发是一种以人为核心.迭代.循序渐进的开发方法.在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征.换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态. 敏捷原则:主张简单,拥抱变化,可持续性,快速反馈,轻装前进. 敏捷思维:让开发过程轻量化(我们不是软件工厂).经验性过程更适合软件项目,需求是涌现式的

上海交大7月7日《敏捷实践之葵花宝典》主题沙龙,约不?

葵花宝典,喜欢武侠的人应该都听说过?但是你知道吗?敏捷实践也可以提炼出一本葵花宝典,上海交大7月7日<敏捷实践之葵花宝典>主题沙龙 看上去挺有意思的,约不? [沙龙背景]敏捷,作为整个项目管理知识体系中的一种思维模式,正在通过其独特的方式改变着今天的项目管理做法.在过去20年,敏捷项目管理用事实证明,在预测(瀑布)模式无法有效创造价值的时候,敏捷在复杂多变的环境中完美的补充了这个缺失.敏捷交付已经成为软件行业的主流,但是很多企业,尤其是传统企业,在采用敏捷的过程中,会遇到很多问题和障碍,导致敏

大众评审 | 最佳敏捷实践奖

为表彰携程敏捷团队取得的突出成绩,鼓励其不断追求技术卓越,为公司创造更大的价值,特设置最佳敏捷实践奖. 评奖面向携程技术全员,每次评选出1位最有价值PO:1位最有价值ScrumMaster:3支最优秀Scrum团队. 本奖项自2015H2起已经进行了8次评选,本次是第9次评选.截至上期,共计评选出21个优秀团队,16项优秀个人奖项:覆盖了机.酒.度.平台.网站运营.火车票.金融等十数个BU/SBU.评选活动包含自由申报.大众评审.现场答辩等环节,进行综合计分排名,由技术委员会确认并在年会上进行颁

敏捷实践总结系列开篇

对于一个组织来说,敏捷转型是否成功,有2点很重要:一是管理层的支持,二是文化的建立.上下合力,敏捷才能在组织中真正落地生根,自我改进,形成良性循环,否则很可能是一阵风来一阵风去,演变成劳民伤财的组织“运动”. 这几年,公司管理层对研发流程的敏捷转型越来越重视,支持力度越来越大,可以说敏捷转型走出了成功的第一步,如何在组织中建立起敏捷文化变得越来越重要. 现在市面上敏捷的书汗牛充栋,往往给大家造成一种误解:敏捷是流程,是理论.恰恰相反,敏捷是一种实践文化,敏捷讲究快速迭代,自我改进.敏捷转型不能停

用shareSDK实现的简单分享

第一步:将ShareSDK导入到你的工程中 然后需要在工程的AppDelegate.m中导入所需要的头文件 比如: #import <ShareSDK/ShareSDK.h> #import "WeiboApi.h" #import “WXApi.h" 第二步:在下面方法中添加如下代码 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictiona

移动团队交叉双迭代的敏捷实践

再快点!再多干点! 在这个移动互联网的时代,作为移动开发团队,对"快"这个字看得尤其重要.不仅仅是移动开发团队,其实每个开发团队都在注重团队效率,具体而言,就是关心开发效率和产出.管理者经常会发出这样的提问:还能更快的上线吗?还能增加每个迭代的产出吗? 影响团队效率的因素很多,且往往是综合作用的结果,仅针对更快速的产品上线和增加每个迭代的产出这两个问题,我们尝试对团队正在执行的敏捷迭代过程进行改进,即使用交叉的双迭代模型进行软件开发. 环环相扣的链条 先简述一下我们在传统迭代上的基本情