通信行业Agile实施思考(Customer Collaboration)

在通信设备行业实施Agile经常会有这样的讨论：

“SCRUM最重要的特点就是短周期迭代，为什么要短周期迭代？从敏捷最开始的一些开发者的著作中可以看到，项目迭代的目的是为了可以随时向客户展示产品，得到他们的想法，所谓“客户合作胜过合同”；另外一个隐含的来自PM，他要随时知道项目的真实进展情况。   现在的问题是我们往往和运营商签订的是一个详细的合同，并在指定时间交付，之前运营商根本不会看这个项目，第一个目的就无效了；如果单纯为了项目的控制管理，就不应该额外增加巨大的工作量，我觉得这应该是一个的基本原则，如果勉强去做，不如不做。硬件紧密相关，功能单一但是复杂的我认为都不适合SCRUM，另外我们每个Story往往都是Cell的Story很难对客户有真正的Value。”

其实问题往往归结于交付给电信运营商的日期是固定，Feature是Fixed的，甚至有时Feature还是要再增加的，但是交付的日期不可变。还有现实摆在我们面前，传统的电信运营商不太关心所有Features是否最具value，最关心的是入网测试那天Feature是否都Ready。

Customer Collaboration Over Contract negotiation: 看起来在通信行业里真的是不太现实，电信客户不可能减少他们Features和延长最终的交付时间，这一点在电信行业中表现的格外强烈。我想说的是，不仅仅是电信行业，还有很多软件项目的Requirement都是不可变的（比如：银行系统）。Customer 是广义的，包括内部和外部的客户。内部客户不是最终客户，但只要提出需求的都是客户，R&D面对的更多是内部客户，包括产品经理，兄弟部门或团队（测试、现场工程师等），甚至开发人员自身。对于R&D的Customer Collaboration来说，内部的客户合作占比重应该是更多一些。

咱们具体到Scrum的应用中来，Story的编写是一个高难度的活，要关注客户价值，要端到端可测。于是就有了这么一个问题：“功能单一但是复杂的我认为都不适合SCRUM，另外我们每个Story往往都是Cell的Story很难对客户有真正的Value。” 我觉得解决这个问题，首先要先鉴别出直接与你合作的客户是谁？如果和外部客户直接合作，当然是直接以外部客户的价值来驱动开发，编写User Story，这是最理想的状态。如果是和内部客户合作开发，最终交付给外部客户呢？我们的Story是否可以从内部客户的需求出发呢？我们的Teams都有分工，合作开发一个百万级代码行的项目，某些feature单独拿出来对于客户来说没有价值，但当集成了其他team的feature后，它的价值就体现出来了。如果考虑针在产品需求的基础上，再结合内部客户的短期需求来定义Story，不仅有助于Team间的不断集成，更有助于加强内部合作减少浪费。这样我们的Story point，business value就可能变得更具体生动。这里只是抛砖引玉，找出适合本组织的Story划分的方法，对咱们的Agile之路会有很大的帮助。

这里在就Story多说几句，我认为Story应该是从日常工作的场景中走出来的，不是从最初的系统设计和需求文档中生搬出来的。在遇到需求不可变的情况下，Product backlog里的value可以考虑结合日常工作中的内部客户的需求进行调整，推动项目中的团队们向同一个价值目标去努力，在不变中求变帮助项目尽可能减少浪费。

再来看看短周期的迭代，它的目的是什么呢？短周期的迭代，将缩短发布和反馈的周期，可以帮助尽可能早的暴露出问题。在产品最终面对外部客户前，必然要在系统集成时先面对咱们的内部客户。那么以短的迭代发布产品，获得内部反馈，暴露出问题不断改进，将必然有助于产品最终获得外部客户的认可。引入自动测试和持续集成等工程实践，对于快速反馈是非常必要的，持续的测试才能带来持续的改进。Agile宣言里接下来的一句话：Responding to change over following plan， 显得格外生动了。暴露出问题来，那就快速响应去解决吧，不要再等待到传统开发流程里的那些milestone了！

Agile不会改变你我他，回到现实工作中，试着按照成功的Agile实践走一段，再找出自己的路，可能才是银弹吧！ 呵呵 ！。（建党伟业观后有感）