开发管理 CheckLists.docx
《开发管理 CheckLists.docx》由会员分享，可在线阅读，更多相关《开发管理 CheckLists.docx（69页珍藏版）》请在冰豆网上搜索。
开发管理CheckLists
开发管理CheckLists
（1）-启动项目
注：
本系列文章是开发管理的checkLists,主要的目的是用来检测和提示在该模块的工作中哪些应该做，哪些没有做.所以各个的功能点可能不会讲解的特别细
一、为什么要关注项目启动（关注启动的项目的启动前提条件）
所有的项目均存在风险，但在项目生命周期的各个过程中，启动过程给项目带来的风险是最大的，很多项目的失败都是一开始就留下来失败的隐患，当这些隐患积攒到项目的后期爆发出来，项目管理人员已经无力回天。
二、项目启动前我们应该关注什么
下面简单介绍下项目开始前应该做些什么？
1、先确定项目驱动因素（做该项目的前提条件）和项目驱动因素的优先级（由于前提条件较多，那个必须存在优先级问题，优先选择优先级高的条件）.目前的项目大体上有如下驱动因素
发布成本、发布日期、功能集合、减少缺陷、人员配备、工作环境
然后确定上面驱动因素的优先级,可以由产品经理进行确认,如果产品经理不确认，那就由项目经理确认
务必要确认需求的优先级
例如如下使用矩阵表名项目的优先级
Java代码
1.项目驱动因素 排序
2. 发布成本 5
3. 发布日期 1
4. 功能集合 2
5. 减少缺陷 3
6. 人员配备 4
7. 工作环境 6
解析：
（1）、在这个项目中，发布日期是最主要的驱动因素。
如果产品今年不能发布，这个项目就没有什么存在的意义了。
（2）、完备的功能也很重要——功能不齐全，即使及时发布，整个项目也没有价值。
而且，
（3）、由于公司业务属于受政府管制的行业，产品的缺陷率必须很低。
（4）、接下来是人员配备，因为只要这些人能在十个星期之后参与下个项目计划就可以了。
（5）、项目的成本控制不太重要，因为项目的价值会很高。
（6）、工作环境排在最后，为了保证及时交付 我可以灵活调整某些事情。
了解了项目的关键驱动因素，我就可以定义出项目的成功条件，并选择适合项目的生命周期了。
项目团队可以制定出发布条件，并根据驱动因素合理地安排各自的工作
这些条件，也是在整个的项目的执行过程中特别要注意的因素，尤其对于优先级较高的条件。
同时也是制定项目管理计划的重要因素。
2、使用与上下文无关的问题识别项目真正的驱动因素
对于如何确定驱动因素的优先级，项目经理可以采用如下的形式来逐步推测。
可以通过如下上下文无法的问题来识别优先级，通过这些比较抽象的问题，
可以诱导其他人说出他们对于项目的假设。
不妨从下面这些问题开始。
1、项目要怎么样才算成功？
2、为什么想得到这样的结果？
3、这种解决方案对你来说价值何在？
4、这个系统要解决什么样的问题？
5、这个系统可能会造成什么样的问题？
要注意：
少用”为什么“来提问，“为什么”这类问题很容易让对方产生戒心。
注意避免“怎么做”之类的问题，出资人会觉得你在让他们设计系统。
在问问题时，要让人感觉到你真心希望了解这个项目， 而不要让别人抱有戒心。
这些问题可以为项目经理和出资人将来的合作打下良好的基础，而不是形成龃龉的关系。
==》给出自己的意见，供别人参考。
三、编写项目章程，共享现有决策
项目章程会明确记录项目的需求和约束，还可以帮助项目经理思考如何进行项目规划。
整个团队和出资人都可以查看项目章程，以此确保他们对项目有关的决策可以达成一致。
下面是我的项目章程模板。
1、远景
发起这个项目的缘由和项目的价值，用描述远景的句子说明项目的价值
2、需求
某个特定日期发布某个功能,例如
“8月21日发布的主要版本中，我们需要这个xxx功能。
”这些才是项目的驱动因素，产品功能列表不是
3、目标
希望通过项目所达成的目标
4、成功标准
成功标准是围绕客户能基于完成的产品做什么给出的定义。
成功的标准并不涉及缺陷，而只关注能力。
下面是一些成功标准实例。
1、要包括功能1、2、3，这样我们的产品就可以打入目标市场了。
2、要提升产品性能，再测出相关数值，这样我们就可以将其与竞争对手的产品进行对比，
3、在第一季度发布
项目章程是有意要设计成这么简短的，目的是帮助团队赶紧启动，足够让大家着手开展工作。
四、铭记在心
1、每个项目启动时都要有章程。
2、对项目章程的反复修改要有心理准备。
章程不一定完美，它的意义在于帮助整个项目团队进行规划活动。
3、要知道“质量”的意义以及项目的驱动因素。
这样随着项目的不断推进，项目经理和团队才可以作出正确的决策。
开发管理CheckLists
（2）-规划项目
有了项目章程，每个团队成员就可以对自己接下来要干什么做些有明确方向的预先规划——或者，也可能提早知道自己还没有明确的方面。
有了项目规划，就可以把团队成员的注意力聚集到预期的项目产出上来 。
一、使项目足以启动的规划
章程有了，规划是什么？
管理层希望知道团队什么时候开发哪些特性。
如何测量进度？
项目何时完成？
1、使用时间盒来限制和启动规划活动
时间盒（timebox）是指特定的时间长度，个人或团队用它来完成某项特定的任务。
个人或团队在这段时间内完成的工作量，就是项目接下来的工作的基础。
如果有必要，个人或团队可以减少工作范围，以保证在“时间盒”内完成工作
二、开发项目规划模板
项目规划模板：
1、产品意图
简单描述产品，为什么公司要开发这个产品，它能为公司带来哪些效益
2、历史记录
如果是在管理某产品的后续版本，比如4.2版本后的4.3版本，就要复查之前或相关版本的历史记录。
这个历史记录可以说明之前任何已知的技术债务
3、发布条件
要详细列举出项目产品的关键可交付物。
想识别出它们，不妨问一问：
“要是不那么做，我们还能发布产品吗？
”
要将功能、性能和质量要求都涵盖在内
4、目标
已知的目标也许隶属于以下几类。
1、产品目标也许包括这样一些需求，它们已经被设定好优先级，但是不承诺在当前发布版本中完成。
这个列表也许已存在于产品的待办事项中。
2、项目目标也许是诸如性能标准之类的目标，对它们的要求会高于一般需求，或者是“在产品交付时，要将未解决缺陷的数目从50个减少到40个”。
尤其是在管理一个工程的情形下，每个子项目的目标要特定于该项目所在的领域。
项目团队要解决某些特定的技术债务，也许也可以作为项目的目标。
3、团队目标可以是“增加产品的自动化冒烟测试所占的百分比”。
团队也许希望改进某个特定功能的性能或可靠性。
4、组织目标可以是“减少项目的耗费时间，以提升组织的敏捷性”。
5、项目组织
1、要明确说明团队在项目中的职责分配，指明项目经理如何使用生命周期组织项目工作，要采纳哪些关键实践，以及是否有决策人可以影响当前项目
2、要说明项目的一般运作方式。
比如，在项目启动时加强整个项目团队意识，招聘新人，开发包括代码和文档在内的完整功能，编写所有的代码，同时检查一下（在那个时间）可以记录些什么，诸如此类的事情
6、日程总览
应该创建一个日程总览，其中标有主要的里程碑，还要说明人们从这些里程碑处可以得到什么。
如果使用迭代或增量式开发，要解释迭代（或增量）的持续时间，并说明在每个迭代（或增量）结束后可以预期得到哪些产出
例如：
Java代码
1.日期 里程碑
2. 2月1日 项目启动。
3. 2月15日 向客户展示Web界面的原型。
4. 2月30日 进行第一轮迭代开发。
5. 3月15日 内部交付Web界面。
6. 3月30日 发布beta版本,让客户进行试用
7. 4月1日 开始beta测试。
8. 4月30日 结束beta测试。
9. 5月30日 系统上线。
7、人员配备（人员曲线）
很多项目经理不能控制项目团队的人员配备。
如果在项目开始的第一天就把所有的人都召集到位了，那么出现人员变动可别吃惊。
如果需要从其他组或是团队中调动人手，要在这里说清楚：
要在何时需要多少、何种类型的人员
8、建议日程
项目经理要根据理解程度，列出主要的里程碑
9、风险列表
在项目规划中，至少要将排名前十的风险记录在案。
还要经常监控这些风险，并在适当的时机更新这个列表。
如果觉得项目目前的风险不到十个，不妨跟项目团队一起坐下来，进行一次头脑风暴
开发管理CheckLists（3）-项目启动会议
结合前2偏文章所列出来的重点信息，下面整理出来项目启动会议的checkLists给大家参考
项目启动会议的以澄清项目有关概念为内涵,以确保大家取得理解上的一致，公开项目相关者的离职和职责，提高大家对项目承诺的兑现程度
该会议有一下大约13个议程
1、欢迎和接收
# 要确保关键利益着或代码能够在现场，远程视频，电话会议也行，向与会人员介绍参与会议的所有名单
头衔，和联络方式，向利益相关者介绍项目组的组要成员
2、介绍会议的目的
#介绍召开的是什么项目启动会议，通过会议确保项目客户、供应商等对项目的管理方法、角色和责任、变更管理方法等认可
#安排专人进行会议纪要。
和会议纪要的发送
3、介绍项目背景
#为什么要发起这个项目，尽量用数字说明
4、说明项目的范围
# 简单的单完整的说明项目包含什么，不包含什么，并说明主要项目产品及重要里程碑
5、说明项目利益着相关角色和责任
#以用责任矩阵予以说明
6、介绍项目经理将采用的管理方式
#必须强调的是项目的管理方式必须得到所在企业和项目利益相关者的忍痛，而且特别重要的是，必须包含项目沟通方式
7、说明项目变更控制方式
#可以使用项目变更历程图辅助说明，明确变更管理责任人，说明何时客户需要参与，说明谁有签字权
8、说明项目行动要点
# 简单介绍项目所采用的工作方式，例如一些主要的度量和控制办法等。
9、说明客户对项目成果的接收标准
#说明项目给客户提供何种产品，他们的质量判断标准是什么，客户将如何验收，要尽量获取客户对项目计划、管理方法、客户角色的责任、变更管理办法及其他项目工作方式方面的认同
10、说明下次会议的议题和时间
#介绍项目会议的原则和时间
11、回答与会人员的问题
#告诉利益相关者能够随时联系的方式。
12、对会议进行总结
#说明本次会议取得的结果和成果，感谢大家参与，说明会议纪要的发放时间和方式。
13、结束会议
总之：
要尽量的完美的无缺陷启动项目
善始善终、要努力是项目其他利益相关者对项目组，特别是项目经理流下深刻印象。
开发管理CheckLists（4）-风险管理
本文章主要介绍在项目启动前怎么样分步骤的去识别风险,才去什么方式去识别风险.
有需要做风险识别的朋友可以按照下面的步骤简单的走上一遍,或者可以提高项目的成功率
注意：
本文章只是你做风险识别的chekcLists,上面提到的一些分析方法都只是简单的介绍
一、识别风险
1、决定识别风险的责任人
项目经理应该跟踪风险并且为已经识别的风险编制相应的应对计划
2、进行识别风险的时间
项目启动过程就应该进行风险识别
3、风险识别的方式
（1）、研究项目说明说和项目交付成果的规格要求->确认项目需求方面是否有潜在风险
（2）、审查项目文件->识别在编制项目章程、人员计划、项目任务书等文件时没有识别到的风险
（3）、拜访项目专家 ->弄清楚风险会出现什麽地方
（4）、采用头脑风暴
（5）、类推比较法：
审查相似项目的经验教训
（6）、使用识别项目风险的鱼骨图进行识别
（7）、输出风险列表（图表一）
详细的项目检测风险表地址：
开发管理CheckLists（5）-风险检测表
4、确定风险类型
（1）、技术、质量风险
1、使用未被充分证明的技术或复杂技术的依赖程度
2、极具挑战性的绩效目标
3、使用的技术发生变化、项目期间行业标准发生变化、客户对产品的规格要求发生变化
（2）、项目进度风险
1、项目任务对应时间的是否准确
（3）、项目管理风险
1、项目经理经验，使用的管理工具是否合适等
（4）、组织风险
1、项目太多,当前项目只是其中的一个,资源供应风险
2、人力资源等不能及时的提供
二、构造风险影响分析矩阵进行风险评估
风险评估：
对已识别的风险要进行估计和评价，风险估计的主要任务是确定风险发生的概率与后果，风险评价则是确定该风险的经济意义及处理的费/效分析
1、风险定性分析
（1）、在风险出现的可能性或影响程度难以精确定义时，才去定性分析方法十分有益。
（2）、风险定性分析将产生各个风险因素的风险等级,
例如：
很小、小、中等、较大、很大
2、风险定量分析
进行风险定量分析的目的是从数值上分析每项风险的概率及其对项目目标的影响程度，一般在风险定性分析后再进行风险定量分析
采用的方法如下
（1）、德尔菲方法：
专家评价法
（2）、敏感性分析：
哪些风险对项目的潜在影响非常大
（3）、决策分析：
使用决策树的形式进行分析.
（4）、模拟:
通过技术进行项目模拟
经过上面的识别和评估步骤我们应该输出如下格式的表
Java代码
1. 分类前的风险表样本
2.
3.风险 类别 概率 影响
4.
5.技术方面不成熟 界面 中等 2
6.高用户并发可能崩溃 后台 较大 1
7.
8.注：
影响类别取值：
1—灾难的 2－严重的 3－轻微的 4－可忽略的
图表一
对绝大多数软件项目来讲，风险因素——成本、性能、支持和进度就是典型的风险参照系。
也就是说对成本超支、性能下降、支持困难、进度延迟都有一个导致项目终止的水平值。
如果风险的组合所产生的问题超出了一个或多个参照水平值时，就终止该项目的工作，在项目分析中，风险水平参考值是由一系列的点构成的，每一个单独的点常称为参照点或临界点。
如果某风险落在临界点上，可以利用性能分析、成本分析、质量分析等来判断该项目是否继续工作
三、制定风险应对计划
1、风险避免
变更项目计划以无效特定风险的威胁
2、风险转移
将有风险以合同形式、保险条款等转移给第三方进行风险转移：
比如购买保险，或者项目外包
3、风险降低
将不利风险事件的概率或者影响程度降到可接收水平
4、风险接受
风险不大的情况下接受风险
风险应对计划将产生如下结果
（1）、风险识别、风险描述、项目受到影响的领域、原因、影响项目目标的形式
（2）、风险管理的角色和职责分配
（3）、风险定性和定量分析结果
（4）、风险避免、降低、转移和接受策略
（5）、使用策略后仍然存在的风险
（6）、实施策略的具体步骤
（7）、策略的预算和进度
四、评审风险应对计划
各方面专家评审一下
五、使用风险评估软件进行评估
软件项目风险追踪工具
追踪风险的一个办法是将风险输入缺陷追踪系统中，缺陷追踪系统能将风险项目标示为已解决或尚未处理等状态，也能指定解决问题的项目团队成员，并安排处理顺序。
可将软件风险项目依序排列出来，按照缺陷存在的时间与负责者等资料排列。
这样，缺陷追踪系统就是追踪风险的工作能更好执行并且不那么单调。
开发管理CheckLists（5）-风险检测表
该文章项目风险监测表CheckLists是对前一篇文章风险管理的一个补充，可以用来识别风险，并可以集中来识别下列常见子类型中已知的及可预测的风险：
1、开发环境
软件工程环境支持项目组、过程及产品，但是，如果环境有缺陷，它就有可能成为重要的风险源。
下面的风险检查表中的条码标识了与开发环境相关的风险：
（1）、是否有可用的软件项目管理工具；
（2）、是否有可用的软件过程管理工具；
（3）、是否有可用的分析及设计工具；
（4）、是否有可用的测试工具；
（5）、是否有可用的软件配置管理工具；
（6）、项目组的成员是否接受过每个所使用工具的培训；
（7）、是否有专门的开发工具管理
如果对于上述问题的答案多数是否定的，则软件开发环境是薄弱的，且风险很高。
2、组织方面的风险
（1）、对该项目是否有足够的支持（人力支持,管理人员、QA、测试或其他外部人员）
（2）、该项目是否是企业最大的项目
（3）、项目管理是否有明确定义流程
3、人员方面的风险
（1）、是否可以获得足够的人员
（2）、他们是否有足够的技能和经验
（3）、是否一起工作过,他们之间的配置是否合理
（4）、他们是否相信项目会成功
（5）、是否有专业领悟的专家
（6）、是否有专门人员进行客户联系
（7）、是否有最优秀的人员可用；
（8）、人员在技术上是否配套；
（9）、是否有足够的人员可用；
（10）、开发人员是否能够自始至终地参加整个项目的工作；
（11）、项目中是否有一些人员只能部分时间工作；
（12）、开发人员对自己的工作是否有正确的期望；
（13）、开发人员是否接受过必要的培训；
（14）、开发人员的流动是否仍能保证工作的连续性；
4、工期方面的风险
（1）、时间表指定的是否现实
（2）、是否可以为了满足时间表而对功能进行规模管理
（3）、对于交付日期的要求有多严格
5、项目规模方面的风险
项目风险是直接与产品规模成正比的。
下面的风险检查表中的条目标识了产品（软件）规模相关的常见风险：
（1）、项目的成功是否能够被评测
（2）、是否有关于如何评测项目成功的协议
（3）、需求是否相当稳定并得到了充分的了解
（4）、项目规模规定不限还是不断的扩大
（5）、项目开发的时间范围是否太短，不够灵活？
（6）、是否以LOC或FP估算产品的规模；
（7）、对于估算出的产品规模的信任程度如何；
（8）、产品的用户数有多少；
6、技术方面的风险
（1）、该技术对于你的公司而言
升级会员 