发表于： 2017-10-17 23:37:24
1 664
今天完成的任务
还是整理老大知乎live
********产品设计阶段********开始
正常来讲就是一个项目的开发，首先你需要有一个产品经理，然后你需要有ui设计师，跟着你需要前端、后端工程师。如果你有APP开发的话，你可能需要安卓组和IOS组，之后你会有运维团队，以及测试人员。
在实际在敏捷开发过程中，可能是比这些参与角色还要多一点。为什么？首先就是你需要有所谓的leader概念，就是在leader的概念中，他其实比开发团队，他要承担一些更多的一些职责，基本上可以这么讲，就是那个敏捷开发的要求并不是单纯对工程师，它对leader的要求也很高，算是一个隐性的一种要求。
我们把敏捷开发分解成三个比较大的阶段，第一个阶段叫做产品设计阶段，第二阶段叫做开发阶段，第三个阶段叫做测试阶段也就是设计开发测试，这是整个敏捷开发过程中三个比较大的阶段。
在整个产品设计的过程中需要出现几个角色，第一个角色就这个产品经理。是由哪个产品经理来设计，哪个他们来设计他就需要负责去拆story、去把这个PPT要做出来，然后验收标准他也要写得很清楚。
在他把这些东西做出来之后，他不见得这个东西做的一定是完善的，所以在正式的需求评审过程之前，他们需要在PM团队内部做一个需求评审。
一般来讲，一个项目中产品经理可能只有一个PM，通常只会有一个PM。两个PM会打架，而且也没有太大意义。所以正常来讲一个项目由一个PM负责，当PM把需求设计完之后，PM不可能也不应该马上就交给研发团队去做需求评审，因为很多需求可能想的不够周全，所以这个时候在PM团队内部要有需求评审会。
********产品设计阶段********结束
********需求内部评审********开始
那么内部评审会是由谁来参加呢？就是PM团队或者是UE部门的内部团队，这个完全是内部的。
首先保证在内部产品风格设计一致。在一些比较大的系统中很多不同的产品线，不同的产品功能都是有不同的人去设计的，比如说举个最简单例子，所有的弹框到底是应该用圆角还是应该用方角？或者是弹框，什么样情况下我应该出这种确认框，什么样情况下我可能不需要确认框，而是让这个弹窗在三秒钟之后自动消失，这些都是需要些具体的规范。那我们在产品内部需求评审的时候也需要把这种规范给确定下来。
还有就是当我们在做这个产品开发的时候，可能会有一些自己想的不清楚的地方，那么内部需求评审就把握两个大方向，第一是我们在这个内部需求评审的时候是不是真的把所有细节都考虑清楚了？这是第一点，也是需求内部评审中你作为leader的一个职责，你要把握这个大的方向没问题。
第二你要确定是不是把所有细节都讲清楚了。一般来讲PM都不太懂开发人员，他很难预估开发需要多长时间，而PM的一般来讲这个时候如果是leader或者是产品总监的话这方面相对来讲今年会比较丰富一点，他们也可以提前发现一些问题。特别是当他们做过一些相关的项目开发，那么他们自己心里清楚大概这个功能要做多久才能完成。
所以刚刚讲的是什么呢？就是指，这个敏捷开发，在需求评审前首先要有个PM内部的需求评审，而且需要的评审可能不止一次两次。
因此敏捷开发里的第一个角色我们是说的是产品经理，而第二个角色就是产品经理的内部leader。内部需求评审完之后就是需求评审了。
********需求内部评审********结束
********需求评审阶段********开始
这个需求评审环节是由谁来参加呢？一般来说是所有跟这个项目相关的所有的利益部门。包括什么呢？包括产品部门、研发部门、运营部门或者是包括CTO或者是包括产品总监，就是所有在公司有决定权的人都应该来参加需求评审的会议。
不同的公司具体情况不一样，但是我们一般来讲，我们期望凡是对产品有发言权的，凡是对产品想表达自己建议的，那么你唯一的通道就是通过需求评审会议，如果说需求评审会议你没有参加的话，那么需求评审只要通过之后，原则上是不允许你的需求做任何更改的。所以在这个时候参加需求评审的，一般都是公司的核心管理层，他代表的是一个公司从一个会议的形式代表出一个结论。
为什么对需求评审要求这么严格？是因为你的需求简单来说代表的是你的研发团队在接下来半个月或者一个月他的工作量。如果说需求设计的本身不合理或者是有缺陷，那么你只会拖延最后面的进度。而且你会经常发现，就通过这种方式，我们可以把所有的需求都在同一个地方表达出来，所以这个呢这个时候我们其实是讲的这个在需求评审中，你会发现他的角色又多了几个，其实确切来讲，我们可以统一成为公司骨干，但一般来讲有几个是必须要参加的：产品总监可以不用参加，但是技术部的技术总监正常来讲是需要参加的。如果技术总监不参加，那么技术总监下面部门的leader，比如说后端leader、前端leader、安卓组/IOS组的leader和测试人员，还有UI以及UE部门，这是要求必须参加需求评审的。
为什么这么讲呢？这些leader的职责是要做几件事情。第一件事情就是他们要评估这个需求是不是能够实现，大概需要多久实现，有没有难度，有没有我之前没有做过的东西，我可能需要提前做什么准备。
简单来讲，在这个需求评审会我们需要得到几个产出，第一个产出就是这个需求多久能够完成；第二个就是这个需求是由哪些团队人员去做；第三个就是我们下次的需求讲解时间应该是在什么时间开始。要想定下来这么三个时间点，只有对项目非常熟悉，对团队人员非常熟悉的leader才能做这个决定。
而且在这个时候，不推荐开发人员去参加需求评审会议。根据我们以往经验，需求评审正常来说的话，产品经理一般都做得比较糙，虽然这个内部评审完善了需求的细节，但是正常来讲，很难有需求评审一次能过的情况。不管是各种各样原因，就是很多时候leader主要精力就在于需求评审上，你要跟他去磨需求，要导致这个一个合理性，是不是有些需求他那么设计就没有太大的意义。所以在这个时候我们其实并不推荐普通的工程师去参加需求评审，因为这样时间是非常浪费，而且还很关键一点是我们在需求评审会议上可能很多时候都在讨论一些具体的东西，可能会有些东西是不确定的。
那么说到这里我们其实讲到了第三个角色，在这里就是各个研发组的leader，包括测试人员。他们的职责就是保证每一个产品经理做出来的需求是合理的，是没有问题的，是我可以放心交给开发人员去开发的。如果说你没有做到这一点，那就是你这个leader的失职。所以这个讲的是那个开发人员的leader。接下来是需求讲解的阶段。
********需求评审阶段********结束
********需求讲解阶段********开始
在需求讲解的阶段，你会发现谁来参加呢？第一个就是产品经理肯定要参加，第二个就是所有负责开发这个项目的人，给他们开一个需求讲解会议，要做什么事情呢？就是由产品经理去给大家讲清楚，我们为什么要做这件事，我们打算怎么做，我们做的东西到底是什么？
我们从业务上、从原型挑选上、重交互细节上，把所有我们想做的东西去跟我们的开发团队讲清楚。这个时候敏捷开发过程中，参与项目开发的工程师，也就是项目组的成员，我们把他们称为第四个角色（至此，第一角色是PM，第二个角色是PM的leader，第三个角色是参与需求评审的各个开发组的leader、公司决策层、测试人员，第四个角色项目组成员）。
那么对于项目组的普通成员来讲，他们要关注哪些需求呢？他们要做的职责其实很简单，一般来说需求讲解的会议可能就是一个小时或者两个小时。你要做到的就是，PM讲需求的时候，你要在这两个小时时间之内你要搞清楚两个事情。第一是你弄清楚这个需求你是不是真的理解透彻了，我可能需要跟产品经理有一些讨论，有些提问，然后证明我对需求理解是没有偏差的。另外一个当需求给你讲出来之后，你必须在当场就应该能判断出来这个需求我可不可以做得到，有没有可能去完成，哪些是我不确定的地方，或者是有没有这个需求？设计不合理的，有没有逻辑混乱的地方。
就我说的这些情况，基本上都是我们过去很多的项目开发过程碰到的。经常就是产品经理讲的不够细致，然后研发人员也不够细致，评审时候也不细致，到最后发现很多地方可能都确认不了，还需要再和产品经理做二次确认。
就是说，在这里，首先你作为一个研发人员，你的职责是要明确三件事。第一件事就是这个需求到底是什么，你是不是理解错了。第二个是这个需求的所有细节我是不是考虑清楚了，有没有遗漏的，因为大家往往会遇到很多很独崭节。比如说这个正常流程，应该需要做错误校验，但是我没有做。还有就是我们在做开发时，我们可能需要把很多错误的情况都考虑得特别清楚。第三个就是这个需求有没有一些特别不合理的，耗时特别长的，或是有没有违反正常表达的。但是这个时候要注意一点，就是你对需求的所有建议不应该在当场讨论，就是你应该反馈给产品经理，让产品经理去做选择，或者是跟自己的leader去做判断。就是在需求讲解时，我们对于有疑问的地方，需要记下来。
惟一的要求就是不管怎么样，一定要保证自己对需求理解是没问题的，这是作为这个项目组成员在需求讲解会议上一定要承担的责任。当这个需求讲解完了之后，就开始进入开发阶段了。
********需求讲解阶段********结束
********产品开发阶段********开始
开发阶段我们要做哪些东西呢？首先你要做方案评审，就方案评审也是个非常非常重要事情。敏捷开发鼓励的是什么呢？每一个参与的人都要需要自己去主动去做方案，这个其实跟这个修真院院一直在提倡的，这和逆向学习法是相对应的。
就是其他的很多公司可能一开始他会有这个所谓的项目经理这个角色，但是在敏捷开发中是没有项目经理的，然后会有所谓的架构师。这个架构师呢，可能会去做哪些东西？他可能他去把所有的方案的设计的细节都会讲出来或者做出来，比如说他把所有的DB结构、表结构都做出来，然后呢他把所有的架构体系都做出来。那你去做什么事情呢？你就在架构师设计的架构基础上去写业务逻辑代码。
在这一点上，我们执行的敏捷开发，是百分百不推荐的。就是我们并不推荐这个所谓的架构师，由他去把所有的方案都设计好，然后用你去写业务代码。原因是这样对每个程序员的个人成长是完全不利的，而且开发过程中很容易出现问题。架构师不可能考虑到所有的这个细节，而我们在写这个项目代码的过程中，如果发现架构不合理的地方中间就会引起这种信息偏差，所以我们推崇的做法是什么呢？
我们推崇做法就是所有的项目参与人员自己去设计方案，作出这个方案之后，我们把做好的方案交给我们的架构师、我们的leader，做一个方案评审，我们看这个方案到底是不是合理。在这个时候我们又重新出现上面提到的，参加需求评审的、敏捷开发过程中的第三个角色，就是刚才讲的小组leader。
正常来说，在方案评审过程中小组leader必须参加的，有经验的工程师也是要参加，我们不怕你做项目的人技术比较菜，但你设计的方案是不是合理一定要经过所有的在公司里比较有实力的人他们的认可。
项目组的leader或者是架构师，他们在这里他们在方案评审上起到职责是什么呢？他们需要把需求理解清楚，也需要知道你是打算怎么做的。然后你把方案拿出来，由leader/架构师去看你的方案设计中有没有问题，如果有问题会告诉你问题出在什么地方给你打回去，让你再重新改。如果说你考虑的不够周全，那就会告诉你说哪个地方考虑的不好，所以方案评审对这个项目开发是有比较大的影响的。
在修真院的开发过程中有时候经常会出现后端一个方案设计可能需要一周到两周的这么一种状况，在某种程度上这种模式的开发效率可能比不上找一个架构师直接把方案定下来，交给下面的开发人员去做。但是实际上，从长远来看的话，我们的这种做法对你个人和你的团队的塑造和提升是非常大的。
我见过很多工程师，只会写业务逻辑代码，可能两年，三年都没有做过DB的设计，根本就不知道一个分布式或者是一个这种，特别是后端根本不知道什么叫架构，应该怎么写，应该怎么解决这种极端问题。他们做的永远都只有一件事情，就是什么呢？别人告诉他怎么做他就这么做，所以在这一点上也是我们这个葡萄藤跟所有公司都不太一样的地方。
就我所带的所有公司，我们对所有员工的要求就是你必须能够独立完成项目，必须能够独立设计方案，这也是这个所有的团队成员就在我手下的人一般来讲成长都特别快的一个很重要原因从在。而且从这个角度来说，只有你自己做的项目，你可能对项目了解的才会比较清楚，所以我们在这里是一直不推崇有这个所谓的这个项目经理或者是架构师，让他去做设计，然后你就去写业务逻辑这种方式。
我不知道刚才有没有讲清楚，因为这点是敏捷开发过程中跟其他的有点不太一样的。
经常有人会问到敏捷开发比较注重什么呢？比较比较注重项目组成员的主动能动性，对于个人的，也就是说你个人能力越强，敏捷开发的价值就越大，就在这点上也是其中的一个体现。
如果说你技术水准越高，那么你的方案评审几乎是没有什么大的问题的。所以说，方案评审到底做到什么程度，要做哪些事情，我会在接下话题里讲得很清楚。而且，我今天讲的就全都是、必须是要落地实施的，也是修真院很多学员中可能要提前注意一下的。
当这个方案评审过了之后是什么呢？就是这个时候就是我们正式开发阶段，开发阶段做的第一件事情一般来讲是要做接口的，就是要定义接口，接口是由前端和后端人员一块来定义的，这个当我讲到这个接口定义的时候我可能会讲得再清楚一点。这个时候我们先了解一下，就需要定义接口。另外一个就是你需要拆task， 就是把之前我们产品经理看到的story拆成一个个小的task。
在这个时候呢，有的敏捷开发过程中会希望有一个人承担这么一个角色，叫做什么呢？叫做项目的owner，这个项目的主人。
他们认为会有一个人，一去把控整个项目的方向，owner他和项目经理他有一些不太一样的地方，但是在我们执行理念开发过程中，我们其实把这一点不一样的地方给去掉了。我们的原则就是每一个参加项目的开发人员都是项目的owner，而leader只有1个（小组leader或者架构师）。
正常来讲，对于其他的敏捷开发来讲，这时候可能会希望有一个人，做什么事情呢？就是每天跟项目组成员开晨会，然后去看这个燃尽图，可能会跟工程师交流一些任务。
比如，我在SOHU的时候是有一个助理叫项目助理，他是来负责做这些事情的，就到点喊大家开晨会，然后做个会议记录，然后中间有问题中间协调沟通，我们在最后发现，其实我们其实不需要这种角色的。那这个角色由谁来担当呢？就是靠所有参加项目的工程师。所以在这点上，对工程师要求是非常高。为什么呢？
因为现在一个项目可能会有大概七八个人来负责，那么有没有一个统一人来负责这个项目进度呢？我们这个时候我们今天讲过我们是不希望有这么一个统一的人去管理负责项目进度的。
在过去我们发现，当指定了其中一个人作为项目的owner、作为项目的主持人的时候，那么这个项目中的所有的开发人员都会向后退一步，没有人会对这个项目负责。你会发现最忙最累的可能就是那个项目的负责人，这不是我们期望结。
我们希望所有项目工程师一开始都要认同一点，就是你很明确知道你要做的东西的价值，我们不怀疑你的职业素养是，我们信任你的职业操守，我们只觉得你可能在技术上是有问题。所以在这一点上就是要明确地提出一点，你作为一个优秀的工程师，你作为敏捷开发项目中的工程师，你就有责任去推动项目中出现的问题，把它尽快的解决掉。
这个讲的重点就是，你作为一个开发者，你需要明确的清楚知道自己需求能不能做，做到什么程度；另外一个呢，你还要负责去推进解决项目发生的问题。
我们知道我们这讲的团队开发中你会遇到各种各样问题，随便可以举几个，比如说需求可能不清楚，那么谁去负责给产品经理把这个事情搞清楚？第二个可能是什么呢？可能是前后端进度不一样，后端进度比较慢，前端人员没有接口可用，那么这个问题是由谁来解决？第三个可能是你作为一个前端工程，后端工程师给你的接口总是对不上，这个问题由谁来解决？我们发现，开发过程中会有各种各样的因素对项目产生一些干扰，导致项目进行不下去，那么又由谁去负责推动这个事情？
我们的原则就是所有项目的人都应该有责任去推动这个项目的问题。如果说你没有主动去推动我们的团队中是不会保留你的，这是我们对敏捷开发的就另外一层比较深的含义。就是我们对团队要求其实非常非常高。
嗯…再往下讲，假设我们项目正常了，问题已经解决完了，这时候你会发现在整个项目开发过程中，我们其实不需要leader去参与的。
那么leader参与在什么地方呢？就是每天会开晨会。晨会结束后会有一个晨报，开发人员会自组织的去把晨报发出来，晨报上会标明项目开发进度。那么项目leader在这里，还有第三个职责。就是具体的开发过程，leader可以不管。但是如果你作为一个leader，发现项目延期或者是你看到的内容也就他们做出来东西，让你意识到这个项目是有延期风险，这个时候就是你需要出手的时候。
这也是我们在修真院的逆向学习法中经常提到的，就是我们的作用并不是提前告诉你做什么事情，而是说呢，当你遇到问题的时候那么你就需要出手。如果说，你没有问题，项目开发的很顺利，就几乎是不需要你做什么事情。
所以有时候我们相当于是一个守护者，一旦发现当项目组的人员解决不了的问题，那么你就要干涉；一旦发现项目延期风险，那么你要去补救。在这个时候他要做的事情就每天看晨报、看燃尽图、去看开发环境集成中的东西，看这个项目中到底有没有风险，风险在哪里，如果说需要出手的话一定要尽早出手，这些就是开发组的leader他要承担的责任。
跟着就是demo的环节，就这个时候其实跳过两个环节一个叫code review，一个叫做性能测试，这两个其实牵扯到角色不太多，比较简单，我们先跳过不讲。
然后demo环节是什么呢？demo环节和我们刚刚讲有个需求讲解的环节还有需求评审的环节，其实demo环节是什么意思呢？
需求讲解就是产品经理把需求交付给研发团队，那么demo环节就是研发团队把这个成品交付给产品团队，或者说交付给整个公司，这个到底是什么呢？首先我们讲的demo、讲的demo演示，并不是说随随便便做个小的东西，我们就上传了，就组织召开一个demo会议，这样的测试版可能会带有很多BUG。
这一点其实在之前我其实没有意识到，然后后来在开发项目过程中才发现有的人并不理解demo是什么含义。
demo是指你把产品经理交给你的功能完完全全地做完了，这就是一个验收的环节，也就是说我们所说的demo其实就是一个产品团队，一个相对来讲小的验收，那么谁来验收呢？产品经理是需要验收的，你的leader是需要验收的，然后可能技术总监也需要验收的，测试人员也是需要验收的，但正常来讲产品经理测试和自己leader这都是需要验收的。
demo由谁发起呢？由我们的项目开发人员自己去来讲我做了什么东西，我做的是什么什么样的，把所有流程都跑一遍。
嗯…所以说demo是一个比较重要的事情，而且经常会发现很多情况，就是你会发现demo一次过不了，他们两次demo、三次demo可能还过不了，但每次demo都有一堆问题，这也是之前反过头来回过来讲的话，你作为开发人员你要很明确的清楚你在这个项目中承担的职责到底是什么，那么对于这个参加demo的验收这个环节我们可以在这个时候认为是属于敏捷的第五种角色，验收人员。验收人员由PM和测试还有我们的这个技术骨干，由他们来组成，有可能还包括CEO。所以作为项目组的一员，作为敏捷开发的一个工程师，你的职责就是一定要求很严格，你不能出现一个问题。我对我们这边要求就是，你不能出现一个肉眼的发现的问题（具体细节我们在讲demo验收到底怎么验收会讲到）。但是这个对他来讲，职责就是保证现在代码是没有什么大的问题的。
********产品开发阶段********结束
********搭建测试环境********开始
在保证代码没有什么大问题以后，开发人员打tag，并向运维发出指令，把代码部署到测试环境（这环境我们要求一定要稳定，不能变，不能随时变更），产品的开发才算是结束，然后可以进入测试阶段。
********搭建测试环境********结束
********产品测试阶段********开始
进入测试阶段，这个时候QA就出现了。他的职责是什么呢？他在测试环境中把所有的测试用例都跑一遍，然后做一些编辑测试。测试人员不做压力测试，因为开发人员在demo之前已经完成压力测试。测试人员的职责就是找出BUG，而且分出BUG优先级，同时要负责追踪这些BUG解决的进度。
我们之前也遇到一种情况，就我们测试人员对于这个BUG的追踪度不够，有的BUG可能放在一个月两个月都解决不了。所以关于BUG怎么解决，他的级别什么样，就有一个相对应的BUG修复流程。所谓的测试人员职责并不仅仅是去找BUG，就这点是要讲清楚。你作为一个QA、你做为一个测试人员，你并不是说把BUG提出来就结束了，你还要尽量去推动这个BUG的解决。
正常来讲，我们会约束一个开发人员在处理BUG大概一个时间，如果说你发现这个时间跟你去的不相符，那么你可能需要把这件事情去跟开发组leader去反映，同时开发人员leader也会关注自己项目的BUG进度，有问题提前说，不要让测试人员来告诉你说什么东西导致产品上不了线。这个时候所有人的关注点应该是我们的上线日期到底是哪一天？这时候测试如果已经做完，BUG也修复完了，那么就发布上钱。
********产品测试阶段********结束
********发布上线阶段********开始
在发布上线当天，就这个时候，其实运维的角色就比较重要。需要一个运维、一个开发团队，一个项目leader...整体来讲的话，每一次上线发布都是一件比较大的事情，所以整个敏捷开发过程中几乎是所有的角色都会要求到场。
********发布上线阶段********结束
********回顾总结********开始
好了，我们几乎把这个角色已经介绍过来一遍了，我们再稍微回顾一下。
第一个角色就是产品经理。产品经理去负责整个项目的产品设计，然后PM完成的设计需要一些人来做一个内部的评审。这个内部的评审就是我们之前讲过的，可能是产品组的leader、可能是UI组，也可能是UE组，就是比较有经验的产品经理，可能由他们来做这件事情。
然后第二个角色是什么呢？就是在需求评审的时候，作为需求所有的利益相关部门，他们掌握了公司去做需求的方向。就有权利发表建议或者有提要求的这么一些人。一般来讲是由各组的leader、各部门的总监来构成的，然后他们的主要职责是决定大的方向有没有问题，然后细节上有没有问题，就是保证所有对需求的建议都在需求评审上去完成。
第三种角色就是开发人员，开发人员其实承担的职责第一是要判断出来这个需求我应该怎么样做，大概要做多久。然后第二个职责就是所有的开发人员都要成为项目的主人，都要推动去解决项目的问题。第三个是在做完项目开发之后，要去主动的去向所有人去演示。这里我们说到的所有人，其实是主要是指的验收团队，而且要明白这里的验收是指的是代码一行都不用再改了，就基本上没有什么大的问题了。我们自己能发现各种小BUG，包括UI设计了，很多这个做得不好的、兼容系统全部都解决掉了，这是一个小的交付环节。那么大的交付环节（上线）是需要测试人员去做测试的。
第四个角色是测试人员。他们第一个职责是把BUG找出来；第二个职责跟踪BUG解决进度，推进BUG解决；第三个职责是保证这个项目的上线是没有问题的。
这个时候基本上把相关的角色都重新已经介绍了一遍。
********回顾总结********结束
遇到的问题
现在整理出来的东西就跟老大在live直播说的话非常接近，容易理解但是篇幅过长。之后会出一个总结版，两个版本对着看，效果应该会更好一些。
收获
让我自己说一次敏捷开发，估计也能说出来6成东西...算是很大的收获了吧
明天的计划
作出总结版
看大佬讲打tag的视频
进度
返回列表
评论