3分钟了解敏捷开发项目管理 敏捷开发项目管理流程( 二 )


确定人员分工
项目经理需要根据每个人的能力和特点初步拟定大致分工 。在任务划分中应考虑以下因素:
任务难度与人员的能力相匹配 , 对于明显超出能力范围或者过于简单的任务 , 容易产生负面影响 。
高耦合度的尽量分配给同一个人 , 避免不必要的通信消耗 。
鼓励团队内部的“任务主张” , 提高员工的积极性和主动性 。
确定迭代操作模式
比如一周迭代 , 两周迭代 , 以及每次迭代包含的工作内容 。
具体的迭代计划 , 请参考样本迭代计划 。
制定其他辅助计划 。
需要制定沟通计划、风险计划、质量计划 。沟通计划主要包括以下几个方面:沟通对象、沟通方式、沟通频率 , 如:
风险计划包括风险项目、责任人、重要性和对策 , 具体如下:
质量计划包括:bug分布满足什么条件可以发布 , 几个致命bug必须停止开发新特性等 。。
构建基本的技术框架
如果是一个全新的项目 , 需要重新开发系统框架 , 这项工作应该在迭代0中完成 , 否则会影响后期工作 。系统框架的每一次变动 , 必然会带来大量的重复性工作量 , 给稳定的团队节奏带来极大的毛刺 。
3.3项目实施和监测过程
迭代n的执行
A.迭代n的需求细化
考虑在每次迭代中要完成的用户故事;
用户的故事需要包括几个部分 , 工作量评估 , 功能需求和非功能需求 。详情请参考用户故事模板、样本和拆分说明 。
写完故事后 , 用户需要在团队内部评审需求 。一方面是向团队成员说明需求;另一方面 , 团队成员也可以在评审过程中给予指导 。
B.测试用例评审
测试人员根据用户故事的要求编写相应的测试用例 , 并组织项目团队对测试用例进行评审 。根据评审意见修改测试用例 。
C.发展
开发用户故事需求的过程 。
d、开展自测
在开发过程中 , 每一个功能点完成 , 都要及时进行开发自检 , 并通知产品策划人员进行验收体验 。
E.接受
开发完成后 , 产品策划需要对开发的结果进行验收 , 以验证是否符合用户故事的要求 。验证通过后 , 可以流向测试环节 。否则 , 有必要详细讨论与发展不符的情况 。验收清单请参考产品验收清单和模板 。
测试和回归
提交测试时 , 您必须拥有正确的版本 。测试人员根据测试用例进行测试 , 在it平台提交测试bug , 根据测试角度给出产品是否发布的意见 , 输出测试报告 。
G.bug修改
把IT平台里分配给你的bug拿过来修改 。
h、展示
分阶段展示必须有体验式版本 。需要
确定展示时间:在迭代开发和自测完成并准备提交测试之前 。
会议前1-2天 , 将体验版发给与会人员 。
会议期间 , 项目经理会组织大家体验 , 反馈问题 , 记录问题 。
项目经理根据问题的情况 , 与开发或产品一起确定问题的解决时间 , 并签发会议纪要 。
一.灰度释放
经过一定的迭代后 , 项目经理和团队共同决定是否需要灰度发布 。
监控模式
每日常务会议
主持人轮流控制节奏 , 记录问题以便会后跟进 。
大家说说昨天做了什么 , 有什么问题 , 今天有什么打算 。
别人了解别人的工作 , 找出可能存在的问题 。
对于发现的问题 , 鼓励提出 , 其余由项目经理指定责任人 。
时间一般控制在15分钟以内 。
会议期间 , 更新任务墙 。任务墙样式如下:
一周的
反馈项目计划的执行情况 , 强调本周工作要达到的目标 。
暴露项目的问题 , 尤其是需要领导或其他团队帮助的问题 。
周报可以在IT平台输出 。
月刊
反馈当月项目的执行情况 , 包括进度、人力、质量 。
反映项目存在的问题和风险 。
迭代评审
告诉大家这次迭代的好与不好 。
回顾上一次迭代的缺点 , 并看到改进 。
让大家发言 。
在每次迭代评审会议之后 , 可以更新燃尽图 。


推荐阅读