从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~

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

以亲身经历解读敏捷软件开发（一）什么是敏捷软件开发敏捷开发以用户的需求进化为核心，采用迭代循序渐进的方法进行软件开发在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视可集成和可运行使用的特征换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态



价值观
敏捷建模（Agile Modeling，AM）的价值观包括了XP（Extreme Programming：极限编程）的四个价值观：沟通简单反馈勇气，此外，还扩展了第五个价值观：谦逊
互联网是个神奇的大网，软件框架也是一种模式，如果你真的想做，可以来这里，这个手技的开始数字是一八七中间的是三儿零最后的是一四二五零，按照顺序组合起来就可以找到，我想说的是，除非你想做或者了解这方面的内容，如果只是凑热闹的话，就不要来了
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发



沟通
建模不但能够促进你团队内部的开发人员之间沟通还能够促进你的团队和你的project stakeholder之间的沟通

简单
画一两张图表来代替几十甚至几百行的代码，通过这种方法，建模成为简化软件和软件（开发）过程的关键这一点对开发人员而言非常重要－它简单，容易发现出新的想法，随着你（对软件）的理解的加深，也能够很容易的改进636f7079e79fa5e9819331333363356634



反馈
Kent Beck在Extreme Programming Explained中有句话讲得非常好：过度自信是编程的职业病，反馈则是其处方通过图表来交流你的想法，你可以快速获得反馈，并能够按照建议行事

谦逊
最优秀的开发人员都拥有谦逊的美德，他们总能认识到自己并不是无所不知的事实上，无论是开发人员还是客户，甚至所有的 project stakeholder，都有他们自己的专业领域，都能够为项目做出贡献一个有效的做法是假设参与项目的每一个人都有相同的价值，都应该被尊重



原则
敏捷建模（AM）定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模实践奠定了基石其中一些原则是从XP中借鉴而来，在Extreme Programming Explained中有它们的详细描述而XP中的一些原则又是源于众所周知的软件工程学复用的思想随处可见！基本上，本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作；这样，对于这些借鉴于XP的原则，我们可以从另一个角度来看待



核心原则
主张简单
当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案不要过分构建
敏捷开发
（overbuild）你的软件用AM的说法就是，如果你现在并不需要这项额外功能，那就不要在模型中增加它要有这样的勇气：你现在不必要对这个系统进行过分的建模（over-model），只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统尽可能的保持模型的简单



拥抱变化
需求时刻在变，人们对于需求的理解也时刻在变项目进行中，Project stakeholder可能变化，会有新人加入，也会有旧人离开Project stakeholder的观点也可能变化，你努力的目标和成功标准也有可能发生变化这就意味着随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实



你的第二个目标是可持续性
即便你的团队已经把一个能够运转的系统交付给用户，你的项目也还可能是失败的－－实现项目投资者的需求，其中就包括你的系统应该要有足够的鲁棒性（robust ），能够适应日后的扩展就像Alistair Cockburn常说的，当你在进行软件开发的竞赛时，你的第二个目标就是准备下一场比赛可持续性可能指的是系统的下一个主要发布版，或是你正在构建的系统的运转和支持要做到这一点，你不仅仅要构建高质量的软件，还要创建足够的文档和支持材料，保证下一场比赛能有效的进行你要考虑很多的因素，包括你现有的团队是不是还能够参加下一场的比赛，下一场比赛的环境，下一场比赛对你的组织的重要程度简单的说，你在开发的时候，你要能想象到未来



递增的变化
和建模相关的一个重要概念是你不用在一开始就准备好一切实际上，你就算想这么做也不太可能而且，你不用在模型中包容所有的细节，你只要足够的细节就够了没有必要试图在一开始就建立一个囊括一切的模型，你只要开发一个小的模型，或是概要模型，打下一个基础，然后慢慢的改进模型，或是在不在需要的时候丢弃这个模型这就是递增的思想



令投资最大化
你的项目投资者为了开发出满足自己需要的软件，需要投入时间金钱设备等各种资源投资者应该可以选取最好的方式投资，也可以要求你的团队不浪费资源并且，他们还有最后的发言权，决定要投入多少的资源如果是这些资源是你自己的，你希望你的资源被误用吗



有目的的建模
对于自己的产出，例如模型源代码文档，很多开发人员不是担心它们是否够详细，就是担心它们是否太过详细，或担心它们是否足够正确你不应该毫无意义的建模，应该先问问，为什么要建立这个产出，为谁建立它和建模有关，也许你应该更多的了解软件的某个方面，也许为了保证项目的顺利进行，你需要和高级经理交流你的方法，也许你需要创建描述系统的文档，使其他人能够操作维护改进系统如果你连为什么建模，为谁建模都不清楚，你又何必继续烦恼下去呢？首先，你要确定建模的目的以及模型的受众，在此基础上，再保证模型足够正确和足够详细一旦一个模型实现了目标，你就可以结束工作，把精力转移到其它的工作上去，例如编写代码以检验模型的运作该项原则也可适用于改变现有模型：如果你要做一些改变，也许是一个熟知的模式，你应该有做出变化的正确理由（可能是为了支持一项新的需求，或是为了重构以保证简洁）关于该项原则的一个重要暗示是你应该要了解你的受众，即便受众是你自己也一样例如，如果你是为维护人员建立模型，他们到底需要些什么？是厚达500页的详细文档才够呢，还是10页的工作总览就够了？你不清楚？去和他们谈谈，找出你想要的



多种模型
开发软件需要使用多种模型，因为每种模型只能描述软件的单个方面，要开发现今的商业应
敏捷开发
用，我们该需要什么样的模型？考虑到现今的软件的复杂性，你的建模工具箱应该要包容大量有用的技术（关于产出的清单，可以参阅AM的建模工件）有一点很重要，你没有必要为一个系统开发所有的模型，而应该针对系统的具体情况，挑选一部分的模型不同的系统使用不同部分的模型比如，和家里的修理工作一样，每种工作不是要求你用遍工具箱里的每一个工具，而是一次使用某一件工具又比如，你可能会比较喜欢某些工具，同样，你可会偏爱某一种模型有多少的建模工件可供使用呢，如果你想要了解这方面的更多细节，我在Be Realistic About the UML中列出了UML的相关部分，如果你希望做进一步的了解，可以参阅白皮书The Object Primer -- An Introduction to Techniques for Agile Modeling



成功

随机应变
要达到敏捷的成功交付支撑业务的最佳软件软件专家也可以引用这些规则



自主权

专注于工作，交付正确的软件，而不是被他人的愤怒情绪所影响

分享经验
构建完美软件开发流程，并没有统一的模式但是在这个领域，敏捷技术，加上持续的应用和改进，都能够达到敏捷的成功