关于Scrum

即刻做为一个创业公司，不论是团队仍是产品都在快速变化。在提高每一个人自身能力的同时，团队协做也慢慢成为一个重要的部分，所以咱们不只引入了Scrum，也在其基础上根据自身状况不停的调整。

先看下没有Scrum时的问题

• 产品发布周期不稳定，迭代缺少节奏感。
• 开发缺少明确任务时间表，时间安排全凭本身。对于工程方面的工做比较有利，想作的能够立刻作，可是对于团队协做开发的需求效率较低
• 产品需求不够明确（只有idea，缺少具体细节）时就开始动工。不能否认这样的好处是小功能能够快速试错，可是随着项目发展，当多team协同开发大功能时，会极大地增长沟通成本。好比因为文档不够清晰，客户端A去跟产品经理B确认一个细节，完成了之后还须要通知其余产品经理C、客户端D、后端E、测试F等等，有时候还会推翻以前的结论。这样一来虽然看起来你们都在热火朝天地讨论，可是效率其实不高。
• 产品和开发对于工期的预期不一致，时常会互相pending，客户端等后端接口，后端等具体需求等等。
• 常常会由于事先未考虑到的突发状况（产品活动、技术上的障碍）而delay。
• 在开发中途遇到新的需求或者idea，常常会犹豫是加到当前开发中的版本，赶一下工稍微推迟发布时间，仍是顺延到下一版本？若是在赶的过程当中还有另外的调整怎么办？

一些假设

• 就像团队开发须要制定代码规范、模块调用须要调用规范同样，团队协做也须要敏捷开发流程规范，确保团队间互相预期一致，减小低效沟通和互相推锅。当出现问题，定责（不是为了blame某我的，而是找到缘由）和改进就相对容易。
• 在高速变化的创业公司，流程自己应该随着公司和产品状况不断迭代的（元迭代？），若是某个环节你们都不满意，应该当即优化并在下一个sprint中执行。
• 对于team leader来讲，提升流程和团队的效率比提高本身的效率更重要，尤为是对于项目环节愈来愈多的时候，须要尽可能避免我的英雄主义。（一个大工程，光靠某一个好模块是不够的。只有当每一个模块间的数据流通畅时，工程自己才能运做良好）
• “改需求”是没法彻底消灭的（在创业公司可能也不该该），可是能够经过合理的流程限制在一个能够接受的水平（比如bug没法彻底消灭，可是code review流程可让工程师自我监督，有效减小bug）。过于灵活的调整会下降开发效率，反过来死板的流程也会伤害产品。须要不停地在二者间作出平衡。
• 产品经理永远是但愿加入更多的功能的，并且必定能给出一些合理的理由来支撑，可是并不必定考虑实际的工做量。Scrum master谨慎评估，在必要时果断拒绝一些短时间看似合理，但其实伤害长期效率的需求，防止Scope Creep发生从而破坏团队间的信任。
• 工程师大多倾向于在本身的领域里单打独斗，天生反感开会等低效而耗时的沟通流程。若是可以减小被打断的次数，能够大幅提升工做效率（就像减小线程/上下文切换能够提升代码执行效率）
• 功能开发不该该占用工程师所有的时间，敏捷流程应与工程师文化相辅相成。产品迭代、流程迭代和技术迭代、工具迭代同样重要。
• 工程师应该参与到产品设计中去，从技术和自身角度出发提供建议，提高ownership。尽可能在功能正式开发开始以前充分讨论，所以这对产品需求计划的前瞻性也提出了很高的要求。
• 对于一个功能，若是花费1个小时时间能够作到70分，可是75分须要2个小时，那么优先选择1个小时的作法，在下个迭代中再看状况优化。
• 一个重要的大前提是，公司可以招到足够优秀的人，且维持足够好的工程师文化。这一点也是即刻一直重点努力的方向之一，在这方面不论是产品、测试、开发至少都能作到“搁置争议，共同开发”。

执行

• 肯定一个稳定的Scrum周期，如两周。当产品的需求周期也是两周时，那么能够作到每两周发一个新版本。
• Sprint planning前，产品需求应该到一个至关清晰的水平，不然每一个team估算的时间成本可能与实际相比有大幅误差，影响本次sprint计划的制定。
• 在Sprint planning时，产品开发一块儿进行任务拆解，估算时间后，决定哪些功能放入本sprint，哪些延后。注意planning meeting不是需求讨论或者brainstorming，不该无休止的争论每一个需求的细节。整个会议尽可能控制在1小时之内。
• 当planning完成时，每一个小团队内部分配task。当分配完成时，整个sprint来自外部的任务就肯定了，接下来工程师有权自主分配开发时间。你们只须要在sprint结束那天达到task完成，并开始beta测试的预期目标。
• 你们共同的预期是，在Scrum结束时，必需要有一个准release版本进行beta测试。
• 天天Daily standup meeting与你们分享目前进度，并提出可能遇到的问题（如被谁block，或者工期delay等）。通常每一个人只须要十几秒时间就能说完，所以整个meeting最多不超过10分钟。
• 若是遇到改需求，须要team leader一块儿评估：相似改字体或者图标，那能够随时改。若是你们认为是较大功能改动（如须要花费1天以上）会影响已有的工做安排，顺延到下个sprint。这对于产品team是一个负反馈，可以促使下一次的需求计划更加合理。
• 当遇到重大突发状况（如突如其来的流量增加、critical bug fix等）一样须要你们一块儿沟通，能够延后一些相对不重要的task，但尽可能不影响sprint的节奏。

快速迭代，快速反馈，快速改进，不论是产品、开发仍是Scrum自己。Facebook（曾经）说Move fast and break things. 对于一个年轻的公司，年轻的团队来讲，须要冲劲，更须要专一和执行。

---

PS: 若是你认同即刻的文化，又喜欢即刻的产品，那还等什么？一块儿来吧！有至关多的职位等着你。连接: 加入即刻