美文网首页
工作有感 | 伪Agile SI项目的痛与思

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

作者: 焦虑的郭大妈 | 来源:发表于2019-12-12 10:57 被阅读0次

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


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

    未完待续……

    相关文章

      网友评论

          本文标题:工作有感 | 伪Agile SI项目的痛与思

          本文链接:https://www.haomeiwen.com/subject/wixquctx.html