产品管理之敏捷之路（一）——携手同行，走本身的敏捷之路

这是我最近在公司内部培训所整理的资料，本篇本来是PPT，我在这里整理成博客分享给你们。

另外，最近因事回家待了一个月，因此不少东西都耽搁了，包括Magicodes.NET，这个直到如今我都没有时间去更新它，但愿下周开始可以逐步投入少许时间。

本篇做为开篇，在此，我先列下本系列的内容（可能有些篇章过多，会进行拆分），但愿和你们探讨交流：

1. 产品管理之敏捷之路（一）——携手同行，走本身的敏捷之路
2. 产品管理之敏捷之路（二）——使用TFS生成服务+PowerShell实现持续集成
3. 产品管理之敏捷之路（三）——使用Worktile+Sharepoint进行规范梳理
4. 产品管理之敏捷之路（四）——使用LessChat进行渠道整合（反馈、开发、日志、通知）
5. 产品管理之敏捷之路（五）——使用Worktile进行产品管理

如今开始说说本章的主题（根据我以前培训的PPT改编而成）。

携手同行，走本身的敏捷之路

前言

近来，我一直在思考：

• 如何在有限的资源下，开发出更可用的产品？
• 如何更有效的开发与合做，以及提高团队的开发效率？
• 如何调动团队中每个人的积极性，让每个人都可以在产品的迭代中不断成长？
• 如何使产品团队内部协做更合理更规范，责任更明确？

 

所以，在本篇的内容中，但愿更多的是引导而不是灌输。在此开始以前，我想表达下我的观点：

• 我从未对一种开发模式寄予所有但愿。指望它能解决咱们如今固有的全部问题是不现实的，它多是甜蜜剂，固然也有多是催化剂！
  真正让我寄予但愿的是团队中的每个人，也就是咱们在座的每个人。
• 世界一直在变，而惟一不变的是变化。咱们一路走来，从项目团队到产品团队，从互不相识到协同工做，咱们须要变化，咱们须要调整，咱们须要成长，以组成一个更高效更合理的产品团队——咱们是一个总体，咱们须要携手并进，精诚合做。
• 敏捷管理不可复制，所以咱们须要走出本身的敏捷之路。

 

书籍是人类进步的阶梯

在此以前先推荐两本书，不是我本身的。

淘宝技术这十年

这不是一本好的技术书，可是却绝对值得作产品的人看。

引用书里的一句话：“任何网站的发展都不是一蹴而就的，一般是在什么阶段采用什么技术。在发展的过程当中，网站会遇到各类各样的问题，正是这些缘由才推进着技术的进步与发展，而技术的发展反过来又会促进业务的更大提高。二者互为因果，相互促进”。

所以，任何一个产品，都有一个从烂到好的过程，产品的完善是一步一个脚印踏踏实实作出来的，是一点一点进步起来的。从书中咱们能够看到淘宝其实并无想象中的那么神话，他们早期的产品也是伴随着各类BUG，各类不稳定，各类不完善，这跟咱们目前开发的产品同样，因此咱们无需妄自菲薄。可是，咱们须要有坚持作好产品的决心与毅力，一点一点的完善，一点一点的改进，最终咱们也同样能开发出好的产品。

右下角为淘宝早期风格。

精益创业

当决定作一个东西的时候，不要一开始就把目标定的很宏大很完善，一开始就要设计一个能容纳多少访问量的架构，其实计划永远赶不上变化，你的系统老是随着用户的扩大而渐进改进的。与其一开始就花费巨大的精力与时间去想之后用户规模到多大以后咱们的系统还能不能用的问题，还不如好好知足当前用户的需求，至于之后，那自有之后的应对策略。不然当你花费巨大的精力想要打造一个容纳千万访问量的系统，最后却发现你的系统连十万访问量都达不到。这也是敏捷开发管理的核心理念（亦是精益创业的核心思想），即先在市场中投入一个极简的原型产品，而后经过不断的学习和有价值的用户反馈(通过证明的认知) ，对产品进行快速迭代优化，以期适应市场。

微软Visual Studio团队的敏捷之路

在讨论敏捷以前，咱们先来看看Visual Studio团队的敏捷之路。

•Visual Studio是微软最重要的核心开发工具，到去年10月止，全球.NET开发人员近6百万人，光是VS 2013年版本，下载次数就达到7百万次。

•参与VS开发的人数超过4,700人，分布在美国、瑞士、中国、印度等地的微软研发中心。这群人要负责190万个开发工做项目，完成了近3,600万个程序代码库，累计数据量达到15.3TB。开发团队平均每月会组建（Build）22万屡次。

过去——瀑布开发模式

•瀑布开发模式，开发时程约2年

•花3个月时间来定制长期计划。其中，部门主管须要订定5年产品计划，而产品经理则是要想象2年后的市场需求，来拟定2年后产品上市时的功能蓝图。而后再设定多个里程碑（如图M一、M2，会发布一个对应的测试版本）区分开发阶段，每阶段内先开发程序代码，再进行测试与功能稳定，达成里程碑后发布一个顾客可用的版本。工程师们再依每个里程碑估算本身的工做进度，并修正产品进度，来计算出2年后的哪一天能发布产品。

•每个里程碑阶段内还得设定程序代码开发完成的时间点（Code Complete），由于得预留时间做为测试工做和功能稳定调校，微软过去至少会预留两倍的程序代码开发所用的时间。多数状况是，微软工程师很快就完成程序代码的开发，反而是花了不少时间让功能稳定，例如整合不一样功能间的冲突或整合。

如今——敏捷开发模式

•采用敏捷开发模式，每三周为一个Scrum敏捷开发的Sprint（冲刺）周期，每次Sprint结束后要发布一个VS版本，试用一周后发布给使用者

•开发与测试工做合而为一，转变成持续测试、持续整合的开发模式

•微软也再也不制订产品的5年计划了，而是缩短为只订定每6个月的计划，也就是两季长的计划，并每6个月进行市场或竞争对手评估，让产品能因应市场最新变化。另外还会订定一个18个月后要实现的产品愿景，来规划如软件架构调整或本质性需求调整等须要较长时间做业的目标

改变

固然还有一些其余的改变，本篇就不一一列举了，好比测试团队缩小了，之前须要配备与开发团队规模至关的测试团队。

快鱼法则

先歇一会，又到了说书时间了。

看完了Visual Studio团队的故事，咱们再来看一个故事：

有两我的在树林里过夜。早上，忽然树林里跑出一头大黑熊来，两我的中的一个忙着穿球鞋。另外一我的对他说：“你把球鞋穿上有什么用？咱们反正跑不过熊啊！”忙着穿球鞋的人说：“我不是要跑得快过熊，我是要跑得快过你。” 这个故事给我两点启迪：

• 咱们面对的世界，是一个充满变数而且竞争很是激烈的世界，比跑得快不快，极可能成为决定成功与失败的关键。
• 以往，“大鱼吃小鱼”以往被视为常理，但是在信息社会的市场竞争中，每每不是大鱼吃小鱼，而是快鱼吃慢鱼。这就是快鱼法则。

天下武功无坚不破，惟快不破！——火云邪神

看完故事，咱们再看点实际的。好比下方的企业，在快鱼法则中体现的淋漓尽致：

 

快鱼法则在互联网服务上的体现

• 市场在变化，有太多不肯定的因素
• 需求变化不可避免
• 抢先战略——商机是有限的
• 追求创新
• 须要快速响应用户的变化
• 持续关注用户行为以及用户体验

知道了快鱼法则，咱们再来谈谈敏捷。

为何要敏捷？

下降项目风险

• 缩短反馈周期
• 减小误解(沟通)
• 下降修正错误的代价

确保正确的方向

• 可用的软件
• 用户验证
• 适应变化

总的来讲，就一个字——“变”，适应变化。

弱弱的说一句，对于公司来讲，这玩意儿就是为了最大限度的挖掘程序员的潜力，而且提升效率以及规避风险，最终就是节约公司成本。

什么是敏捷？

关于Scrum和XP

前面说了敏捷它是一种指导思想或开发方式，可是它没有明确告诉咱们到底采用什么样的流程进行开发，而Scrum和XP（即极限编程，它强调把它列出的每一个方法和思想作到极限、作到最好，而它所不提倡的，则一律忽略（如开发前期的总体设计等））就是敏捷开发的具体方式了，你能够采用Scrum方式也能够采用XP方式；Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，可是大部分状况下，二者是结合一块儿应用的，不过咱们侧重于说Scrum。

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动做；把一个开发流程的名字取名为Scrum，我想你必定能想象出你的开发团队在开发一个项目时，你们像打橄榄球同样迅速、富有战斗激情、人人你争我抢地完成它，你必定会感到很是兴奋的。而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工做。

简单的来讲：

XP说：除了编程，什么事也不要打扰我（极限编程）！客户甲，你的测试工做Delay了（客户也是开发中的一员）！

Scrum说：你们都是一条船上的人啦，都利索点划（团队对项目负责）！上次TM才起步就翻船了，此次请你们按照咱们上次总结的划法配合好（反思）！划到前面那个岛，你们就休息下，而后总结下此次的经验还有看看接下来划到哪（迭代、评审、回顾、规划）！…

Scrum开发模型

产品开发反思

了解了敏捷开发，那么，咱们如何走向本身的敏捷呢？

也就是，咱们应该如何来提升开发效率？如何来保障软件质量？如何快速响应市场？

敏捷不是说出来的，是干出来的！Go！

走本身的敏捷之路

如我开篇所说，敏捷管理不可复制，咱们须要走出本身的敏捷之路。每个团队在初始阶段状况都不一样，好比咱们团队，存在如下问题：

1.你们对敏捷了解很少

2.单元测试大多还不会写，并且当前架构并不利于单元测试，那么测试驱动开发咱们须要根据咱们的状况逐步渐进

3.持续集成咱们还难以作到完善，可是能够初具规模

4.会议咱们会增长，可是更多的强调的是随时沟通，若是有须要演示或者相对严谨的，咱们才会召开会议

5.结对编程目前是不可能的

6….

总之，咱们确定没法作到很严格的敏捷开发，那么咱们就开始咱们本身的敏捷之旅吧。

改变观念——主动接受需求的改变而不是拒绝

对于需求变动，说实话，个人内心是拒绝的——一方面，咱们尽量的在细化需求，挖掘需求，以及复杂设计，另外一方面，咱们亦是尽量的确认需求，天然是不太乐意接受这种需求变动。由于每一次的变动都须要咱们付出很大的精力。

然而，产品的方向，谁都没法把控。咱们一次次的拒绝，实际上最终还得一次次接受。咱们必须转变这种心态，而是应该接受合理的需求，同时欢迎并积极引导用户反馈，来不断的完善咱们的产品。

最后，咱们须要知道一点：改变需求是好事情，由于这些改变意味着咱们更了解市场需求。

快速迭代

在以前，咱们总须要很长时间（好比V1耗时大半年）才能发布一个版本，并且这个版本仍是在遵循业务或者咱们的理解的基础上开发的版本。而如今，咱们须要快速迭代，来不断的交付可用的产品。

什么是迭代？迭代是指把一个复杂且开发周期很长的开发任务，分解为不少小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代均可以生产或开发出一个能够交付的软件产品。

敏捷测试——测试驱动开发（TDD）

咱们老是在抱怨没有测试人员，事实上咱们如今招聘测试人员也是很不划算的，由于测试人员的工做量很难饱和，咱们并无须要持续测试的任务交给他们。可是咱们确实很须要测试，由于Bug老是层出不穷，并且很容易重复出现，尤为是当咱们在发布版本前集中测试时，Bug老是让咱们改到崩溃。

确实，在传统测试中，开发人员负责编码，测试人员负责质量验收，测试人员是软件质量的最后一道防线。那么如今起，在咱们的敏捷开发中，系统设计、编码、单元测试、开发测试、重构等关键任务都须要咱们本身（开发人员）来完成，以保证持续的、快速的业务价值交付。也就是，咱们之后须要本身来作测试，除了编写单元测试，手工测试也是咱们分内的事情。所以，后面招人也会优先考虑招聘开发人员。

注意：在持续集成时，会运行全部的单元测试。这实际上提升了开发者的开发效率，由于单元测试能够有效的帮助开发人员发现代码中的逻辑错误。

固然，产品达到必定规模的时候，独立测试人员也是须要的。他们能够来全面的验证和检查一个系统，以及提供自动化测试工具的支持，进行性能测试、负载测试、安全性测试等。

产品自动化测试反思

咱们目前的状况并不适合大规模的自动化测试，咱们只能着手如下几点：

1.简化手工测试（好比自动造数据等等），若是须要花费不少工做量来编写的单元测试，那目前仍是以手工测试代替

2.从架构级别增长对一些经常使用的API的单元测试，保证架构中主体API的正确，便于架构重构

3.在后续的设计中或者系统下个版本时，使用利于搭建单元测试的架构

持续集成

持续集成正是针对上述一系列问题的一种软件开发实践，它倡导团队开发成员必须常常集成他们的工做，甚至天天均可能发生屡次集成。而每次的集成都是经过自动化的构建来验证，包括自动编译、发布和测试，从而尽快地发现集成错误，让团队可以更快的开发内聚的软件。

要素

1.统一的代码库

2.自动构建

3.自动测试

4.每一个人天天都要向代码库主干提交代码

5.每次代码递交后都会在持续集成服务器上触发一次构建

6.保证快速构建

7.模拟生产环境的自动测试

8.每一个人均可以很容易的获取最新可执行的应用程序

9.每一个人都清楚正在发生的情况

10.自动化的部署

原则

1. 全部的开发人员须要在本地机器上作本地构建，而后再提交的版本控制库中，从而确保他们的变动不会致使持续集成失败。

2. 开发人员天天至少向版本控制库中提交一次代码。

3. 开发人员天天至少须要从版本控制库中更新一次代码到本地机器。

4. 须要有专门的集成服务器来执行集成构建,天天要执行屡次构建。

5. 每次构建都要100%经过。

6. 每次构建均可以生成可发布的产品。

7. 修复失败的构建是优先级最高的事情。

8. 测试是将来，将来是测试

咱们的持续集成流程

生成列表：

失败结果：

成功结果：

推行每日站立会议

咱们过去老是很死板的在项目经理和开发人员之间互动——这个任务你作的如何了？那么如今，咱们须要这么一个短会：

目的：

• 团队成员间工做进度的沟通和协调；
• 帮助团队聚焦于每日活动，而且便于更新任务板和燃尽图；
• 细化任务，尽量的将任务具体到天，让你们都明确知道今天应该作什么！

时间：每日早晨10点，时长控制在15分钟左右

内容：

• 从上次站立会议到如今，你完成了什么?
• 从如今到下次站立会议，你将要作什么?
• 你遇到什么阻碍，须要其它人如何帮你?

注意：

1. 不要迟到，延时，或者坐下
2. 不要在会议中讨论技术细节以及沟通需求。

提示：团队成员在聆听他人发言时，都应该想这个问题：“我该怎么帮他作得更快？”

简单

产品伊始，我花了一个月的时间来制定了插件式架构，实际上如今这个架构看起来已经不太适合当前的业务。需求一直在变，咱们尽量的去设计与开发，可是如今，不少设计只是当时看起来很好罢了。咱们抱怨过设计缺陷以及架构缺陷，甚至“抱憾终身”，那么如今开始，咱们再也不过多的设计——而是注重规范与重构。

咱们不可能预期后面需求会如何变化，因此不可能一开始就构建一个完美的架构来适应之后的全部变化。所以敏捷团队不会去构建明天的软件，而把注意力放在如何经过最简单的方法完成如今须要解决的问题。若是已经预计到了确定存在哪些需求扩展点，咱们在一开始是否须要考虑呢？这时咱们须要根据本身的理解去决定是否考虑，若是深信在明天发生了这个问题也能够轻易处理的话，那么就最好先不考虑。

所以在后面的开发中，咱们的法则就两个字——简单。简单设计，简单架构，简单编码还有简单评估。

另一点，咱们须要注意的是，数据库咱们也再也不作过多的设计——也就是咱们须要认同一点，数据库的设计是随时能够变动的，也就是咱们几乎不进行预先设计。

微博上有人说“好的架构是进化来的，不是设计来的”。的确如此，其实还能够再加上一句“好的功能也是进化来的，不是设计来的” 。——《淘宝技术这十年》

注意代码规范，提升代码的可读性

简单并不意味着没有规范。简单和规范的目的都是为了提升代码的可阅读性，提升代码的可阅读性是为了便于代码修改以及重构——也就是增长代码的可维护性。

以下图所示，在有条件的状况下，咱们会逐步实行如下步骤：

若是说提升代码的可读性是为了便于重构，那么自动化单元测试则是重构的保证。

利用反馈以及真实的数据来完善产品

以下图所示，咱们已经开发了不少功能，咱们尽量的使每一个功能完善。可是实际上，咱们并不清楚用户喜欢哪些功能，这些功能的用户体验具体如何，甚至是在用户的环境下能不能用！

那么如今开始，咱们必须以真实的反馈以及真实的使用数据来不断的完善咱们的产品。

下面是反馈流程：

迭代规划会议

迭代规划会议是指在每轮迭代开始时进行的规划会议，定义本轮迭代的目标，承诺本轮迭代中要完成的工做，提早识别和评估可能出现的风险，并经过合理的估算调整项目的迭代范围。

目标

• 制定合理的迭代范围和目标
• 明确迭代的开发任务

要求

• 如无特殊缘由，产品团队利益相关者均需参加
• 会议召开前，会通知全部利益相关者具体开会时间

内容

• 这里我要求将反馈审批与讨论放在这里进行，以减小大型会议的次数
• 会议只讨论下次迭代内容以及任务优先级，并不涉及工做量的评估以及时长的评估

会议结果

明确迭代范围与目标，明确这次迭代的开发任务

评审会议

在每次冲刺结束，咱们都须要进行一次评审会议，让团队向产品负责人和利益相关者展现已完成的功能。

也就是“全部的sprint（冲刺）都结束于演示”！

目标：

1.增强团队的自我承认。

2.展现功能、回答利益相关者对展现的疑问并记录所指望的更改与反馈。

3.评审会议能够吸引相关利益者的关注，让其余人了解团队在作些什么，并获得重要反馈。

4.作演示也会迫使开发团队真正完成一些工做（好比那些完成了99%的功能）。

时间：每一次冲刺完成时根据状况召开。

要求：

1.团队成员都可主持。必须准备PPT，能够很粗糙，可是必须有条理。

2.确保全部人员都清晰目标，若是有人对产品不知道，则花几分钟来进行描述。

3.团队根据本次迭代内容，逐个地介绍此次 Sprint 的结果，和演示新功能。

4.会议过程当中，须要记录需求变动、新想法、新需求、Bug或问题以及障碍。

5.若是功能没法演示，则以报表或者报告甚至其余任意形式证实。

会议结果

对此次 Sprint 的结果和整个产品的开发状态的共识

注意：

• 让演示关注业务层次，不要关注技术细节。注意力放在“咱们作了什么”，而不是“咱们怎么作的”
• 有的sprint可能会包含不少bug修复等功能，在评审会议中不要演示太多一大堆细碎的bug修复，除非这个很重要。

事实上，后续咱们还能够加上估算会议以及sprint回顾会议，可是目前我想将这些内容在平常探讨中完成。除非有必要，咱们才会单独召开。

常常检讨

上图是孔子，曾经子曰….，这里就不赘述了。

敏捷不能照抄照搬，所以，咱们须要常常在如何才能更有效地工做方面进行检讨，而后相应地对本身的行为进行调整。

因为不少不肯定性因素会致使计划失效，好比项目成员增减、技术应用效果、用户需求的改变、竞争者对咱们的影响等都会让咱们做出不一样的反应。而敏捷不是基于预约义的工做方式，而是基于经验性的方式，对以上这些变化，咱们必须经过不断的检讨调整来保持团队的敏捷性。好比，反思会议。

反思会议

根据项目须要举行。其目的不是为了找到治愈方案，而是要发现哪些方面须要改进。项目成员都可召开与推动。

要求：

1.从过去中学习，指导未来。

2.改进团队的生产力。

3.轮流发言。每一个人都有机会在不被人打断的状况下讲出本身的想法，他认为何是好的，哪些能够作的更好，哪些须要改变。

注意：

1.不要让管理层人员参与会议。

2.不要在团队以外讨论找到的东西。

会议内容：

1.过去哪些作的不错？哪些应该改进？

2.咱们能作什么？哪些不在咱们掌控以内？

3.意见交流

始终保持让团队坐在一块儿

如今，咱们都是坐在一块儿的，可是从此咱们会始终保持这种状态。

“一块儿”意味着：

• 互相听到：全部人均可以彼此交谈，没必要大声喊，没必要离开座位。
• 互相看到：全部人均可以看到彼此，便于协做。后续还能够考虑放置一个实体的任务板，便于团队随时可以看到进度。
• 隔离：若是大家整个团队忽然站起来，自发造成一个激烈的设计讨论，团队外的任何人都不会被打扰到。反之亦然。
• 随时沟通：好比我须要协助
• 不过于依赖文档和工具：好比任务在Worktile上分配完毕，也给他们打个招呼吧。

保持可持续的开发速度/精力充沛的工做

敏捷开发讲究的是高效工做，并且是持续的高效工做。那么咱们须要注意如下几点：

1.尽量避免加班（几乎全部的敏捷开发模式都反对加班，由于加班工做在软件开发中会下降生产率，并且会下降产品质量。咱们目前还没法保障不加班，可是咱们要尽量的避免加班——将当天的事情在工做时间内完成）。

2.上班时间保持充沛的精力（好比早睡早起，喝点咖啡等等）

3.集中精力

精诚合做的团队理念

• 产品不属于我我的，整个团队都必须对其负责。那么在需求评审、需求评估、迭代规划、开发交流的时候，你们都应该积极参与
• 必须达成共识，必须明确每次迭代的内容，并且知晓本身的和整个产品的进度
• 每一个人再也不是单独的个体，在交流的时候，你不只仅只关心本身相关的模块，你还得为你们出谋划策，甚至是帮忙
• 积极沟通，固然文档不是必须的，可是有准备的沟通是必须的！

不断的提高本身

就如上篇所说，系统设计、编码、单元测试、开发测试、重构等关键任务都须要咱们本身（开发人员）来完成，也就是咱们必须得肩负起更多的使命——咱们再也不是只关注开发，只专一于本身的开发任务，咱们是全能的（测试、开发、设计甚至管理）。

每周讲座

目的：鼓励你们交流、分享、学习甚至是反思。

讲座内容：技术、经验、心得、建议、产品与团队思考都可，亦可召开反思会议。

机制：每周一次，一次仅限一人，轮流讲座，次序能够根据须要调整。

时间：每周周四下午，时间和日期能够更改，可是须要提早通知。如非客观缘由，不然不能取消。

要求：必须准备PPT以及演讲素材。

时长：半小时左右。

讲师：团队成员。

参与人：无限制，自愿参加 
讲座完成，须要将PPT和相关资料附加到相关任务，后续统一归档到Sharepoint相关文档库。

规范以及梳理意识

不管是本身，仍是针对整个产品，咱们都必需要有规范以及梳理意识，这个意识不能单靠我我的来推进，须要你们自发的来遵照以及完善。目前咱们作到了如下几点，可是我但愿你们在遵照的前提下，反过来推进这些机制的完善，而且相互监督：

    

无规矩不成方圆，团队还将试行行为规范和准则，实行扣分制。具体请查看相关文档说明。（后续会介绍）

最后，嗯，好比长期提供咖啡

其实说了这么多，仍是这句比较实在。

最后

敏捷开发之路，咱们还需不断摸索前进。

我知道个人将来不是梦
我认真的过每一分钟
个人将来不是梦
个人心跟着但愿在动

——张雨生《个人将来不是梦》