快闪编程｜ 陌生人凑一起一天开发一个MVP的故事

​如果召集一波互相不认识的程序员在一起就一个真实项目进行一天的开发会产生什么样的化学反应？

会写出多少代码？

会完成多少用户故事？

能出一个MVP吗？

我们召集了38个人完成了12个用户故事。

前端代码819行，持续集成44次。

后端代码2814行，持续集成58次。

本次活动是临时组织的，大家非常踊跃的参与，最终活动开始时群人数达到38人。其中也有一些抱着学习目的进行围观的小伙伴。

到当天活动结束，基本上一个MVP就要交付了。这是如何做到的？

这个玩法叫做 快 闪 编 程。

2021年6月2日王洪亮和邓志国在一起突发奇想的想到一个编程的玩法 —— 快闪编程（Flash Mob Programming）。这是一种结合了快闪（Flash Mob）和Mob Programming二者的特点的一种活动形式。

召集一波对极限编程有兴趣的爱好者们一起就一个真实项目需求为基础，进行代码开发。看一天能够产出多少。而参加活动之前已经选好了约定的技术框架，编程语言，开发环境以及用户故事等一系列基础设施准备活动，参与者按照单件流的方式组对认领任务开始开发。必须要遵循一定的质量标准。

想要让一个活动就要有一个充分地准备活动。

首先，要有明确的需求和用户故事

没有明确的需求是无法进行任务开发的。

王洪亮担任PO，提出所有的用户故事需求，在活动开始之前一天，江鑫给提供了更进一步的需求细化工作，设计了整个产品的故事线，促进了需求理解，并且设计了相关数据库表结构。整个项目以教练在客户现场通过作业方式训练学员的项目为蓝本进行用户故事分解和需求细化。

本次由于准备匆忙，临时发起的，只是分解了用户故事和AC，没有确定UI布局。这给开发的过程中增添了不少确认工作。

其次，要有明确的前端框架，后端框架技术以及编码约定和提交代码约定。

编程语言后端采用了Spring Boot，前端采用了vite. vue3  element-plus。

后端基础脚手架由邓志国提供，采用了领域驱动设计的方式进行了架构划分。前端基础脚手架由崔效瑞提供，赵水平在该技术上搭建了前端的布局模板。

前后端各自进行了编码约定。

再次，环境要准备好

因为开发过程需要docker，但是很多同学docker并没有提前安装，这引起了大约2小时的环境调整工作，整个活动7小时，占比不小，如果能够早点准备好，相信产出还会更高。

另外，当天没有准备好持续部署服务器，就暂时缺少了前后端持续一起集成的过程。都是分开的集成和自动化测试。

还有，重点是任务的单件流

认领任务的时候应该从价值高的任务优先开始，而不是从简单的开始，但是很多小伙伴对技术的不熟悉，只能先从简单的任务开始，先熟悉任务再说，不过熟悉了技术之后，明显的下午开发的效率比上午高出很多辈，大家都相信，随着技术的熟悉，如果是两天的话，那么第二天效率会更高。

另外，持续集成和自动化测试一个也不能少

能够确保质量的手段中，持续集成和自动化测试都是居功至伟的。离开了自动化测试，集成就不会那么顺利。离开了持续集成，就不会那么容易的集成。

不少同学来之前对于持续集成的理解也就停留在持续打包上，对于自动化测试也只是听说过没有实际使用过。

活动总结

真实项目和FizzBuzz的对比

不少线下编程活动都是以FizzBuzz等训练TDD思维的简单题目开始的。很多参与者无法建立这个和实际项目之间的关系。而本次采用的是真实项目，大家参与的过程会有明显的在做项目的感觉，很多平时的工作的习惯都会在这次开发活动中得到体现。

反思

1. 现场还是远程由于受地理位置限制，参会者有6名到场，其他人员以线上方式参与。全程采用腾讯会议进行远程沟通。
2.  沟通和确认由于需求开始写的不够详细，尤其是缺少UI原型，开发过程中，很多前端同学会对界面应该是什么样没有意识。但是也缺少主动沟通的勇气，这造成了实际的进度延迟。后来在另外一些同学的推动下，界面得到了迅速确认，开发和集成效率明显提升了很多。
3. 勇气和习惯有的同学想要一次性提交所有的工作，但是却因为测试没有通过，而迟迟不能提交，时候该同学明确的意识到，小步快跑和批量提交之间的差异。
4. 架构的复杂度本次的需求为单体应用，按说用不到比较复杂的结构，MVC架构就可以满足要求，但是最开始设计的架构是一个基于DDD的架构。其中用到了很多领域相关信息。架构的复杂也是一个阻碍。不过很多小伙伴反馈通过这个架构学到了很多架构相关知识。
5. 环境的准备环境准备不足是本次时间消耗的一个重点。下次活动之前会准备一个环境清单，让所有参与者提前安装好。
6. 工作空闲还是人员空闲整个过程中，没有人关注谁没在干活。而是关注MVP是否被正确的实现了。小伙伴们会主动地认领自己觉得自己可以胜任的任务。并没有谁来分配任务。这个方式对你的项目管理有什么启发？
7. 只做必要的有些同学做了不少超出用户故事的内容。比如在MVP中对于表单校验并无要求，有些同学习惯性就加上了验证，实际上不校验也可以用。我们要做的是一个从滑板车到汽车到过程，每一步都可以迅速闭环。
8. 需要有人关注障碍优于报名的前端工程师比较少，导致前端成为障碍。如果有Scrum master，可以提早发现这个障碍，让一些在编写后端代码的全栈工程师换一下工作。对交付上会有帮助。

收获

1. 学到了Cucumber技术本次采用cucumber作为自动化测试引擎，语法简洁，上手简单。
2. 持续集成小伙伴们领略到了真正的持续集成。持续集成的结果随时反馈实际的质量情况。当问题发生的时候很快就有人来处理解决。
3. 分层架构分层架构虽然有点大材小用，但是实际上还是很好的推进了整个活动顺利进行的一个重要手段。因为分层架构很好的解耦业务逻辑和细节。让问题发生的概率大为降低。
4. 小步快跑每个人都在处理一个部分就提交代码，绝不会因为看到了或者想到了就去把旁边的任务一起做了。这样会让精力更集中，更好的交付最必要的特性。并且每个任务的完成速度都很快。
5. 只做必要的工作比如说：并发是否要考虑，是否要加乐观锁，这个问题。答案是不要。因为整个系统中没有并发的场景，并不需要因为乐观锁是解决并发问题的方案就加进去。
6. 自动化测试自动化测试是本次所必须的一个活动，所有的小伙伴都按照约定的形式进行自动化测试代码的书写，每个代码的提交都伴随着一组符合条件的测试。测试内容按照AC来书写的。

拓展思维

1. 企业内能否做到同样的效果我的思考是可以的，当然，上述的准备条件是必须的。来参加活动的小伙伴并不全都是资深工程师，很多都是经验不多的同学，但是一样可以在这样一个临时的团队中高效的工作。其中工作约定和自动化工具带来了不少帮助，拉高了质量基线。开发过程中团队很快形成了团队的一种默契和约定。这种默契和约定是保持高质量高效率交付的重要前提条件。
2. 除了这些还缺少什么条件除了上述这些条件，还需要的条件，我认为是一个比较好的企业文化，允许进行这种方式的尝试。