写点什么

迈向敏捷 CMMI Level 3:需求开发和验证

2014 年 8 月 29 日

本文解释了如何在敏捷环境中做需求开发,本文涵盖了相关的概念,并举例说明了敏捷团队应该如何针对标准 CMMI 过程改进评估方法(SCAMPI)去执行 CMMI 开发模型,以达到需求开发和验证域的第三级。

第一部分描述并分析由敏捷实践覆盖的 CMMI 开发模型的过程域。

第二部分列举了一些敏捷 CMMI 实践案例,它们采用了一些公认的最佳实践。这些例子来自于实际的应用,能够与敏捷一起用于 CMMI 过程域。

1.1 敏捷 CMMI 介绍

1.1.1. CMMI 简介

CMMI 在 Wikipedia 上的定义是:“一种过程改进培训和评估程序和服务……它能被用来指导跨项目、部门或者整个组织的过程改进。”

CMMI 模型是用过程域来分类的。每个过程域覆盖一组通过执行某些实践可以达成的目标。CMMI 开发模型的目标不是评价这些实践怎么是最优的。它希望团队能够进一步演变这些实践,从 CMMI 开发模型的视角来看,有一个不怎么完美的实践总比什么都没有要好一些。

CMMI 开发模型过程域有配置管理、验证和确认等。每个域都有一个简称,比如众所周知的配置管理是 CM,验证是 VER 等等。

图 1:CMMI 开发模型分类。CMMI 可以看成是过程域的集合体,过程域由目标组成,这些目标可以分为通用目标(所有过程域通用)和特殊目标(单个过程域专属的)。每个通用或特殊目标都与实践有关,它们分别是为通用实践(GP)和特殊实践(SP)。

这里有两类目标。以下列表是通用目标和相关的通用实践:

  • GG 1 达成特殊目标
    • GP 1.1 执行特殊实践
  • GG 2 管理流程制度化
    • GP 2.1 建立组织方针
    • GP 2.2 设计过程
    • GP 2.3 提供资源
    • GP 2.4 分配职责
    • GP 2.5 培训
    • GP 2.6 控制工作产品
    • GP 2.7 识别干系人并争取相关干系人的参与
    • GP 2.8 监控过程
    • GP 2.9 客观地测评过程的符合程度
    • GP 2.10 和高层管理一起审查活动的进行状态
  • GG 3 制度化已定义的过程
    • GP 3.1 建立一个已定义的过程
    • GP 3.2 收集过程相关经历

通常,通用目标和实践是由组织提供并授权的。个体团队可以更加自主地决定他们想要如何去达成特殊目标。我们在本文中将重点关注需求开发的特殊目标的达成,我们将说明如何用敏捷实践来达成。

当使用 CMMI 开发模型时要考虑工作产品的定义。简而言之,工作产品就是实践的结果。任务的执行如果不能产生任何价值那就是在浪费时间(也是在浪费金钱),所以所有实践应该至少有一个工作产品。

为什么 CMMI 开发模型经常被视为是官僚的呢?其中一个最主要的原因是,它以笨重的过程产生了大量以文档为主的工作产品。所有这些文档非常难以维护。我们在 ALM@团队的经历告诉我们说,一定要按照实际需要开发和发布文档。我们还学会了一种尽可能自动化地生成所需文档的方法。这听起来很神奇吧,其实流行的 ALM 工具更关注团队的工程任务,而不是那些官僚的做法,因此工作都是围绕着 ALM foundation 开展的。

ALM foundation 是中央集中式的平台,它使整个组织单位(例如公司、部门或商业单位)共享流程中的工作产品和知识,自动化地执行那些冗长的流程,比如自动化测试、构建和发布(乃至最终的部署)。如果你想要进一步深入研究 ALM foundation 的概念,可以从 David Chappell 采用通用 ALM foundation 下载这本白皮书。

(点击图片可放大查看)

图2:将Microsoft Team Foundation 服务器中保存的工作项生成文档的示例。

在我们的ALM@团队里,ALM foundation 主要由Microsoft Team Foundation Server 提供支撑。在这个平台上,支持图表类的工件,这些是可以被保管和维护的元素。要发布文档时,团队成员可以利用类似于TeamSpec 或Team4Word 的第三方工具以简易的模版去下载选中的工件。

虽然文档也很有用,但对于每个工件来说就只有一种可能的格式了。

1.2 纠正错误的观念:CMMI 和敏捷并不对立

这一章的目标是向大家解释其实事实上 CMMI 和敏捷是兼容的。

因为我们都喜欢 90 年代初的一款称为街头霸王的游戏,我们就用它来形象地说明我们的观点吧。很多人是这样来对比敏捷和 CMMI 开发模型的:

图 3:右边的春丽代表敏捷过程——甜美、轻快、灵巧多变。本田代表我们通常对 CMMI 开发模型的认识:厚重、缓慢、一身的肥肉。(© CAPCOM 有限公司)

后来我们开始执行 CMMI,努力使其适用于我们的敏捷团队,我们从中认识到其实它们像是这样的:

图 4:真实的情况是,敏捷和 CMMI 看上去其实像两位类似的街头霸王,只是穿着不同的衣服,有着不同的头发。(© CAPCOM 有限公司)

CMMI 或敏捷:为什么不能同时满足!》是 Hillel Glazer 等人于 2008 年发表的一篇很棒的文章,该文章深入探讨了这个主题。我们在之前的文章中曾经讨论过一旦大型组织决定转向 CMMI 所需面对的挑战,那就是敏捷团队如何应用 CMMI 模型。我们发现本质上敏捷和 CMMI 之间并不矛盾。在施耐德电气的 ALM@团队中,我们甚至发现它们彼此间相得益彰毫无违和感。

1.3 良好实践清单

最近几年中,我们在施耐德电气的 ALM@团队进行团队训练,帮他们提升 CMMI 成熟度。在 InfoQ 的文章《在大型组织的敏捷团队中推广 CMMI 实践》中详细描述了我们的经验。将这篇文章概括总结来讲就是,我们学到的最重要的一课是实践必须去适应团队,而不是让团队去适应实践。

(点击图片可放大查看)

图 5:针对需求开发的良好实践清单示例

如果你的责任是和团队一起达成 CMMI 的特殊目标,你就应该分析团队成员是如何完成他们每天的任务的。团队在这里努力为公司创造价值,所以已经实行了很多良好实践。你可以把这些实践增加到组织的良好实践清单。团队实行具有良好实践清单的 CMMI 时,通常会遇到以下几种不同的情况:

  1. 他们发现团队早已采用了某些良好实践。
  2. 他们发现团队的某些实践有助于 CMMI 目标的达成,所以可以把团队经验充实到良好实践清单中。
  3. 团队可能缺少达成某个 CMMI 目标的实践。在这种情况下,团队成员将选择一个已有的实践,或者提出一个新的有助于达成该 CMMI 目标的实践。

2 需求开发和验证

让我们在本章一起探讨一下这个领域吧。

  • 需求开发(RD)的目的是得出、分析和确定客户、产品和产品组件的需求。
  • 验证(VER)的目的是确保工作产品能够满足需求。

有句话可以很好地概括验证(VER)与确认(VAL)之间的不同:验证证明的是正确地做了事,确认证明的是做了正确的事。RD、VER 和 VAL 是高耦合的(在某种程序上大多数 CMMI 过程域都是这样的)。我们会在后面的文章中介绍确认。

让我们把软件过程比作任何一种其他类型的工厂来进行探讨吧。一家香肠加工厂接收了很多的商品,比如肉类和调味料,以及硬纸板、塑料制品、化合物等等。这家工厂把这些商品加工成一盒盒的香肠,做好交付食品的准备。香肠加工厂就这样增加了肉类的价值。

在软件工厂中,本质上团队是在接收需求,指望对这些需求进行处理,交付最终产品,增加需求的价值。在需求开发中,我们努力地转化客户的输入,使其可以被团队用来开发软件,从而增加价值。

一些敏捷需求开发的良好实践是:

  • 按照 Scaled Agile Framework 的说法,敏捷资产组合管理或程序资产组合管理(PPM)像“最高水平的信托(投资和回报)和内容权威”那样是可以定义的。换句话说,以投资组合的视角,管理人员决策在哪些方面投资,创作高层次的工件,我们把它称为史诗故事(业务或架构史诗故事)。
  • 梳理待办事项是一项活动名称,在待办事项的废弃、恢复、分解时,以及待办事项条目的共性修改时会执行这项活动。随着时间的推移,某些待办事项条目可能失去了原有的商业价值,而新的待办事项会更加地重要。待办事项的条目可以由许多不同的方法来进行修改。我们可以把它们被分解成不同的待办事项条目,还可以修改它们,甚至一旦事件超时还可以取消它们。每个团队都要梳理自己的待办事项。其关键是要认识到待办事项是灵活可变的,团队不应该回避对它的修改。
  • 产品待办事项开发是团队接收高层次工件并把它们转化为用户故事、场景等等的过程。这种游戏规划是敏捷环境的基础部分,通过它产出一组工件,然后开发团队就可以围绕这些工件开展工作了。

VER 的主要目标是确保最终产品会按照团队的理解予以交付。大家普遍都认为,VER 是工厂化软件测试(比如单元测试、集成测试等等)。虽然软件测试是软件验证过程的强点,但应该注意的是,这种验证方式并不适用于所有的产品工件。例如,我们评审一个已经完成的文档时(在大多数组织中这就算是彻底完成了),我们采用的验证方式非常类似于代码的同行评审。因此,当源自于某投资组合元素的产品待办项目(比如一个用户故事)完成时,这个产品待办项目也应该得到验证。

3 敏捷 CMMI 实践实例

3.1 良好实践:投资组合管理

就像你正在更加详细地描述功能一样,也可以把投资组合管理条目拆分成数个投资组合的层次。我们会发现拆解的层次取决于多种因素,比如解决方案的复杂度、团队规模和能力。关于如何管理敏捷投资组合,MSDN 有一篇很不错的文章,名字叫做《敏捷投资组合管理:使用TFS 支持跨多个团队的待办事项》。虽然文章特定于Team Foundation Server 的技术,但你仍然可以把它的结论和实践引申到其他的ALM 平台,比如SourceForge 或者CollabNet。

投资组合管理包括两个投资组合的层次:举措和特性

(点击图片可放大查看)

图6:按商业价值把举措进行分解归类

举措和特性通常用客户业务语言来描述。一个不成文的规定是,在待办事项中你用更加地深入、细致的表达方式。举措是概括的、总结的,比方说就像大家所熟知的电梯演讲一样。它概括地描述了解决方案应该满足干系人的什么需求。当举措被发掘了一段时间时,就能用来作为解决方案路线图的主要来源了。

(点击图片可放大查看)

图7:待办事项之前的举措示例。

举措分解为特性,它是以客户业务术语来描述的。在小型团队中,特性可能是唯一的投资组合工件。大型团队将使用举措把一组特性包装起来,以便特定的团队去执行它们。

投资组合管理有助于定义主要的交付物,如果你在项目计划时采用CMMI 过程域(比如项目计划(PP)和项目监控(PMC))中的实践,那么就可以用到它了。

最重要的是要与最终客户对投资组合达成共识。理想情况下,投资组合的举措和特性应该来源于客户,由产品经理以流畅持续的方式审批。一种可行的方式是,做一张表格通过传统的邮件方式与客户达成共识。

(点击图片可放大查看)

图8:ALM 平台工件导出一张传统的Excel 数据表。

最好按需来交付文档,以防文档化对每日的任务造成过重的冲击,我们只需要那些能够为最终产品增加价值的文档。因此,团队应该乐意既简单又快速地创建文档,这不会对他们的工作造成太大的影响。大多数ALM 平台都支持将工件导进文档模版中。

使用这条良好实践,我们就能够考虑RD 部分的覆盖了。它也是下面要讲的实践的基础,这个实践叫做:待办事项开发。

3.2 良好实践:待办事项开发

投资组合管理虽好,但还不够充分。最近流行把它作为需求开发的终点,但这不是敏捷,而是应付。我们需要从投资组合中以更为敏捷的表达方式去开发待办事项。

我们能够从特性中导出用户故事。在 ALM@时,为了同时支持正规的(例如,RUP 或 PMP)和敏捷的过程(比如,Scrum 或看板),我们把它们称之为业务用例。(不要把它与营销的业务案例相混淆。它仅仅是业务故事和用例的融合物。)

(点击图片可放大查看)

图9:来源于特性的用户故事

用户故事通常用以下模式来编写:“我,作为< 角色> 想要< 触发动作>,所以< 增加了价值>”。你如果想要了解更多关于编写用户故事的详细内容,可以扩展阅读Ronica Roth 的文章《编写好的用户故事》。

(点击图片可放大查看)

图10:用户故事示例

CMMI 开发模型的一个目标是需求应该是已确认的。作为用户故事的扩展,我们的 TFS 模版包括一个检查表,这个检查表可以用来决定该用户故事是不是可以发给开发人员了。它包括通过同行评审来确认需求。通常,敏捷用户会在此时设置验收标准和定义完成标准,但在我们选定的良好实践清单中,在下列的良好实践中我们将它划分为不同的工件。

3.3 良好实践:需求梳理(待办事项条目完善)

需求梳理是在敏捷社区广泛应用的一项实践。我们要关注需求的验证。梳理确保待办事项的条目是一致的,不是重复的,不是废弃的。在非敏捷环境中通常用检查表来执行这项工作,但在敏捷环境中也没理由不用检查表来检查产品待办事项的条目,用它可以提醒我们好的用户故事应该是什么样的。既然在正规生命周期中也要检查相同的工件,为什么不和敏捷实践一起使用相同的检查表呢?

(点击图片可放大查看)

图11:验证检查表。

一个用户故事包括一名同行去执行需求评审。当用户故事状态有变化时,TFS 支持用户去自动化地指派。当一个用户故事分配给评审人员,并将状态改为待评审时,文章就会自动地指派给该评审人员。

如今,大多数流行的ALM 平台都支持这种自动化:

(点击图片可放大查看)

图12:用户故事的提供者和评审人员

这项验证实践是需求管理域(REQM)和项目计划域(PP)的一部分,在后续文章中我们会对它们进行更加详细地探讨。此时的重点是,需求是要被验证的,它是我们的良好实践梳理的一部分。

3.4 良好实践:场景定义和实现

许多敏捷团队在达到用户故事这一层时就不再开发他们的待办事项了,而是直接开始实现,这需要定义验收条件和完成标准。然而,还有一种早期测试的方法,叫做 BDD。BDD 是行为驱动开发。它是一项强大的技术,非常地适合于 CMMI 开发模型。详细地解释 BDD 超出了本文的范畴,但让我们简单了解一下它是如何用于定义组件和接口的吧。让我们看一下用 Gherkin(比如 Cucumber 或 SpecFlow)编写的示例场景。

复制代码
Feature: HoldingEnhancedVisibility
I, as ALMC User, want to filter Holding combos, so I could select only Holdings
I am allowed to see
@ScenarioTests
@EnhancedVisibilityTests
@XX4147CRBCShowHoldingInformation
Scenario: An administrator wants to display all available holdings
Given an admin user who will display holdings
And a Regular User so at least one holding were created
When admin displays Holding
Then all available holding in ALMC are returned
@ScenarioTests
@EnhancedVisibilityTests
@XX4147CRBCShowHoldingInformation
Scenario: A Holding Manager can display only his Holding
Given a Regular User to create a Holding Structure
And a 'HoldingManager' for this Regular User
When manager displays Holding
Then only one holding is displayed
And holding for user and holding for manager is the same

BDD 开发人员熟悉并能读懂特定的架构术语(SOA/DDD),能够和服务及实体一起识别出类似于“When”动作之类的组件。换句话说,这时没必要定义复杂的图表,它们太难以维护了。这也是一种定义 UI 动作的方式(比如,当参与者点击按钮时)。

在本例中,“Then”能够用来作为验收条件和完成的标准。

让我们再举一个其他的例子吧:

复制代码
@ScenarioTests
@EnhancedVisibilityTests
@XX3216CRBCShowDependencyTasks
Scenario: An administrator user displays combo to create a dependency among two tasks
Given a registered user with administration permissions
And a Task with description "AdminTaskDependency" which is unique
And a set of Tasks non associated
| Description |
| AdminNotDependency3216A |
| AdminNotDependency3216B |
And a set of Tasks already associated
| Description |
| AdminDependency3216C |
| AdminDependency3216D |
When combo is displayed for associating with pattern 'a' from previously created task
Then all non associated task will be displayed
| Description |
| AdminNotDependency3216A |
| AdminNotDependency3216B |
And Master Task wont be among them
And Task with taskid to be associated with wont be among them
{1}

BDD 易于被团队学习和采用,他们很欢迎这项技术。经过一些练习并具有适当的架构之后,是可以把参数(上例中粗体字)理解为接口参数的。BDD 是一种可以轻松定义组件、接口和参数的方式,换句话说,这也是一种定义产品需求的方式。

当需求已经插入到 ALM 平台,并历经了待办事项条目成熟完善,BDD 可以把测试和需求绑定在一起。

以下是待办事项的展现方式:

(点击图片可放大查看)

最终,像Jenkins 或Team Foundation Server 之类的持续集成平台就可以随着每一次源码的上传而去执行那些测试了。这应该需要定义一个控制配置环境。

3.5 良好实践总结

这四种良好实践在敏捷环境中相当普遍,通过执行这些实践只需要很少的工作量就可以覆盖一个过程域中的大多数特殊实践。

按照之前介绍过的良好实践去做,会达成以下域及其目标:

  • 绿色 -> 完全实现
  • 黄色 -> 部分实现(这种情况是因为我们未随着 CM 和 PI 一起执行代码同行评审)
  • 黑色 -> 未实现,因为它应该由 CM 和 PI 来覆盖

需求开发特殊实践目标

  • SG 1 开发客户需求

    • SP 1.1 引导需求
      • 投资组合管理
    • SP 1.2 把相关干系人的需要转化为客户需求、待办事项开发、场景定义和实现
  • SG 2 开发产品需求

    • SP 2.1 确定产品和产品组件需求
      • 待办事项开发
      • 场景定义和实现
    • SP 2.2 指定产品组件需求
      • 场景定义和实现
    • SP 2.3 识别接口需求
      • 场景定义和实现
  • SG 3 分析和验证需求

    • SP 3.1 确定运营理念和场景
      • 场景定义和实现
    • SP 3.2 确定功能性需求和质量属性
      • 场景定义和实现
    • SP 3.3 分析需求待办事项开发
      • 场景定义和实现
    • SP 3.4 分析需求以取得平衡
      • 待办事项开发
    • SP 3.5 确认需求
      • 需求成熟度评审
  • 验证特殊实践目标

  • SG 1 为验证做准备

    • SP 1.1 选择用来验证的工作产品
    • SP 1.2 建立验证环境
      • 不采用本组良好实践
    • SP 1.3 建立验证程序和准则
      • 不采用本组良好实践
  • SG 2 执行同行评审

    • SP 2.1 为同行评审做准备
      • 通过待办事项条目成熟完善检查待审需求
    • SP 2.2 实施同行评审
      • 通过待办事项条目成熟完善检查待审需求
    • SP 2.3 分析同行评审数据
      • 通过待办事项条目成熟完善开展需求评审
  • SG 3 验证选定的工作产品

    • SP 3.1 执行验证

      • 待办事项条目成熟度
      • 场景定义和实现
    • SP 3.2 分析验证结果

      • 在本组良好实践中未实现

关于作者

Nicolás Afonso Alonso现在是施耐德电气的软件开发技术领导人。他作为航天工业集成项目的质量保证团队领导人有多年的工作经验。加入施耐德电气之后,他主要关注适用于软件开发主导的 Team Foundation Server 活动和 ALM foundation 计划的过程工程学。

Victor Jara是施耐德电气的运维架构工程师。他的一部分职责是根据技术需求去实现特定的解决方案以完成配置管理与产品生命周期。

查看英文原文: Towards Agile CMMI Level 3: Requirement Development and Verification

2014 年 8 月 29 日 03:211717

评论

发布
暂无评论
  • 《What Drives Quality》作者访谈录

    不论软件产品应用的领域是什么,不论我们用怎样的方式构建它,质量都是所有软件产品最为关键的方面。Ben Linders发布了一本新书,名为《What Drives Quality》,他在书中提供了具体的例子和可执行的建议,帮助我们甄别和提高软件产品的质量。

  • 将敏捷与针对重复结果的过程改进相结合

    在2013年SEPG欧洲大会前夕,InfoQ采访了CMMI研究所的产品经理Eileen Forrester及UNICOM商业总监Alec McCutcheon。Eileen重点介绍了将CMMI与其他方法结合的“配置文件”这项产品策略;Alec则解释了为何CMMI研究所与UNICOM联合组织本次会议,以及会议的大体内容。

  • “一问一答”第 1 期 | 30 个软件开发常见问题解决策略

    软件开发中的很多问题,都是可以通过软件工程的知识来解决的。

    2019 年 3 月 16 日

  • 利用两个完工定义改进流程

    敏捷团队可以使用分开定义的完工定义的理想版本和当前版本。这样做的目的是扩展完工定义,进而提高成熟度和能力。这既可以在实物板上实现,也可以在其它电子的敏捷工具上实现,如JIRA。

  • 团队试点(一):让你的敏捷实践“事半功倍”

    所谓“凡事预则立,不预则废”,在推进团队敏捷试点之前,你要挑选好试点团队,并做好试点工作前的充分准备。

    2020 年 1 月 6 日

  • 微软发布安全开发周期流程能否拥抱敏捷?

    近日,微软发布了《安全开发周期(SDL)流程指南4.1a》,以指导开发团队将安全需求无缝地引入到软件开发过程之中。SDL是微软内部全公司软件项目强制使用的安全流程,并在众多旗舰级产品得到应用。鉴于敏捷方法在社区和微软内部的广泛应用,此次发布的指南专门列出了一章讲解如何将SDL与敏捷方法集成。由于SDL一贯应用在微软内部的传统瀑布式开发方法之上,所以此次发布引发了社区的激烈讨论。微软此次发布的安全开发周期流程指南能否成功拥抱敏捷呢?

  • 用户故事——需求的占位符

    传统“瀑布开发”的需求分析与敏捷的需求分析有什么不同?整个敏捷团队在需求分析的过程中起到什么作用?用户故事在研发过程中扮演什么角色?本文将同您一起探讨如何在敏捷过程中围绕需求开展工作。

  • 增强 UML 符号的提案

    Raul Rugioro对UML符号提出了一些改进建议,在这里,需求与测试案例,尤其是验收测试是密切相关的。敏捷方法本身基于测试驱动方法,尤其强调这点。可以增强UML用例的符号以使增强后的UML工具可以正确地处理用例与测试之间连接。

  • 使用 Water-Scrum-Fall 交付软件

    Water-Scrum-fall通常被描述成一种混合的敏捷工作方法。根据 Andy Hiles所说,Water-Scrum-fall是一种封闭的、阶段性的软件交付方法,其中 Scrum是最主要的开发管理方法。它可以作为通向敏捷、成为活生生的敏捷组织的跳板。

  • 在大型开发组织的敏捷团队中实施 CMMI

    敏捷开发方法更加适合现代软件开发,逐渐发展成为软件开发的主流方法,正在改变着软件开发过程。CMMI是一个跨组织的方法,CMMI的严格执行可以改进软件质量和控制软件开发成本。通过使用共同的元语言和良好的实践,在大型开发组织的自组织敏捷团队中也可以实施CMMI,达到某一成熟度级别。

  • 甘特更新企业敏捷规划工具的魔力象限

    2017年,甘特从研究“企业敏捷规划工具”转向了“应用程序开发生命周期管理”。分析师表示,通过利用以客户为中心和以业务成果为驱动并带有持续反馈的实践,企业敏捷规划(EAP)工具可以帮助企业大规模地实施敏捷实践,他们认为这代表了以项目为中心的敏捷工具和传统应用程序开发生命周期管理(ADLM)的一种演化。

  • 适合敏捷开发的合同模式:目标价格,风险均摊

    敏捷给产品开发带来的价值已经日益被软件开发业界所认可,从几个人的创业公司到几十万人的跨国企业,越来越多的产品团队采用敏捷的方式收集分析需求、开发产品、乃至部署运维。然而,传统的软件合同与敏捷开发方式相互冲突,往往会导致产品失败或大大降低敏捷给产品开发带来的价值。在11月7日召开的Agile Singapore大会上,来自挪威PROMIS公司的Trond Åsheim展示了一种适合敏捷开发的合同模式。

  • 微软模式与实践团队发布 Repository Factory

    Repository Factory是微软模式与实践团队(Microsoft Patterns & Practices Team)最新发布的全新指南开发包。它替代了之前被Web Service Software Factory(WSSF)集成的Data Access Guidance Package指南开发包。

  • “一问一答”第 5 期(内含彩蛋) | 22 个软件开发常见问题解决策略

    “经典案例解析”主题下的内容就是帮助你结合日常生活中一些常见的现象,去站在软件工程的角度思考和分析。

    2019 年 6 月 18 日

  • 实现非软件 IT 项目的敏捷交付

    大多数组织都避免在不涉及软件交付的IT项目(比如,路线图计划和架构开发)中使用敏捷。这些项目提供了很高的价值,但常常也是所有项目中风险最高的,而高风险需要敏捷交付。本文将回归敏捷哲学的基本知识,探讨如何成功地采用敏捷交付这些项目。

  • 论软件生命周期集成

    对于许多组织而言,是否有综合性的软件交付实践会决定了项目的成败。这时,就应该将精益思想(Lean thinking)应用到软件交付的实践中,并创建和维护从构想到实现的软件流,消除断点,实现实时协作。此时还要创建一个端到端的软件交付实践的规范。该规范必须为连接软件交付实践提供必要的材料,为软件交付实践专业人员提供创建集成体系结构和测量方法,以使软件交付更迅速,并消除实践过程中不必要的麻烦。

  • 第 50 讲 | 你的研发流程符合你的组织架构吗?谈高效研发流程那些事(二)

    当一家公司内可能存在多种组织架构时,是否也意味着应该存在多种开发流程呢?我的答案是”肯定的”。

    2018 年 7 月 10 日

  • 用什么工具,能加强 OKR 落地效果?

    当 OKR 初见成效时,再使用“OKR 周报”并结合“OKR 看板”的一系列游戏化玩法。

    2019 年 9 月 6 日

  • “一问一答”第 2 期 | 30 个软件开发常见问题解决策略

    项目管理贯穿项目始终,需求是项目的源头。

    2019 年 4 月 13 日

  • 如何用敏捷消除项目风险?

    需求定义不规范是开发中最大的浪费之一。本文描述了一种非常简单的技术,可以用于所有的用户故事,以便提高质量减少浪费。本文还探讨了如何通过未充分利用的“就绪定义”将它匹配到现有的计划和工作流评估中。那是一个你可以马上应用的、可操作性很强的概念。

发现更多内容

极客时间架构师培训 1 期 - 第 8 周作业

Kaven

Architecture Phase1 Week8:HomeWork

phylony-lu

极客大学架构师训练营

一个典型的大型互联网应用系统使用了哪些技术方案和手段,主要解决什么问题?请列举描述

幸福小子

互联网系统架构

“区块链+营销”:科技力量助力行业前行

CECBC区块链专委会

市场营销

苏州崛起为我国区块链产业高地

CECBC区块链专委会

区块链 社区矫正

年轻人的第一个MyBatis项目就要这样来学习,不走弯路

小Q

Java 学习 架构 面试 mybatis

ebay支付核心账务系统架构演进之路

贾奇 (Jacky)

支付系统 共识机制 系统稳定高可用 Event Sourcing 异地多活容灾

极客时间架构师训练营 1 期 - 第 8 周总结

Kaven

架构师训练营第 1 期第 8 周作业

好吃不贵

极客大学架构师训练营

架构师训练营第 4 周学习总结

菜青虫

极客大学架构师训练营

架构师训练营第 4 周课后练习

菜青虫

极客大学架构师训练营

架构师训练营 W04 作业

Geek_f06ede

极客大学架构师训练营

架构师训练营第 1 期 -- 第八周学习总结

发酵的死神

极客大学架构师训练营

推荐好书:《使用Python进行图像处理和采集》第二版(附下载方式)

计算机与AI

Python 图像处理

「八大排序算法」16张图带你彻底搞懂基数排序

bigsai

排序算法 基数排序

网络时间协议介绍以及服务器同步网络时间

MySQL从删库到跑路

ntp 时间同步

分分钟玩转SpringBoot自定义注解

比伯

Java 大数据 编程 架构 编程语言

区块链治理的真实价值在哪里

CECBC区块链专委会

区块链 治理 治理机制

腾讯强推Redis大神之路成长手册!原理+应用+集群+拓展+源码五篇齐飞

Java架构追梦

Java 数据库 redis 架构 面试

架构作业--相交链表

Nick~毓

Java8引入新的日期和时间库,你应该知道

Silently9527

java8

产品发布 | 准备好提升你的 ITSM 了吗?

Atlassian速递

DevOps Atlassian ITSM ITIL

架构师入门学习感悟四

莫问

架构师训练营第 1 期 -- 第八周作业

发酵的死神

极客大学架构师训练营

四、应用系统探讨

Geek_28b526

LeetCode题解:169. 多数元素,哈希表,JavaScript,详细注释

Lee Chen

算法 LeetCode 前端进阶训练营

架构师训练营 week4 学习总结

花果山

极客大学架构师训练营

架构师训练营 week4 课后作业

花果山

极客大学架构师训练营

脱钩!打工人不配拥有Java程序员306道面试秘笈吗?真香

996小迁

Java 学习 架构 面试 笔记

架构师训练营 - 第 8 周课后作业(1 期)

阿甘

Architecture Phase1 Week8:Summarize

phylony-lu

极客大学架构师训练营

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

迈向敏捷CMMI Level 3:需求开发和验证-InfoQ