+1 投票
分类:项目管理 | 用户: (190 分)
敏捷的原则与现实的扭曲

个人与互动:重于 流程与工具

开会是非常烧钱的行为,如果项目成员一多,要用什么方式降低沟通落差、尽量让每个人理解到的都相同?怎么确保部门和部门间的信息交流顺畅?靠出张嘴沟通就能办到吗?

可用的软件:重于 详尽的文件

有文件产生/解决什么问题?没有文件产生/解决什么问题?不写文件最爱用「我们是敏捷开发」当借口了,不会写就不会写、不知道文件写来干嘛就老实承认,少拿这个当说词。

与客户合作:重于 合约协商

如果客户没有在好的引导下一起合作,现实状况会变成「最后一次-确定最终版-说好不改了-V21.psd」。嗯?改来改去不就是敏捷开发吗?(喂)

回应变化:重于 遵循计划

这不是改来改去改到死的好理由!为什么要「变化」,变化是为了解决什么问题?没有问题改它干嘛?完全不代表可以没计划就上啊!

结论

敏捷开发宣言里各种许愿…拔掉敏捷二字不也是所有项目开发的理想?所以为了解决什么问题而采用敏捷式开发?为了改善工作流程加快效率?

那设计师修改到死的工作情况在敏捷开发里要怎么被改善?

我觉得敏捷开发适用「头脑清楚」的人,只是这种人往往是大神级的了。和大神 PM、大神 Planner、大神 RD 合作,都清楚知道自己在干嘛、别人在干嘛,还能 Cover 一点别人的领域,知道解决这个问题可以往目标更进一步,这种合作模式才有办法做到「敏捷」,而不是因为抓漏抓虫在修改。是啦这也算朝目标迈进,但「创新改 良产品」和「让产品看起来洞没那么大」的改来改去本质上是两回事啊!敏捷开发只是个方法,不是万灵丹。

敏捷式开发就是改来改去?

那「字大一点、Logo大一点、换一张照片、多出几版让我挑」也算啊~

你的回复

昵称(可选):
隐私:你的邮箱仅用于接收通知,不会被公开。
欢迎来到 Ogeek|极客中国 ,有什么不懂的可以尽管在这里话题,你将会收到社区其他成员的回复。
...