Web 开发模式 Scrum or Waterfall

Waterfall

一般瀑布式(Waterfall) 是最常见的开发模式，开发流程是由 PM 先规划完整的功能与细节，然后再交由 Designer 来做画面的设计，接著交给 Frontend Engineer 开发出前端的 Templates ，也就是 HTML, CSS, JavaScript .. 等，最后由 Backend Engineer 来开发后端功能，并整合前端的 Templates。

这个开发过程可以用下面简单的甘特图来表示：

Scrum

另一个最近很流行的开发模式为敏捷式 Scrum， 首先我们会把专案相关的人员集合在一起，大约 5 ~ 8 个人左右，这一群成员中包含了 PM , 前后端工程师，设计师，测试人员等，并且把开发时间切分成两周一个单位，每个单位称之为一个 Sprint ，而每个 Sprint 都算是一个小小的 Waterfall ，其中包含了需求定义，设计，开发，测试等工作，在每个 Sprint 一开始时，要先规划本次 Sprint 的工作内容，结束的时候要 Demo 成果，以及每个成员要分享这次 Sprint 的心得，改善方式等。

如左图所示，开发流程会分成多个 Sprint ，每 14 天为一个周期，在每个 Sprint 结束时都会有成果发表

左图则是每个 Sprint 要做的事。

• Planning ： Sprint 一开始 PM 会跟所有成员讨论这次 Sprint 的工作项目与范围。
• StandUp ： Sprint 当中，每天要花十分钟让所有成员说明重要的事。
• Demo： 跟 PM 展现这次 Sprint 的成果。
• Review：讨论这次 Sprint 的优点与缺点，是否有哪些地方可以改善。

两种开发模式都各有优缺点， Waterfall 的最主要缺点是开发时间长，一个大型专案从需求定义完成到测试结束上线，有时候甚至会超过两年，另外 FrontEnd Engineer 开发完第一个专案后，马上就得进入下一个专案，但这时，第一个专案还尚未结束，Backend Engineer 也还在开发与整合中，一旦有测到 Bug， FrontEnd Engineer 又得立刻下海来帮忙，变成同时处理两个专案。；不过 Waterfall 有个最大的优点，就是分工清楚，干净，开发模式简单，不用学习也知道这个开发流程。

Waterfall 优点

• 专案的架构、需求，在开工前就制定完成，细节清楚明白，工程师在开发的过程会很顺畅。
• 不用花太多时间来沟通，只要需求写得够清楚，工程师就能很快的完成工作。
• 不用学就会的开发方式。
• 分工清楚，工作起来也比 Scrum 单纯。

Waterfall 缺点

• 开发时间很长，中间没有任何断点，只能一直死命的做到专案结束。
• PM 能力不能太差，因为专案规划是越完整越好，时程安排也要流畅，如果 PM 做得不好，在开发的过程中不断修改需求，厘不清楚需求，这会卡死专案时程，工程师则是做完了又改，改了再重做，工作效率会变得很差。
• 同 Team 的成员没办法同时开发，同时结束，有些成员会同时处理多个专案，例如设计师完成第一个专案的设计后，会马上接著做第二个专案，若这时第一个专案要补页面，Icon 等等需求，会造成设计师得分心来同时兼顾两个专案。
• 越底层的人员，越没有发言权，因为你接到的工作，都是高层讨论完的结果，你唯一要做的就是尽快完成它。

Scrum 优点

• 专案分阶段完成，完成一小部分就立刻推出产品，产品可以快速上线。
• Scrum 可以解决这种需求不明确，或是功能变动幅度大的专案， Scrum 本来就是诉求边做边设计，一步一步完成，完成的部分就可以先上线。
• PM 不用很专业，需求不用说得很清楚，因为每个 Sprint 都会大家一起讨论功能，Scrum 这个开发模式，很适合用在团队中的 PM 没什么经验 ，因为没有经验的 PM 无法制定出完整清楚的需求，这时就可以透过 Scrum 的精神，在 Sprint 当中，每个成员都能够对该专案提出建议并确定功能。
• 团队内的成员都有机会发表意见，工程师可以提出对 UI 的看法，设计师也可以提出需求的意见。
• Scrum 可以解决这种需求不明确，或是功能变动幅度大的专案， Scrum 本来就是诉求边做边想，一步一步完成，完成的部分就可以先上线，所以很适合还没有完整规划的专案，或是不懂得规划的团队。
• 团队内同时存在不同领域的人才，很方便讨论各种跨领域的需求，例如前后端工程师，可以一起讨论如何开发一个新 Feature ， QA 与 RD 也能一起讨论测试的方式与工具，有些大公司分工太细，各领域人才没有良好的沟通管道，这时一个聚集各方面人才的 Scrum Team ，可以加快沟通的时效性。

Scrum 缺点

• Scrum 精神不容易在传统公司中实作出来，每一个阶段完成的工作，根本就上不了线，因为大部分的老板都希望专案做得很完整，一推出就大受好评，不愿意做一半的产品就推出去。
• 需求变动大，程式改动的幅度也很大，所以不适合一开始就写太完整的 Unit Test，而在未来也很难找到机会回来补 Unit Test 。
• 花太多时间在开会， Review，影响工作情绪，每天早上都会花十分钟快速说明有什么状况，根据经验常常都会超过十分钟(个人建议可以直接取消每天的 Stand Up)。
• Scrum 模式有点梦想化，实际上根本就做不太到。

我觉得 Scrum 开发模式可以让团队中的每一个成员，「一起开始，一起结束」，这是非常好的想法，每个人的工作目标是一致的，进度也是一致的，成员的向心力远大於 Waterfall 开发方式，但是成员的能力跟 scrum 的运作有很大的关系，例如 PM 只能参与规划，设计，测试，当专案进度已经到的程式撰写，那么 PM 会没有事情做，同样的状况也会发生在设计师，所以 Scrum 开发比较适合团队内每一个成员能力相似，例如 Backend Engineer 都是 Full Stack Engineer ， PM 本身也懂得写技术文件，能够帮忙写 Library or API Document ，设计师也要懂得 Front-End 的开发或是自动化测试工具，而且每个人要愿意去学一点不同领域的知识，如果团队的成员编制没办法达成能力一致，那 Scrum 的开发最后还是会变成 Waterfall，这就一点意义也没有了。