我们的项目方法最近从瀑布模型迁移到敏捷,开发和QA团队在这方面得到了适当的培训。现在,敏捷策略之一是“小反馈周期”。但是我们的产品负责人在2-3次冲刺后仍然给予反馈。这反过来导致应用程序中的主要功能更改,有时我们必须从头开始处理特定的模块。
有办法处理这件事吗?在提出重大功能改变之前,如何进行适当的影响分析?还是在反馈周期大的情况下,只使用瀑布模型更好?
是否需要对客户进行敏捷方法学的培训,就像培训开发人员和QA团队一样?
发布于 2016-12-22 09:38:34
是否需要对客户进行敏捷方法学的培训,就像培训开发人员和QA团队一样?
简单的回答:是的。只有当每个参与者都参与进来时,敏捷才能发挥良好的作用。而且,由于敏捷主要是关于沟通和客户参与,所以如果他们不参与,它就不会起作用。产品负责人是团队的一员。
如果决策者太忙或太不关心而不愿参与进来,那么就可以指派一个代理产品所有者来扮演客户的角色。但她必须承担责任,并且应该充分了解客户和他们的需求,以便为他们做出决定。
因此,您应该首先尝试一切,让客户了解过程和反馈的重要性。然后积极地让他们参与进来。首先,请他们参加sprint评审,而不是使用像电子邮件这样的异步通信。
发布于 2016-12-22 17:35:45
顾客是否觉得这起作用了?作为一个客户,我会想出一个更好的系统,所以我不会付钱让你做更正和重做的事情,本来可以指出更早。
你可以试着让你的短跑更长一点,只要它不会太长。此外,没有法律规定冲刺必须立即跟随下一次冲刺。如果你完成了一次冲刺,而客户在两周内无法见面,那么将开发暂停。
他们要么让自己有空,要么忍受拖延。否则,他们会为那些可能会陷入更短反馈循环的事情付出额外的代价。只要他们理解,并愿意支付额外的钱,在某个时候,这不是你的问题。
https://softwareengineering.stackexchange.com/questions/338647
复制相似问题