五千年(敝帚自珍)

主题:【原创】闲聊敏捷开发——SCRUM(一) -- 哈酷

共:💬141 🌺325
全看分页树展 · 主题 跟帖
家园 回答一下

传统模型对待需求变更的解决方案是--“商务谈判”,在开发前你得把需求定下来,如果中途有变更,要么排到下一版本开发,要么加钱加时间(这里的钱和时间会让客户有肉痛的感觉,呵呵)。

对,这也是一种平衡,只是效率很低,遇到大量频繁的改动,不可能频繁的谈判。

但在一些规模稍大的项目中,如果用户的需求变更影响到架构需要重新设计或做大的修改怎么办?

无论如何分解,都无法避免这种修改的成本很高,这种成本将以point的形式直接让客户看到,客户有权力选择进行或者不进行,如果执意进行,那么要么追加工作人员或者工作时间来‘充实自己的钱包’,要么踢掉其他优先度低的需求。除此别无他法。(当然也可以逼迫员工加班,这个后果就不说了,大家都知道)

国外那种几个人十几个人完成个比较大的项目或创意的团队,那更是个人能力的体现

能力是不可能通过管理方式来短期提高的,能力差的就做的差点,能力好的就做的好点。这是无法回避的。但能力好和差只是个程度词,在能力范围内如何把事情做的更好,才是要讨论的问题。

而需求变化是项目环境恶化的因素之一,而同时创意就是以需求变化的形式产生的,如果好的创意都能是在项目一开始就能做出,那么就不存在需求变化,那么不在我的讨论范围之类。我一开始就已经说过既然要讨论,就要把项目环境考虑的糟糕一点。

在需求变化很多的状态下,极容易出现一种情况,就是原本可以干更多更重要的事情,却被不那么重要的事情耽误了时间,这才是SCRUM要解决的。

全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河