pmp敏捷性开发

从PM的角度聊聊敏捷开发

从去年年底开始负责APP的社区功能，技术实现上用可H5的形式，从APP团队中独立出来以小团队尝试敏捷开发模式的探索，而我作为产品经理，自然也是这个敏捷项目的Scrum Master

我们团队的构成为：

这应该算是敏捷开发中最mini的团队，而且大部分人还不是完整的一人力投入到社区工作中，包括我自己但好在其他人额外的工作也由我这边管理，从需求排期上我可以灵活支配大家的工作排期，不影响到社区项目整体节奏经过这快一年的磨合，我们的迭代速度从2周变为1周，也把敏捷开发流程修改践行到最适合我们团队的模式

有一些我作为产品经理对于敏捷开发的思考，将其记录下来

所有讲Scrum敏捷开发的文章里都很重视团队每日的站会，今天做了什么，将要做什么，有什么障碍的站会三个主题是为了团队每个人快读沟通当前的进度与困难，促使团队更好的协同开发，认为站会是敏捷开发中必不可少的环节但是在施行中，站会的效率很难保证，经常变成昨日热门话题的集中闲聊会，当然也是我这个PM组织的烂而且因为是弹性工作制，加上北京早上糟糕的交通，召集会议也花很多时间

鉴于此，我们不再开晨会，而是直接坐在一起每天需要同步大家进度的时候，直接转个椅子快速沟通就结束了，而且遇到问题也及时让同事提出来，大家一个转身就去看具体问题了

另外这种从技术产品设计的独立团队中剖离出来的独立感，坐在一起能让团队成员有项目团队的归属感除工作以外，大家也更熟悉生活中的彼此，能更好分担协助彼此完成项目的工作

在公司开发流程中最常用的项目协作工具是Readmine我个人是对传统的这类软件开发时代用的协作工具ReadmineBugzilla抱有无限的敌意，因为这类工具经过这么多年的更新，实在是太完善了，太大太全太复杂并且传统项目管理工具的受众是专职的项目经理，产品经理用这类软件做项目管理太耗费时间，太容易掉到琐碎的项目管理细节中

所以，在我们项目中采用Tower做项目管理工具类似的看板类项目管理工具如TrelloTeambitionPhabricatorTower大多大同小异，找一个自己顺手习惯的就好看板类的项目管理工具最方便的就是拖拽任务，可以在一页上看清该版本各个任务的进度另外这类项目管理工具有更好的扩展性，有丰富的插件可以去选择性集成以提高开发效率

在敏捷开发的流程中，产品经理需要做好项目管理的工作而项目管理工具是必不可少的，至于如何选择每个人使用习惯差异很大，可以根据自己团队现实情况去选择总之不要用传统的项目管理软件，因为传统项目管理工具的受众是项目经理，而不是产品经理

我们公司没有UE，产品经理除了出需求，还需要给出交互如果按照正规的文档流程规范，一个版本的文档写完，留给开发的时间也就不多了至少在我们项目中，我不写文档只出交互，重要的点直接在图中文字标注但产品的逻辑细节，我会在画交互稿的同时记录在个人的印象笔记里好记性不如烂笔头，尽管不输出正式的文档，但产品的逻辑必须明确毕竟后续的需求修改测试用例都基于原始的产品逻辑，产品经理忘记自己设计的东西，无论如何都是说不过去的

输出交互稿之后，我会单独拉上开发测试和视觉去开一个会，具体讲一下这个需求的设计，传达本来需要我用文字写在文档中的意思当然不写文档，不代表需求模糊，经不起其他人在会上的挑战

会上说需求设计的最大的好处是，我能明确的用口语传达出对需求细节的感情色彩，哪儿是重点，哪儿细节体验要保证，哪儿做成什么样都行很多是无法拆分的需求细节，但是通过言语说出来就很容易被拆分掉，更好地让开发容易理解需求重点，加快开发速度

一般项目的需求评审一般是产品拉着各个老大来做需求评审，各个老大接了需求后会上评估下工期，会下再把相关的需求分给下面的人做具体做事的人，往往是接到需求后再啃文档，自己理解后再去开发总结复盘的邮件更是只在产品组内部和leader的邮箱里呆着，根本不会给到每个开发成员

而敏捷开发从需求评审阶段就必须拉上所有团队成员，产品经理要把需求场景优先等级用户调研讲给所有人听然后要在团队中达成一致，让团队所有的小伙伴都认可你的需求，并且愿意主动把这个需求做下去版本上线后的效果也需要同步给团队的小伙伴，让大家都输出的结果都有反馈，然后也可以听听团队每个人的建议与感觉，再综合考虑及时调整产品这些能极大强化团队的凝聚力，让每个人并非只是做自己手头的工作，更有产品的主人翁意识

这点经验与我们项目类型有关，因为我们做的是社区类产品，很多测试的case流程必须要帐号间的互动，久而久之我们团队在测试阶段每个人都演变成了测试

测试同事写完测试用例，等提测之后，我们所有人都汇聚在一个小会议室里每个人分工其中的一些流程测试，快速协助测试走完case，然后快速将bug记在白板上发到群里备份，一部分需要专业手段的测试还需要测试同事专业的方法，大家协助测试的部分主要还是流程测试快速过完之后，开发回去解bug，测试同事整理测试报告遇到重大的bug block版本，大家就直接在会议室里讨论预案

这种快速的团队测试能极大的提升测试效率，往往测试同事花一天才能跑完的用例，我们四个人在会议室一小时就搞定了，而且因为开发也参与了测试流程，连问题描述复现步骤都不用写就可以直接定位问题

这点其实是所有开发排期的都需要注意的问题，只是敏捷开发更容易暴露这个问题这里的重要功能，并不是产品优先级上的重要，而是开发难度上的定义因为敏捷开发的周期很短，每个重要功能上线后往往需要一定时间进行稳定如果在排期上每个Sprint都有重要的功能，稳定上个版本与开发下个版本交叉，基本上会造成下个版本的delay

所以在需求排期中，临近的Sprint要注意功能上的间隔有的功能干脆就在需求排期中强制拆开，留足稳定的buffer另外，有时候版本发不出去就不要发，不要为了敏捷而发版，那样就本末倒置啦！我们团队还有一个约定俗成的事，如果大家齐力克服困难将一个眼看需要delay的版本弄上线了，上线后必须tb大吃一顿作为奖励刺激，23333~

我们项目经过大半年的敏捷开发，无论是团队气氛还是产品数据都取得了比较好的结果 与其说敏捷开发是一种项目管理的方法，不如说是一种切换大家工作角色的方式让大家抛开原来的螺丝钉角色，全方位的参与到整个项目的流程中，强化主人翁意识 让团队的每个人切实地认识到自己就是这个产品的主人，主动为产品考虑，主动协助上下游更好地完成目标

PMP敏捷管理CMMI分部是什么区别CMMI主要是针对1个公司的软件开发能力来评审，级别分为5个级别PMP是项目管理专家，是个人在项目管理（不限于软件）的1个能力水平考核简单说，CMMI对公司或组织，只是软件开发能力方面PMP对个人，不限于软件，是项目管理专家证书CMMI全称是Capability Maturity Model Integration，即软件能力成熟度模型集成（也有称为：软件能力成熟度集成模型），是美国国防部的1个假想，是由美国国防部（United States Department of Defense）与卡内基-梅隆大学（Carnegie-Mellon University）下的软件工程研究中心（Software Engineering Institute，SEISM）和美国国防工业协会（National Defense Industrial Association）共同开发和研制的，他们计划把现在所有现存实行的与行将被发展出来的各种能力成熟度模型，集成到1个框架中去