项目启动
Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018
在名为 Project Initial 的初始阶段中排列项目的基本资源。
召开规划会议
在项目的早期阶段,应召集几个利益干系人和主题专家讨论该项目并制定产品计划。 根据项目的性质和复杂性及其产品可交付结果选择利益干系人。
根据项目的大小及其复杂性,会议可能需要几天或几周时间。
练习迭代开发
风险管理中的一项重要技术是在迭代中规划项目,通常为 4 到 6 周。 迭代计划是项目团队将开发和测试的功能列表。 每个功能指定任务或改进后的任务变体,用户可以使用该产品完成。 在每个迭代结束时,将演示计划的功能。 在一些迭代结束时,部分完成的产品由一组有限的用户发布供试用。
这些演示和试验的反馈用于审查该计划。
产品计划是安排的,以便主要用户方案和系统的主要组件在早期执行,即使仅以简化的方式进行。
大多数项目中最重要的风险之一是误解的要求。 不仅可由开发团队和最终用户和利益干系人误解要求。 他们很难想象其业务活动如何受到新系统的安装的影响。
此外,业务上下文可能会在项目的生命周期内发生变化,从而导致产品要求的变化。
迭代过程可确保通过演示产品在项目结束前可以适应所发现要求的任何调整,而不会产生重大返工成本。
另一个重大风险是低估计的开发成本。 对于在新领域工作(也许在新平台上)的开发人员来说,在项目之前估计开发成本可能很困难。 在某些情况下,很难确定特定实施策略是否能够很好地执行。 但是,通过在每次迭代结束时查看计划,团队可以考虑之前迭代的体验。 此活动是一个很好的产品计划在早期阶段安排每个主体组件的一些工作的原因之一。
此项目范围是驱动还是日期驱动?
某些项目要求所有要求在交付之前必须正常运行。 这些类型的项目在软件上下文中是不寻常的。 实际示例可能是构建桥梁。 一个半完成的跨度是无用的。 相反,一个半完成但已正确规划的软件项目应该可供一组有限的用户部署和使用。 然后,可以在多个升级过程中以增量方式完成它。
首先确定项目是否真正由范围驱动。 如果是,则必须等待确定结束日期,直到有详细的估计和详细的计划。 你为等待付出代价。 计划开销增加,计划缓冲作为应对不良估计的应急措施将推出更多的交付日期,从而增加成本。 因此,在确定你有一个范围驱动的项目之前,请务必。 在复杂的系统工程环境中,它比纯粹的软件产品或服务情况更可能。
大多数软件项目都是日期驱动的,因为它们可以增量交付。 例如,如果计算机游戏将在美国中为假日季节发布,则必须在 10 月前准备就绪。 10月份未能交付将严重影响万圣节和圣诞节之间的销售,如果时间表滑落两个月,机会窗口可能会完全丢失。
规划项目资源
项目应配备人员,以便按所需日期交付项目。 应使用以前的项目的历史数据来告知讨论足够的资源。
了解员工要求后,请创建一个项目组织结构图,以明确标识项目团队结构、资源级别和地理分布(如果合适)。 将所有人员配备信息保存到项目门户。
定义角色和职责
描述每个项目角色及其职责,并在项目计划中发布它们。 加入项目的每个人都应了解其在项目中的角色和职责。
定义通信计划
必须定义项目的通信计划。 通信路径有助于管理项目的协调成本。 必须定义谁应该参加会议、会议召开频率、沟通路径以及如何升级任何会议通常与会者无法解决的问题。
良好的沟通计划的目标是确保项目上的协调活动尽可能顺利地运行,并通过错误沟通避免浪费的努力。
通信计划应发布到项目门户,并根据需要进行维护。 沟通计划是适用于所有员工、新成员的有用工具。 它可以帮助他们了解更大的团队的工作原理,以及如何通过以不同方式与不同的团队成员进行适当沟通,以及如何实现工作,以及实现不同目的。
标识利益干系人
确定所有相关项目利益干系人。 与核心团队成员一起,该列表应包括对项目成功实施感兴趣的业务人员和技术人员,或者产品进入服务后可能具有的效果。 这些利益干系人可能是软件工程活动的上游或下游。
概述项目计划
创建第一个项目计划的草图版本,可在开发启动时进行修改。 此版本的目的是帮助与项目发起人讨论资源和时间刻度。 它应概述主要功能及其估计的交付日期。 有关详细信息,请参阅 “规划项目”。
查看项目计划
在项目门户上发布项目计划的大纲。 虽然很多工作已经进入该计划,但它仍然是一个高级计划,推迟了许多详细的计划决策。 这种尊重是有意的。 现在太多细节以后会产生浪费。
如果要求不确定,请仅以大纲方式规划这些要求,详细信息应推迟到更多信息可用。 计划获取该信息。
与所有利益干系人安排评审会议。 面对面会议始终最适合此类活动。 请务必安排足够的时间,以便进行全面审查,并允许听取不同意见。
获取项目承诺
现在,项目计划已与项目利益干系人达成一致,请从每个利益干系人获得承诺,以批准项目计划。
收集承诺,并在项目门户中存档详细信息。
其他资源
有关更多信息,请参见以下 Web 资源:
特色驱动开发的实用指南,斯蒂芬·帕尔默和约翰·马尔科姆·费尔斯:Prentice Hall PTR, 2002.
IT 度量手册:通过功能大小度量、曼弗雷德·邦舒和卡罗尔·德克尔估算和基准测试成功:斯普林格,2008年。