听《worktile首席科学官讲scrum》笔记 - 简书
听《worktile首席科学官讲scrum》笔记
前几天听了worktile的徐老师分享了一些对scrum软件开发管理方法的一些经验和理解，觉得讲的非常好，在此总结一些要点和自己的理解，以免以后忘记辜负了徐老师的分享。
首先科普一下何为scrum，下面是wiki上对的解释。
Scrum是一种的，用于迭代式增量软件开发过程。Scrum在英语是运动中争球的意思。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法。Scrum之间的合作称为“Scrum of Scrums”。
那么先说说什么是敏捷软件开发，从字面上理解敏捷就是快，灵活的的意思。敏捷开发就是一种快且灵活的软件开发管理方法。用一句流行的话说就是“拥抱变化”。
为什么要敏捷
那么为什么要拥抱变化呢，其实这个世界上任何事务都在变化之中，软件需求也是一样，客户也不可能在开发没有开始之前就把需求想的明明白白，在开发开始到产品交付，需求难免不发生变化。而需求一旦变化就会出现问题，修改已经实现的功能成本很高。为什么改动一小下成本那么高呢？这里分两个成本——劳动成本和心理成本。
要理解改动成本先要理解传统项目管理流程。首先在项目开发是以团队协作（一般指10人以上的开发团队，一两人的团队自带敏捷属性）的形式在推进的。有了团队就自然需要管理。那么怎么管理团队呢？最简单直观的方法就是至上而下的推进，由上面的人员负责设计，写好文档（文档越详细越好），分好任务（任务越细越好）下派到实际的代码编写人员。这样其实写文档的时间就会占据非常长的开发周期，然后下派任务，下面的人员需要严格执行被分配的任务。这样的话对于管理者来说是表面上是非常容易衡量执行人员的工作量，并且可以清晰的掌握项目进度。
然而理想很美好，现实很残酷。首先从文档上说，对设计系统写文档的管理人员要求非常高，其实就是凭经验，想象来描述如何实现一个系统。这就有点像考试的时候全凭心算来解一道数学大题，大部分人没有这个能力，不动笔一步步算很难把前后的推导逻辑在脑海中连成一条线。所以难免在系统设计阶段就有一些遗漏，而且设计阶段只有少数几个有系统设计经验的程序员来做，其他初级程序员的劳动力处于闲置状态。
再说任务分配，传统开发团队里面的项目成员一般都是每个人有每个人的特技，比如一个完整的项目一般分UI/UX设计、IOS开发、Android开发、web前端开发、服务器后台开发（还可以继续细分）。这些开发人员一般都是彼此不了其他种类的开发人员所掌握的技术，只能做自己擅长领域的开发工作。初级开发人员拿到了高级程序员写的系统设计文档（有很多甚至详细到用伪代码描述实现逻辑），就可以开始工作了，完全照着文档来实现代码，这样他们不需要动脑袋，完全执行上级的指令，自然也不需要对产品负责，也不关心项目成功与否，项目的目标是什么。
这样就会造成两个问题：
一个功能从设计到实现，需要经过很多人手。这样下面的执行人员要等上面的执行人员的设计稿，很难避免人力上的浪费。并且执行人员也需要一段时间来理解设计人员的意图，这中间还会产生很多沟通成本。（想跟深入理解这种浪费可以看这本书，虽针对IT项目管理的书，但是很详细的讨论了关于生产流程的改进）
写代码的人由于只是照着设计写代码，没有脑力活动，很难调动工作热情，也不会产生对程序品质负责的责任心。
理解到上面存在的管理的问题，那么就知道为什么改动一个功能需要的成本很大了，首先需要从设计到执行，至上到下的需要几个人的工作来实现一个改动，中间就会产生很大的沟通成本（扯皮现象几乎是不可能避免的）。这是劳动成本。其次就是由于代码编写人员对项目是没有责任感且是被动接受任务，所以改动一个功能相当于说他们之前的工作白做，他们避免不了出现埋怨心理。（会觉得PM和客户都是脑袋不好使的SB。单如果他们自己也参与到产品的决策和设计当中所不定就会意识到需求变更时不可避免的）这是心理成本。
敏捷方法的产生就是为了解决上面的问题。首先变化是不可避免的，与其说痛苦的被动接受变化，我们为什么不主动拥抱变化呢。
解释了这么多，我来给徐老师介绍的scrum做个总结。
思想的转变，拥抱变化！！（这是根本，需要从老大到最底层的共同认识）
以客户利益最大化为目标，只做对项目有意义的事儿。
团队角色分为scrum master、product owner、developer team。
product owner 总结backlog item，对产品功能有最终决定权。
挑选核心功能来放在一个scrum里，所有团队所有成员评估工数。
开发人员自己领task（增加主观能动性）
task粒度最好控制在一天之内完成。
一个sprint结束的产出物必须是一个可演示的demo。
开发人员自己演示他们开发的功能。（好处是可以给开发人员压力让他们代码的bug减少）
每天站立会议，掌握项目进度，当前遇到的问题。(控制时间在15分钟以内)
partial release。（后面会解释）
理想状态下 developer team的开发人员都是cross functional的。（俗称全能，从前端到后端什么都能做）
一个sprint（scrum中的一次冲刺）结束之后，要开总结会议，总结出需要改进的地方，在下一个sprint中改进，持续改进。
敏捷推进过程中不好搞定的人加入到敏捷团队里，感受敏捷过程。
上面都是我从徐老师的谈话内容里整理出来的关于scrum的一些要点，基本上可以认为越上面的点越重要，越是scrum的核心。
一个敏捷项目
现在我自己以一个假想中的案例来讨论在具体实施中如何应用上面总结出来的要点。假设公司接单开发一个有IOS、Android、web客户端的SNS产品。
Product Owner
product owner虽然理论上应该是客户，但是一般情况下客户不会到开发现场，所以对于这样一个外包的开发项目，product owner就应该是我们平时说的销售（售前或产品经理），这个人的首要技能是沟通技巧，尽量能全面掌握客户需求，及时反馈客户意见。他在我们所说的Scrum里面应该算责任最大的人，一个功能做与不做他一人有最后决定权。这里所谓的责任最大指的是当项目完成时，这个product owner要确保我们实现的功能是客户所需要的。他其实就是一个“客户代理”，他的职责就是尽可能让他的想法接近客户想法。所以他在团队里做决定的时候要尽量把自己想象成客户。
Scrum Master
scrum master这个人就可以是我们原来所说的技术经理或者PM，他负责搭建开发团队，推进项目进度。这个scrum master和product owner两个人必须通力合作，力气往一块使，共同的目标应该是【以高质量，高效率实现用户需求】。
Developer Team
根据徐老师的讲解，这个团队的团队成员最好都是多面手，一个人可以做项目开发中的各个阶段的工作。比如服务器后端的程序员可以干HTML&CSS，IOS开发可以干服务器后端开发。下面专门用一个小节讨论这个。
设计&测试人员
虽然根据徐老师的讲解，他们的scrum团队里不存在设计和测试人员这个团队，但是考虑到现实项目中Developer Team中的团队成员不可能都是那种高配的多面手，考虑到需要保证项目完成的质量在这里还是需要导入测试团队，设计人员由于也对产品的UX负责，他们其实应该是最懂产品的那群人，所以在项目开发阶段也介入测试工作。
这个时候是PO（Product Owner，以下略称PO）与客户沟通，尽量全面的总结客户需求，然后与SM一起沟通（Scrum Master，以下略称SM）项目的工数，初步给客户报价。然后SM就需要找到一到两个DT（Developer Team成员，以下略称SM），进行初期项目的技术调查，把技术难点总结出来（找几个给力的DT先期攻克），把初期的服务器框架搭建好。这时需要一个设计人员先期就开始设计产品的界面（web，native）。项目全面开工的条件是，当这几个前期跟进的人员对产品需求达成统一认识，并且设计人员已经出了客户基本认可的设计稿的时候。
组织DT团队，开会给所有团队成员讲解产品的核心需求，还有第一期的设计稿以及功能设计。讨论第一轮sprint首先要开发的功能。
把功能需求制作成功能卡片，每个项目成员都挑选他们认为第一轮sprint需要开发的功能并写明理由预估工时数。
由PO参考所有开发人员的意见最后确定这次sprint需要开发的功能。
DT团队成员各自的领取功能卡片。
开始冲刺开发。
每个功能卡片开发结束之后，发给其他成员review代码。（随时改善代码规范）
由开发人员负责向团队全体成员演示他所开发的功能。
PO负责带领测试团队对产品进行测试，产品上线之前的质量把关有PO和测试团队负责。
一个冲刺结束，开总结大会总结项目推进流程。
循环执行上面步骤。
原则上文档尽量少写。API的定义以及接口规范一定要写。在开发过程中，客户端、前端与服务器后端有任何上的沟通不便需要及时反映给SM，然后由SM视情况判断是否需要追加说明文档，以方便各个开发人员之间的衔接。功能卡片也可视作项目的文档。随时检验开发人员对整体需求的把握，以及产品系统构成的理解，如果有理解不透彻的地方，可考虑补充说明文档（尽量图形化）。
关于Review
项目初期每一个功能开发完成之后要马上review代码，前期开发阶review工作的权重要大于功能开发，以保证团队在代码质量方面能磨合到认识一致，功能开发可以慢慢加速。代码review这个是一个很大的课题，可能还需要专门写一篇文章来讲。
原则上尽量避免开会，基本上团队成员每天开一个15分钟的站立会议，团队成员提出开发中遇到的问题，各个功能开发的进度如何。然后PO和SM两个人单独开会看是否有急需解决的问题，例如需要人员调度或者功能变更。
尽量实施每日部署，部署环境如下：
dev： 开发服务器，服务器开发人员与客户团开发人员确认用服务器。（尽量每天部署）
stg： 一次scrum完成，demo演示完毕的代码部署到pre服务器，这个是PO、测试人员、以及客户都可以访问的服务器，代码bug发生率相对来说比stg应该低。
prd：真正上线产品的服务器。
版本控制工具上应该维护同名的三个分支（当然还需要创建其他的开发分支，推荐使用git管理代码，分支的创建对于git也是相当轻量的操作），用来部署上面的三个服务器。客户端的产品应该以同样的管理方式打包，利用deploygate之类的测试应用发布服务来发布。
关于bug反馈
需要专门的课题管理工具登录bug，比如worktile（开发流程中的任务管理同样也可以使用worktile之类的工具）。敏捷team也需要测试团队。尽量让测试人员也接触到开发。自动化测试，持续集成。
关于DT团队中的多面手
现实的团队中多面手是比较少见的，一般情况下一个团队成员只干他擅长的一方面的技术工作。在一个SNS产品的项目里。我们可以把开发团队的成员分为下面几类：
前端（HTML&CSS 或者JS）
后端 （服务器开发 Java PHP .net Python等）
Android客户端
在一个项目中培养能干各方面技术的开发人员是有很多好处的，最重要的一点是产品开发过程中，可以根据具体需求，随时调节开发人员配置，减少下游开发人员等上游开发人员造成的人力浪费。从另一个方向考虑，培养多面手开发人员本身符合员工自己对成长的需求。
具体来讲可以按下面的技能延伸轨迹培养员工：设计&-& 前端 &-& 后端 &-& IOS客户端/Andriod客户端
敏捷的核心观点是改变，所以上面的流程也不会一层不变。考虑到敏捷会不断的改变上面的开发流程，我也没有把开发流程写的太具体。当然万变不离其中，我们改进流程的宗旨是为了让开发人员能更舒服的干他们喜欢干的开发工作，让彼此间的沟通协作更流畅，让生产效率更高。一切阻碍往这些方面发展的流程我们都可以尝试去掉。理想和现实的差距总是很大，上面谈的都是理想，现实做起来一定不会顺利，不管怎么说，我们需要不断改进，并且有一个量化标准来衡量改变是否对开发过程有益，如果有益就保持这个改变，如果无益就删除这个改变，然后寻求其他的改变，往复循环。我们把它叫做持续改进。
推荐一本书：。徐老师讲课的总结请点击。附近人在搜什么
Worktile王涛：以任务为轴心驱动团队协同
　　有个孩纸，读了个莫名其妙的大学，读了个莫名其妙的研究生，然后找工作跳槽，走过大多数人该走的路，但是他身上却有个犀利的名词“微软MVP”。他叫王涛，Worktile的CEO。　　三十多岁的人都有点躁动和跃跃欲试，可能因为小时候的“理想”还没有实现，积攒了一部分财富后，分分钟想跳上“有轨”的电车，奔驰在创业的路上。& & & & & & & & & & & & &
& & & & & & & & & & & & & & &速途网配图　　技术大牛：创业之路到处是“坑”　　80年的王涛坐上了“80后”的头班车，一个机电工程的学生由于“不学无术”一头扎进了IT领域，然后在这个行业里无法自拔的走下去。
“第一次创业是朋友在做主导，当时没有太多想法，就是觉得上班有点无聊，但是那款产品没有成功。”王涛说。对于第一次创业的失败，王涛的反思是产品价值，一款有用的、用户价值清楚的产品才能吸引用户。　　由于个人兴趣所致，王涛的第二次创业选择了效率类软件，他说：“当时是Win8要上线，由于个人对微软很了解，所以对Win8很看好，也是想借着Win8这个平台把知事做起来。”但事实证明，Win8是不成熟的操作系统，知事虽然广受好评，但狭窄的平台导致了知事用户群受限，虽然知事还在但王涛并不想把他继续做下去。　　第三次创业王涛选择了协同软件，他说：“云服务在中国落地，垂直化服务的Saas就有了土壤。对于一个中小团队，买不起五六十万的OA系统，DIY不但功能不完整，而且浪费人力物力，所以对效率的追求是一个扁平化团队的痛点。”就这样，第二次创业的三个人撸起袖子开始了第三次的创业。　　Worktile：以任务为轴心的协同软件　　Worktile是一款以任务及效率为核心来驱动团队协同的软件。首页工作台类似个人的工作板和信息流，有团队中各种各样的工作动态，不同项目上成员发生的东西都在动态里有体现，动态可以主动性的关注，被关注的人会有通知，消息通知是实时性。对于感兴趣的动态可以点开交流，直观了解团队发生了什么，也有类似schedule、meeting的功能。　　看板式的团队管理方式是Worktile的一大亮点，王涛说这个idea来自于原来办公室的贴条主义，随意的拖拽从体验上讲更自由更人性。Worktile上的文档支持就像一个在线的office，文档存储是以项目为维度，文件可以和任务相关联。　　在管理方面Worktile可以有效的生成周报和日报，客户关系管理上列表本身的自由度可以任意调整工作流程，灵活性更高。王涛说：“这些就像团队的无形资产，让团队之间形成知识库。”　　随着Worktile移动版的上线，使移动办公变得具体化。但是相较于PC软件，移动端显得功能单一，结构不够丰富。对此王涛表示：“因为前面有点赶，想尽快的把0变成1，完善web的同时兼顾移动端就有些吃力，下一段时间会聚焦在移动端，一两个月的时间移动端将会焕然一新。”　　Saas疯长：面对市场信心十足　　云计算炒热后，Saas呈井喷式疯长，市场上出现多款相似的协同办公软件，面对竞争王涛表示现阶段的定位看似一样，但团队基因不一样就决定了产品的重点。王涛说：“以哪个作为重点去驱动产品是有差别的，如果是以沟通作为重点的话产品就会变成明道、Yammer，如果以文档记录来驱动可能就变成Evernote，Office365，Google
doc。Worktile以任务作为一等公民，因为对于协同来说，任务可以驱动着解决效率、分享、沟通。”　　对于最近被大家嚼烂的账户安全问题，王涛说：“Worktile现在采用两步验证，这是目前同类产品上没有出现的。并且专门聘请白帽子帮忙把关安全问题。数据栽备方面，Worktile在香港、美国都有数据备份。”
　　Worktile在海外华人圈中颇具人气，据王涛透露年内移动版将上线拓展海外市场。现在Worktile的团队用户已经超过三万，王涛表示Worktile可以做三年五年十年，但产品初衷不能变。小团队使用团队任务分配和协作软件(如 Tower, Worktile，Trello)时,怎么划分任务粒度会比较合适?
团队协作任务管理TeambitiontowerWorktile知乎用户，...看下 Tower 团队自己的使用方法吧~ 戳下面的连接“任务”让项目顺利运行引用一部分内容：分解任务注意范围和粒度1、只确定最近1～2周内完成的任务，而不是项目内的所有任务。目的是保证每个人都可以聚焦在近期的工作目标上，不用浪费精力去思考太久远的可能要做的事情。2、尽量细的拆分每条任务。在我们产品团队中，以“小时”为单位拆分任务，指定计划者能够考虑更加周详细致，也更容易在团队内部讨论，及早发现问题，减少及闭门造成导致方向走偏。所以，我们团队目前定期每周开例会的——大家对本周工作目标有了一个统一清晰的认识后，着手安排本周工作计划，分解任务也基本控制在2～8小时的粒度范围。明确任务的唯一指派人我们强调每条任务都要指定给具体的负责人，对于暂时不能确定负责人的任务，我们会默认分配给自己，由创建任务的人来负责，保证每个任务都有人在跟踪。此外，我们收到不少用户对增加任务分派多人的呼声，经过仔细分析思考，我们认为任务分派给多人会造成的责任人不明确，如果任务延误，容易相互推诿责任。任务分配给多人，对每个人的工作内容描述不明确，还容易造成工作浪费，因而，我们坚定的放弃了这个功能需求。任务的描述详尽清晰因为是Tower中都是书面化的沟通，语言文字的表述会直接影响沟通的顺畅度。任务描述尽量详尽完整，清晰易懂，方便其他成员理解。有用户反馈说任务标题有字数限制不方便，我们发现他们把关于任务的描述通通放在了标题里，其实任务的标题用来简要描述任务的，需要更加详尽的文字和附件信息，可以在评论中去完成。卢瑟西德，身宅斗室之中，心浪千里之外……这是Worktile官方博客上《最佳实践：如何跟踪分配给多人的任务状态》中的一部分，很适合这个问题，粘过来分享一下，有兴趣的可以点击文章标题看看全文。一：任务的粒度尽可能细分每个任务的粒度尽可能划分的详细，不要创建一个毫无意义的任务，比如有一个任务：实现评论的回复功能。这样一个任务实际意义就不大，因为实现这样一个功能涉及到各个成员之间的配合问题，有产品设计、UI设计、前端、后端等等。不如对任务进行更细粒度的划分，把任务按照每个成员职责的不同，分解为不同的任务，每个任务只指定一名负责人：另外，如果你更希望按每位成员的职责分配任务，可以灵活使用Worktile中的任务列表，如下图所示：二：使用检查项拆分任务对于任务粒度的划分，只是我们的一个最佳实践建议，并不是必须的。Worktile中的任务支持检查项，你可以为任务设置多个检查点，每位成员完成之后都给自己所负责的那部分检查点打勾，这样既能避免多个成员同时标记任务完成状态，也能只管的看到任务的进展情况。当所有的检查项都完成时，再标记任务状态为完成。王宝明，企明岛（）专注于团…分享我们团队的一点经验：分层次分解任务，因为变化的比较快，所以最大粒度会按周分解，比如运营人员、市场人员等，按周的计划一般是用文档记录的，按每周记录。方便大家聚焦团队当周的工作重点；对于开发性的任务、BUG处理、设计任务，一些比较细的执行事项都是按事情分解的，指派给相关的责任人后，通过处理、验收。最后闭环。其实还是得根据具体的情况定，我们一般不会限定说多久时间，都是以截止日期为目标，成员根据实际的情况调整执行。郭雄飞，软件开发/IC设计/开源一般来说大于两个小时，小于几天的粒度比较合适。任务的结果应该被清晰的描述，如果对于如何完成这个任务没有很明确的界限，可能会导致这个任务卡长时间的呆在板上，成为瓶颈。知乎用户，独学而无友，则孤陋而寡闻。任务的粒度与工具并无太大关系，而应该看任务的复杂度及被分配对象的能力。通常来说，如果接受任务的人能力够强，经验够丰富，任务的颗粒度就可以粗一些。
TA的推荐TA的最新馆藏