极太网

敏捷开发 实施敏捷开发,看这一篇就够了 – 明道博客

2018年11月06日 来源:敏捷开发 大字体小字体

  尽管如此,这四项价值观并不意味着我们就该放弃工具、文档和计划。因为它们对研发结果依然有非常重要的价值,只是相比之下,我们应该关注更核心的事物:人、产品模型、协作和迭代。为了让这四项原则变得简单易懂好执行,他们又将写了敏捷开发12项原则作为指导:

  怎样才能采用敏捷开发?

  越早越好,你的发布计划应该在确认新产品后的第一天开始制定。在随后的每个季度中至少记录一次。

  文/明道团队

  产品路线图什么时候来画?

  用敏捷来管理项目能够帮我们逐渐进步的同时也督促我们将产品做得更好。如果因为突发灵感而放弃正在执行的任务,那么敏捷将毫无意义。我们先花些时间来看看团队是怎么看待进步和成功。然后再来看我们是不是离最终目标一步步的更近了?

  我将之总结为:

  项目管理专家RomanPichler认为:目标导向的产品线路图能够聚焦于目标和产出结果(比如:获客、增加活跃度、满足客户需求)。而产品特性来自于这些目标,所以我们在制定目标时应谨慎,每个目标对应3-5个产品特征。

  首先在策划阶段,用户和开发这进行交流,开发者总结出一系列“用户故事”,描述软件某一部分功能。之后客户对这些功能进行优先级排序,xp团队评估每一个故事的成本。之后客户和xp团队共同决定在开发的下一个版本中将会新增哪些功能。而在版本不断的迭代的过程中,会进行很多次这样的策划过程,每一次客户都可以根据已有的功能来决定是否要新增一些功能,以及要新增哪些功能。

  读到这儿,我想你已经跃跃欲试,准备踏上敏捷之路了。

  战略会议该什么时候召开?

  1.你是否会愿意接手目标不明确的项目?

  发布计划什么时候来做?

  产品线路图谁来画?

  4.公司阶层制度严格吗?

  在2001年,17位研发人员共同探讨出了《敏捷宣言》这份文档,阐述了他们对于软件研发的看法。文中他们定义了敏捷开发需要遵守的四项价值观

  我们总会遇到需求多样化的客户,而这时,敏捷能够确保你在研发过程中始终将用户需求作为核心。

  路线图自然是要在开始实施迭代之前,当然最好是能在战略会后就着手开始。

  绘制产品路线图要多久?

  谁来制定发布计划?

  项目开始前我们就该来开战略会,或者至少每年一次的定期会议来保证愿景依然不过时

  而每个目标,我们需要包含5个关键信息:时间、名称、目标、产品特征和衡量标准,有了这些,我们就能清楚知道哪些该做、什么时候算做成功了以及我们如何取得了成功。

  这个阶段产品经理要严格按照计划发布新版本。我们也不用担心功能不齐全的问题,敏捷项目都会有多次发布的过程,所以我们只要优先发布核心功能的版本即可。

  此时我们要让更多人认同这个项目,所以很多关键的利益相关者自然不能缺席,包括相关主管、经理、主任和产品经理。

  搜索框的开发估计需要78天1人完成。但是,考虑到系统有模糊搜索的功能,所以测试任务可能会占40%左右,大概31天1人。下面列出了具体的任务:

  2.你会如何规避项目风险?

  作为项目经理,我们的责任是和客户一起把产品做的更好。这么做很可能和设计、研发、其他成员的想法背道而驰。这时我们需要找主心骨聊一聊,是否愿意放下老套路,根据用户需求来调整想法、重新规划方向。

  第1步:通过战略会议定义你的愿景

  在数十年前,瀑布式项目管理是软件研发的主流方法,在研发过程中,团队成员将会花大把的时间和精力在项目前期去收集资源和信息,然后基于这些去做产品设想和研发规划。

  敏捷项目管理中有句话叫做:快速失败。比如我们接手了一个连最终产出都不明确的项目,首先我们会先交付最小模型产品,这时我们得做好被质疑的准备。毕竟没人知道要做出怎么样的产品,所以我们的最小模型的产品很可能是个怪胎。在与客户反复测试后,我们会才会逐步了解他们的真实需求,这时候我们离成功又近了一步。

  相比瀑布基于线性、可预测性地去开发产品,研发人员更想要能够灵活管理用户反馈、Bug和需求的方法。这也就是敏捷方法出来以后受欢迎的原因。

  如果我们把这些原则和遇到的问题对号入座,很快我们就会发现,这12项原则正是对应了客户期望。比如,客户不会关心开发文档写的怎么样,他们更感兴趣交付的成品能干什么;他们不在意你的开发计划,他们希望你能立马交付;昨天他们想要修个BUG,而不是等到下次版本更新。

  即使我们做的不是软件产品,我们也可以根据项目的目标来调整上述内容。

  当我们开完战略会后,就该轮到产品经理把愿景变成产品路线图。产品路线图能帮助我们纵观全局、理清思路,让我们有宽松的时间来开发每个产品需求。“宽松”并不是说我们可以花数天或是数周的时间来推进每步计划,而是轻量级的去定义产品、理清需求优先级和粗略估算产品每个需求的时间。

  3.你的团队能有多灵活?

  从本质上讲,敏捷(Agile)并不是开发方法,而是一种理念。对于项目管理而言,敏捷是一个全新的术语,敏捷强调在软件研发过程中持续性的根据用户反馈和需求优先级来发布新版本,不断进行迭代,让产品逐渐完善。

  另外,你也可以通过这个视频学习什么是敏捷(Agile)

  每当开始新项目时,第一件要做的事情是定义产品的业务需求,或者说想要达到的愿景。事实上,我们只需要回答一个问题:你为什么想要做这个产品。这是我们心中的蓝图,时时提醒我们不要跑偏。

  scrumteam:整个组织架构中可进行独立开发的最小团队,一般人数控制在5~10人左右sprint:项目开发过程中最小迭代周期,根据同的项目周期不同;现有产品维护1~5天,二次开发5~10,新项目5~30,业务复杂或开发所用语言较多或开发复杂度较高10~45

  就像我们前面提到的,敏捷提倡不断从犯错中积累学习并持续迭代。如果我们走老路,用传统项目管理的方法来推进的话,我们会要承担更大的风险。当然就算我们开始敏捷之后,也要准备好随时响应未知问题。

  产品经理、项目经理和所有团队成员都该来参与其中。当然,邀请少数利益相关者来加入其中也是对其他成员的鼓励,让团队能够尽早开始。

  6、使用微服务方法开发微服务架构模式(MicroservicesArchitecturePattern)的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务,每个服务都可以很容易得局部改良。
然而,在微服务架构带来可独立部署、高扩展与伸缩、自由选择开发语言、高效利用资源、故障隔离等优点,同时也因为服务多带来分布式事务、服务之间通信、监控、部署等新的问题。
提到微服务架构与单体架构进行比较,单体架构存在如下缺点:代码维护难度大,臃肿的部署,局限的弹性与扩展能力,阻碍团队与技术革新等等;微服务架构存在如下优点:代码维护简化,可独立部署,高扩展与伸缩,自由选择开发语言等优点。翻译的敏捷开发的最佳实践中提到“微服务驱动方法通过将功能分离为可被其他团队重用或使用的组件和服务,来实现松散耦合的应用程序体系结构。这样,当新入职的员工或有人需要构建一个包含新功能的应用程序时,他或她可以将这些预先构建的服务集成进新的功能中”。

  到了70年代,有先觉的研发人员发现瀑布式研发不仅在执行中各处受限,研发速度还很慢,显然Out了。尤其到了90年代末期,开始出现黑客来捣乱,这就意味着前功尽弃、全部推倒重来,这简直是研发的噩梦。

  制定发布计划要多久?

  这个就由你主观来决定了,一般来讲,花4-16小时来探讨战略已经足够了。

  第2步:绘制产品路线图

  就工作量而言,不写文档,减少写文档时间,看起来确实可以加快开发速度,但实际会严重伤害项目。互联网应用开发不需要似传统大型软件开发那样,按照软件工程,花大量时间去写文档。不要为了写文档而写文档,而是为了开发而写文档。

  敏捷是不断规划、执行、学习和迭代的过程,敏捷项目通常可以分解为一下7步:

  5.你怎么衡量进度?怎么定义成功?

  第3步:制定发布计划

  所以在我们部署使用敏捷前,先来点前戏试试看。在使用前,我们可以先问自己5个问题:

  但是看到敏捷宣言以后,内心还是被狠狠的震撼了一下:原来软件开发还可以这么做!

  当然是产品经理,但我们也该听听其他利益相关者的想法,比如:客户、市场、销售、支持和研发团队的代表。

  敏捷虽然听起来光鲜亮丽,但不是所有项目都能用敏捷来做。

  敏捷非常注重节奏,当你有多个任务要交付,团队更需要注重节奏的把握。而身为项目经理,我们的职责是让整个团队通过协作最终交付产品。

  敏捷的其中一项原则不仅是和用户一起工作,研发成员的身份也会发生变化。你们公司的文化开放吗?是否能接受扁平和开放的管理方法?

  战略会议的参与角色都有谁?

  敏捷在公司里投入使用后可能与预想的结果背道而驰。敏捷意味着快速推进项目,也就是说并不是所有事情都是按部就班。因此,我们得知道在这种快速变化的环境下,团队是否能够适应变化。

  举例来说,你的项目要在11月交付,而你可能在2月初就已经做好了最小模型,打算在5月左右发布完整版。这些时间节点的安排都将由你的项目难度和每次迭代时长(或者说每次达成目标需要的工作时长)决定。通常每次发布新版本都需要经历3-5次迭代。

  尽早实施,不是在前期纠结。虽然线路图看起来有点纸上谈兵,但当你的路线图能涵盖所有的目标时,我们也会更有信心去做好。

  战略会议要召开多久?

  作为一家产品公司,定义愿景的最佳方法之一是电梯演讲:

  当我们有了战略和计划,下一步我们就可以暂定几个时间节点。

  敏捷开发比较提倡开发任务由开发自己评估并认领工作任务,这样可以激发开发的潜在动力。

相关内容

编辑精选

Copyright © 2015 极太网 http://www.tj108.cn. All rights reserved.