大家好，这里是修真院前端小课堂，今天给大家分享的的是

修真院教学模式四大体系之开发流程

修真院教学模式介绍

不同于市面上其他培训机构的传统教学模式

修真院经过线下3年多的实践探索

通过8万多篇的学习日报，400余名结业学员99%就业率的教学成果

开创了一套独有的347教学模式

三大阶段：

【任务】【复盘】到【真实】，从技能学习到项目经验的积累

四大体系：

从【知识技能】到【学习方法】，【开发流程】到【职业素养】，从学员到职人的转变

七种教学工具：

【日报】【小课堂】【周会】【师兄】【评审】【学分】【坑乎】

善用工具，掌握自主解决问题的能力

从今天开始，将以每天一篇的频率

详细介绍修真院得以超高就业率培养IT人才的347教学模式

本篇为【开发流程篇】

四大体系

从零基础，到成长为独立完成项目的工程师

入职公司成为靠谱的开发人员，以下四方面必不可少：

知识技能、学习方法、开发流程、职业素养

开发流程篇

第一、为什么需要敏捷开发流程

在互联网蛮荒时代，软件项目的开发都是以年来计算的

这代表什么意思呢？

需求设计了半年多

方案设计做了半年多

开发了三年多

测试了半年多

修改Bug用了半年多

总计花了很长很长的时间：

上线后发现有很多需求已经不存在了，同时又出现了很多新的需求

怎么办？继续改

这一改又是半年多的时间过去了

马丹用户的需求还在改，怎么办？

这是困扰软件开发项目最大的问题：

越大的项目，参与的人越多，风险越大

文档越规范，维护起来的难度就越高，导致项目中遇到的问题越来越多

不仅仅在几万年前，就是在现在，也是经常会有团队出现这种问题

不相信，你可以看看是否遇到了以下这些问题：

1.需求总是在变动，反复变动，无限拖延

2.开发工程师做出来的项目，bug不但多，而且经常改不好

常常是改了一个Bug，出现另一个Bug

好不容易把一个Bug改好了，过了没多久又重现了

原本好好的功能，反而会因为改Bug导致出现的问题更多

3.做出来的东西完全不是产品经理想要的样子

沟通完之后才发现开发工程师的理解和产品经理的理解是完全不一样的

4.项目延期不是最坏的结果，最坏的结果是还从不知道项目到底会延期多少

根本没办法去衡量工作量，团队的成员都在加班加点，然而完全看不出来问题出在什么地方

5.开发文档，产品文档，接口文档，测试报告和真实的代码从没有完美契合过

产品经理设计出来的原型和UI设计出来的页面和程序员开发出来的代码完全是一种不同的体系

三位一体的故事从没有真正发生过

代码的实现和接口文档根本不一致

最后索性干脆不看接口文档，完全口头交流

出错的时候各种撕逼扯皮，谁也分不清倒底谁错了

6.Team的战斗力和凝聚力不强，经常是对着干，对分配的任务总是各种报怨

出现问题之后第一反应是这个不关我的事，不是我的问题，是后端/前端/设计/QA/PM的问题

如果你遇到了这种情况，或者说你不甘于这种现状

那么恭喜你，你真的需要敏捷开发流程了

第二，敏捷开发包括了哪些内容

敏捷开发总的流程如下：

1.需求规划和分期

2. 需求评审

3. 需求讲解

4. 方案评审

5. 每日晨会

6. 性能测试

7. CodeReview

8. Demo

9. 测试阶段

10.线上Bug修改流程

表跟我说哪些东西不应该包含在敏捷开发流程里

如果你不喜欢，跟你的观念有冲突，你可以把敏捷开发这四个字换成任意四个字

总之，如果要解决这些问题，这是我目前看到的最佳实践：

每一个节点都非纸上谈兵，而是经过无数个尝试和失败总结出来的

确切的说，我说的敏捷开发流程，并不仅仅是开发团队的事情

它背后隐藏着更多的理念，我可能整理的不够清楚，毕竟这是第一版

1.产品和开发必须是一个Team

大家只是分工不同，角色不同，并不是两个对立的团队

如果你的公司是把产品和开发分成两个部门

那么恭喜你，产品和开发之间的纠纷一定无限多

在所有我带的Team中，自始至终强调的理念就是：

出了问题，别跟我说这是产品设计出来，这是开发团队实现不了的

我只知道这是你们一个开发小组所有人的责任，这个后果是所有的人都需要承担的

如果我们认真的区分这是什么问题，那么也只是为了避免下次出现同样的情况

用户只会知道是一个公司出了一款垃圾产品，没有人关心到底是产品还是开发的锅

这是做敏捷开发的大前提

或者不仅仅是产品和开发，责任共担，One Team这个理念是贯穿始终的

这并不是说大锅饭，而是说：

面对不好的结果，所有Team的人都必须共同承担

出现问题的原因仅仅是为了追溯和重现当时的场景，以避免后续会出现同样的情况

产品和开发必须是一个Team还体现在需求分期上

这一点在讲到需求分期的流程的时候，会提高的

实际上，需求分期如果没做好，敏捷开发只能流于形式

需求分期怎么做，这是MVP的事情，另一个话题

简单来说，每一期都要有一个提前的预测：

这一期里要做的所有的功能都只为了检测自己的预测是否正确，并根据结果去不断的调整开发规划

2.职责明确

每个人要负责的事情必须清晰无误，谁该做哪些事情，必须要提前讲清楚

开发团队的推荐角色应该是这样的

PM 1个

UI 1个

CSS/js 1~2个

Java 2~4个

Android 1~2个

IOS 1~2个

QA 1个

这是一个相对平衡的模板：

这样的一个8~10人的小Team，是可以复制的

敏捷开发支持多个Team并行开发

理论上来讲，这种方式，可以支持五到六个小Team同时启动

在讲到最后多Team并发协作的时候，我也会提到的

除了这些项目小组的角色，还有各个Team的Leader

我比较推荐小组分成如下几种：

1.产品Team

产品团队

2.用户体验Team

传统的UI团队升级为UE，升级为整个系统甚至是公司的用户体验师

3.后端Team

苦逼的后端

4.前端Team

Android/IOS/JS

表问我为什么把这三个放到一起，我就是认为一个前端工程师应该三者通吃

可以在某一个客户端上了解的更深入，但是普通的项目上手还是应该没有问题的

5.QATeam

QA只需要做功能测试，回归测试，边界测试，并不需要做性能测试

这里也会在后面提到

那么来描述一下每个角色的不同职责

这些不同的角色牵涉到团队并行开发，所以并不是简单的随便扒拉到一堆就好了的

PM ：

PM的职责并不是画原型，而是去分产品的分期，确定产品要做的功能和优先级

对于产品来说，最大的职责并不是将原型画出来，而是要证明自己要做的功能是合理的

如果你证明不了自己要做的功能是合理的，是值得尝试的，就是产品经理的失职

可以参考MVP，有无数的办法可以提前验证

如果不能够提前验证，那么就证明这是有风险

作为PM，一定要有这种风险的意识，要知道自己身上担负的责任

PM花了两周时间设计的原型，8人的开发团队要折腾近三周左右的时间

原型和产品文档都是辅助的东西，我甚至不推荐产品经理去做原型设计，只拆分Story

原型设计交给传统的UI更合适

然而在真实实施的过程中，因为很少有UI具备原型的设计能力，所以实施起来会有一些难度

这个不算特别重要，慢慢培养

PM不需要为开发进度负任何的责任，这很重要

不要把PM当成项目管理来使用

如果你让PM去做了项目管理，恭喜你，Game 近乎 Over：

产品经理没有时间再去思考如何做功能了

PM的职责就是：

把功能设计好，优先级排好

给开发团队讲清楚需求，结合Story优先级和功能实现的大概时间点去做排期

开发工期交给开发团队去做，Bug会和QA，开发团队一起来定

记着要在开发团队开发项目的时间里，去做好下一个产品迭代的设计

小组Leader

需求评审会的成员应该包括：

PM组的Leader

前端组的leader

后端组的leader

测试组的Leader

或者其他公司的中层骨干

这应该是一个公司所有应该为这个项目负责的人的评审会

在评审会上的结论，就应该被坚定的执行下去了

不参与评审会的人，不应该再对需求指手画脚

需求评审会的目标就是确定原封不动的需求

所以在这里要格外的注意，PM拿出来的方案设计，一定是完整的，而且必须评细节

如果说，一个公司的中层骨干经过需求评审会议，仍然需求乱成一比，那就没什么可说的了

继续努力提升自己的水准，或者是补充真正的中层

而PM的目标就是吸收需求评审会的意见，尽量让自己的需求和设计通过评审

各个小组的Leader还应该承担的角色就是各个组的方案评审

这是中层骨干必须要起到的作用

小组的Leader还应该负责项目中风险的调控：

考虑是增加人手，安排加班，项目延期，还是调整功能

与此同时，应该去审核最后的性能报告：

看看是否达到系统的期望值，遇到了疑难问题如何解决

开发组成员

项目进入真正的开发阶段后：

开发组的成员就应该是主动去控制项目的进度和风险

主动去测试项目中存在的问题

在这个阶段，除了一些需求不明，或者是发生变动的情况出现，不应该去打扰产品经理

不要让产品经理做开发团队的保姆

开发组的成员的目标就是做好项目的进度控制，有风险就及时反馈给Leader

确保自己理解的需求是明确无误的

确保自己的测试是完整和严谨的

确认自己写出来的代码是可以维护的

一定要理解清楚：

一旦PM通过Story讲解，将需求交付给开发组成员

那么开发组成员就应该主动而独立的为这件事情负责

当项目完工以后，开发组成员应该交叉去做CodeReview，并且出性能测试报告，以及组织Demo

测试组成员

测试级成员的职责不是做功能性的测试，也不是做性能测试

而是应该做边界测试和回归测试

功能性的测试主要应该由开发组成员完成

除了一些特别麻烦的，需要各种极端条件才能复现的

正常的操作过程中出现的问题，都应该是有开发组承担

性能测试同样是开发组人员自行完成，各小组Leader只需要知道一件事情，测试报告是否能够通过

所以测试组的主要做的就是准确的记录，以及bug的统计

也不应该去天催促开发组的成员去改Bug

只需要去反馈给开发组的Leader就好了

整个CTO或者是技术总监应该以此为标准去衡量每个小组Leader的绩效

回归测试是需要做的，但是也不是完全必须要做

如果能够积累足够多的自动化测试用例，就去正常使用它

如果不能，就尽可能少的减少回归测试

这需要跟开发人员沟通的比较清楚，他们往往更清楚，什么地方容易出问题

接受线上的反馈并且记录也应该是QA的职责

如果Team足够细，可能会有运营或者是客服统一对外收集，然后交给QA，QA再负责录入Bug系统中

基本的敏捷开发流程中的角色的职责大致就是这样的了

这不是一件容易的事情，其中的很多小细节，都照顾到了每个角色的职责和义务

理论上来说，如果有一张图的话，可以更清楚的画出来不同角色的功能

这种职责的划分，和传统的职责会有一些不同

反正，在我带过的Team中，这是最高效的，也是最能发挥出团队的能力的方式

你可以信，也可以不信，这中间的每一个细微的调整，都是经过无数个日日夜夜的验证而得来的

我还未曾看到过比这种职责划分方式更高效，更合理的做法

3.每个人必须学会主动去为自己的事情负责

当有了第二条，你很快就能发现团队中，谁是能够尽守职责，更主动的人

第3条很难做到，特别在很多公司，并不注重对于团队凝聚力的培养

也不会注重和他们之间的交流，不知道他们想要什么

所以这也是我一再强调的，敏捷开发并不仅仅是一个开发流程，更是一种管理的方式

它牵涉到绩效考核，公司福利，上下班制度等等你看不到的东西

如果说你的团队成员并不能做到为自己的事情负责

那么你需要的就是，要么就是去更换团队，要么就是想办法去激励团队

这是另一个话题了，我心情好的话，可能会在这里提到

如果心情不好，可能会在下一个文章里，也可能根本就不会写了

这件事情其实也不算难：

第一，明确这种职责的分工是合理的

第二，Leader都需要了解自己的团队的状况

第三，不断的去强化和培养这种做事的习惯。

这就够了

团队是需要打磨和改造的

这三点是敏捷开发实施的前提，而不是说，有了这三点，敏捷开发就一点能做好了

说了这么多，其实理解敏捷开发流程是一个长期的过程

最好的办法还是：

参与一个敏捷开发的团队，在项目中实践它

才能真正理解为何敏捷开发中要如此设置流程与分工

为何这样才是最快相应需求最优碟迭代方式。

【欢迎加IT交流群565763832与大家一起讨论交流】