项目规划是否被认为是一项“伞式活动”？

Question

伞式活动被定义为跨越整个软件开发生命周期的非SDLC活动。

考虑到这一定义，我们是否可以说项目规划是一项总括活动，因为计划在整个过程中不断变化？在软件项目管理中有什么总括活动吗？

Answer 1

SDLC的范围是什么?

第一个问题：软件开发生命周期(SDLC)是否都是软件项目的活动？或者仅仅是软件特定的子集？

围绕这一点存在一些困惑，因为在60年代的S早期的SDLCs之一本身就是(系统开发生命周期(也称SDLC)，发展之时，从前期计划开始，似乎是唯一严肃的工作方式。

我将接受第二种解释，所以只有SW指定活动，因为：

• 有权威的来源(PMBOK和ISO 21500)在一方明确区分项目管理(独立于外地的活动，包括规划)和另一方的产品制造(领域特定活动，即软件开发)。
• IEEE的软件工程知识体(SWEBOK 3.0)描述软件开发活动，并将计划作为管理活动(“管理架构”)。

项目规划是否符合标准?

根据上面的解释，项目规划不是SDLC活动，因为它并不是特定于软件的。事实上，完全有可能(尽管不一定是可取的)开发一个软件而不进行规划。而且--非常具有挑衅性--看看大型软件公司的一些严重延迟，人们甚至可能会想，规划是否不是一厢情愿的想法，与生命周期活动完全脱钩。

此外，计划是一个跨越整个生命周期的过程，不管你怎么做。你可以在一开始就做瀑布式的计划(然后每次你不得不承认事情不像预期的那样工作时，你就重新计划)。您可以分阶段完成(并在计划需要更改时进行调整)。您可以敏捷地完成它，一次只跑一次(但如果有些故事比预期的要复杂，则可以非正式地调整计划的范围)。因此，只有在项目结束后，规划才能完成。

因此，规划符合你对“伞式活动”的定义。这把伞的比喻纯粹是视觉的，一点也不贬损。

其他辅助资料：

• 规划是由PMBOK和ISO 21500定义为一个连续的过程。PRINCE2将其视为一个迭代过程。
• SCRUM认为计划是一个sprint事件。尽管如此，这并不是全貌，因为每天的scrum计划在接下来的24小时。
• 第一个“现代”(70年代)的SDLC (臭名昭著的瀑布 )确实用预期的产品描述了软件开发活动，并且没有将规划作为一个重要步骤。

Answer 2

我不认为项目规划是一项总括性活动，但这无疑是一项SDLC活动。

有许多不同的方法将SDLC划分为各个阶段，然后将这些阶段组织成不同类型的生命周期模型，从纯顺序模型到高度迭代的增量模型。然而，它们都有类似的活动--启动、构思和构思、计划、需求开发、设计、开发、集成、实现、操作和处理。

项目规划是项目管理活动的一个子集。其他项目管理活动包括项目启动、估算(成本和/或时间)、资源分配、风险管理、供应商管理、测量、监测和控制以及项目结束。

项目管理，作为一个整体，是一个伞式活动，延伸到整个项目生命周期。然而，并非项目管理中的所有活动都是总括性活动。有些活动可能会在不同的时间点再次出现，但反复出现(即使是有规律的或在节奏上)并不能使活动成为一项总括活动。

项目计划通常只进行一次。即使在迭代方法中，您也倾向于计划增量(例如Scrum中的Sprint )。然后，您就有了里程碑或事件，在这些事件中，您可以对照计划回顾您的工作并进行更改。不过，并不总是需要进行更改。

在我已经确定的项目管理活动中，我会将风险管理、度量以及监控和控制视为总括性活动。但是，根据执行这些活动时发现的情况，您可能会触发不同项目管理活动的发生，例如重新计划项目计划或资源分配，以调整项目可用的人员和资源。