开发人员怎样参与需求讨论？

作为GJB5000A的实施者，我们都知道需求管理过程域要求“获得对需求的一致理解”，为了满足这一要求，我们通常的做法是让开发人员参与需求的讨论，并且期望在讨论中达成这一目标。

可是，这个讨论如何去做才是最有效的？

如果仅仅是用户代表或者系统设计师讲解需求，开发人员只针对不理解的需求提出疑问，双方就这个疑问达成一致理解就可以了吗？

这样进行需求讨论的结果能够让开发人员理解用户代表或系统设计师的需求，能够按照这个理解开发出软件来，但这个软件可能仍然存在这样或那样的问题，即使问题不多，它也只是一个基本完成用户的业务要求，但它绝不会是业务目标的最佳解决方案。

因为用户代表或系统人员由于缺乏足够的经验以及软件领域的相关知识，他们不可能提出针对业务目标的最佳解决方案。最佳解决方案还是需要具备业务领域知识的开发人员在与用户代表需求讨论的过程中挖掘出来的。

所以，开发人员参与需求讨论，不能只是被动地澄清需求的疑问，更应该深度去挖掘出用户真正想要的功能。

开发人员参与需求讨论的最佳方式是参与“用户故事”的制作。

用户故事是敏捷开发方法中常用的描述需求的方式。用户故事通常分为3个部分：

• 作为利益相关者；

• 为了实现某件有价值的事情；

• 我想要某个系统功能。

最佳的需求讨论方式是让用户代表负责“作为……”和“为了……”两个部分，而让开发人员负责“我想要……”，即用户代表负责背景和目标，开发人员负责解决方案。

用户故事	用户	开发人员
作为……	X
为了……	X
我想要……		X

当然，开发人员的这种参与需求讨论的前提是用户愿意积极配合，双方都以追求最佳的软件解决方案为目标。

如果用户不配合，无法采取共同制作“用户故事”的方式进行需求讨论，开发人员也要尽量避免无脑的接受用户的需求。

开发人员可以通过以下几种方式来帮助用户获取更好的解决方案：

• 询问高层次的实例。开发人员通过高层次的实例去了解某个功能如何产生实际价值。

• 询问替代方案。开发人员可以根据自己的经验对用户的期望提出替代方案。

• 不要只顾低层次的需求。开发人员不要只盯着需求的细节，要有大局观，综合考虑软件的功能和解决方案。

总之，开发人员参与需求讨论，不仅仅是澄清需求中歧义，达成需求的一致理解，还要深入挖掘出用户真正的需求，寻求最佳的解决方案。

这正是：

需求讨论是为何，一致理解第一波

到此不能就止步，最佳方案要挖掘

参考书目：实例化需求：团队如何交付正确的软件，作者：（塞尔维亚）Gojko Adzic，出版社：人民邮电出版社