对于敏捷实践的思考

前言

在ThoughtWorks任职的时期,学习到了非常多的软件交付项目关于敏捷实践的内容。说起敏捷实践,本身与老东家ThoughtWorks有千丝万缕的联系,ThoughtWorks的创始人,也是IT界享有盛名的 Martin Fowler,就是是敏捷宣言的签署者之一,可谓“根正苗红”。在敏捷实践的推广和技术文化分享上,ThoughtWorks一直也做的不错。就我个人在公司的体验上,所有项目的开发实践,都是围绕着敏捷实践的流程来的,自己也享受了很多由完整的敏捷实践带来的好处。

那么我想到一个点,如果我在之后的项目中,能由我作为项目的技术leader来推行敏捷实践以及相对应的团队和项目敏捷管理的方案。我应该怎么做呢。

实践

首先是团队本身,需要保证一定的规模。我以前有过一个开发项目随着人员地不断增多,后来一个敏捷开发团队,拆分成两个小团队,分别进行迭代开发,以此保证团队的沟通和协调顺畅。

使用看板工具,比如Trello or Jira这样的工具网站来管理项目迭代的流程。这一点非常重要,毕竟整个项目的开发流程是围绕着看版管理工具来进行的。比如该有的In Analyze To do Doing Done 等等关键状态,这些附带的测试和业务需求对齐的点,对于整个团队的开发效率和质量都至关重要。

pAM6Wsx.md.webp

对于故事卡的拆解,这个建立在整个需求和迭代的背景上,我们对于每一个可以拆分出来的开发点,进行转化为一个个的故事卡,而故事卡就是放在看版工具上的卡片。我们在每一个故事卡上,用简单的语言描述功能,比如“完成网页的登录功能(前端部分)”,然后在卡片上,完善一些细节的补充,比如是否关联一些功能,比如鉴权和API等等,这些卡片上的需求对齐,也是故事卡片在被开发人员准备开发之前,需要做的一个重要流程。故事卡本身的拆分和书写,应该由项目技术leader或业务人员一起对齐过,然后呈现在迭代之中。

关于日常的流程,团队应该每天早上有个短暂且精炼的站会,讨论今天的计划和一些项目上可能的阻碍,并且由站会的主持人来分享屏幕,展示迭代开发的看版状态,每一个成员对于自己负责的卡进行一个更新。在这流程,如果哪一个成员负责部分有一些需要介入的部分,也可以及时帮助和更新。然后一天的主要时间是做交付,到了下班前的一小时左右,可以进行一个code review的会议,每个成员来分享展示自己今天的交付内容,对于一些困惑的点也可以分享给团队成员,以此来获得一些建议和启发。同时分享代码也可以让大家共同拥有一些各自负责需求的上下文。

关于项目的管理,应该加上持续集成和一些自动化测试,当然对于测试,可能要在意的是工期时间。良好的CI/CD则能帮助迭代开发的质量提升。

维护好项目的看版系统和文档系统,优秀的文档也能帮助后续新加入团队的伙伴,更好地融入项目。当然文档这一块也要看项目本身的需求和开发时间管理。

还有一些之前参与过的项目的敏捷实践内容,这里就不展开了。 我感受到的敏捷实践的核心,是“小步快跑”,也就是逐步完成。定时的反馈和总结。以及团队的自组织等等方面,都影响着整个开发项目的敏捷实践的成色。我想到的是,在一个项目里,如果真正推行敏捷实践管理,则要结合实际情况,不可以搞一个“水土不服”的敏捷实践出来,这样非但不能发挥敏捷实践的效果,还会让团队怀疑和不甘地执行敏捷流程,影响开发效率和质量。好的敏捷流程,就算是一个人的项目也可以顺利进行。重点还是如何去将敏捷实践结合实际团队和项目的情况。