敏捷

  敏捷是一种软件开发方法,其源于将大量工作分解为较小的部分的想法。这使产品经理,开发人员和所有利益相关者对工作有了更好的了解。  

  敏捷通常用于软件开发中帮助企业应对不可预测的一些因素,比如对需求无法短时间掌握等。在过去十多年内有很多实施敏捷的成功案例,其中有的公司已经显着提高了他们的IT开发团队开发效率和业绩。敏捷已经跨越多种行业,包括媒体和技术,大型企业,甚至政府被广泛采用。

  在现实中,虽然敏捷不是所有软件开发问题的灵丹妙药。真正的关键是要知道如何根据情况合适选择瀑布与敏捷(顶层设计 vs. 摸着石头过河 )等等不同开发方法,甚至可以混合。这其中真的需要大量的经验和技巧。在敏捷软件工程,项目管理更依托对项目经理的技能,沟通,促进和协调能力,而更少强调对规划和控制(摸着石头过河 > 顶层设计)。

  敏捷是从敏捷宣言派生的。在2001年一小群人(包括Martin Fowler、kent Beck等)聚在一起讨论他们的项目管理经验,他们认为传统的管理软件开发项目的方法频繁发生问题,由此提出了敏捷宣言,描述了四个重要点:

  1. 在开发过程中通过工具实现独立开发和相互协作。
  2. 程序软件要胜于复杂的文档(代码本身就是最好的文档)
  3. 与客户协作商量,而不是以谈判等含有对抗意味的交流。
  4. 响应变化高于执行计划(计划没有变化快)

  当遵循敏捷方法论时,较小的工作帮助团队会变得更加灵活,在此过程中,可以帮助他们更快地交付功能并更快地响应更改。

  这些想法已分解为采用这种方法的不同框架。常见的两种是ScrumKanban

Story故事

  故事通常是定义的最小的作品。 它通常在项目工具(JiraGithub Issues中以创建的新ticket的形式出现。

  在进行项目时,您可能会遇到人们表达故事的各种方式。例如,如果希望向使用您的网站的人提供在微博上分享博客帖子的功能,则您可能希望将故事写成:作为读者,我想分享我刚刚在微博上阅读的帖子。使用“作为[人],我想[行动]”这种模式有助于提供上下文,作为某人在访问其站点时可能处于的状态以及他们试图实现的目标。如果您要为已登录的访客开发与访客不同的功能,这将特别有用。

  尽管故事的标题是作品的重要代表,但您还需要提供其他细节。一个好方法是:验证[需求]。上述案例故事详细:

  • 单击共享按钮时,验证是否创建了新的推文
  • 验证推文是否包含指向当前博客文章的链接

  提供强大的需求集有助于开发故事的开发人员和审阅该故事的人员进行衡量,以确定故事是否真正完成。没有它,每个人都只能猜测。

  每个故事都由许多观点来代表。这些观点是表达开发团队期望一个故事付出多少努力的一种方式。意味着工作量和难度。团队可用斐波那契数列表示工作量难度,其中难点的数量可以是1、2、3、5、8等。如果某个功能工作量难度可能是1点,而另外一个则可能是3点。

Epics史诗

  故事的目标是定义比较小的作品,而史诗则是将这些作品组合在一起以代表功能的一种方式。也就是将故事定义为功能。

  如果您正在处理需要集成身份验证的应用程序,则可能需要创建一个新的史诗,简称为“身份验证”。

  在该史诗中,您可以找到类似的故事:

  • 作为来宾,我想用我的电子邮件地址登录该应用程序
  • 作为经过身份验证的用户,我想更改密码
  • 作为安全团队,我想防止垃圾邮件和滥用用户身份验证

  定义好史诗之后,您可以为团队提供一条调用功能完整的途径,同时还可以了解整个工作范围。当计划要完成的工作时,这一点很重要。

  在史诗中定义您的故事可以使您了解某件事情需要多少工作,但是这并不能帮助您确定要花多长时间,这就是冲刺Sprint的目的。

Sprint冲刺

  冲刺是一种计划工作的实际完成方式。虽然与史诗相似,因为它们是一种对工作块进行分组的方式,但sprint通常表示一段时间,在此期间将完成特定的工作块。

  定义冲刺的一种常见方法是两个星期的工作。在这两个星期中,您的团队将为单个冲刺设置特定的速度或平均可以完成的工作量。该速度由多个点积分表示,这些点积分是在该sprint上工作的每个开发人员的平均速度之和。积分将大致转化为每个开发人员的平均工作时间。对于有经验的开发人员来说1分可能是1个小时,而对于没有经验的开发人员来说,同样的1分可能意味着3个小时。

  一旦获得了团队中每个冲刺的平均点数,您就会知道可以期望计划完成多少个故事点。当您发布一组故事或也就是史诗时,此计划会不断进行,因此您可以预测功能何时完成。

 

文章与教程

什么是Scrum?

什么是Scrum积压?

什么是看板Kanban?

什么是Devops?

什么是企业架构?

敏捷的真相

敏捷开发其实意义不是很大,在复杂项目中

用户故事与史诗有什么区别?

敏捷项目中非功能需求是如何定义和管理的?

软件工程测试用词解释

原型基本概念

基于Web的在线建模工具

建模风暴(使用领域事件作为用户故事的建模案例)

持续交付的概念和工具介绍

TDD死了 测试永存

代码评审清单

15条软件开发的基本规律

Spring创始人Rod大叔:软件交付的未来是编码

敏捷运动发起人马丁·福勒认为当前敏捷运动是一场悲剧

软件架构师的类型

敏捷项目中的业务分析师角色

什么是金丝雀版本?

从敏捷死了到Devops死了

敏捷和devops之间有什么区别?

重构的三个层次

用户故事的生命周期是怎样?

一定要满足管理人员的一致性要求吗?

Babok®指南的敏捷扩展是什么?

什么是DevOps以及它与软件开发有什么关系?

瀑布和螺旋式开发哪个更好?

INVEST简写是什么意思?

讨论组应如何有效地进行?

如何将自己的开源项目发布到Maven中央仓库中?

自己搭建Maven服务器私服

需求产品团队如何有效地管理时间?

组建,激荡,规范和执行是什么意思?

Koter领导变革的八个步骤

产品从概念到实现的步骤

开发应用程序时应考虑哪些类型的测试?

什么是总体拥有成本(TCO)以及它的重要性?

是否应该创建用户故事来计划系统维护和支持?

尽早修复bug有什么好处?

商业计划书应该包含哪些信息?

什么是敏捷中用户故事点?

什么是SAFe?

正念冥想

#事件风暴 #精益创业 

更多话题:

#敏捷 #DevOps #业务分析

#重构 #项目管理 #BDD行为驱动开发

#需求分析 #软件观点