|
随着带的团队做的事情越来越多, 发布的产品也越来越多, 关于软件开发的流程的思考也越来越多.前段时间的高效虚拟自适应团队是在历经困难后磨练出来的方法的总结, 在此基础上,又经过几个版本发布的洗礼,对之前的认识又有了更新,更深入的看法. 在此特提炼出一套方法论, 供大家参考.pmp.mypm.net
一个软件从开发到上市(我们抛去维护部分), 一般需要经历阶段有 需求分析, 方案设计, 开发方案设计(包括概要设计, 详细设计等), 测试, 交付. 相信这些名词在软件工程中大家都能找得到, 那在这些过程中, 具体怎么实施呢?training.mypm.net
先看下面的流程图:项目管理者联盟
service.mypm.net
一. 前期准备阶段training.mypm.net
有很多人不太重视前期的准备, 或者不太在意这方面的事情. 还有一个问题, 前期的准备要准备到什么程度?www.mypm.net
在我这里, 前期要做好三件事: 需求分析工作, 数据分析工作, 概要开发方案pmp.mypm.net
需求分析: 这部分就是我们的专业需求人员所要处理的事情. 主要负责把本次版本中的功能分析清楚.我们一直强调一点, "需求要明确", 不允许在需求文档中出现类似"跟XXX一样"等这种含混不清的字眼. 一般来讲, 分析到此业务的背景, 解决的问题, 用户的操作场景, 有这些信息有可以了.项目管理者联盟
数据分析: 尤其在我们的计价软件中, 定额库是不可缺少的东西. 他是你程序能够运行的前提.对于数据如何制作, 用何种方式制作能,制作成什么格式是最省力的, 对开发, 对数据人员的加工量是最少的, 能否支持程序运行. 数据的存储的介质,格式决定了后面的开发方案项目经理圈子
开发方案分析: 目标达到能说清楚这件事怎么做就可以了. 内容格式方面可以自由扩展. 可以以下面的我的分析方案为参考: 项目经理圈子
项目管理者联盟
图2(需求分析格式)项目管理者联盟
二. 方案评审项目经理圈子
这一步是必须的. 让业务专家, 或者有经验的人给你把下关.这样对你的方案是一个很大的补充. 一个人的想法很难保证想的很全, 所以, 可以经过这个环节进一步充实你的方案.等这一步完成后, 你会形成项目列表. 就是针对每个开发功能, 拆解为详细的开发步骤, 并估算出工时, 如下图所示:项目管理者联盟
项目管理者联盟
图3(任务分析明细图)bbs.mypm.net
这样有助于你完成更为详细的开发计划. 一定要把任务项列细了, 越细, 对后面的进度控制就越有帮助.项目管理者联盟
三. 项目启动会议bbs.mypm.net
正如我上上篇文章所说, 这个过程的好坏会对后面的开发任务有很大的影响.在这个过程, 重点是进行需求交底. 把前面的分析结果再加上已经评审通过的内容做成PPT, 给整个团队成员做讲解. 让团队中的每个成员都能知道项目管理者联盟
我们很难保证让团队中的每一个人都能把所有的业务都理解的很清楚, 这是很难办到的, 但可以保证的是,当这个任务为某个人做的时候, 他会更专心的去听这块内容, 对于要执行者,他是最为关注的. 这样当需求交底完成的, 可能是大部分人对需求都有所了解, 理解度在20%~60%左右吧, 但执行此任务的人理解度应该能达到90%左右. 不用担心, 我们后面有办法让那些只理解20%的人也能掌握另外的没掌握的内容.项目管理者联盟
当需求交底完成后, 就要开始进行方案交底了, 一般你会把之前分析的内容给大家讲出来, 并给出自己的一套默认的开发方案,然后由大家来评审这个方案如何.club.mypm.net
在这个过程,有开发, 有测试, 有需求, 有数据,都会从不同的角度去分析此问题.在讨论过程中,那些本来可能还是太懂的人, 结过这么讨论,就会更明白了许多. 这样, 其理解度会上长到50%应该是没问题的.做为主持者, 当你发现某些人确实不在状态时,可采用单独提问方式来让他加深记忆,这都是可以的.项目经理圈子
还有不太清楚业务的, 没关系, 下面我们就要根据前面敲定的方案来排定任务了. 因为已经经过了前面的方案讨论, 所以对开发的时间应该有所把握, 这时,对于不清楚业务而无法估算出时间, 或者为了估算出正确的时间以至不会让自己任务拖延的, 也要再熟悉一遍需求. 经过这样, 需求基本上就都搞清楚了.那最后就要出我们的作战图了:项目管理论坛
项目管理者联盟
图4(作战图示例)项目管理者联盟
|
