多终端时代敏捷实践——蒋炜航（网易有道云笔记）
两年时间，一千五百万用户 66个版本。内部项目，起点低，3个人。两年半，50人团队。有道云笔记：云+端的产品。有个大规模的分布式文件系统类似Hadoop。有很多东西需要计算，索引，文本的模式识别等。还有其他很多问题，比如客户端多的问题。在PC的开始第一版我们还用过MFC，很丑陋不好看；Android也版本多，适配起来非常麻烦；另外各客户端还不能是独立的应用，得通过云来让用户有相对一致的使用体验。
各个阶段的敏捷实践：进入市场；迭代发布；开拓进取。
围绕这几个阶段，分享敏捷是什么。
进入市场。立项后6个月内，一切都需要被证明。开始资源有限，而且员工的信心会随着时间丢失。资源有限，市场前景不清。开始时非常小众，以有道的渠道去推，有没有可能？
博士导师也是多次创业者，关注于文件存储系统。开发了一个系统，以性能为卖点，但是市场不买单，所以很快就卖掉了。这个教训学的很深。后来采用数据挖掘的技术，统计的方法去处理代码，去找代码中的Bug。有了上次的教训，只花了6个月，加班加点把这个引擎搭出来，去买这个产品，但是发现很多大公司都已经有了找bug的系统，而且他们觉得，我们已经很多麻烦了，别再来添乱了。
作为一个资源有限的公司，这条路看来行不太通。重新定位了一下，把思路转变了一下，把一个从找Bug的工具转化成管理Bug的工具。相对成功，结果12年被VMware买去了，成立了一个大数据Team。
回到云笔记，我们花了很快的时间做出了一个基于MFC的版本。最基本的功能，同步、存储和简单的编辑。我们认为这是同品类最好的卖点，可能有其他的功能，但是用户会花很多时间去适应。一开始都没敢叫1.0版，以0.9版形式发布了。
市场反应还可以，2011.6发布0.9~2013.8发布3.4，一个7个平台66个版本。
大规模重构进行了2次。
核心就是快速的迭代发布，为什么要这么做呢？
目标、启动时机、团队规模、拥抱变化、量化指标、测试&发布
互联网行业中：
频繁的按时发布（发新版本是有效的营销方式，第三方首发，新闻稿、推荐资源预约都有档期）第三方市场，是双方共赢的。2Business很复杂，2Custorm这是非常方便和有效的。
大版本和大改动（2.0、3.0两次很大的改版。底层存储架构升级，视觉风格改版，界面库迁移，编辑器内核迁移）
要能够通过用户的反馈来调整版本计划（这个循环我们希望越短越好，我们现在控制在2-3个月，我们会做到更快）
Scrum不是万能药，要在实际成熟时推行。
团队3人以上（1人，sprint周期和产品演示；2人，结对编程，持续集成，相互代码审核）比如开始的时候，Web端，服务端就一个人。但是我们还是用了sprint周期的概念。PM还是会跟踪项目。后来有二个人的时候，我们也不是立马就Scrum了，主要是找寻有没有优秀的候选人去做Scrum Master，必须是认可Scrum的精神。当然我们也不是要求每个人去认可，大部分就可以了。
这里就不得不说到，可靠的Scrum Master是推行敏捷的基础
优秀：认可敏捷，熟悉业务，团队教练，理解优先级
我们尝试过用Tech Lead 和产品经理去做Scrum Master。后来不用产品经理去做了，他们有太多的事情。当然，也有兼任的，比如IOS团队。
限制规模，确保高效（没有站立式会议，30分钟会议，坐在一起，3-9人，每周比较重要的执行2次）30分钟必须完成，Mobile团队慢慢变大了，得45分钟完成，后来就切成IOS和Android。另外座位安排物理的比较接近，也会一起吃饭，成为饭团。
平衡团队的技术等级（优秀的人做什么都优秀）
对于研发工程师来说，我们的感觉是，在Engineering层面上，每个人是差不多的，除了从Engineering到Research的级别可能有点差距。
团队间协作（工程之间协作为主）Scrum精髓，高度自治！让他们自己去解决。复杂的问题，有必要时强制引入Scrum Master会议（定义接口）类似一个按需的机制。
拥抱变化
产品经理（原来：确定版本功能点和预期发布时间；现在：Sprint前只决定功能点的优先级；Sprint后再决定发布计划；提70%需求）看板思路：控制Working Progress，只让产品经理定义优先级。因为互联网行业唯一不变的就是变化。
研发工程师（原来：追求大而全的技术、喜欢整体重构；现在：不鼓励过度设计！而采用涌现式设计，每个Sprint结束时有30%的时间来提新的需求或者方向——比如有人发现了一个很好的UI库）。我们不自觉喜欢研究比较深的问题，比如06年开始我们自己开发了一个类似Hadoop的系统。其实都有现成的开源，后来我们有意识地避免重复造轮子。
得到一个相对稳定，相对敏捷、快速的版本发布。
量化评估
完成度（100%——剩余时间/评估时间；保持80%-90%，100%过于保守）
辅助指标
评估准确度（避免过度乐观）：计划时间/实际时间
不确定性（做好预留量）：额外任务时间/计划时间
每个团队的情况不一样，比如服务端和IOS端，自己控制。
测试和发布
开发团队通过历史数据预测bug修改时间。
产品经理决定发布时间和周期。
开发流程是相对Scrum稳定的周期，通过测试发现的问题返测，保证预测的相对准确，可以知道该团队能否很顺利地进行下一个Scrum周期。
一个迭代周期某项功能有问题，或者功能有变动，我们就在界面里先关掉，先发布了。有功能无法实现，我们就放到下一个迭代周期去执行。测试和版本发布都基于迭代发布的程度。有个问题，开始的时候，不停地去堆功能。但是有很多功能可能最后都没被使用，这是很浪费资源的。
开拓进取的需求
列举一些我们认为在项目里是攻坚的部分：跨平台编辑器；各个平台的浏览器内核；内容格式的兼容；复杂操作的逻辑等；手写优化。一旦开始做这些事，就有很多很细节的逻辑，比如添加附件、拷贝黏贴等功能，是有难度的。另外手写优化部分，在手机终端的处理器性能是有限的，十几个算法都看过了，没有特别适合的，所以我们现在也继续在做。举得这两个例子是在我们这里认为攻坚项目。
更多更快的尝试（天下武功，唯快不破）
挑战：尝试新功能，尝试新交互
攻坚项目挑战：主产品线的周期对这些问题来说太短（3-6个月）
需要积累：手写和编辑器都超过1年的研发
风险性高，解决方案：
专人专项，保证连续性，保证周期；独立发布，供主产品线使用。
（比如手写，自己有自己的模块版本号，已经发布3个版本，好处是他们自己相对有自己的管控流程，有点类似Agile）
挑战：增加功能对用户是一种干扰
增加功能会增加工程复杂度，常规的发布周期对这些尝试来说太长（1-2个月）
解决方案：
主产品线：多平台异步尝试，使用插件添加功能
（Android平台有很多插件可以调用）
尝试线：用js在web前段做些快速的技术原型，使用open-api访问开放接口，对数据进行做二次处理，一定范围内的测试（100人）。开放一个小的服务器，比如内部的bbs，内部的员工试用，就可以得到很多反馈，很多思路。
几个要点：
根据阶段确定目标和方式
（各个阶段的重点都不相同，根据每个阶段的要求不同确定目标和方式）
采用Scrum以人为先
（我们每个平台都可以等，招聘到熟悉到上任，要有合适的人。）
分而治之：平台、开发&测试、主产品&攻坚项目&快速尝试
（太难有一招鲜吃遍天的方法了。我们可以考虑把问题变得小一点，慢慢的采用，一步一步地将Agile分开落实）
新浪微博@蒋炜航
Q&A
问：通过什么途径搜集用户需求和反馈，怎么确定真实和噪声
答：很好的问题，我们一直定性和定量，我们有feedback平台，搜集留言和信息。我们有内部日志。我们会用NPS（NetProtocalScore），我们一直有搜集，问题是比较缓慢，主要针对大的改版。
问：需求人员如何与开发人员沟通
答：我们文档沟通比较少，我比较喜欢Facebook的办公室，open table特别容易交流，我们现在办公室还是cube，我有时候会叫他们一起去吃饭，这要看个人性格了。这是一方面，另外文档也会有，因为测试需要这个写测试用例。我们可能会找一两个开发的同事热身下，提前和需求人员沟通。
问：如果前边的人离职了，会增加成本么
答：因为我们自己就是重度用户，离职的话会有影响，但是我没怎么感觉到。可能我们离职率比较低，呵呵。
问：团队里的绩效考核，很多企业按数字说话，比如KPI，你们怎么考核
答：网易有道会有数字化，一般数字化会抗在我身上，或者产品，但是在研发人员上会不是很合理吧。但是我们会有一种思想，这个数字是全体的，大家共同是一个团队的。因为是一个敏捷，一个比较透明的团队，所以一般谁做的多，谁做的少都大家心里都比较清楚。可能有些人比较熟悉某一块，这一块就一直他做，其他人看着。我们现在也鼓励大家多探索自己不熟悉的部分。解决一个一直困扰的问题，做一个presentation，给大家讲授，这个是放在个人绩效里头。总结：让老大抗指标，各开发人员自己评！
问：你们的产品有多个平台，如何处理同时发布的问题，是否会相互牵制？
答：很好的问题，我们也遇到这个问题。我们每个版本有buffer在里边的。我们不是每不是要求平行发布的。但是有的版本是需要这么做的，如果赶不上，就等到下一个Scrum周期后发布，尽可能保证在平行就可以了，不是绝对的。