您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
产品经理敏捷实践：如何让团队的迭代效率更高.pdf 4页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
下载提示
1.本站不保证该用户上传的文档完整性，不预览、不比对内容而直接下载产生的反悔问题本站不予受理。
2.该文档所得收入(下载+内容+预览三)归上传者、原创者。
3.登录后可充值，立即自动返金币，充值渠道很便利
需要金币：150 &&
产品经理敏捷实践：如何让团队的迭代效率更高
你可能关注的文档：
··········
··········
——————————————————————云客网 您网站的流量加油站
产品经理敏捷实践：如何让团队的迭代效率更高
【文章摘要】在产品研发过程中，从需求管理到最终的产品运营，全过程应
用敏捷的思想，让产品团队成为产品的主人和管理创新的驱动者。当产品团队自
发的去持续优化产品，不断提升产品质量和研发效率时，整个团队的工作效率就
提升了，产品的迭代周期自然会缩短，他们会树立更高的目标去挑战，当他们持
续地周而复始时，卓越就成为了团队的习惯。
在互联网行业，敏捷应该不是陌生的名词了。互联网产品快速发展的特性，
决定了“小步快跑”的管理思想，持续迭代，不断的改进产品。而应用敏捷基本上
可以让迭代周期减少一半，在追求效率和产出的互联网，这确实是一剂良方。
在产品研发过程中，从需求管理到最终的产品运营，全过程应用敏捷的思想，
让产品团队成为产品的主人和管理创新的驱动者。当产品团队自发的去持续优化
产品，不断提升产品质量和研发效率时，整个团队的工作效率就提升了，产品的
迭代周期自然会缩短，他们会树立更高的目标去挑战，当他们持续地周而复始时，
卓越就成为了团队的习惯。
在敏捷实施的过程中，从产品经理的角度来说，更应该关心需求是否也可以
迭代的方式去产出，合理的按照价值和优先级去安排每个迭代需求，是产品经理
需要关注的。这会保证每个迭代开发人员在实现的都是优先级最高的需求。从开
发人员角度来讲，对每个迭代的任务的需求理解和工作量安排是他们所要关心的，
要合理的分配每个人的任务，以达到最大化的效率利用，进而保证每个迭代的高
——————————————————————云客网 您网站的流量加油站
1号店目前已全面实施敏捷开发，结合自己对敏捷需求管理的理解，分享在
1号店工作期间实施敏捷项目管理的实践经验、失败教训。主要从以下几个环节
提高团队效率，最终成功地让4-6周的交付周期缩减到了2 周左右。
迭代需求集中评审和评估工作量
在每个迭代开始之前，产品经理就需要把下一个迭代要做的需求安排好，待
到迭代开始之前，对所安排的需求进行集中讲解评审，参与的对象是整个团队。
这样做的好处是：研发、测试团队和ScrumMaster 一起深入理解需求，测试团
队也因此能够更早地开始编写测试脚本，这样需求、开发、测试都是敏捷的，否
则只有开发是敏捷的，两头就会都跟不上。
很多人觉得每个迭代开始之前，花上一整天的时间去理解需求和评估工作量
是很浪费的，但是磨刀不误砍柴工，在工作开展之前把一切不确定性的东西都确
认好，这样后续的开发效率就会高很多。另外对产品经理的要求就是提前梳理需
求，这个不是简单的梳理，而是要充分评估手头所有需求功能点的价值和优先级，
先做优先级高的。
站会：随时把控进度、解决问题
站着开会带来的紧张感和疲劳感可以有效地避免过于冗长的会议，且可以保
持清醒的状态，一般都在早上上班的时候开，也叫“晨会”。可以尝试让发言者站
在中间，这种做法更能增强其自信心和责任感。站会的议题是每人说一下自己昨
天做了什么，今天要做什么，有没有遇到问题。产品经理可以参与站会听取一下
团队成员的进度，对各个需求的进展了然于胸，对发生的问题需要介入协助的，
可以在会后就协助处理。
团队自我驱动
在迭代开始之前要做好任务的认领和分配，可以培养团队主动工作的积极性。
在迭代开始后，要明确只有开发出可用的功能才算完成;明确迭代目标，并把目
标分配给明确的负责人;严格要求代码提交环节，确保提交后测试即可介入;明确
每个人的工作职责，优化团队协作机制，中间出现某个成员进度弱后的情况，可
以调配进度快的成员帮忙。同时要避免整体重构，尽可能局部重构。产品经理更
需要确定迭代目标能否完成而不仅是关注迭代进度。
持续集成和产品演示环境
迭代任务陆续完成过程中，要能自动化集成到演示环境，这样就可以边开发
边验证，测试也就可以边开发边测试，省去了很多重复的工作。并且可以尽早的
发现问题或bug，及时修复。产品演示环境能够尽早Ready 是很重要的，这样可
以提前看到产品的最终形态。
迭代总结会
—————
正在加载中，请稍后...登录以解锁更多InfoQ新功能
获取更新并接收通知
给您喜爱的内容点赞
关注您喜爱的编辑与同行
966,690 十一月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
实战大规模敏捷
实战大规模敏捷
Yousef Awad
0&他的粉丝
0&他的粉丝
日. 估计阅读时间:
：开启与Netflix、微软、ThoughtWorks等公司的技术创新之路！
亲爱的读者：我们最近添加了一些个人消息定制功能，您只需选择感兴趣的技术主题，即可获取重要资讯的。
通过大规模敏捷，各个团队可以共同集中资源、安排优先事项，共同为整个项目承担责任，而不是只关注自己的团队或特定的任务。然而要做到这一点实非易事。从职场文化上来看，这就像是要求财务部门为了公司的高级目标而自愿退居市场部门身后一样。不仅如此，财务部门还得向市场部门贡献自己的时间与专业技能来帮助后者创造绩效！财务报表先放着，必须先把产品宣传册搞出来！呵呵……
我们曾同一家在线礼品市场的领军级电商企业（年营收5亿美元）合作。他们成功实现了大规模敏捷，过程中也遇到了人们能想到的各种障碍，并进行了相应的调整。这家客户并没有循规蹈矩，而是在实践大规模敏捷的过程中寻找适合自身的方案与最佳实践，选择了行之有效的路线并一路随时修正方向。与他们合作并见证他们克服挑战的过程开拓了我们的视野。我们明白了哪些东西是有用的，哪些是不切实际的，及怎样做才能成功实现目标。
迁移到大规模敏捷环境
这家电商企业有6个敏捷团队，他们各自独立运作，但都在为同一个项目提供支持。这个项目包含多个功能驱动型团队（如登录、结账、礼品选项、消息、交付、支付、账单和评价），这些团队的工作彼此交错，服务对象则是一些相互关联的线上品牌。各个团队皆为敏捷团队，习惯了沟通、合作与责任分担。但要把这种合作氛围扩展到他们熟悉的领域之外却是团队未曾接触的理念。从敏捷到大规模敏捷的区别，就像是从国家内部的省份间合作到国与国之间的国际合作一样。总体上，大规模敏捷需要更高层次的思维、包容与耐心。
相关厂商内容
相关赞助商
但相比大规模敏捷遭遇的挑战，放弃它带来的成本似乎更高。因为这些团队之间没有实现敏捷，随之而来的沟通障碍与效率低下的团队合作让敏捷环境的许多优势丧失殆尽。从头至尾，整个项目沦落到几乎没能实现和交付一项明确的功能。客户希望通过企业层面的大规模敏捷让整个项目得到广泛认可。
这家公司将6个包括3至10人的独立队伍整合为一个团队。主要的方式是为整个项目设置具有明确指标的短期迭代；并根据迭代、技能差异、团队依赖来灵活安排团队成员贡献他们各自的技能。他们没有特意去塑造某种大规模敏捷的形式，而是以循序渐进的方式来调整团队和安排会议，根据团队反馈与数据分析结果来逐步前进。
与此同时，各个团队依旧保有自己的每日站会（daily standup），有自己的scrum master和技术领导。大规模敏捷的目的并不是淘汰独立团队的形式，而是让各个团队能够为同一个项目协作努力。
从开始阶段到项目过程中，这家电商企业部署了一些工具，应用了一些实践方法以实现大规模敏捷：
单一的任务列表：一开始6个团队都有自己的任务列表。开始大规模敏捷后他们就把所有团队的列表合而为一。大家需要像在自己团队内部那样来安排优先事项，但因为涉及到多个子团队，他们要设法让优先事项、关联事项都对彼此透明。单一的任务列表解决了这个问题。现在大家依照同一份任务列表实施敏捷行动，由此引出了产品委员会。
产品委员会：产品委员会基于战略层面运作，每天召开一小时的会议。通过专注于以下领域，委员会在所有团队间维持敏捷文化氛围：
最高优先事项
当前的迭代（sprint）活动
未计划事项
需要在项目层级和跨团队层面做出的决策
为下一次迭代所做的准备，包括两种情况：
某个团队需要其他团队的协作来完成下一次迭代。例如A团队要完成迭代15中的任务需要一些B团队在迭代14中的成果。
在团队之间重新分配资源：根据之后迭代的情况，团队可能需要一些自身当前不具备的技能。这时就需要考虑在必要时，将各团队或团队成员集中起来以完成最优先事项。
产品委员会的最重要角色是引入与增进文化氛围的变迁，这种有些戏剧化的改变就是从部门或团队级的敏捷升格为项目层级的敏捷。结果当然可能出现某种状况：例如完成项目的最优路线中，A部门的需求需要让位于B部门，甚至在必要时为后者贡献时间与技能。所有利益方都必须意识到这一点并支持这种做法。
Scrum of scrums：如同产品委员会从战略层面制定单一的任务列表一样，各团队的scrum master也需要有机联合为同一个scrum master服务。由此引出所谓“scrum of scrums”。在大规模敏捷环境中代表各个团队的scrum master组成一个小组。小组在战术层面运作，专注于执行。小组每两天碰一次头，讨论各项预期、需要克服的障碍和任何团队内部或团队之间的各种问题。
引入“产品委员会”和“scrum of scrums”时，公司遭遇了团队成员的一些质疑。很多团队成员想到的是官僚作风，所谓“委员会的决定”之类。事实上，如果成员不能全心参与到这些会议，不把它们当作一种通向开放和无私分享的途径，不去共同探讨优先事项、技能组合、面临的障碍和机遇，这些委员会也就形同虚设。大规模敏捷要起效靠的是将好的商业实践应用到项目中，重要的是实际行动而非纸上谈兵。
这家客户为平息对产品委员会和scrum of scrums的质疑而采取的一项重要的附加手段，不是减少会议频率，而是开更多的会！召开这些额外的临时会议的目的是为了消除个体层面的怀疑。这么做是为了强调一个观点，这家客户实施大规模敏捷实质是优先看重人力资源，且项目的成功取决于此。因此企业的行动需要增强这种优先级，不仅体现在管理层面，更要体现在所有层级的每一位团队成员。由此发起了两类会议：“精益咖啡会议”（lean coffee session）和“敏捷咖啡会议”（agile coffee session）。这些会议为所有团队的成员提供了非正式的途径来讨论各种话题，包括技术上或人际关系方面的事项、担忧和建议。这些会议有助于有机扩散大规模敏捷的文化，这种扩散并非从上至下，而是相反。
敏捷教练（稍后进一步讨论）在转变团队成员对会议的看法上扮演了关键角色，这些会议不只是理论争辩和观点分享，更多的是作出决策和即时行动。与会成员发现这些会议导向了实时行动和开放交流后，他们就乐于参与其中了。
主动汇报：很多团队成员习惯于将数据收集当作被动的汇报工具，与他们的日常工作无甚关联。但在大规模敏捷环境下，只有实时应用收集到的团队数据才会有效促进项目进展。由此引入了主动汇报。类似地，敏捷教练会帮助团队成员将数据视为主动而非被动的工具。
大规模敏捷需要同时在宏观和微观层面收集数据，并进行数据分析和实时响应。这家企业的案例里，统计信息和数据来自整个项目和所有为项目提供支持的团队。这些数据包括如下内容：
故事分数（story point）的完成数量（即Velocity）
按照原因对积压的用户故事（user story）进行分类（例如“被阻塞的”）
团队之间的依赖
根据以往的迭代执行效率来预测项目的完成情况
这一层级的汇报需要一些企业级的工具，这些工具用来在项目、团队和成员层级收集数据。这家公司之前就使用进行代码与bug追踪，结果他们发现拿它用于项目层级的报告也挺容易。重点在于这套工具需要应用到所有层级，用在所有种类的报告与回顾上，不能拿Excel工作簿或者Word文档来应付了事。
在项目、团队与迭代层级的回顾阶段会进行数据分析。根据分析结果采取的行动包括合并、拆分团队和调动团队成员。精益咖啡会议和敏捷咖啡会议有助于让这些转变更加平滑自然。
敏捷教练：这家公司请到了外部的敏捷教练，不过根据不同案例中技能组的情况，外部和内部人员都可以充任这一角色。本案例中，请到的敏捷教练引入并激励了企业的敏捷文化，鼓励并促成了团队的表现，并引导团队学会与内部、外部的团队、管理者与其他利益方进行协作。在团队成员改变固有思维和接受新理念的过程中敏捷教练起到了关键的作用。
大规模敏捷过程中不该出现的问题
为了让6个敏捷团队有效协作，这家领军级电商必须解决一些遗留问题：
未能将人员置于比项目更高的优先地位：在这家客户成功实施大规模敏捷的过程中，由项目至上的文化转变成人员至上的文化是核心要素。如果没有这种核心的转变，公司不可能得到团队与部门内部必要的信任和尊重，自然也就无法有效完成任务和迭代。咖啡会议就是用来促成这一变化的。所有层级的担忧都应该得到听取和重视，这样所有人才会愿意去信任上层体系。
未能有效处理数据：大规模敏捷中的主动汇报与回顾能反映出问题所在，乃至揭示处理它们的方法。通过研究数据，公司发现往往问题的根源和解决方案的瓶颈恰恰来自于抱怨这些问题最多的人身上！正是经过分析的数据证明了这一点。
未能使用可扩展规模的工具：公司里有的敏捷团队想用Excel工作簿来实施大规模敏捷。对于这种情况来说工具就成了瓶颈。让所有团队都迁移到TFS环境是至关重要的。
未能实现协调一致与透明化：有些项目参与者觉得开会是浪费时间，不管会议是开发层级、scrum master层级还是利益关系方层级。他们认定会议上大家不会开诚布公，开会也不会直接引发行动。因此，委员会与scrum of scrums在透明原则下作出的努力与进展，成为了提升项目参与度的不可或缺的要素。
未能给团队成员设置敏捷成果的考核标准。实现大规模敏捷是体系与人员的职责，最终的成功需要两者共同努力。这家公司发现他们需要提供、选择、参与、撤出和调动各种资源来激发团队活力。公司对内部与外部利益方定下了考核标准，如果团队成员不能提供所需的技能，缺乏应有的态度，他或她就是项目成功的阻碍，会被立即调到其他项目中。公司会主动拒绝或调动这些人员：
一门心思只想着在自己擅长领域干活表现，对其他事情不管不顾的成员
对适应持续变化的环境不感兴趣的成员
不想与同事持续沟通，获取信息和反馈结果影响了项目总体效率的成员
企业级大规模敏捷事关交付与控制。这家公司的成果正是交付与控制的结果：
在规模化初期，开始的两个迭代用来建设团队、组建工具、设置产品列表。第四个迭代开始交付。第六个迭代起团队开始持续交付。Velocity数据能够了解和预测各个团队何时交付自己负责的功能。
大规模敏捷开始之前几乎没有明确的功能得以实现和接受。随着大规模敏捷开始实施，积压的用户故事比例从80%降到了50%，直至最终下降到了稳定、可接受的10%以下。
数字摆在这里，而与这些数字同样重要的是一种协作、信任和充满信心的文化；这种文化是实现这些数据所反映成果的关键因素，并最终成就了一个规模更大、更加忠诚敬业的队伍。平台根据团队成员的特质与项目情况进行调整，使得雇员能够亲身体会大规模敏捷的成果。这家客户不仅成功完成了项目，更是形成了能够实现更多类似成就的企业文化。
Yousef Awad是Integrant的CEO，他在开发、数据库管理和项目管理方面有着亮眼的从业经历。Integrant有超过130位员工，提供定制的.NET软件开发服务和测试团队，帮助IT部门掌控项目，有效扩展内部团队。除了Integrant的事业之外，Yousef还热心于让儿童和青年体会编程的力量。Yousef正在努力为低龄儿童开设代码课程，为他们提供手把手的指导。他欢迎相关的探讨，可以通过与他联络。
查看英文原文：
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（，），微信（微信号：）关注我们。
Author Contacted
文化 & 方法
51 他的粉丝
伸缩性敏捷
0 他的粉丝
1 他的粉丝
企业级敏捷
1 他的粉丝
13 他的粉丝
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
订阅InfoQ每周精要，加入拥有25万多名资深开发者的庞大技术社区。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
找回密码....
InfoQ账号使用的E-mail
关注你最喜爱的话题和作者
快速浏览网站内你所感兴趣话题的精选内容。
内容自由定制
选择想要阅读的主题和喜爱的作者定制自己的新闻源。
设置通知机制以获取内容更新对您而言是否重要
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。探索技术管理与敏捷管理的一年：到底如何做技术管理和敏捷管理？
探索技术管理与敏捷管理的一年：到底如何做技术管理和敏捷管理？
人人都是产品经理
回想2016年初，至今还诚惶诚恐。在那时，Android应用开发团队还一团乱麻，时常有紧急问题发生，在那时，敏捷开发还在蹒跚学步。好在，一年过去了，我们也走出来了，没有原地踏步。1.如何学做管理其实，我很不想用“管理”二字，但是用一个新的词语，又未免增加了理解的成本。为什么不想用“管理”二字呢？因为，提到这个词语，我总是会很肤浅的联想到“流程”、“控制”、“绩效”、“计划”、”组织开会“这些工作。然而，我每天跟在团队后面，不断的督促他们完成任务就是管理了吗？这件事情有意义吗，我做这件事能产生多少价值？做这些事情有利于我个人的职业发展吗？这些问题，在开始之初时常在我脑海中荡漾，久久不能平静。回到原点，公司把我安排在这个位置上，最现实的，也是最基本的，是保障这个领域能高质高效的配合产品项目的研发工作。那么，还管他管理的定义是什么，带领一帮人，达成这个目标，就是管理。是的，我就是这样一个现实主义者。于是乎，所有的管理工作，都将围绕着这个目标去探索，去开展。在这项工作的开展过程中，有两个人的话影响着我，其中包括：“你自己写程序都能干得那么好，为什么人到你手下后，就不行了呢？“，”现在你们的管理知识，就和小学的数学水平一样。“，”管理是一门实践的艺术。“，在此，不得不感谢这两位导师，促进了我在这一领域的发展。个人的拙见，学做管理要重点关注以下三件事情：1.培养你的团队成员，目标就是让他们和你一样强，甚至比你还强。有时，我们会担心团队成员变得比我都还强，那我的位置不是会被他取代？公司还要我干嘛？个人的拙见，这是一个伪命题，这里仅仅是目标让他们变得更强，但是既然是你去培养他们，他们不可能全面超越你，你们各有所长。另外，作为一名管理者，应该有这样的自信和胸怀，我们自身也在不断学习，我们会走得更远。只有他们都变强了，团队才会变得更强，才能把事情做得更好，我们带领团队的价值才能有所体现。2.加强管理知识的专业化学习，而不是闭门造车，自己摸索，多看书，看好书，多听有经验人士的讲座。3.针对公司的特点，团队的特点，不断的尝试、总结、调整你所学到的方式方法，在实践中验证和改进它，变成你自身的经验，深入骨髓。这种机会难得，很多人没有这样的机会去学习管理。2.如何做Android应用团队管理Android应用技术团队，专业知识强，技术细分领域多，人员技术能力参差不齐。面对市场上纷繁众多的机型，移动端让人操蛋的网络复杂性，以及让人恶心到爆的运营商，简直是苦不堪言。苦归苦，事情还得做，而且还得做好，于是今年一年经历了以下三个阶段：第一阶段：全面重构以前那让人难以启齿的代码。第二阶段：配合永不停歇的敏捷开发，人员迅速激增。第三阶段：领域化划分，基本走上正轨。我对Android应用团队的管理的观念，也随着这三个阶段，不断的演变和进化。在接手团队之初，团队人员仅有5人，那是程序代码格外凌乱，耦合严重，连最基本的代码合并都会经常出问题，线上问题也是时常发生，而且是越演越烈的趋势。由于我个人经验有限，当时也就只看到了这些问题，针对问题解决问题。并且当时有这样的观念，只要我把代码整体重构了，保障代码框架清晰易懂，解耦，Android应用团队就会在框架的引导下越来越好。可惜，我错了，我真的错了！虽然，这样做了后，在很大程度上改善了原有的问题，但是并不彻底。整个团队开始暴露新的问题：框架约束力不够强，部分开发人员在执行过程中有其形，无其实。部分开发人员基础知识不过关，框架可管不了这个。svn管理，jenkins编译，gradle，maven等开发工具链问题不能得到较快、较好的解决。团队对某些领域的技术研究深度不够，导致问题不能得到有效的解决。敏捷迭代不断，团队成员忙于迭代，缺乏技术积累，人员工作分配不均，开发效率和质量得不到太好的控制。人员不断增多，但是却不能较好的发挥他们的价值。等等就这样，带着这些问题，我走过了前两个阶段，直到到达第三阶段，才有了质的改变。总结以上问题，核心还是在于团队能力线问题，所以提高团队能力线，才是以上问题的正解。到这里，正如“如何学做管理”中所说，这个问题要通过培养团队成员来解决，那么问题来了，怎么样培养团队成员呢？我们的Android应用开发团队是一个年轻的团队，一些知识体系都还有待完善和建设，作为团队负责人，我有责任和义务给团队成员指明未来的方向。因此，作为培养的第一步，先明确我们团队需要些什么，他们要做些什么，现在能做些什么？我们先来第一步，组织构建：组织构建控制组织大小，4到6人为一个小组织。我们团队有20人，一个20人的团队，任何思想的传达效率都会比较低，协作成本高，根据我个人的开发经验，4到6人的团队沟通成本低（随便找个空地就能开聊），利于互帮互助。明确各个小组织的领域范畴和责任。这个点需要一定的技术背景才能操作，我将Android应用领域拆分为8个领域，包括数据与系统对接、网络与性能、界面与国际化、H5与工具链，每个小组织负责2两个领域的持续跟进研究，以及沉淀。人员责任包括领域研究和产品开发。对于人员的要求，所有应用开发人员同样需要负责模块功能的开发，同时要兼顾领域研究，让所有人员既有产品观，全局观（了解应用开发需要的所有技术），同时又有自己的核心领域，做到广而精。这样才划分带来了很多的好处，各个领域的独立，降低了团队成员的心智负担（操心的事情多），每个人都能一门心思的研究自己的领域，遇到非自己领域问题搞不定时，团队里总能找到能提供帮助的人（有所依靠，哈哈）。一个小组织的成立，我们还可以做弱结对编程、代码审查。因为他们的领域相同，知识体系一样，很容易做到这件事，沟通交流更顺心。另外，附加的收益，由于领域的独立，紧接着领域的沉淀也逐步加强，各种设计文档也很自然的产生（开发人员不是天生都不喜欢写文档，而是不愿意写没有意义的文档），未来新成员培训也是很有希望做到的。这些好像和团队成员培养没关系？嗯，是的，没有直接关系，但是他们是我进行团队培养的基础，是成员成长必不可少的环境，没有这样的设定，团队培养很难落地执行，接下来开始团队培养：团队培养识别团队中的核心成员，给他们合适的权力和责任。想想，一个班里面，除了老师还有班委。为什么呢？层级太多不是也不怎么好么？如果我能同时兼顾20人的所有细节工作，自然不想再构建新的层级。当我们的关注的事务细化到一个层面后，那么精力就不够了，作为领域团队层面，我们的关注点要细化到代码设计甚至编码级别，一个人能搞定吗？至少我搞不定！那么这和培养有什么关系呢？我对培养的定义不仅仅是指导，还包括培养环境的构建。所以这里做的目的主要有两个。第一，给他们更大的发挥空间，发挥更多的价值（构建带领一个小领域开发的学习环境，现在的开发已经很少能单兵作战了），第二，让他们带我传递我的思想和理念，小团队传递效率更高，深度更深。各领域持续指导和跟进。各领域成立后，我的精力主要放在和他们沟通上，让他们明白程序应该怎么设计，这个领域需要做哪些事情，应该怎么做，成员如何组织等，反复不断的沟通、总结、改善，持续的做下去，直到我觉得我们大家的思想是一致的，方式方法没有问题（当然，如果我错了，那么问题就大了，我得保证我没有搞错，或者错了及时改正），这样他们才能有效的指导他们领域的成员，带领他们前进。领域拉通，成员能力挖掘，查漏补缺。各小领域成立后，并不代表我就可以做甩手掌柜，除了各领域的培养以外，我还需要拉通各个小领域，促使他们有效的协作，降低他们之间的耦合，减少跨领域的成本。同时，还需要持续不断的关注团队成员的学习进展，给与他们合适的建议，以及符合他当前能力的工作，针对有潜力的成员重点指导，针对有问题的成员及时告诉他的问题，促使他改善。关注新技术，加强自身对技术的学习，带着团队向前走。细节有很多，这里谈到了主要方面，个人总结能力还是有限啊，主要只想说一点：核心是为了产品的研发，开展基于培养提升团队成员能力，形成自组织，流程、规范、考核均是辅助措施，能无就无，谨慎对待。3.如何做敏捷项目管理敏捷团队是一个全功能团队，里面包含了各个领域的成员，由于公司原本组织架构的一些特点，我们并没有像标准敏捷项目团队那样，有产品经理、敏捷教练等职务，与之对应的是规划与交互，项目负责人。虽然“形”对不上，但是如果能对上“神”，也是不错的。在敏捷之初，我们并没有理解什么叫迭代，我们傻乎乎的定迭代周期为一周，而且还觉得自己在走敏捷的迭代。可惜我们那不是迭代，我们只是每周计划一下需要开发的工作而已，仅此而已。因而带来了很多问题，前端需求人员不知道功能的开发预期和进展，项目负责人也就是协调协调资源，面对纷繁复杂的功能项开发，也不太情况每个功能的开发进展，当前是否正常（除非非常不正常才能发现）。整个项目组感觉都忙忙碌碌，但是却不知道大家都做了些什么？每天晨会大家说的事情都有点不知所云，感觉晨会都快没有实际意义了。问题太多，以至于我们有点迷失方向。敏捷，宣称要拥抱变化，我们却粗浅的理解为不需要计划，是不是很白痴。我个人现在对拥抱变化的理解为：“及时交付可体验的产品，随时做好调整的准备，日常的工作任务安排，如果发现不合符预期，需要及时调整，重新评估新的任务，而不是掩耳盗铃，觉得不列一个新任务就会快一点”。好了，临近年底，对于敏捷总算有所顿悟，多亏了《敏捷估算和规划》这本书，给予了我很多启发。接下来，谈谈具体的一些实施细节。由于我们为了保障版本的按时发布，我们采用了版本火车的形式，所以，我们每个发布版本并没有很强的计划（目前还在纠结改善的地方），而常规的敏捷一般包括三个维度的计划工作，最高维度为版本计划，其次而迭代计划，再次为工作任务。所以，针对我们现有的特点，本文仅讨论到迭代计划及其以下维度层面。那么如何做迭代计划呢？我个人觉得一定要遵循以下原则：迭代的目标是交付可体验的产品，不是完成任务。所以，迭代计划里面只能是用户故事及需求，而不是某某人的任务，另外迭代并不是完成开发，还包括视觉、测试的工作。迭代的周期要合理。针对不同的产品特点，迭代周期一般为2到4周，如果周期过短，就需要把用户故事的粒度拆分到足够小（不是任何产品都能拆到如此小的粒度），因为我们要在一个迭代周期完成开发、视觉、测试的工作，针对我们的产品特性，我们最终改为3周一次迭代。此外，过短的迭代周期，会议也会增加不少呢，还有一些别的非研发工作损耗。评估故事点。从长远考虑，评估故事点有利于团队知道自己的速度，如果哪天上版本计划，有了这项基本数据，能更好，更快，更准确的评估版本开发时间。故事点是对规模的评估，不是时间的评估。评估故事点需要一定的技巧，我选择10个用户故事，里面包含各种难度的需求，然后给0.1、1、2、3、5、8、13、20、40、100，然后让他们根据这些用户故事的工作量（包含开发、时间、测试的工作量），然后给这些故事分配对应的值，值得重点说明的是0.1和100，在《敏捷估算和规划》一书中采用了0，代表那些基本可以忽略工作量的故事，避免因个别故事太小导致影响后面的相对值，里面重点说到10个0不等于0，因此我干脆改为0.1，更容易体现出10个0.1是有工作量的，至于100嘛，仅仅是为了标记当前故事无法评估，其实目前我们20和40也没有用到，过大的用户故事不利于跟进。有了这些以后，还有一些问题会困扰我们，一个迭代安排多少用户故事，每日晨会如何开展？迭代发布会，迭代计划会，故事点评审会这些会议怎么组织，在什么时候组织？我们怎么能准确评估一个迭代的工作量，某个领域任务过多怎么办？啊呀，问题实在是太多了，真是人越多问题越多，我们的敏捷团队有20人，20真的和我有缘啊，同时管理两种类型，两个20人的团队也是一种挑战！目前潜意识认为20人的敏捷团队过大，还没有想到太好的拆分计划，还需要不断的总结分析想办法。上面的问题我就不都解答了，只是想说明敏捷并不是几项简单的流程，它是一个系统化的解决方案，里面有很多细节，就像我们写软件，设计交互一样。现在回想以前自己做软件时，对项目管理人的哪些肤浅的认识真是惭愧。接下来我要重点说明一下在迭代计划下的任务拆分，当我们计划好本次迭代需要完成的用户故事时，下一步任务就是需要将用户故事拆分成实际领域的工作任务，这种任务我们简直是太熟悉了，例如：完成界面编码。那么在做任务拆分时，有哪些需要遵循的原则呢？任务需要拆分到1到16小时的工作量。控制任务的粒度，有利于更快的得到任务的进展和反馈。告诉团队成员，尽量评估准确任务工作量，但是我们允许任务评估不准确，并且我们也认为任务不可能评估那么准确。拆分任务的目的不是为了评估某个人的工作量和效率，主要目的是基于任务得到反馈，团队事务透明，以及便于拉通各个领域协作。当发现任务评估不准确时，及时调整任务时间，或者将原有的任务重新拆分为新的任务，或者新的几个任务。我们要客观的承认任务的难度，这样有利于团队成员更积极的拆解任务，更真实的评估任务时间，让整个团队得到最真实的反馈。根据任务计算各领域工时，发现迭代瓶颈。当所有的故事都拆解成各个领域的任务时，我们可以很轻易的发现瓶颈出下哪个领域，并及时作出对应的调整。根据剩余的总工时量，绘制迭代耗散图。每日晨会根据看板的任务流动情况，更新迭代耗散图，让团队成员了解到迭代进展和速度。不要量化团队成员的个人速度，更多的基于团队去考核和引导。不要通过量化团队成员的速度来对团队成员进行考核，这样很容易引起团队成员各自为政，并且各种评估不合理，我们需要通过其他手段进行成员评估，引导大家基于团队目标进行行动，共同承担责任。当我们任务拆解已经完成后，接下来就是每日晨会了，开晨会一般是聊昨天做了什么，遇到什么问题，今天要干什么。在没有做这些计划之前，我觉得早上说这三件事很无趣，很无意义。但是，当我们的迭代这样进行后，说这三件事就很自然了。昨天做了什么？用于驱动看板上在doing中的任务，是否要挪动到done中。遇到什么问题？根据对应任务遇到的具体问题，促使团队成员了解具体的情况，进行交流。今天要做什么？用于驱动看板上在todo中的任务，是否要挪动到doing中。有了这些细粒度的工作任务，晨会就这样开就可以了，由于晨会流程的标准化，我们可以任意安排团队成员主持晨会，好开心！我可以从这件事中解脱出来，在晨会中更专注的关注项目的进展。在任务安排中，同一个人尽量要控制doing中的任务不超过2项，否则不太好及时得到反馈和跟进。这样的晨会，我能很及时的发现项目中的异常点，及时评估和协调，当我告诉测试你们资源不够时，再也不是那么苍白无力，测试也会很悻然的接受我的建议。4.总结本年度参加部门的例会，部长的三句话目前印象深刻。三角形最稳定。刚开始听到这句话基本上是左耳朵进，右耳朵出，没有太多的感触。直到我将Android应用开发团队划分为四个小领域团队后，才有所领悟。是的，多方关联的组织相对于一家独大的情况确实更加的稳定可靠，也许物极必反也是这个道理。提升团队能力线。这句话给了我信心，让我确信当前做的事方向是正确的，作为一个团队管理者，这一点一定要做到。我们谈原则。这句话给了我信心以及指导，渐渐我的也潜移默化的给团队成员谈原则，谈思想，谈未来。让我们的思想在同一战线上，路才不会走偏，才能放心的把一些事情彻底的交手出去。很感谢部门对我的信任，对于我这样一个管理的新人，授权我去尝试这么多的事情，给我成长的环境。2017年且行且珍惜，尽量少挖坑，带领团队走得更远。本文由 @空穴来风 原创发布于人人都是产品经理。未经许可，禁止转载。
本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。
人人都是产品经理
百家号 最近更新：
简介: 中国最大、最活跃产品经理社区
作者最新文章