最近在实践Scrum，有一些心得。Scrum不是一个技术名词，而是一种开发流程，确切的说，是敏捷开发（Agile Development）的一种。
通常讲，在一个完整的Scrum流程中，会有产品负责人（Product Owner)，流程管理者（Scrum Master），开发团队（Scrum Team）三个角色。大家各司其职，从一个产品需求列表出发（Product Backlog），细化成每个迭代周期（Sprint），再接着利用每天的站立会议和看板更新每个人的开发进度（通常还有燃尽图）。
一些讲Scrum实践的书里，(甚至)会提到用计划纸牌（Planning Poker）来精确预估研发周期的方式，招式百出。
听起来很美好对不对？
实际差之千里。
Scrum对于很多初创团队，都好似Teenage Sex，臆想跟现实判若两然，做不好实践，就觉得是完全扯淡，屁用没有。
事实上，敏捷一定要多实践，自己实践得出的经验才是最牢靠的。我们之所以抱怨敏捷开发没有解决问题，是因为对它的理解有误区。
很多人觉得敏捷就是：
- “想做就做”的态度，避免任何形式的管理、流程和规矩。
- 每日站立会议上，对着空气念经，随便挪一挪看板上的任务
- 一个领导管下属的噱头，走个流程而已
看起来日日有产出，实际上鬼才知道这些产品做了有没有用，这些代码堆完意义在哪里。团队浑然不知下一步要做什么，纷纷两眼看天。
为什么会这样？
问题的本质不在于敏捷开发这种流程，而在于团队本身。
初创团队永远是在在极端不确定的情况下，开发新产品或新服务。
这本身就无路可循，无迹可探，没有围绕着问题的核心去做产品，是没有办法获得要领的。
所以如果要做好敏捷开发，就必须：
#厘清产品诉求，认真完成商业闭环
- 你的产品多大程度上解决用户的问题，有没有比现有的方案好10倍
- 你能从产品上赚多少钱，天花板在哪里
- 用户会主动推荐你的产品吗，自然增长引擎在哪里
- 产品要做到何种规模可以覆盖团队开支，你能闭着眼睛算出来吗
#面对现实，解决核心问题
- 你现在手里做的，是不是在解决用户真实的产品诉求，还是你自己脑补的产品诉求
- 有什么方式可以快速解决问题救火上线，而不是等待一周后的新版本
- 面向用户场景输出需求，不要过于在意何种格式，Done is better than perfect
#落实到人，而不是流程
- 任务最终要拆解到人头上，围绕一个人每日工作量/难度来追踪进度，而不是大锅煮汤摸鱼，要保证进度透明
- 保持同理心和道义，你的接口或者文档写的烂，是不专业的表现。己所不欲，勿施于人
- 朴素的拆分任务并完成，你的队友不会把一个简单任务描述的艰难万重，你也不会。
自我欺骗是敏捷开发的禁忌。不管你用什么样的工具（比如用Geekbot代替每天早上的站立会议），都解决不了自欺欺人。
装作看板上一直有任务（哪怕是个简单issue也要拆成好几个），装作设计的产品就是用户想要的，却根本没有调研过友商出品的水准，装作采集的数据有意义，结果根本无法从中得到任何帮助决策的信息，装作每天刷微博是在看行业动态，实际上真的就是在刷微博。
遇到这些情况，团队的负责人必须立刻马上One One，一个人滑水的最大的问题是让团队其他人感到深深的不公。
敏捷开发让你做到在产品夭折前，留出救命的发育机会，越早推出产品，越早拿到你的Alpha用户的真实反馈（他们通常对于现阶段的产品缺点充分包容，但提出问题时却毫不含糊），你也就有更多的机会修正轨道。
如果一个软件开发上线了，最终客户根本没去体验，这样的上线，算不算上线成功？
Scrum必须回归业务本质，才能被善用，否则都是假的。