2016-05-15 22:49:17 u014231523 阅读数 4059
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

一般产品人员进行过需求采集,分析,筛选后就会进行产品的设计。
在产品设计的过程中会产生PRD(Product Requirement Document 产品需求文档 ),如果是新产品或者在大公司一般还会有BRD ( Business Requirement Document 商业需求文档)和MRD (Market Requirement Document市场需求文档 )。
当写好PRD之后就会画出简单的线框图,在画好线框图后,为了后面更好的评估开发难度和开发时间,这时产品经理就会和开发经理和开发人员进行一次简单的会议,会议主要是介绍产品的功能点和交互。
这时开发人员进行给出开发难度,如果功能点太难以实现或者比较复杂且优先级不那么高的可能就会先实现主要功能(主要为了降低开发成本,看上线后用户的反应再进行深度开发同时也是为了把试错成本降低)。
没有问题后,产品就会让UI人员给出高保真原型图,同时开发人员进行开发。主要步骤如:

  1. 确定需求后,产品人员写PRD和线框图。
  2. 产品人员和开发人员进行讨论,评估开发难度和开发时间。(如果开发迭代时间固定,主要是评估难度)
  3. UI根据线框图和PRD设计出高保真原型图,同时开发人员进行开发,项目管理开始。
  4. 开发,测试,修改bug(开发中可能会出现需求更改的情况)
  5. 产品经理(项目经理)进项验收,没有问题上线。
    开发流程
    以前的开发大部分都是瀑布式开发,现在一把都采用敏捷开发。项目经理这个职位一般也是只有在稍大的公司会有,在创业的小公司一般有产品经理或者开发经理来担任。我们公司是由开发经理来担任开发进度管理,最后由产品经理验收。
    一般敏捷开发流程(每个公司的迭代周期不同,但大致流程相似。下面是两个星期一个迭代)如下:
    迭代

  6. 如果我们需要从第1周周一开始开发新的迭代(假定第5个迭代)。那么就要在上周的周三,产品人员和开发人员进行PRD评审,如有需要修改的地方进行修改。(第四个迭代开发持续中,UI按照优先级开始绘制已经确定需求的高保真图)

  7. 上周的周五产品进行修改后,再次和开发人员进行评审,确定没有需求没有大的变动。(UI设计持续,启动新的开发迭代(第5个迭代),进行上次迭代(第4个迭代)总结会议和新迭代开启会议),这时项目也会在进行拆分,比如按照epic-story-sprint-task的方式进行拆分。然后把这个迭代的任务拆分成各个小的task,然后进行人员分配。task的时间颗粒度一般不超过两天,分的太粗容易造成delay。task维护一般使用看板的形式,我们使用过的有Jira,kanbanflow,icafe等。(可以根据喜好使用,里面有相应的曲线图和燃尽图)
  8. 第一周周一上班,UI同学会给出一部分设计的好高保真图。这时服务端同学会根据安排好的优先级给出相应功能的接口文档。移动端的同学进行页面编码和设计。同时移动端同学会根据给出的接口文档先造一批假数据已备本地测试(如果有相应的接口测试工具会更好,我们是用的自己开发的接口测试沙箱,可以根据绑定的真假接口进行真假数据的测试)。同时,每天下班前都要有站会。站会主要说自己的三个问题:1.今天做了什么2.有什么问题3.明天做什么
  9. 开发持续进行,到第一周周四时,会先发个测试包,让测试人员进行测试。当然开发过程中也在不断测试。出现问题就进行修复,bug修复不再安排时间,不会在看板上建新的task来修复bug,开发任务继续。
  10. 到第二周的周三,要确保开发任务基本完成。然后发个测试包,进行测试。有bug进行修复。同时产品经理进行查看。同时和产品进行下的迭代(第6个迭代)的PRD评审。
  11. 到第二周的周五,再发个测试包,进行测试。有bug进行修复。产品经理验收。(没有问题,一般会在夜里凌晨1-2点上线。)上线后可能要安排人员进行值守,看有没有问题。同时周五还要和产品进行确认最终新的开发。同时开总结会议和新迭代启动会议,这两个会议也可能放在周一开。
    至此,一个迭代开发周期完成。
    注意:

    • 在开发的过程中,项目经理每天要通过看板或者询问开发人员的进度是不是符合原来的预订计划,如果出现delay现象,可能就要通过加班来把进度提上来。
    • 测试人员也要参与需求的评审,方便后面业务测试。
    • 开发人员要对自己写的代码负责人,写好后要进行代码review和自测,不能把没有测试的代码进行提交。
2019-08-16 01:05:19 seagal890 阅读数 39
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

[敏捷项目管理和敏捷开发] 开卷有益—推荐阅读书单

软件测试系列推荐阅读书单

序号 书名 作者 出版社
1 《敏捷实践指南 》项目管理协会 敏捷项目管理书

(美)Project Management Institute

电子工业出版社
2 《敏捷软件测试:测试人员与敏捷团队的实践指南》

(美)Lisa Crispin Janet Gregory  著

孙伟峰 崔康 译

清华大学出版社
3 《精益―敏捷项目管理:实现企业级敏捷(修订本)》(第3版) [美] Alan,Shalloway(艾伦.沙洛维),Guy,Beaver(盖伊.比弗),James ... 著,王雪露 译 电子工业出版社
4 《如何构建敏捷项目管理团队》ScrumMaster、敏捷教练与项目经理的实用指南 [美] [美] 丽萨·阿金斯 电子工业出版社
2016-06-22 19:28:58 diyal 阅读数 1748
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

敏捷开发需求管理

比较有用的资料文献(感谢作者分享):

敏捷开发模式中的需求规划
http://www.woshipm.com/discuss/277343.html

来一起聊聊产品工作中的优先级
http://www.woshipm.com/discuss/277343.html

敏捷开发模式中的需求实现
http://www.woshipm.com/pmd/34565.html

一、需求管理
PRD 实现的连续性问题->需求拆分的方式方法->需求变更处理
产品功能列表 Backlog(主题、描述、优先级、验收标准)
通常一个迭代的开始都是通过计划会议来开始的
PO 今日事今日毕

PRD:(Product Requirement Document,PRD)及产品需求文档。是产品项目概念化进入到图纸画阶段的主要的一个文档,其作用就是对MRD过程中的内容进行指标化和技术化,这个文档的质量好坏直接影响到研发部分是否能够明确产品的功能和性能。

当开发工程师不能高效完成开发的时候,产品经理要做哪些工作?
http://www.woshipm.com/pmd/273525.html
国内团队中一般都会碰到这种问题,提高自己才是王道。
如何提高:
1、促进开发工程师交流
一个人力量有限,几个人讨论方案很快就解决了。产品经理在这方面的能力,和平时大家说的沟通能力有点不一样了。
2、反推产品问题
这里主要是产品的逻辑,产品规划的UI、交互等。大方向扯一下也无妨,但是每个人的工作总要落实到功能和细节的,不然人人都谈理想、远景久没有落地的执行能力了。
3、反思自己
总结、总结、总结,自己多写东西。总结下近一周、一个月的工作中出现的问题,怎么解决的、解决的好不好、还有没有更好的方式?也可以总结下得失。不一定要长篇大论,总结行该要即可。

二、开发管理中一些问题的思考:
1、寻找问题
为什么开发工程师不能高效的完成开发。主要的原因可能有:产品逻辑不清晰,技术真的难实现,设计资源不充足,开发工程师个人能力问题,以及团队协作问题,等等。

2、定位问题
定位问题主要是确定问题的轻重缓急,也就是确定优先级。——小技巧——在确定产品核心价值后,与核心价值直接相关的问题,以及团队协作问题等。

3、沟通问题
定位结束后,沟通环节并不是相互推脱,而是大家就问题沟通。比如问题的原因、环节、步骤、涉及到的界面,功能,按钮,以及涉及到的部门和工作人员等。
沟通是为了更到的寻找解决方法,并且能够很好的总结经验。

4、解决方案
解决问题是根据问题产生的,有些问题需要当机立断,有些需要讨论后作出决定,有些需要较长时间讨论确定方案。
寻找解决方法的路上有一件事一定要明确,就是“Deadline 什么时候完成”。
过程步骤:讨论——确定——实现

5、验证
6、其它辅助

2019-12-28 20:28:39 A13438889891 阅读数 11
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师
  1. 我应该如何为大型开发小组做计划?
  2. 我应该采用多长的迭代周期?
  3. 我应该如何向管理层做进度汇报?
  4. 我如何确定用户故事的优先级?
  5. 我如何得到有关项目的全景?

    接下来通过对《AgileEstimating and Planning》的译著《敏捷软件开发实践-估算与计划》一书的阅读和梳理逐渐明确上述问题的解决之道。

博客的内容多数内容来源于该书,且作为读书笔记仅供参考。

2016-06-22 19:13:30 diyal 阅读数 3205
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师
纵观整个游戏开发周期,大部分时间都是在赶赶赶,赶开发进度,赶Bug进度,赶发布进度。搞得交投烂额,搞得最后大家筋疲力竭,最终商务、策划、boss都觉得开发不给力。所以我们有必要,也有义务去采取一些措施来管理我们的游戏开发周期,无限期的加班加点都是我们自己作出来的。首先作为管理者,我们需要清楚最近整个团队的进度,很多人喜欢使用各种各样的工具,但是我喜欢使用Excel来管理,高效便捷,这可能是在日立工作的习惯。当然认可高效管理能带来更好的产出效能,是这所有一切的基础。

通常团队中会有人员有如下特征:
1、不会思考、不会沟通、表达能力、书面表达能力极低。
2、只会按部就班工作、没有主见,喜欢被命令式安排工作。没有创造力,不能胜任高难度工作。
3、无组织无纪律,不适合团队工作。
4、拖沓,总想着推倒后面再处理,没有时间观念。
5、过度自信,或者过度自卑。

整队这些情况,我们可以如下方法:
1、日程管理表
以项目迭代周期为准,将所有的项目拆分出来,在安排工作的时候,按照参与人员的工作分拆开来。Coding阶段,测试阶段、UAT阶段等等。当然对于很多开发者来讲,这个像是一个紧箍咒,因为总是感觉没办法完全评估工时。当然这个是慢慢调整的,这个要看团队效率。
通过这个表,管理者可以每天直接问进度,比起日报来更让人接受、节约时间。也是沟通的一种高效手段。
这里写图片描述

2、课题管理表
手游行业一直在吃着快餐,并不太关注产品的质量,所以玩家更追求游戏品质阶段到来的时候,快餐不再适用。所以开发过程中,我应该更重视课题管理。
所谓课题,也就是日常开发中比较重要的技术实现,及重要的Bug修改问题。一项值得花时间研究的问题。
这里写图片描述
参考上表。
课题类别有:
Issue (讨论)
ToDo(执行)

课题状态:
Open: 起案状态
WIP: 作业状态(调研)
Hold: 暂定状态(未解决)
Close:关闭状态

3、Bug管理表
日常所有Bug我们用一个文档,按照版本等分类,管理Bug状态,来减少Bug,另外可以让大家看到相同的Bug是不是有相通的解决方案,是团队消灭Bug的利器。当然也可以用禅道之类的工具来处理。也可以作为后期成品质量提升的数据支撑。例如,我们可以分析这个版本的Bug率,哪个模块Bug率高,就要把代码拿出来,进行代码审查。达到什么Bug率的模块需要开发者重新开发等等。

4、Crash管理表
Crash对开发来讲,是最大的杀伤。管理者应该要重视。将Crash管理起来,让每个Crash问题解决者,在文档中填好解决方案,争取让每个Crash的解决带来“感悟”。既起到警示作用,一定阶段我们还可以汇总分析,我们的游戏Crash率,及Crash频发模块,版本等信息。
这里写图片描述

5、版本迭代管理表
每一个版本迭代,我们都是匆匆忙忙的,都会忽略出现的问题,出下一个包说不定又出现什么问题了。或者一段时间后boss或者产品扯皮,我们可以潇洒的拿出这个表。记录下发包需求下发过程的关键信息,如渠道、版本内容、覆盖的计费、配置参数,提交时间、过审时间、拒绝时间、拒绝理由等等。
这里写图片描述

没有更多推荐了,返回首页