菜鸟关于Scrum的一些疑惑，希望大家给我指正。

keledie 2017-12-18 05:06:57

我们公司实行了一段时间的Scrum，大家只是看了一些书，一些原则，就开始执行。可能是断章取义，导致现在的工作感觉不伦不类。也许是我的想法还停留在瀑布的模式中，希望有经验的人能指点一下。

1、持续交付：我们的用户主要是一些官僚部门，软件使用前必须领导点头。为不让领导批评，办事人更愿意拿一个他认为完整的系统让领导确认，即使一些系统设置（即便是半年内不会调整）这样的功能也要完成。再有这些软件使用人往往不只是自己部门的人，他们不愿意将一个半成品推下去，导致大家对他们工作产生一些非议。也就是说，在没有完成90%工作前，他们不愿让领导确认，领导不确认就没有办法推广，就获得不了用户的真实的体验。
而需求对团队来说还非常陌生，以往我们的原型设计稿一般经过3版后才能和用户达成共识，经常感觉大家说道一起了，但是说道后面的工作时发现前面的东西实际双方是有偏差的。另外一个系统中的各个功能之间有千丝万缕的关系，在没有系统时，人处理起来很多东西只是感觉，有问题变通处理就行，有系统就不同了，不把这些关系搞清楚后面很容易返工。
问题：是不是敏捷也需要我们弄清客户想做什么，至少一个完整业务功能后才能进入开发阶段，研发工作可以持续交付。

2、计划会：我们的计划会开的时间太长，用户故事是说清楚了，在估算工作量时，发现大家的实现思路千差万别，自然花费的时间也就不能统一，最后计划会变成了一个业务扫盲会和方案确定会。为实现一个用户故事，大家在这个功能应该是什么样子的常常分歧较大，一旦确定好了，技术上容易达成共识。
问题：是不是在计划会时，应该将系统的UI已经设计好了，大家只是讨论如何实现，当然也希望提出意见。

3、文档：这点我们做的可能有些离谱，借口是面对面的沟通胜过面面俱到的文档。我们几乎没有文档，在测试前由研发团队告诉测试人员主要业务，测试人员按照自己的意思去测试，没有人知道测试了哪些，哪些没有测试。后来发现很多前期讨论的注意点都被忘记了。
问题：是不是应该规定下一些必须的文档，如业务的约束，一个业务执行的条件、特点、影响等，起码在功能完成后可以检查一下自己的程序是否达到当时的预期了。

4、拥抱变化：做一个产品我可以理解这个问题，而我们是个性化开发。对方牵头人的想法直接会影响我们的软件开发，再加上一个软件项目有很多的不确定性：开发完成后，用户推广时发现领导不关注了，其他部门不配合，然后借口软件不符合要求；在执行中用户核心主导人发生变更，全面推翻以前的系统；在研发后期用户的管理规定发生变化，导致系统不适合……。但是自从签订合同后，软件的价格就已经确定，每次修改就意味着成本的提高，如果要加钱，即使用户愿意追加，也需要有证据说明我们有变动，以前他们的想法和现在我们实现的一致的。
问题：是不是即使是敏捷，我们也必须和用户在需求和方案上达成共识，并确认。至于是否可以收到返工的钱并不重要。

我个人认为敏捷的核心是自管和持续改进，至于上面提的只是实现方式，应该找出符合公司的方法，发挥敏捷的作用。

...全文