本文主要是介绍拒绝加班：是不是只有“全栈”工程师才能实现软件开发的“单件流”，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在上篇文章中，我讨论了使用“单件流”的理念来提高软件开发的效率。相对于一个人负责一摊的“批量生产”模式组织软件开发的方法，使用团队合作的“单件流”模式会有以下优点：
- 更高的研发效率
相比“批量生产”，“单件流”会有更高的研发效率，这是因为“单件流”会减少库存，运输，移动等浪费。 - 提前交付
做完一个功能就可以交付一个功能，客户可以立即得到收益。 - 尽早发现问题
单件流要求持续集成，以交付为最后完成标准，所以问题会提前发现，而不是等到所有功能开发完毕以后的集成测试阶段才发现问题
但是，很多开发者认为单件流就需要“全栈”，这不是回到了远古时代，现代社会应该分工协作才对啊。笔者下面尝试回答这些问题。
单件流必然要求“全栈”工程师吗？
单件流不是在开发一个软件功能时，开发者一个人完成前端、后端、测试、集成等所有的开发工作，而是根据要开发的功能，团队把任务拆分成一个人 1 天以内就能完成的小任务，组员自己认领任务，先完成任务的组员认领下一个任务直到完成所有的任务，软件功能可以被交付为止。
所以使用单件流来开发软件，团队成员应该：
-
积极主动
组员需要在做完一个任务以后，主动领取下一个任务，这样就可以减少组员的等待时间，提高效率。 -
一专多能
一个可以被交付的功能通常包括 API 设计、前端开发、后端开发、UI 测试、API 测试、集成测试等任务，组员不一定要精通所有的技能，但是如果组员能一专多能就可以在初次分配任务的时候使用熟练的技能，在完成后又可以做一些简单的非自己专业技能的任务。一个懂得前端开发的后端工程师，可以承担修改错字、调整组件样式这样的任务，而不用等待前端工程师。 -
持续集成
每完成一个功能都应该可以被交付，这样对于云端软件来说客户可以立即用上软件的新功能，对于就地系统来说交付实施工程师可以在实施时团队可以并行开发下一个功能。 -
坐在一起，面对面交流
运输和移动都是一种浪费，团队合作最高效的方式是面对面的交流。在办公室，团队成员的座位应该集中在一起，这样团队成员就可以随时随地沟通。注意远程办公做不到这一点，远程办公无法随时知道合作伙伴的状态，要谈话之前还得呼叫。
团队成员抵触“全栈”开发该怎么办？
根据笔者的项目实践来看，几乎没有团队成员会抵触“全栈”开发，他们更多的是担心“全栈”开发会耽误项目进度。与团队成员不抵触“全栈”开发相反，更多的“抵触”来自于团队管理者，他们对“单件流”理念表示怀疑。传统的一个模块一个人来负责的管理模式责任明确，管理起来简单，而“单件流”需要把每个需求分成多个1天左右可以完成的任务，管理者如果不熟悉技术和业务的话，很难做到准确地拆分任务，另一方面他们同样担心“全栈”开发会耽误项目进度，不愿付出让团队成员学习新技能的成本。
作为团队管理者，要实践“单件流”理念应该怎么做呢？
-
更深入的了解技术和业务
需求任务的拆分需要对技术和业务的了解。任务拆分到以天为单位，可以让团队成员同时参与到任务中来，在完成一个任务后开始另外一个任务。团队合作，效率会更高。因为组员被占用的时间最多是1天，当有新情况发生需要处理时，组员可以更快地接受新任务，团队变得更敏捷。 -
相信人能够学习
人都是能够学习和进步的，作为管理者允许团队成员一步步学习更多的技能，投资到人身上，给成员成长的空间，是除了薪资以为的一种激励方法。 -
向团队宣传精益思想的理念
在每天的站会上宣传精益思想，以减少软件开发各个阶段的浪费和提高交付效率为目标，就会激发团队成员寻找达到目标的方法，勇敢尝试新的工作方式 -
在项目中让成员互换角色
从长期看成员能够互换角色，比如开发和测试的互换，可以增进相互理解，在某个角色稀缺时及时补位，避免等待。另一方面，可以让所有成员都理解整个项目的结构，避免单点故障。
一个功能让整个团队一起做，出了问题责任算谁的呢？
如果团队开发的产品出了问题，责任是整个团队的。在客户看来，产品的质量问题不会是某个人的问题，而是交付产品的团队的问题。团队同心协力才能高效率、高质量地完成项目交付，所以在开发过程中，团队的互动交流，开发过程透明，组员的责任心是团队项目成功的保障。
在“单件流”的各个工序上，每个任务完成后都需要测试，只有质量合格的组件才能进入下一个环节。如果团队在这样严格的流程下还是出现产品的严重缺陷，团队就需要停下来找到问题的根本原因以后再继续下面的工作。
“单件流”模式开发软件是不是团队一次只能做一个功能？
WIP 也就是正在进行的工作 (work in progress)，当然是越小越好，但是每个团队的人数不一样，团队成员的技能也不一样，所以团队应该自己衡量同时进行的工作数是多少时，Cycle Time 和 Lead Time 最小，交付最及时。
只有能够不断总结经验教训的团队才能持续进步。团队一方面要努力积极工作，另一方面也应该定期总结，查看 KPI，产生共识，优化流程。
“单件流”更适合单体架构？
实际上“单件流”不依赖于软件架构，只要团队能够把需求拆分成一个人一天能完成的小任务，就可以让工作“流”动起来，使团队成员通过任务接力提高开发效率，从而实现准时交付。
总结
“单件流”的软件开发模式并不是一个“全栈”工程师完成从设计、前端、后端、测试到集成的全部任务，而是团队在尽可能少的WIP下，团队成员通力合作，完成要交付的功能中的各项任务。为了减少等待时间，团队成员应做到一专多能，管理者应该信任团队成员给他们发展和学习的空间，最后达到提高软件开发效率的目的。
参考链接：
-
死磕996：如何使用“单件流”概念来提高软件项目交付的准时性？
-
拒绝加班：如何避免开发完成了但是不能交付的困境？
这篇关于拒绝加班：是不是只有“全栈”工程师才能实现软件开发的“单件流”的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
