工作有感 | 伪Agile SI项目的痛与思

最近5个月在忙的项目很快就要roll-off了。回首这5个月，我从一开始的extra resource到后面的offshore lead，中间真的发生了太多太多来不及思索的故事和插曲，今天想提笔将能想到的坑与雷一一列出，以便后续不要重蹈覆辙，将错误的苗头扼杀在摇篮里，同时也试着回忆并记录下自己在这5个月的成长和感悟。

项目简介：offshore Dev team(mainland)与onsite BA team(HK)通力合作的非典型的e-commerce实施类项目。以伪Agile的方式去run整个project，在我看来就是将一个大的项目拆成了小周期的waterfall去执行(但这也是很中期的时候才想明白的)。

本人背景：在此项目之前，绝大部分所做的事情都属于被管理者所做的范畴，基本上都是亲力亲为。从技能领域来看，大部分时间所担当的角色都是业务顾问(BA)，同时也会穿插着做做数据分析类的项目。毫无扎实的技术背景，所了解的开发相关的技能也都是在之前项目上看猫画虎学到的。但自认逻辑功底强，且可接受建议和有技巧的反驳。

下面将以想到啥就写啥的方式，列出一些未来可改进的地方，正所谓前事不忘后事之师。

---

如果规划的有问题，那么拼命按照这个错误的规划去执行就真的是痛苦。但当不可抗力的时候，就试着去接纳它，夹缝中求生存。

刚刚来到这个项目的时候，当时给我的position是去解决remote communication衍生出来的问题，比如确保开发是真的理解需求，也同时兼顾一些solution的制定。快1个月过去(原计划3周一个sprint)，大家痛苦不堪。从表现上来看，交付一直在delay且质量不高；同时offshore团队又在一直加班；整个offshore团队的戾气很重，经常吵架——开发埋怨BA的Story写的不清不楚，QA埋怨开发交付质量不高，retest成本很高；BA则一直赶下个sprint的需求确认；大家也都会埋怨时间紧任务重。而我夹在中间(一开始将自己看成一个三不沾的角色，想的就是怎么加快进度，解决沟通问题)。后来通过理性的分析(现在也不见得是对的)，但是先考虑一些造成这种情况的原因：

1.    完全没预估到的沟通成本，具体包括前端和后端的沟通成本，测试和开发的沟通成本，测试和BA的沟通成本。
2.    完全预估不准的沟通成本，主要就是后端和BA的沟通成本。

而造成这写问题的根本原因(目前想到的)：前端、需求、后端、测试几乎在同一个Sprint去完成HTML、JSP、Story编写和Grooming、开发以及Fix In-Sprint defect。而这一切都是在几乎同一个3周内完成，且3周的Capacity被排的满满，但凡由于dependency造成的一点delay都会因为连锁反应导致整个链路每个环节都会有问题，回想起那段痛苦岁月真的是头皮发麻。

说到这就要点题了，这个plan做的是有些糟糕的。一开始只是闷头按其执行，完全没觉察其中的不合理的地方，就是想100人天的东西给你100人天来做，怎么还是处处有问题，到底是团队有问题，团队有问题还是团队有问题呢？

-    明明前端就要很提前于后端去完成HTML并且交付给后端的是要pass vQA的HTML；
-    明明就应该在一开始就明晰前后端界限处的功能，比如JSP是由谁来完成，而不是看人情，看状况来区别对待；
-    明明Story就要拿到Product Owner和Delivery Lead两方的signoff才能进行到开发阶段，而不是只是快速的go through一遍所谓的story就开始马不停蹄的码代码了；(这点后面会详细讨论story的重要性和问题)
-    明明QA就是应该和开发错开1～2周去完成In-sprint test，怎么可能QA和开发是完全同期并行的节奏，如果这样那capacity的计算就应该提前考虑；
-    明明QA就应该一起参加Grooming Session，且作为重要角色是一定要的，就是因为测试无法按期完成(当然原因也是开发给的晚)就不参加Grooming，后面还需要额外的投入去做这件事情

不禁想问明明是谁，哪里来的野鸡怎么这么多戏？

---

Story，一切的起点，同时也是罪恶的根源。此Story真的不是小说，请不要效仿曹雪芹写红楼梦一样好吗？请考虑写Story的目的是为了让别人看且能看懂，都不要求让别人愿意看好吗？[手动狗头]

每每想到这个Topic我就心痛的不能呼吸，刚来项目的时候真是too young too simple。被第一次见的高大上的JIRA和Confluence冲昏了头脑，想这么高大上的外表里面包括的一定是不俗的内心，但是我真是信了你们的邪。

-    Epics的定义已经有overlap和not reasonable的地方，但这不重要
-    每一个Story对于Business的重要程度真的是天差地别，但这不重要
-    有些Story有裹脚布那么长，有些Story只有吴昕在快本的台词那么短，但这不重要
-    有些同一Epic的Story居然前后矛盾，这有点重要
-    有些Story在每个Sprint都会做一部分功能，或者推翻/改进之前的功能，浪费，这比较重要
-    有些Story居然不更新，这真的要掀桌子了

此处同时想问，以上的要求真的仅限于Story能表达清楚需求，真的没有要求去考虑偏technical的solution。但可能这也是后续问题的原因吧，做BA的，如果真的只看需求，不看落地，除非你们是甲方需求爸爸和甲方IT爸爸，否则真的会出问题的，而且你就不好奇需求是怎么被实现的吗，咻—，就像变魔术一样。

在这过去的5个月，Story的问题深深困扰着我和我的生活。有时候看到那些莫名的需求和偏白目的问题，类似“为什么不能这样做呢”，我只想微笑着消音。这不禁有人会问(有没有人看都是一码事，居然还想着有人会问)，这需求不清楚和你有什么关系？你管好自己的部分不就好了吗？这不禁要引出下一个话题——

---

规矩请立在前头！！！不要等所有人都形成思维定式时才意识到骑虎难下！！！同时自己挖的坑，再大也要自己把它填上！！！

未完待续……