WBS 和职能规范以及主项目计划之间的可跟踪性
职能规范、主项目计划和 WBS 之间存在一个可跟踪的关系。它反映了交付内容和构建交付内容所需任务之间的关系。
对于职能规范里的每个特性或者组件，WBS 列出了与完成该交付内容相关的任务。在职能规范里，特性或者组件被分组的方式同与它们相关的任务出现在 WBS 里的方式不同。
如果一个特性在 WBS 里没有与之相对应的任务项目，那么它可能会在后来的估计过程中“掉入裂缝”，而这可能会导致不切实际的日程安排或者预算。
主项目计划和 WBS 以一种互补的方式工作。WBS 会简要地列出每个任务。任务如何进行、质量标准和详细的子任务或者清单等的详细信息都被归档进了计划。
图 6 是 WBS 能够如何成为维护规范、计划和日程安排之间可跟踪性的强大工具。
构建工作分解结构
每个小组都会识别生产项目交付内容所需要的特定活动。活动的具体细节都由各种角色或者子小组以清单和项目的形式所有和跟踪。
在 MSF 里，层次最低的活动出现在主项目计划里，而不在 WBS 里。这些会合成为值得在整个项目层进行跟踪和报告的大型任务，这就是 WBS。
小组领导与其他角色小组碰面，以分解工作要求。通过与职能规范和其他交付内容的规范一起工作，所需要的工作就要被识别和分解成微小的活动和任务。这一过程就叫做工作分解。
MSF 风险管理过程的结果之一就是其它响应风险（有时候也叫做“威胁”）或者意外计划和活动的任务。这些任务必须像其他所有的任务一样被加到 WBS 里，被估计、规划和列入如日程安排。要考虑连续开设小组工作分解讲座和风险集体讨论讲座。
WBS 的第一层应该包括项目生命周期的一个阶段。MSF 过程模型在这一点上做得很好。MSF 所建议的中间里程碑与交付内容的完成以及基准的制定是密不可分的。中间里程碑还会构成一个自然的第二层。在这一层次之下，可以识别所有的交付内容并针对每一个都分解任务。这一过程也叫做工作分解或者任务分解。
任务分解指南
在进行任务分解的时候，建议采用下列指南：
| • |
能够被实际地估计。 |
| • |
被认为不会少于一天，不会多于 40 天（对于 IT 项目而言）。 |
| • |
有成果丰硕的结果和交付内容。 |
| • |
能够被完成，而不会有较大的中断。 |
| • |
可以被分配给一个人负责其完成。 |
| • |
要比其他的更能够分解为特定的层次。 |
| • |
能够把高风险的活动分解为其他低风险的活动。 |
| • |
除了最上面的一个或者两个层次，要使用一个动宾短语来描述任务。例如，使用“设计数据库架构”，而不是简单地用“数据库架构”。 |
| • |
以大纲的形式包括三到五个层次。 |
| • |
WBS 会在项目过程中反复发展，但是会在规划阶段中定型。 |
从下到上的估计
IT 项目的估计应该由那些日程安排里规定的人员来进行。从下到上的估计是对来自多个小组成员的估计进行开发和集成的过程。它带来了下列好处：
更高的准确性。 由那些专门人员作出的估计要更加准确，因为进行估计的人员具有从事类似工作的经验。
责任。 开发自己工作估计的人会感到他们对自己工作的责任更大。他们也会对成功达到自己作出的估计感到更大的责任。
赋予小组权力。 拥有由小组开发的日期而不是由管理指定的日期会赋予小组权力，因为日程安排建立在小组成员能够接受的实际估计之上。
集成小组估计
每个小组领导及其子小组，对准备完成其角色领域里的交付内容所需的时间估计负有职责。例如，开发领导会为开发人员准备估计；用户体验领导会利用来自小组的信息为用户体验 (UE) 交付内容准备估计等等。
程序管理角色会推动小组估计过程，并把所有的估计集成（“累积”）成为一个主日程安排和预算。
软件项目的估计
IT 项目的成本在很多程度上由劳动成本构成，所以对工作努力的估计是获得成本和日程安排估计所必需的数据输入信息。
设置正确的预期
估计会为未来的某种结果设置一些预期。由于这个原因，设定一些关于估计准确性的正确预期与生成预期所需要的技术一样重要。程序和产品管理角色群必须努力工作以确保下面这些内容的共同预期：
估计要依靠规范。 开发 IT 解决方案和自定义建造一个房屋很相象。在特性被仔细定义之前就了解其成本是很重要的。这不是说规范就是项目估计所需要的所有东西。其它的工作项目，例如客户沟通、项目会议、状态报告等，都需要花时间，而且必须在估计里予以考虑。
为折衷做好准备。 利用折衷矩阵来讨论折衷三角形和设置默认的优先权有助于小组和客户设置共同的预期。
某些不精确是无法避免的。 由于解决方案的开发是一个不断改进的过程，所以估计包含有一定的变动空间。
在每个里程碑处重新估计。小组应该随着项目的进展而提供一系列经过更多改进的估计。
文章来源于领测软件测试网 https://www.ltesting.net/
