对于敏捷实践的思考

对于敏捷实践的思考

前言

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

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

实践

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

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

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

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

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

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

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