IT项目管理个人报告

最新推荐文章于 2021-03-19 10:57:02 发布

chenzhx_

最新推荐文章于 2021-03-19 10:57:02 发布

阅读量168

点赞数

本文链接：https://blog.csdn.net/chenzhx_/article/details/107800751

版权

本次大作业我参与了团队作业2，调查至少3种竞争产品或类似产品，如 Agilo for Scrum 等，聚焦产品特色、业务支持和工具，给出产品对比分析报告。

在第四次团队作业中，主要做的是需求团队的工作，准备“故事板”。

我们决定做校园服务软件，根据之前团队作业收集的需求准备故事板。

以下是确定故事以及估算故事点的方法与经验：

故事点是任务安排和绩效的重要依据，必须符合SMART原则：

Specific(具体、明确) 范围要清晰，即活动的输入、输出明确，业务目标或技术要求清晰。

Measurable (可度量，可估算) 对活动的时间、工作量等属性有量化或定性的指标。

Attainable(可达的) 活动的目标预期是可完成的。

Relevant (相关性) 活动是当前最必要的，这对敏捷方法尤为重要！

Time-bound（DDL明确）。

每个故事需要确定故事范围、重要性、时间估计。“故事板”中，重要性是我们评出的一个数值，指示这个故事有多重要，分数越高越重要。时间估计在“故事板”中由Initial estimate（初始估算）体现，这是团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点（story point），一般大致相当于一个“理想的人天（man-day）”。

每个故事必须确定输入-操作-输出，以及一些非功能约束，这部分对应“故事板”中how to demo部分，它大略描述了一个故事应该如何在 sprint 演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果 ”。通过这些描述，可以更清晰的确定故事的范围，避免团队成员对范围理解产生误解。

如果有重要页面的原型，以及涉及的数据模型与事务，也需要补充到故事板中。

故事不应该太短，也不应太长（从估算的角度出发）。

很大的故事基本上都能进行拆分。只要确定每个小故事依然可以交付业务价值就行。

故事点估计：

故事可以被拆分成任务，故事是可以交付的东西，任务是不可交付的东西，根据每个故事具体的任务来估计故事点。

团队中估计故事点的方法：计划纸牌

在估算故事的时候，每个人都选出一张卡片来表示他的时间估算（以故事点的方式表示），并把它正面朝下扣在桌上。所有人都完成以后，桌上的纸牌会被同时揭开。这样每个人都会被迫进行自我思考，而不是依赖于其他人估算的结果。

如果在两个估算之间有着巨大差异，团队就会就此进行讨论，并试图让大家对故事内容达成共识。他们也许会进行任务分解，之后再重新估算。这样的循环会往复进行，直到时间估算趋于一致为止，也就是每个人对这个故事的估算都差不多相同。

估计故事点时，不可牺牲内部质量来缩短故事的估算时间。现在节省下来一点时间，接下来的日子里你就要一直为它付出代价。一旦我们放松要求，允许代码库中暗藏问题，后面就很难恢复质量了。

如果团队中提出要缩短故事的估算时间，我们可以考虑能不能把范围缩小一点，这样实现时间就能缩短。也可以考虑简化一些功能，把一些功能更具体的实现当作一个单独的故事，放到以后再实现。或者也可以降低其他故事的优先级，让团队集中处理当前的故事。

整个项目过程中的一些方法经验总结：

在项目启动阶段，我们要对项目进行可行性分析与成本研究，要确定项目的范围，调查初步需求，制定项目章程、项目管理计划等。