如何更好的控制基线后的配置项

iamredeye · 发表于 2008-5-22 17:44:32

迭代是比瀑布难玩一些，玩的不好也许就变成了假迭代，真瀑布。

关键是，迭代的phase和瀑布的phase关注点是不一样的，没弄清楚这一点就比较麻烦了。迭代关注的是risk，瀑布关注的是deliverable。

但baselining基本上还是差不多的－－从change control的角度讲

xixiaojing666 · 发表于 2008-5-26 14:21:04

原帖由 iamredeye 于 2008-5-22 17:44 发表
关键是，迭代的phase和瀑布的phase关注点是不一样的，没弄清楚这一点就比较麻烦了。迭代关注的是risk，瀑布关注的是deliverable。

有时间给我们详细讲讲他们关注点的区别！:lol

iamredeye · 发表于 2008-5-27 10:49:00

这个有点难度啊:Q ，人家可是用一本书的篇幅在讲

xixiaojing666 · 发表于 2008-5-27 11:01:02

原帖由 iamredeye 于 2008-5-27 10:49 发表
这个有点难度啊:Q ，人家可是用一本书的篇幅在讲

你可以挑一两个关注点给我们讲讲呀!:lol

iamredeye · 发表于 2008-5-28 16:50:06

刚好看到一段话，觉得很有意思：“我经常说管理一个瀑布式的或者传统的项目，在项目的前80%非常直接而有趣，在那段时间内，任务是线性的，在一段时间内你可以集中注意于一项规则（比如需求）. 然而当集成和测试开始的时候，你会经常发现不是模版不能整合，测试很费劲，系统架构有缺陷，执行效果很差，就是用户提出这个应用不是他们所需要的。如果你在管理一个瀑布型的项目，你在项目临近结束的时候，需要找一个借口将这个项目转交给另一个可怜人。”

我记得这个论坛里有不止一个人说过他们的项目是高层领导，后来因为“时间问题”，“只好”把撒手不干。。。

iamredeye · 发表于 2008-5-28 17:14:05

我试试吧：）

瀑布在每个phase结束的时候都是期望相应的文档能够baseline甚至finalize。听起来很美好，流程很清晰，但这也带来了后期问题，主要是requirements / architecture change和quality issue。

迭代认识到了这些问题无法避免，与其消极的等后期来解决问题，不如提前confront the problem。所以迭代的phase不是按照discipline来划分时间线，而是按照风险的解决程度。比如conception解决或更准确的说降低的是business risk；elaboration 是technology。每个phase会按照需要跨多个discipline。

[ 本帖最后由 iamredeye 于 2008-5-28 17:29 编辑 ]

xixiaojing666 · 发表于 2008-5-29 08:44:39

感谢一下!
继续支持:victory:

jiayan2000cn · 发表于 2008-6-13 17:06:12

这些内容我现在比较关注!

xixiaojing666 · 发表于 2008-6-18 09:23:20

原帖由 jiayan2000cn 于 2008-6-13 17:06 发表
这些内容我现在比较关注!

你可以在这里提出你的关注问题，或经验分享呀！:)

惹你见笑 · 发表于 2014-4-25 15:06:40

还不错哦，如果再能多分享一些就perfect了！

命犯挑花 · 发表于 2014-6-6 14:30:38

看起来好像不错的样子

飞花弄影 · 发表于 2014-6-30 09:37:58

路过的帮顶

[旋木] · 发表于 2014-8-18 11:13:04

看帖要回，回帖才健康，在踩踩，楼主辛苦了！

十指紧扣 · 发表于 2014-8-20 16:52:38

前排支持下了哦~

漫长的青春。 · 发表于 2014-8-25 16:27:11

向楼主学习

如何更好的控制基线后的配置项

逛了这许久，何不进去瞧瞧？