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

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

    10427 人正在学习 去看看 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和自测,不能把没有测试的代码进行提交。
2018-10-09 17:08:50 u014526891 阅读数 827
  • SCRUM敏捷开发视频教程

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

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

上面一篇文章我们提过为什么分布式需要做前后端分离,今天这篇我们从开发模式来详解为什么互联网项目使用于敏捷开发?

因为笔主经历过瀑布开发模式和敏捷开发模式这两种开发模式,所以存在有一些自己的见解跟大家交流。

下面所以我们这边先来简单介绍下这两种模式:

瀑布开发模式:

瀑布开发模式是由W.W.Royce在1970年最初提出的软件开发模型,瀑布式开发是一种老旧的计算机软件开发方法。
瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行
步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等。 总的来说,迭代周期长一些,一次性解决所有的任务,一次上线。

下面我们说说瀑布开发模式的几个特点

1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下一阶段的工作就不展开。

2.重视和强调过程文档,在开发的中后期才会看到软件原型,早起只能通过文档来了解系统的模样。在这种情况下,文档的重要性仿佛已经超过了代码的重要性。

3.瀑布模型每个阶段的人员只关心自己阶段的工作,不需要关注其他阶段的工作。

优点:

1、可以让开发人员能够更专注于本职工作,提高阶段效率

缺点:

1、在项目各个阶段之间极少有反馈,风险往往迟至后期才显露,失去及早纠正的机会。

2、项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂

3、测试人员最后才参与到项目中来,后期风险较大。

4、只有在项目生命周期的后期才能看到结果。

 

敏捷开发模式:

敏捷开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不 尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织 型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用。

在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。总的来说,拆分成多个小迭代,多次上线。

下面我们说说敏捷开发模式的几个特点

1、最核心的功能最先完成,容易出成果。

2、小步快跑,尽早交付,拆分各个小迭代(spring),一定的迭代周期内需要确保开发的完成,规避了一定的上线风险。

3、各组人员分迭代来有序工作,比如:设计人员出一个模块RP,开发人员完成这个模块编码,测试人员完成这个模块测试。

4、敏捷的管理是团队的自我管理和项目经理的服务式管理,项目经理需要根据当前开发资源确保每个迭代的的可完成性,团队成员需有良好的自我管理能力,来确保小迭代内功能的完善;项目经理需要对整体启到把控作用,迭代中可以根据开发进度进行各成员工作的微调,保证迭代进度的完成

优点:

1、容易出成果,可以快速提高软件发布周期,敏捷确实是项目进入实质开发迭代阶段,用户很快可以看到一个基线架构版的产品

2、测试人员能够尽早参与进项目中来,规避了一定的风险。​​​​

3、每次迭代周期应尽可能短,以便能及时地处理需求变化和用户反馈​​​。

缺点:

1、迭代周期端,为了不影响迭代完整,需要项目中存在经验较强的人,要不大项目中容易遇到瓶颈问题,延误迭代进度。

2、敏捷开发要求各员工自我管理要强,所以对人员素质和稳定性的要求又更高。

 

那为什么互联网项目要用敏捷开发呢?

1、出成果(版本)快,互联网就是以快吃慢,一般都是迭代发布的,追求创新,说明了需要快速响应用户的变化,时间就是一切,需求不确定性高,这个在软件行业也很常见;关注用户行为,倡导以用户为中心的产品设计。很典型的例子微信,腾讯一个月开发出来的产品,根据用户体验和反馈,通过反复的小迭代来优化。

2、互联网项目中市场反响和客户体验尤为重要,需要有一个快速迭代来响应客户的需求,确保客户的满意度。如果是瀑布式开发,迭代慢,更改的成本也比较高。

3、随时应对变化,因为迭代周期的减小,使得项目的弹性更足,可以更好的适应互联网项目上更多的不确定性。

 

那如何从瀑布开发模式往敏捷开发模式切换?

任何开发模块的切换都是存在风险点的,包括我们前面介绍的前后端分离模式,那我们需要做什么来减少这些风险呢?

1、优先选择周期比较长的项目,资源较充足、素质较高的团队来试行。

2、需要制定一套较为完整的敏捷体系,从产品到开发到测试,选型敏捷工具

3、刚切换过来的迭代,可以适当减少迭代内容,切换过程需要缓冲时间,避免因为试行阶段出现的问题,从而团队的整个心态。

4、项目经理需要把控好任务进度,需要在迭代的中间,每天了解迭代运行情况,最好是每天团队可以有晨会。

 

 

2020-01-07 23:36:42 y002j 阅读数 10
  • SCRUM敏捷开发视频教程

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

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

敏捷开发其实是对由于在长期的软件开发的实践中形成的一种方法论体系,现在的敏捷开发的理论体系包括了很多种方法论的。到目前为止最常用的方法有Scrum,Kanban,XP和Crystal 等等。

在很多时候,有些朋友会问敏捷的概念是不是能够用在其他类型的项目上面。我觉得敏捷理论其实是为了解决在软件开发项目项目遇到的特殊问题而产生的方法论体系。并不适合推广到更加宽泛的其他工程项目的领域,当然的确也有某些人在鼓吹把敏捷方法用到其他行业,我觉得这个是不负责任的说法。即使是经过一定调整的敏捷项目管理方法,也只适合于知识产品生产领域的项目。更广范围的项目管理还是遵循PMP或者Prince2这样的通用方法论再加上行业相关的实践比较好。

我们可以对比一下传统的工程项目(如建筑,机械,化工类项目),在建筑领域,通常会有设计师设计需要施工的设计图;制造类项目会有工程师设计好要生产相应产品的生产线的设计图,并计划和设计每个工位的功能,机械和控制结构。然后再交给项目经理安排团队或者供应商进行施工和搭建。在整个过程中,每个环节和角色都有明确的功能和职责,而且也有明确的先后顺序和责任范围。在设计和制造的过程中通常也要遵循一定的行业标准。实施单位或者项目组通常不需要对设计和需求进行讨论,具体执行的人员只需要围绕他个人的工作完成即可,也不需要过多的交流。而且通常交流也是由上级到下级的单向指令为多,从下到上的反馈和沟通渠道在精益生产的实践的持续改进中虽然是需要的,但并绝对不要求过于频繁。只有工作内容有交集的工作单位之间才需要项目沟通,比如说挖掘隧道,两队人马从两个方向施工,最后需要在中间汇合,那在快要汇合的那个时间段,这需要沟通隧道挖掘的位置和进度需要相互了解的。而具体的进度和决策都是有项目的管理者来决定。

敏捷方法的一些基本概念包括 - 迭代,最小交付物,及时沟通,持续交付,去流程...这些概念如果用到传统的工程项目上一定会让整个项目成为一场灾难。如果某公司盖房子先弄一个没有厕所和阳台的,没有楼梯的最小可验证交付,然后再在后面的迭代中慢慢设计楼梯,窗户,厕所,然后添加上去...只能说这家建筑公司的项目离失败不远了。而在工程类项目中过多的沟通和交流,甚至将一些技术上的决策权下放,只会造成整个项目的混乱和无序。

那为什么软件和IT开发可以采用敏捷方法?而且经过实践下来,这是一个可行而且高效的方法论呢?我觉得其实主要有以下几个特点:

1. 软件产品总体上是知识产品,几乎所有成本是知识工作者本身的成本。提高开发人员的单位效率才能够提高整体项目的生产力

2. 软件类项目和其他研发类项目相同,有高度的不确定性,不能保证在项目设计阶段一次性完成所有需求设计并考虑到所有的技术难点和解决方案。随时都要准备设计,需求,资源和技术等方面的变更。

3. 无法用流程和制度来确保知识工作避免人为的错误发生(非设计错误),必须及时进行测试和验证才能确保减少错误。

4. 团队成员之间,团队与客户之间必须要保持及时和通畅的沟通渠道,以确保交付的产品符合用户的预期,同时确定工作的进度也是符合整体的要求的。

5. 软件开发人员通常受过一定的高等教育,掌握了一定的分析和研究方法,能够从不同角度提出问题或者解决方法。

 

2017-04-06 09:28:40 huver2007 阅读数 512
  • SCRUM敏捷开发视频教程

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

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



如何理解敏捷开发?

没有参与过敏捷开发项目的人可能觉得敏捷开发抽象难懂。举个例子,敏捷开发像是在冲浪,一直处于动态、不断变化的环境中。在项目研发过程中出现的需求变化和挑战就是你在冲浪时要应对的海浪。他们从不停止而且永远在变化,这种情况下意味着需要快速地适应变化。

首先,敏捷开发是一种过程控制方法,通俗的说,就是一种做事情的方法。

1. 它主要适用于软件,在运维、服务等领域也有广泛应用,但在硬件领域还没有成熟的方法,因为硬件一般不允许需求变更。
2. 它适用于客户不知道自己要做什么的情况,其实,这样的客户占绝大多数。因为客户不知道要啥,所以你需要不断帮客户弄明白他到底想要啥。换句话说,你需要和客户沟通,合作,倾听反馈,持续改进。
3. 它适用于竞争激烈的市场,这样的情况下,赶在竞争对手前交付一个不完美但至少能用的产品非常重要。
4. 它适用于快速变化的市场,你在埋头造一辆汽车的时候,客户已经想开飞机满天飞了,这就需要你能一步步的把汽车改成飞机,还能按时交付。
5. 它适用于小团队,一般5-9个人。这样能使敏捷中主要的沟通方式“Face to Face” 是可行的。

其次,敏捷开发是一套工具集,里面有形形色色的工具,你也可以将各种最佳实践提炼成敏捷实践。你可以不搞敏捷,但可以用其中几个来提高工作效率。

比如:

1. 站会:三个问题,简洁有效的小团队沟通方式
2. 看板:直观反映工作进度,反映流程遵守情况,反映流程缺陷
3. 演示,计划,反思会:适合于小团队的协作和优化反馈方式
4. 用户故事:站在用户的角度讲需求
5. 持续集成:随时高质量交付的基础,有利于应对变化剧烈的市场

最后,敏捷开发也是一种企业管理方式

1. Team可以是架构师,开发工程师,测试工程师,发挥了他的主观能动性,有利于创新和效率
2. 敏捷不专注于敏捷团队中个人的绩效考核,而更多的侧重于整个团队的绩效,更好的避免了KPI驱动模式。
3. 把大项目拆分成小项目去做(每个Sprint都是一个迭代,需要输出一个高质量的版本,相当于完成一个小项目),把bug的生存期控制在一个迭代以内,降低了风险,也减少了后期改bug的工作量。
4. 把数十人的大team 分成几个敏捷团队,这几个敏捷团队的SM/PO再组成一个更高一级的敏捷团队,利用站会,回顾会,看板等等敏捷元素,可以避免数十份邮件也不能解决一个小问题,大家互相踢皮球,沟通不畅的大企业病。
5. 老板可以是最大的PO,他给下面的高管讲idea(UserStory),定期检查Demo,把控产品用户体验,负责和外界的沟通合作。

综合各方观点,敏捷开发是:在高度协作的环境中,持续不断地快速输出可交付产品,通过反馈进行自我调整和完善的方法。

2017-05-08 09:53:58 qq_21586623 阅读数 1176
  • SCRUM敏捷开发视频教程

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

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

1.目的

规范互联网软件产品开发项目管理过程,指导开展项目研发、管理等活动。

2.适用范围

本章程的作用范围为互联网软件产品开发立项至结项管理过程。

1.对项目经理开展产品规划及设计活动以及项目管理手段和应遵循的开发流程提供了指导;

2.对项目团队的日常管理活动及内容进行了指导;

3.角色及职责定义

项目经理:

进行产品开发过程中的业务目标、进度、成本、质量控制。

挑选项目团队并进行团队建设,激发、鼓舞和改进团队的生产效率。

识别项目干系人,定期向干系人汇报,并作为团队和外部的接口,屏蔽外界对团队的干扰。

确保项目中流程被遵循,组织、监督、培训项目各实践活动。

产品策划

确定产品的功能,拆分用户故事。

需求功能确定优先级。

接受或拒绝开发团队的工作成果。

参与产品开发过程中的有关会议。

UI

根据用户故事,负责产品的功能交互及界面设计

组织开展人机交互及用户体验,不断跟踪改进,提高产品表现力。

参与产品开发过程中的有关会议。

开发

根据用户故事,负责产品的技术架构设计及功能开发

评估、设计及维护产品相应模块,确保模块的稳定性、易用性、高效性。

参加产品开发过程中的有关会议。

测试

根据用户故事,设计产品测试标准,确保产品品质满足市场需求。

合理分配测试资源,组织产品测试并优化测试流程及测试标准,提高测试效率。

编写产品测试用例,提交测试问题,编写测试总结报告,以测试角度来确定产品版本是否发布。

4. 项目管理过程

按照互联网软件产品项目开发过程,可将整个项目管理过程分为立项过程、规划过程、执行与监控过程、结项过程。下面分别阐述在每个阶段过程中该如何进行项目管理。

4.1立项过程

互联网软件产品开发项目的立项过程,通常是指从准备项目启动会到召开会议这个阶段,在立项过程中,需要完成项目目标,需求范围的初步确认,项目团队成员,其他资源的安排。

确定项目的初步目标并达成共识

对于项目目标,需要和干系人在以下几点上达成共识:

项目的背景、目标用户、核心人员及产品定位是什么

项目的资源投入预算是多少

项目的资源投入是多少

各人员在项目中扮演的角色和对项目的作用是什么

准备启动会议文档

文档内容包括:

用户画像

产品定位

市场策略

业务目标

技术可行性

研发成本预算

路标规划

召开项目启动会

参加人员包括:

管理层代表

项目经理及项目团队

其他干系人代表

主要议题包括:

申明项目目标范围及对组织目标的贡献。

管理层正式任命PM,设定期望,统一思想

文档内容的宣讲。

与PM小组确定项目管理要求

项目启动会完成后,需要与PM小组成员确定项目立项机制以及公司项目管理要求。

4.2规划阶段

在规划阶段,团队需要共同完成产品的版本规划,迭代计划

版本规划

从产品的关键特性列表中按照优先级规划产品每个版本需要完成哪些特性,在规划完成后需要在项目干系人内达成共识。具体可参考《版本规划样例》

迭代如何划分

迭代划分是指将特性列表拆分形成用户故事列表,并将其对应的主要任务划分到各个迭代中去,形成粗粒度的项目迭代计划。这个过程主要考虑以下几个因素:

有些任务间是有依赖关系,某个任务的开始或结束是以另一个任务的开始或结束为前提,在划分时必须考虑这种前后依赖关系。

在安排每个迭代的任务时,需要对各种因素进行综合考虑,如平衡每个迭代中任务的技术难度和价值差异。

除了进行初步的迭代任务划分,还需要确定项目过程中迭代任务调整的规则,如迭代任务未完成时是将剩余任务延至下一迭代还是延长迭代周期。

确定人员分工

项目经理需要根据每个人员的能力和特点,初步拟定大致分工。在进行任务分工时需考虑以下因素:

任务难度与人员能力相匹配,对于明显超出能力范围或过于简单的任务容易造成负面影响。

耦合度高的尽量分配给同一个人,避免不必要的沟通消耗。

鼓励团队内部“任务认领”,提高人员的工作积极性和主动性。

确定迭代运行模式

如一周迭代、两周迭代,每个迭代包含的工作内容等。

具体的迭代计划可参考《迭代计划样例》

制定其他辅助计划

制定沟通计划、风险计划和质量计划是必要的,沟通计划主要包含以下几个方面:沟通对象、沟通方式、沟通频率即可,如:


风险计划包括风险项、负责人、重要性、应对措施,如下:


质量计划包括:bug分布满足何种条件可以发布,有几个致命bug必须停止开发新特性等。。

搭建基础技术架构

如果是一个全新的项目,需要重新开发系统框架,则这个工作应该在迭代0完成,否则会影响后期的工作开展。系统框架的每次改动必然会导致大量的重复工作量,从而给稳定的团队节奏带来很大的毛刺。

3.3项目执行和监控过程

迭代N的执行

A、迭代N的需求细化

考虑每个迭代需要完成的用户故事;

用户故事需包含几个部分,工作量评估、功能性需求、非功能性需求。具体的可参考《用户故事模板及样例及拆分说明》

用户故事编写完成后需要在团队内部进行需求评审,一方面是为了向团队成员解读该需求,另一方面团队成员也可在评审时给出指导性意见。

B、测试用例评审

测试人员根据用户故事要求编写对应的测试用例,并组织项目团队进行测试用例评审。根据评审意见修改测试用例

C、开发

将用户故事的需求开发的过程。

D、开发自测

在开发过程中,每完成一个功能点,都需要及时的进行开发自测并通知产品策划人员进行验收体验。

E、验收

开发完成后,产品策划需要对开发完成的成果进行验收,验证其是否符合用户故事的要求,验证通过后方可流到测试环节,否则需与开发详细讨论其不符合性,其验收的checklist可以参考《产品验收checklist及模板》

F、测试和回归

提交测试时,必须要有正确的版本。测试人员根据测试用例进行测试,在IT平台中提交测试bug,并根据测试的角度给出产品是否发布的意见,输出《测试报告》

G、bug修改

在IT平台中获取分配给自己的bug进行修改。

H、showCase

阶段性必须有可体验版本进行showCase.需要

确定showCase时间:某个迭代开发、自测完成,准备提交测试前

会议前1-2天发出体验版给到参与人员

会议期间,由项目经理组织大家体验、反馈问题、记录问题。

项目经理根据问题情况,与开发或产品确定问题的解决时间并发出会议纪要。

I、灰度发布

迭代一定版本后,由项目经理与团队共同决定是否需要进行灰度发布。

监控方式

每日站立会

主持人轮流担任,负责控制节奏,记录问题,以备会后跟踪。

每人讲自己昨天做了什么,有什么问题,今天的计划是什么;

其他人了解别人的工作情况,并发现指出可能存在的问题。

对于发现的问题,鼓励认领,其余由项目经理指定责任人。

时间通常控制在15分钟内。

会议期间,更新任务墙,任务墙样式如下:


周报

反馈项目计划的执行情况,强调本周工作要达成的目标

暴露出项目的问题,特别是需要领导或其他团队需要协助的问题。

周报可在IT平台中输出。

月报

反馈项目当月的执行情况,包括进度、人力及质量。

反映项目存在的问题和风险。

迭代回顾

每人讲述本次迭代做的好的地方和不好的地方

回顾上个迭代不好的地方,看看改进情况。

让每个人发言。

每次迭代回顾会议完成后,可更新燃尽图

3.4结项阶段

项目经理指导产品策划收集总结项目的产品运营数据,同时指导团队成员从自身角色进行总结,包括测试、开发、UI等。

项目经理与项目团队成员给出项目总结报告,内容可参考《项目经验教训总结-项目团队》,《项目经验教训总结-项目经理》

召开结项会议,各成员进行结项汇报。

PM小组将过程文档和经验教训总结进行归档。

敏捷的适用范围

阅读数 1900

敏捷开发

阅读数 64

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