Scrum

最近在实践Scrum，有一些心得。Scrum不是一个技术名词，而是一种开发流程，确切的说，是敏捷开发（Agile Development）的一种。

一般讲，在一个完整的Scrum流程中，会有产品负责人（Product Owner)，流程管理者（Scrum Master），开发团队（Scrum Team）三个角色。你们各司其职，从一个产品需求列表出发（Product Backlog），细化成每一个迭代周期（Sprint），再接着利用天天的站立会议和看板更新每一个人的开发进度（一般还有燃尽图）。

一些讲Scrum实践的书里，(甚至)会提到用计划纸牌（Planning Poker）来精确预估研发周期的方式，招式百出。

听起来很美好对不对？

实际差之千里。

Scrum对于不少初创团队，都好似Teenage Sex，臆想跟现实判若两然，作很差实践，就以为是彻底扯淡，屁用没有。

事实上，敏捷必定要多实践，本身实践得出的经验才是最牢靠的。咱们之因此抱怨敏捷开发没有解决问题，是由于对它的理解有误区。

不少人以为敏捷就是：

1. “想作就作”的态度，避免任何形式的管理、流程和规矩。

2. 每日站立会议上，对着空气念经，随便挪一挪看板上的任务

3. 一个领导管下属的噱头，走个流程而已

看起来日日有产出，实际上鬼才知道这些产品作了有没有用，这些代码堆完意义在哪里。团队浑然不知下一步要作什么，纷纷两眼看天。

为何会这样？

问题的本质不在于敏捷开发这种流程，而在于团队自己。

初创团队永远是在在极端不肯定的状况下，开发新产品或新服务。

这自己就无路可循，无迹可探，没有围绕着问题的核心去作产品，是没有办法得到要领的。

因此若是要作好敏捷开发，就必须：

厘清产品诉求，认真完成商业闭环

• 你的产品多大程度上解决用户的问题，有没有比现有的方案好10倍

• 你能从产品上赚多少钱，天花板在哪里

• 用户会主动推荐你的产品吗，天然增加引擎在哪里

• 产品要作到何种规模能够覆盖团队开支，你能闭着眼睛算出来吗

面对现实，解决核心问题

• 你如今手里作的，是否是在解决用户真实的产品诉求，仍是你本身脑补的产品诉求

• 有什么方式能够快速解决问题救火上线，而不是等待一周后的新版本

• 面向用户场景输出需求，不要过于在乎何种格式，Done is better than perfect

落实到人，而不是流程

• 任务最终要拆解到人头上，围绕一我的每日工做量/难度来追踪进度，而不是大锅煮汤摸鱼，要保证进度透明

• 保持同理心和道义，你的接口或者文档写的烂，是不专业的表现。己所不欲，勿施于人

• 朴素的拆分任务并完成，你的队友不会把一个简单任务描述的艰难万重，你也不会。

自我欺骗是敏捷开发的禁忌。无论你用什么样的工具（好比用Geekbot代替天天早上的站立会议），都解决不了自欺欺人。

装做看板上一直有任务（哪怕是个简单issue也要拆成好几个），装做设计的产品就是用户想要的，却根本没有调研过友商出品的水准，装做采集的数据有意义，结果根本没法从中获得任何帮助决策的信息，装做天天刷微博是在看行业动态，实际上真的就是在刷微博。

遇到这些状况，团队的负责人必须马上立刻One One，一我的滑水的最大的问题是让团队其余人感到深深的不公。

敏捷开发让你作到在产品夭折前，留出救命的发育机会，越早推出产品，越早拿到你的Alpha用户的真实反馈（他们一般对于现阶段的产品缺点充分包容，但提出问题时却绝不含糊），你也就有更多的机会修正轨道。

若是一个软件开发上线了，最终客户根本没去体验，这样的上线，算不算上线成功？

Scrum必须回归业务本质，才能被善用，不然都是假的。