敏捷开发 架构

2019-03-05 10:56:25 weixin_39835036 阅读数 720

敏捷开发对软件架构设计产生了一定的影响,让人产生敏捷开发中“轻架构设计”的印象。文章就笔者经验,和大家一起讨论一下敏捷中的架构设计这个话题。

浅谈敏捷开发中的架构设计!(干货)

 

首先,笔者认为敏捷开发是一种软件过程方法和工具,敏捷开发本身并不能代表架构设计。这就好比建筑架构设计和建筑工程管理之间的差别一样,两者是建筑的两个方面。相同的软件行业也是类似的情况,软件架构设计描述的是事物本身,而敏捷开发描述的是创建这个事物的过程。所以敏捷开发和架构是没有直接替代关系的两个范畴。

但敏捷开发后,架构设计(内容和形式上)还是有了一定程度的变化。

1. 敏捷开发中架构设计的方式

这里的架构设计方式,指什么时候进行架构设计,并以什么样的方式进行架构设计,如Iteration中新需求引入时,重构的方式,Code is Design的方式等。

下图描述了敏捷开发前和后架构方式:

浅谈敏捷开发中的架构设计!(干货)

 

上图中,敏捷开发后软件架构设计的方式产生了变化:敏捷开发把原先软件过程前期的架构设计,分散到了整个敏捷开发软件过程中

看到敏捷开发中分散化的架构设计,想起公司财务中的"马克威茨资产组合理论",用马克威茨这个诺贝尔大师的理论来解释敏捷开发中的分散架构形式,却也行得通。

“马克威茨资产组合理论”中说道:可以通过分散投资使收益率不变而方差(风险)减少。通俗一点讲也就是不要把鸡蛋放在一个篮子里。资产组合分散化后,可以做到收益率不变的情况下,风险减少。

这里的风险指的是波动,也就是方差。这和软件工程中的风险有异曲同工之意,即软件工程中的风险指:需求的波动,数学化后就是需求的方差。然后可以按照统计定理推论出,把架构设计组合化,并分散化,有益于收益率不变的情况下,减少软件风险。(中间的推导过程省略,有兴趣的朋友参考相应文献)。

如果按照资产组合理论,下面这些就是软件架构设计中的组合,把一次性软件过程前期30%(甚至更多)的架构设计,换成如下的软件架构组合:

(1)引入新需求后的架构。每个Iteration中,新需求引入前,都可以进行构思和架构。

(2)重构产生架构。先让软件运行,再重构其代码。那么软件的架构随着重构自然而然的在软件过程中产生

(3)开发过程中的设计:以前是设计完后开发,现在是边设计边开发。

(4)其他

所以敏捷开发不是轻架构设计,而是依然注重架构设计。只不过架构的方式变化了,变得更加有效且风险更小。

2. 敏捷开发中架构设计的内容

传统的架构设计,包括架构和设计两个方面、其中设计可以包含详细设计,如详细的UML图(详细的类图,顺序图等),详细的API设计以及接口描述,存储层数据库表字段设计等等。

出于下面两个方面的考虑,敏捷开发不适合这种架构设计内容:

(1)在当今的快速变化的社会中,业务需求和技术也都快速变化着,在软件过程前期花费30%(甚至更多)的时间进行架构设计,要么开发出来的软件不符合市场需求,要么就是一旦需求变动,造成较大的改动成本。如,作者了解的一个电子商务产品,当前所做的功能都是两年前规划设计的,而且如有新需求发生,需要下个版本才会采纳,导致整个产品脱离市场和客户的需求。

(2)架构设计包含两个方面,一是:架构,二是:设计。其中设计中的详细设计需要大量的时间,包含详细的流程,API,数据结构等设计。但软件开发阶段的Code编码阶段,同样蕴含了很多详细设计的内容,所以二者之间存在着Repeat Yourself的情况。换句话说,现在敏捷开发提倡Code is design,而以前是Design is code。但问题是,软件开发人员维护一套Design,外加一套Code,不堪重负,效率低。所以,现在是Code is Design盛行,敏捷盛行。

基于这两种原因,敏捷中将传统的架构设计分成:架构 + 设计

(1)敏捷开发的架构保留架构部分

(2)转移设计到Code编码阶段、重构阶段、Unit Test阶段等。

分离后,敏捷开发中的架构就轻装上阵,内容可以包括:

(1)软件的架构层次,层次化是软件产品架构中很重要的一部分。

(2)产品和技术选型

(3)各个组件的结构,以及的关系

(4)重要模块,和重要类的说明。但无需设计全部的类,和类的方法。

而详细设计阶段,则在Code编码和UT单元测试阶段进行。这个阶段重构很重要,重构使你的软件架构和组件结构自然呈现

所以在敏捷开发中架构设计的内容发生了变化:敏捷开发中止于架构,轻详细设计。但详细设计不是消失不见了,而是转移到了开发阶段,也即是:Code is design。这样既能拥抱变化,又规避风险,又Don't Repeat Yourself。

3. 敏捷开发中架构设计的人员

敏捷开发后,软件过程变化了,架构形式变化了,随之相应的人员的责任和需要素质也会变化。

这里不说整个软件过程中的人员角色,以及职责和能力,如组长,经理,测试人员,开发人员等。这不是说这些的地方。可以另外的文章再继续。

这里强调的是,敏捷开发架构设计变化后,对开发人员提出了更高的要求,要超越Code is Code阶段,达到Code is Design的要求。如上面我们分析,敏捷开发中架构设计内容变化后,一部分的设计职责转移到了开发人员身上。所以开发人员不仅需要是技术专家,不仅能够写很好的程序,还需要有架构设计思想和能力,能够在开发过程中不断重构出Design。

浅谈敏捷开发中的架构设计!(干货)

 

总结

架构描述的是软件本身的结构,敏捷开发描述的是制造这个软件的过程,他们二者是软件科学的两条脉络,互相影响。不管敏捷与否,架构设计依然软件中最重要之一,是软件开发人员的进阶目标。

2013-05-16 09:08:33 wzm112 阅读数 2264

参考网站:http://yuan-bin01.iteye.com/blog/1756125

写这篇文章的背景是:一个项目组实施Scrum取得成效,如何在整个开发部门推广Scrum?看一下我们一个大产品,三个项目组共同完成的具体实践:

我们做了如下的组织调整:

1.     产品部增加一名总监(CPO),负责公司层面的产品思路,整合三个子产品

2.     各个Scrum小组的架构师和DBA成立虚拟架构师团队,架构师团队根据产品部的整体产品思路,提出并实现公司层面的技术架构(此时每一个项目组需要一个高级开发人员参加)。公司所有产品在这个架构平台上进行开发。这样的好处是:公司整体的开发成本、维护成本降低,质量提高。同时架构师和参加架构开发的高级开发人员在项目组内可以快速将架构平台应用在本项目组。在产品开发迭代开始之前,由“架构师团队”完成系统级的架构,然后架构师团队的成员回到自己的Scrum团队进行每日的工作。

3.     各个Scrum小组的QA成立虚拟QA团队,主要的目的是为了整合研发部QA的资源,推出更加高效的测试方法、测试工具

4.     三个项目组的SMScrum of Scrums的方式,每天(需要的时候随时)以会议的方式沟通1020分钟,主要是产品间的整合、项目组见资源的协调、遇到的Impediments如何解决等。

5.     各个Scrum小组的美工成立虚拟美工组组,负责公司所有产品的界面(页面)设计,最大的好处是页面风格统一,页面层的技术可以共享,同时有利于公司的产品宣传和产品形象。

6.     每个Scrum小组内部以Scrum的方式工作,Scrum of Scrums的沟通介质是Kanban

7.     成立部门级的支持团队,分为技术专家团队、公共组件团队、领域专家团队、独立测试团队,每个团队人数很少,但是可以使整个部门的工作有效率。例如,架构师团队的Leader就是组件团队和技术专家团队的PO,只不过他们的Product Backlog只有技术需求而已。

8.     技术专家的工作以Kanban管理,公共组件团队的工作以Scrum管理

 

以下是我们实际使用的组织架构图:

 

 


2013-08-18 12:01:19 baodinglaolang 阅读数 6280

原创作品,转载请注明出处http://blog.csdn.net/baodinglaolang/article/details/10042857

android 敏捷开发系列(二)——《敏捷开发架构图》


书接上回,首先奉上敏捷开发的架构图



首先为大家解释里面的几个概念


Frame 整个项目的框架、组织者。里面并没有实际的代码,只是通过配置文件决定了项目需要哪几个模块

Model 模块,项目的组成部分,通常表示单一或部分功能集合

Component 组件,包含Model的UI以及需求逻辑,在android敏捷开发中包含(Activity、Service、BroadCast Receiver、Provider

Lib lib库,为Component提供了具体的实现,封装了其需要的各种方法


从图中我们看到,

首先Frame包通过配置文件决定项目的模块,这样来满足我们上话提到的各种需求,

此处的Model是我强加来的,其实Frame只需要依赖Component即可以构成项目,因为从依赖链看往往Component会依赖一个特定Lib,但是从逻辑看Component + Lib才完整。所以建议大家把Component + Lib想象成一个Model。

然后每一个模块又通常被分为独立的组件和Lib,这样的好处很明显,通常变化的只有组件,而Lib一但完成只需要维护其稳定即可,当项目界面需要大变化的或需要我们向三方提供此模块功能的时候可以直接提供此Lib,也就是我们说的SDK

最后是我们项目积累封装好的各中jar包,例如图上提到的HTTP、FILE等工具类,可以直接被依赖进来,提高了复用率,我们还可以随时丰富其接口,供大家使用。


敏捷开发的的架构基本是这样,他充分体现了灵活、高效,怎么样,赶快阅读博主的第三篇《android 敏捷开发 环境搭建》,一起开始我们的敏捷开发之旅!

传送门

android 敏捷开发系列(一)——《啥是敏捷开发

android 敏捷开发系列(三)——《环境部署》
2017-02-16 17:29:00 xiaoxiaoyusheng2012 阅读数 331


转自:http://blog.csdn.net/uxyheaven/article/details/49618097

敏捷开发知识体系整体框架

敏捷开发工程实践

项目管理

  • 迭代开发
  • 风险价值生命周期
  • 多级项目规划
  • 完整团队
  • 每日站立会议
  • 任务板
  • 燃尽图

需求管理

  • 需求订单
  • 业务流程草图
  • 用例驱动开发
  • 用户故事

架构

  • 演进的架构
  • 演进的设计
  • 基于组件的架构设计

开发

  • 结对编程
  • 测试驱动开发
  • 重构
  • 代码规范

测试

  • 单元测试
  • 并行测试
  • 测试管理

变更管理

  • 持续集成
  • 自动构建
  • 团队变更管理

敏捷开发管理实践描述

  • 定义和特征说明
  • 主要角色
  • 主要活动和最佳实践
  • 主要输入输出
  • 工作流程

敏捷开发工程实践描述

  • 定义和特征说明
  • 应用说明
  • 案例说明

敏捷开发核心价值观和原则

敏捷软件开发宣言

个体和互动 高于 流程和文档
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说, 尽管右项有其价值, 我们更重视左项的价值.
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5

敏捷软件开发的核心价值观

敏捷开发的核心理念就是以最简单有效的方式快速打成目标, 并在这个过程中及时地响应外界的变化, 做出迅速的调整.

核心价值观

  • 以人为本
  • 目标导向
  • 客户为先
  • 拥抱变化

敏捷开发的原则

  • 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
  • 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
  • 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
  • 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  • 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  • 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
  • 可工作的软件是进度的首要度量标准。
  • 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
  • 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
  • 以简洁为本,它是极力减少不必要工作量的艺术。
  • 最好的架构、需求和设计出自自组织团队。
  • 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

敏捷开发管理实践

Scrum

Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。

Scrum中的角色

“猪”角色

  • 产品负责人(Product Owner) 
    • 通常由市场部门的人担任
  • 敏捷教练 (Scrum Master) 
    • 通常由开发组组长担任
  • 开发团队 (Scrum Team) 
    • 包括开发,需求,测试

“鸡”角色

  • 用户 
    • 软件是为了某些人而创建!就像“假如森林里有一棵树倒下了,但没有人听到,那么它算发出了声音吗”,“假如软件没有被使用,那么它算是被开发出来了么?”
  • 利益所有者 (客户,提供商) 
    • 影响项目成功的人, 但只直接参与冲刺评审过程。
  • 管理者 
    • 为产品开发团体架起环境的那个人

主要活动和最佳实践

  • 迭代式软件开发
  • 两层项目规划 (Two-Level Project Planning)
  • 整体团队协作 (Whole Team)
  • 持续集成
  • 冲刺规划会议 (Sprint Plan Meeting)
  • 每日站立会议 (Sprint Daily Meeting)
  • 冲刺复审会议 (Sprint Review Meeting)
  • 冲刺回顾会议 (Retrospective Meeting)

scrum方法中得主要活动和交付件

主要输入输出

  • 产品订单(Product Backlog)
  • 冲刺订单(Spring Backlog)
  • 燃尽图(Burndown Chart)
  • 新的功能增量

工作流程

scrum方法全景图

项目管理过程

  • 在Scrum项目管理过程中产品负责人获取项目投资, 并对整个产品的成功负责.
  • 产品负责人协调个中利益干系人, 确定产品订单中初始的需求清单及其优先级, 完成项目商业价值分析和项目整体规划, 并任命合适的敏捷教练开展项目工作.

项目开发过程

在Scrum软件开发过程中, 每个冲刺就是较短的迭代, 通常为2~4周.

  • 在每个冲刺开始时, 产品负责人和敏捷教练通过召开冲刺规划会议和”两层项目规划”的最佳实践, 制定冲刺订单(类似迭代计划)
  • 产品负责人明确在本次冲刺中实现的需求清单, 响应的工作任务和负责人.
  • 在每个冲刺迭代中, 团队强调应用”整体团队协作”的最佳实践, 通过保持可持续发展的工作节奏和每日站立会议, 实现团队的自组织, 自适应和自管理, 高效完成冲刺工作.
  • 在每个冲刺结束时, 团队都会召开冲刺复审会议, 团队成员会在会上分别展示他们开发出的软件(或其他有价值的产品), 并从产品负责人和其他利益关系人那里, 得到反馈信息.
  • 在冲刺复审会议之后, 团队会自觉招开冲刺回顾会议, 回顾整个项目过程, 讨论哪些方法做的好, 哪些方面可以改进, 实现软件交付过程的持续, 自发的改进.

XP

OpenUp

Lean

敏捷开发工程实践

迭代式开发

敏捷迭代开发是指每次按照相同的开发方式短期的开发软件的部分, 或前期开发并不详尽的软件, 每次开发结束获得可以运行的软件, 以供各方干系人观测, 获得反馈, 根据反馈适应性的进行后续开发, 经过发福多次开发, 逐步增加软件部分, 逐步补充完善软件, 最终开发得到最后的软件. 每次反复开开发叫一次迭代, 在Scrum中成为Sprint, 中文常译为”冲刺”.

持续集成

持续集成(Continuous integration)是指当代码提交后, 马上启动自动编译, 自动部署金额自动化测试来快速验证软件, 从而尽快的发现集成错误.

多级项目规划

多级项目/产品规划, 在软件开发领域, 是指以迭代开发为基础, 形成多层次的, 逐步细化的项目或产品计划. 这些层层相关的项目/产品规划包括:

  • 项目/产品愿景
  • 项目/产品路线图
  • 版本发布计划
  • 迭代计划
  • 每日实现

项目/产品愿景

在计划阶段, 首先, 项目stakeholder, 项目/产品负责人将参与并组成工作组, 他们负责阐述项目的重要性, 给出项目成功失败的关键标准以及项目整体层面”完成”的定义; 在过程中, 可以利用形成项目愿景的一些个工具, 包括愿景盒子(Vison Box), 业务收益矩阵(Business Benefits Matrix), 项目范围矩阵(Scope Matrix), 滑动器(Slider), 成本收益矩阵(Cost/Benefit Matrix)等; 最后, 项目愿景需要使用尽量简要的文档固定下来, 并保证项目团队成员都能了解.该文档需要包括:

  • 当前的问题
  • 机会描述和理由(描述项目的重要性)
  • 项目的价值
  • 项目如何和组织的战略目标达成一致
  • 解决方案综述
  • 项目包含的关键功能
  • 项目必须服从的技术和约束条件
  • 项目范围
  • 项目的关键时间线
  • 项目收益分析
  • 项目和其他项目的依赖性
  • 项目的相关风险以及如何消除

项目/产品路线图

主要描述为了达到产品愿景而需要交付的关键功能和特性, 这些特性基本处于Epic和特性层面, 不包裹用户故事(User Story). 它从时间的维度来表述对愿景的支持和实现. 它从时间维度来表达对愿景的支持和实现. 当项目/产品需要发布多个版本时, 项目线路图就非常重要, 否则, 它和发布计划相同, 项目/产品线路图由项目负责人和项目经理维护, 并保持更新. 通常, 会形成路线图问题或幻灯片, 使用大图标显示重要的里程碑, 包含的功能和发布日期等, 让所有项目/产品相关人员都清楚产品各个组件的可能发布日程.

版本发布计划

版本发布计划由团队成员和项目/产品负责人共同制定, 并通过版本发布计划会议讨论通过. 它包括了当前版本需要交付的, 达成一致的关键功能, 并经过优先级排序, 可以包含EPIC和User Story. 版本发布计划中常使用的概念包括:故事点, 迭代团队速率和优先级排序. 通常, 项目/产品负责人提出本次发布的目标, 团队成员根据目标和功能特性的重要性对故事进行排序, 并依据团队速率觉得本次发布需要包含的故事点. 前几次版本发布使用估算值, 其准确性随着项目/产品的时间持续而逐步精确. 版本发布计划是剧本适应性可调整的计划, 会随着项目演进而改变.

迭代计划

迭代计划是对版本发布计划的再次细化, 同样由团队成员和项目/产品负责人共同制定, 并听过迭代计划会议讨论通过. 迭代会议负责两件事情:

  • 根据当前状态确定是否需要对版本计划做出更新
  • 为当前的迭代计划制定迭代计划

迭代计划中常使用的概念包括: 拆分Epic和User Story, 任务, 任务估算. 在迭代会议上, 成员首先根据当前的项目变化对发布计划进行更新, 然后根据更新后的, 重新排序过的故事制定当前迭代需要完成的故事, 并对这些故事进行详细的任务拆分. 成员在认领完任务后, 会对任务的实现时间做出估算, 估算值需要具体到这些估算信息可以方便任何成员追踪任务的进度.

每日实现

没事实现是团队成员完成任务的具体过程, 它依据任务估算值并根据任务最终实现情况更新该值. 在敏捷方法中, 使用每日站会议来报告进度. 通过15分钟的站立形式, 团队成员报告故事或者任务的完成,未完成状态, 而解决层面的问题则在会议之后处理.

完整团队

Scrum团队必须具备的三个完整性:

团队职责完整性

产品负责人(Product Owner)

  • 确定产品的功能。
  • 决定发布的日期和发布内容。
  • 为产品的收益(profitability of the product)负责。
  • 根据市场价值确定功能优先级。
  • 在30天内调整功能和调整功能优先级。
  • 接受或拒绝接受开发团队的工作成果

敏捷教练 (Scrum Master)

  • 负责监督整个Scrum项目进程, 调整开发计划
  • 保证团队资源完全可被利用并且全部是高产出的。
  • 保证各个角色及职责的良好协作。
  • 解决团队开发中的障碍。
  • 做为团队和外部的接口,屏蔽外界对团队成员的干扰。
  • 保证开发过程按计划进行,组织 Daily Scrum, Sprint Review and Sprint Planning meetings。
  • 需要知道什么任务已经完成,哪些任务已经开始,哪些新的任务已发现,和哪些估计可能已经发生变化. 根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图
  • 需要找出阻碍Scrum的障碍和依赖, 根据优先级指定计划解决这些障碍
  • 个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清,或通过内部的沟通解决,或向管理层和HR寻求帮助解决
  • Scrum Master需要知道什么任务已经完成,哪些任务已经开始,哪些新的任务已发现,和哪些估计可能已经发生变化。Scrum Master需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的Burndown Chart。 Scrum Master还必须仔细考虑进展中的开放任务数,进展中的工作需要得到最小化,以实现精益生产率的收益。
  • Scrum Master需要找出阻碍Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决,有些则要团队之间的协调,还有的要管理层的介入来解决.

开发团队 (Scrum Team)

  • 具有不同特长的团队成员,人数控制在5-7个左右, 跨职能, 包括开发, 需求, 测试
  • 弱化分工, 每个人都参与设计, 开发与测试
  • 确定Sprint目标和具体说明的工作成果。
  • 在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
  • 向Product Owner演示产品功能。

团队素质完整性

  • 要具备很强的集体协作精神.
  • 要具备良好的沟通能力
  • 必须能积极主动的接受新的事物, 要具备创新能力
  • 要具备极强的自我管理能力和积极主动的精神

沟通的完整性

  • Sprint启动会
  • 每日站立会议
  • Sprint回顾会

案例

验收测试驱动开发ATDD

TDD 只是开发人员的职责,通过单元测试用例来驱动功能代码的实现。ATDD在准备实施一个功能或特性之前,首先团队需要定义出期望的质量标准和验收细则,以明确而且达成共识的验收测试计划(包含一系列测试场景)来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员,强调如何实现系统以及如何检验。

  • 挑选用户故事
  • 为故事写测试
  • 实现测试
  • 实现故事

结对编程

结对编程可以看做是一种敏捷化的Code Review

新结对编程

两位程序员新成结对小组, 每人一台电脑, 坐在临近的工位上, 两人合作完成一组功能(可以是两个或多个独立的模块)的设计, 代码实现. 但对已某一个模块来说设计和代码是分开的, 一个人负责设计, 另一个人负责写代码, 对于其他模块则反之.

确定冲刺计划

定义和说明

  • 目的: ST和PO共同决定在接下来的冲刺周期内的目标以及那些功能和任务需求要完成
  • 主要角色: ST, PO, SM
  • 主要输入: Product backlog, 团队的能力
  • 主要输出: Sprint Backlog

冲刺会议分两个部分 
1. 解决本次冲刺要完成哪些需求 
2. 解决这些选择的需求要如何被完成

案例

故事点估算

故事点是表述一个用户故事, 一项功能或一件工作的整体大小的一种度量单位. 数值本身不重要, 重要的是这些故事之间对比体现相对大小.

计划扑克

  • 开始时, 美人得到一张扑克, 上面有任务点(?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, 无穷).?代表无法估算, 无穷代表故事太大
  • 开始对故事进行估算, 先由PO介绍这个故事的描述. 接着澄清问题
  • 每一个组员从扑克中挑选可以代表这个故事的卡片, 集体亮牌
  • 最高分和最低分的组员像团队做出解释
  • 全组成员自由讨论几分钟
  • 重新打分, 直到全组统一.

敏捷估算2.0(Agile Estmating 2.0)

  • PO像团队成员介绍每一个用户故事, 确保所有需求相关的问题都在做估算前得到解决
  • 整个团队参与游戏: 一次由一人将一个故事卡片放在合适的位置, 规模小的在左,规模大的在右, 一样大的竖排. 轮流移动故事卡片, 直到整个团队都认同白板上故事卡的排序为止.
  • 团队将故事点(Story Point)分配给每个故事.

需求订单(Product Backlog)

记录用户需求的列表, 包括产品所有需要的特征.

  • 每一项包含了需求标题, 描述, 重要性, 故事点(或其他表示大小的数字)
  • 需求订单式开放的, 团队每个成员都可以编写和维护
  • 在整个项目开放生命周期内, 需求订单需要不断维护, 管理与跟踪需求变化

燃尽图

在项目完成之前, 对需要完成的工作的一种可视化表示. 燃烧故事点.每天更新一次

  • 具备可视性
  • 具备风险预估, 提醒团队目前完成情况
  • 具备可估量, 直接显示当前还需要的时间.

燃尽图常见问题

每日站立会议(Daily Scrum)

每日站立会议旨在让团队统一目标, 协调内部问题的解决, 绝非进度汇报.一般不超过15分钟.

  • 我们上次开会后你都干了什么
  • 在我们下次开会之前你要做什么
  • 每个你负责的、正在做的任务还剩下多少时间
  • 你的工作被阻碍了吗

任务板(Task board)

  • 为项目团队提供一个便利的工具用于管理他们的工作
  • 是团队成员对本冲刺的工作一目了然

任务板通常设立与项目团队日常工作的公共空间的一面墙上. 任务板上得信息包括该冲洗计划完成的用户故事和相应的任务, 分别卸载卡片上, 按照一定的方式贴在任务板上(To Do, In Progress, Done). 团队成员通过调整任务卡得位置和上面的信息反映任务的执行情况.

用户故事卡

每张卡片记录一条用户故事, 故事点.

任务卡

每个用户故事卡片通对应的多个任务卡. 每张卡片记录一条任务, 到目前为止完成该任务所需的工作量(小时).随着进展试试更新.

任务板的使用

用户故事

作为<某个角色>, 我希望<实现何种功能>, 以便<带来何种价值>.

如: 作为一个用户, 我希望在每次退出系统前得到是否保存的提示, 以便所有内容都被成功存储了.

测试驱动开发(TDD)

先开发测试用例, 然后再开发代码


2015-05-21 06:17:56 u011790275 阅读数 1952

过往的软件开发, 往往都是由架构师将他对产品的理解,利用 UML 来体现软件的架构设计。

这种方式的问题是:因缺乏使用者与团队成员间的互动参与,使得对外并未能完整的将使用者需求,映射到软件架构中; 而对内所提供的软件架构设计文档, 对实际开发的工作, 指导意义并不大(因为,厚重的架构设计文档,便如老太婆的裹脚布般;又臭又长)。更严重的问题是,由于架构设计耗费太长的时间,如此再加上开发、测试的时间,团队往往会太晚才会发现软件架构上的重大缺陷。而由于太晚才发现软件架构上的缺陷,所以,软件架构上若需做优化,则往往需耗费惊人的人力与时间成本。

敏捷开发, 经由可视化、轻量级的 "场景树", 使得使用者与团队成员间可共同的协作, 共同的识别:

  • User Story 中的活动
  • 活动后所产生的实体对象
  • 验证实体对象的纬度
  • 识别描述实体对象的价值对象
  • 整合所有 User Stories 的 User Story 地图

所以, 开发人员可根据 “场景树”与 User Story 地图,轻易且高效的找到单元测试点并设计出有效的测试用例与测试数据。而使开发人员能在最短的时间内,将软件架构直接转换为测试代码与产品代码。使开发人员能在最短的时间内,经由单元测试的 “黑盒测试”,发现到软件架构上的缺陷。

另外SonarQube也提供了一可持续优化产品代码(架构)的平台。

所以,在敏捷开发中,我们真的找到了一个有效的方法,去构造一高效、健康的产品开发的生态系统;经由此生态系统,使用者与团队成员将可高效的协作,共同的设计软件架构,并在最短的时间内,发现软件架构上的缺陷并持续的优化软件架构。

欢迎你也来试试。