2017-11-10 00:00:00 O4dC8OjO7ZL6 阅读数 328
  • C++项目开发

    RUP(统一软件开发过程):分析、设计、编码、测试、维护 要求一开始就要有一个好的设计 XP(敏捷开发):素材(编码)、结对编程、测试驱动开发 通过以上两种方式保证我们素材的质量. 交付 迭代速度很快 重构 在不影响功能的前提下, 重构代码 通过重构实现一个好的设计

    885 人正在学习 去看看 杨波

点击上方“中兴开发者社区”,关注我们

每天读一篇一线开发者原创好文

▎作者介绍

丁一:无线研究院敏捷教练,也是敏捷软件开发爱好者,致力于让管理实践和技术实践在团队中扎实落地。

叶卫军:优秀的团队Scrum Master,具有敏锐的洞察力,丰富的管理经验,打造了一只高效能的团队。

李会毅:专注于软件设计和开发,善于思考和总结,致力于通过敏捷软件开发技术与流程提升团队绩效。


我们接触敏捷软件开发也有一段时间了,但这其中的一些实践,比如“四会”、代码走查、结对编程等实践我们真正做“到位”了么?如果仅仅当成一种形式去开展这些实践,反而达不到预期的效果。时间长了,团队成员就会对敏捷开发动摇信心了。


在《重构》一书中,软件大师Martin Fowler以代码坏味道的方式给出重构建议。本文也以敏捷实践坏味道的方式展开叙述,结合作者们的实战经验对问题进行改进。这些实践在作者们的团队中都获得了不错的效果,在此和大家分享。



▶1.站会

坏味道:

- 拖沓、冗长

- 针对具体问题讨论发散

- 汇报会


重构方法:

- 可以买个小闹钟挂在看板上,设定好时间,超时就提醒

- 团队成员讲解的时候,要面向大家,不要看着SM。发言内容仅限站会要求的三件事。

- 不讨论具体的细节问题,可以等站会结束后找相关人员单独讨论。


▶2.启动会

坏味道:

- 任务安排会

- 只评估开发的工作量

- 冗长


重构方法:

- SM首先整理出这个迭代的backlog(优先级已经和项目确认好)。

- 交付类故事需要在迭代前完成需求研讨,输出设计方案,如果没有方案,不能进入迭代。

- BA已经初步拆分史诗故事(可以独立交付、验收)。

- 启动会开始时,BA对方案进行讲解,大家提问,达成共识后,评估点数,包括开发、验收测试、自动化测试、UT等全部点数,拆分用户故事。

- 当全部故事评估完成后,根据总点数,看是否超过了团队的承受能力,如果超过,需要舍弃低优先级需求。

- 最后认领故事。


▶ 3.回顾会

坏味道:

- 回顾内容单一

- 改进措施跟踪不到位


重构方法:

最初的回顾会,就是传统的敏捷回顾会,讨论这个迭代做的well, less well, suggestion的地方。

当然这种方式并没有问题。但它忽视了软件交付过程的改进。

因此,除了上述的回顾方式,可以增加如下内容:


- 迭代度量数据解读。比如特性、史诗故事、用户故事的交付周期,代码覆盖率等度量指标,从中挖掘需要解决的问题。

- 故障复盘。这个可以说是我司传统保留活动,不解释了。


通过以上三种回顾方式,可以从文化、交付、团队等角度全面进行回顾。


针对回顾发现的问题,在wiki上建立了专门的backlog,然后把待改进点打印出来,贴在看板上,提醒实施人跟踪。

下次回顾会时,首先会对上次回顾会的改进内容进行讨论,看问题是否解决。


▶4.演示会

坏味道:

- 缺失

- 时有时无

- 提出的问题没有跟踪和反馈


重构方法:

- 演示会需要固定时间,比如在迭代完成后的第三天进行。提前确定主持人。

- 主持人提前整理演示的内容,一般从需求系统上导出交付的功能清单。用项目的集成环境进行演示。

- 主持人发邮件给用服、规划、开发、测试、项目经理等干系人。

- 演示过程有专人记录提出的问题。

- 演示后,主持人把演示过程和发现的问题记录在wiki上。

- 下个迭代,对问题进行改进并合入版本。在后续的演示会上,会对这些改进点进行演示,做到闭环。


5.代码走查

坏味道:

- 评审的同事对代码不熟悉,发现不了问题。

- 讨论发散。

- 只能走查部分同事的代码,其他同事的内容没有覆盖。


重构方法:

- 代码走查时间分两块:每天下午16:30--17:30,第二天09:05--09:30。如果当天下午能把全部内容走查完,第二天早上就不再进行走查。如果没有走查完,第二天早上就要继续走查。

- 走查前,会统计下几个人要走查,每个人大概要花多长时间。做好初步计划。

- 走查时,主讲人要对业务背景、代码意图进行介绍,让大家有整体了解。

- 引入主持人机制。主持人要有敏锐的洞察力,一旦发现大家讨论发散或者延迟,立即叫停。


▶6.看板

坏味道:

- 荒废了

- 故事卡移动不及时


重构方法:

针对看板,团队内部做过一次讨论。正好当时项目要统计迭代人力投入,为了能更准确、工作量小的完成这件事情,我们做了这样的约定。


- 迭代开始前,在团队backlog(excel文档)中更新任务,然后把故事卡打印出来,贴在看板上。故事卡进行分类:设计、开发、测试、故障、文档、沟通等。

- 站会开始前,每人检查自己的故事卡是否完整?如果不完整,补充故事卡

- 站会开始时,每人在故事卡上划道道,最多两道(每道代表0.5天)。然后移动故事卡。


迭代完成后,SM收集故事卡,结合excel表格和卡上的道道,很容易就能统计出团队这个迭代的人力投入以及故事交付是否延迟?并且是相对精准的,也节省了大家的时间。

还有一个好处就是:团队的任务全部可视化,故事卡也能流转起来了。


▶7.自组织

自组织是大家为了目标能自发的做事情,检验的标准很简单:如果SM不在,这个团队的工作能否正常运转下去?

要实现自组织,一定让大家达成目标共识。

比如可以做了如下约定:

1. 每天早上8:50,自觉到看板前集合召开晨会。

2. 每天下午16:30,自觉到大电视前集合进行代码走查。


刚开始执行的时候,可能有些同学还不太习惯,需要有人叫一下。时间长了,大家养成习惯就按照这种方式自觉开展了。


另外,对于一些敏捷实践,比如回顾会、启动会、showcase等也不仅仅是sm的事情,通过认领的方式,让大家都能参与其中,同时也锻炼了个人的组织协调能力,一举两得。


▶8.需求研讨

坏味道:

- 没有需求研讨

- 计划会上SM或者BA简单澄清需求后开始认领故事


重构方法:

- N-1迭代BA组织完成N迭代的开发需求研讨;

- 研讨过程必须参与角色齐全:BA + TSE + QA + DEV(不一定全员);

- 形成团队自己的需求场景清单,并在后续复盘改进中不断完善;每个需求研讨结束前对照清单逐一分析波及影响;

- 研讨完成后,计划会之前TSE和QA协商输出测试用例


▶9.无差别团队

坏味道:

- 团队一个萝卜一个坑,各人只扫自己门前雪

- 计划会无故事认领环节

- BA拆分好故事后,SM挨个指派任务


重构方法:

- 故事按照优先级排序,主动认领;

- 如果认领者认领了陌生领域卡片,SM可以安排一个熟悉的同事协助,但一定要认领者负起交付责任;

- 无差别建设过程中,团队营造一个开放的氛围,允许犯错;SM在考核或者语言鼓励上,给予成员足够的安全感;

- 如果团队现状不适合大规模无差别,建议逐步小范围开始,但一定要开始做起来。后续收益会超乎想象。


▶10.结对编程

坏味道:

- 大部分时间都在闲聊;

- 在结对中滥竽充数、心不在焉、得过且过;

- 都结对编程了,就不需要代码走查了;

- 结对过程中两人没有任何交流;

- 新人和老员工结对时,新员工一直默默的看着;


重构方法:

根据团队的实践经验,结对的方式是非常灵活的,结对编程应该是自由选择,不应是强制性的。

是否使用结对编程,需要具体问题具体分析,不可盲目。任何事手都有他的好与坏,结对编程也不例外,只有知道了好与坏,才可以更好的利用它。提升开发的代码质量和开发的效率,更好的知识共享,更好的团队氛围。



- 如果两个人都喜欢闲聊,就不要在一起结对编程,通过分别认领不同的任务。

- 不是所有工作都适合结对完成。架构设计和技术验证、简单的任务、已经有成熟的解决方案,这些都不适合结对。对于有挑战的问题,结对双方有不同的技术背景,可以通过结对达到技术互补或者碰撞找到更好的解决方法。

- 老练的程序员和新程序员结对,可以分享业务和技术经验,使新人更快的成长,同时新老结对也需要给新人独立完成任务的时间和机会。使新人有自己解决问题的思路和方案。通过结对-独立开发-结对,不断的乒乓来发现自己的短板。使团队人员能力达到提升。

- 结对编程不能没有代码走查,两个人有可能缺少同样的知识点,导致犯同样的错误。代码走查是必须的。

- 结对需要结对双方都要明白结对的意义,不是为了结对和结对。不能发挥结对的优势,那么需要果断的终止结对。

2008-12-21 16:42:05 EverToBe 阅读数 91
  • C++项目开发

    RUP(统一软件开发过程):分析、设计、编码、测试、维护 要求一开始就要有一个好的设计 XP(敏捷开发):素材(编码)、结对编程、测试驱动开发 通过以上两种方式保证我们素材的质量. 交付 迭代速度很快 重构 在不影响功能的前提下, 重构代码 通过重构实现一个好的设计

    885 人正在学习 去看看 杨波

GAE上面的Unittest总结: http://ihere.appspot.com/post/2465
我是个推崇敏捷开发 重构 TDD 小步迭代 快速交付的 开发者,本来一直都用java来开发 , 最近迷上了python, google app engine, django
一开始我就想python上面的敏捷开发应该是怎么样的, 那阵还真不太了解 碰了不少壁:-( 经过一段时间的总结在 现在慢慢找到python gae上面开发的套路了, 觉得这个应该是GAE上开发以及unittest的较好实践了:P  特此发文分享:-)

参考:unit-tests-for-google-app-engine-apps, gaeunit, appengine helper

首先我想直接通过django的test 来测试gae上的app, 众所周知 appengine的mode层与django完全不同 这样其实直接运行test是不可取的 通过查阅这篇文章unit-tests-for-google-app-engine-apps得知 :其实appengine 的开发sdk本身已经提供了很多api stub 来帮助我们写unit test.  其实主要的地方是在test的setup方法里面注册这些stub 以及设置必要的环境变量, 以我发的demo 做个讲解

# coding=UTF-8
import unittest,os,urllib
from django.test.client import Client
#import the stubs, i.e. the fake datastore, user and mail service and urlfetch
from google.appengine.api import apiproxy_stub_map
from google.appengine.api import datastore_file_stub
#from google.appengine.api import mail_stub
from google.appengine.api import urlfetch_stub
from google.appengine.api import user_service_stub
from google.appengine.api.memcache import memcache_stub

from django.utils.encoding import force_unicode,smart_str
from google.appengine.api import users
from django.test import TestCase

from google.appengine.ext.db.djangoforms import ModelForm
import unittest
from django.test.client import Client
from google.appengine.api import users
import logging
from models import *

#How I do gae test:-)
#1.
#using gaeunit: http://code.google.com/p/gaeunit/
#and need to fix a bug of Django : Ticket #5176
#http://code.djangoproject.com/ticket/5176

#2.
#using appengine_django_helper:
#http://code.google.com/intl/zh-CN/appengine/articles/appengine_helper_for_django.html
#http://appengineguy.com/2008/06/proper-unit-testing-of-app-enginedjango.html [GFW blocked]
#run from cmd: manage.py test upload
#Here i use the 2nd way:P
#enjoy
class FileTest(unittest.TestCase):
  
    def setUp(self):      
        # Start with a fresh api proxy.
        apiproxy_stub_map.apiproxy = apiproxy_stub_map.APIProxyStubMap()

        # Use a fresh stub datastore.
        # From this point on in the tests, all calls to the Data Store, such as get and put,
        # will be to the temporary, in-memory datastore stub.       
        stub = datastore_file_stub.DatastoreFileStub(u'myTemporaryDataStorage', '/dev/null', '/dev/null')
        apiproxy_stub_map.apiproxy.RegisterStub('datastore_v3', stub)

        # Use a fresh stub UserService.
        apiproxy_stub_map.apiproxy.RegisterStub('user', user_service_stub.UserServiceStub())
        os.environ['AUTH_DOMAIN'] = 'gmail.com'
        os.environ['USER_EMAIL'] = 'myself@appengineguy.com' # set to '' for no logged in user
        os.environ['SERVER_NAME'] = 'testserver'
        os.environ['SERVER_PORT'] = '80'
        os.environ['USER_IS_ADMIN'] = '1' #admin user 0 | 1
        os.environ['APPLICATION_ID'] = 'appId'
      
        # Use a fresh urlfetch stub.
        apiproxy_stub_map.apiproxy.RegisterStub('urlfetch', urlfetch_stub.URLFetchServiceStub())

        #User a memcache stub
        apiproxy_stub_map.apiproxy.RegisterStub('memcache', memcache_stub.MemcacheServiceStub())

        # Use a fresh mail stub. mail stub have a conflit with the other api by now in the real gae environment. so comment it.
#        apiproxy_stub_map.apiproxy.RegisterStub('mail', mail_stub.MailServiceStub())

        # Every test needs a client. using django test client
        self.client = Client()     

...

可以看到 蓝色部分是在注册gae的api stub (想深入研究 可以看看sdk 里面的dev_appserver.py 那里有具体的使用方法)
注意我使用了 Django的Test Client 来模拟Http请求  使用时候需要fix个bug 改django.zip里面的文件 如果使用我得demo 的话是已经改好的:-)

接下来是个简单的test:

    def test_add_file(self):
        file=open('upload/testtxt.txt')
      
        response = self.client.post('/album/', {'file': file})
        file.close()
        self.failUnlessEqual(response.status_code, 302)
      
        returnResponse = self.client.get('/album/')
        self.assertTrue('testtxt.txt' in returnResponse.content)
        userFile=UserFile.all().filter("name =","testtxt.txt").get()
        self.assertTrue(userFile is not None)

向'/album/' 发起post请求  上传一个文件  并对response进行验证.

def tearDown(self):
        #For that we are using a temporary datastore stub located in the memory,we don't have to clean up.
        pass

tearDown不需要做任何动作  因为最开始setup的时候 只是在内存中建立了一个临时datastore


这就是一个完整的 unit test 例子:-)

上面这个例子 在本地控制台 直接 manage test upload 可以直接运行 不需要启动gae的dev_appserver
但是通过一段时间的开发发现本地的sdk环境与gae的实际环境不完全相同.本机调试ok ,上传之后 ,可能在实际环境中还会有意料之外的bug:-(  有没有一种方式可以在实际的环境中进行测试呢? 老外已经看到这个了 并且有了解决方案 就是 : gaeunit    它由http ajax驱动test的执行, 大家可以看我页面sidebar左下 lab 里面有个run test 就是这个出于安全原因当然只有admin才可以执行. 下面说下怎么将django 本身的test与gae unit结合,并且不留重复code:-)
gaeunit 执行的时候会执行所有test文件夹下的test 我的demo 中test/test_upload.py
中只有一句话:
from upload.tests import FileTest

简单吧:P 而FileTest就是我们之前写的django unit test .这样集成之后这两种方式可以混用而且没有重复test code :-)
本地开发时候可以运行 manage test upload
而在gae 实际环境中又可以 直接在浏览器:http://yourhost/test
来执行gae unit test
每次看到这个都很高兴:-)

 

2014-09-04 22:14:32 u011409995 阅读数 1009
  • C++项目开发

    RUP(统一软件开发过程):分析、设计、编码、测试、维护 要求一开始就要有一个好的设计 XP(敏捷开发):素材(编码)、结对编程、测试驱动开发 通过以上两种方式保证我们素材的质量. 交付 迭代速度很快 重构 在不影响功能的前提下, 重构代码 通过重构实现一个好的设计

    885 人正在学习 去看看 杨波

    随着时间的推移,现有的代码会 有 新特性、新功能的添加,需要处理一个又一个的错误,代码的结构逐渐退化。如果对此置之不理的话, 这种退化最终会导致纠结不清,难于维护的混乱代码。 xp(极限编程 eXtreme Programming)团队通过经常性的代码重构来扭转这种退化。重构就是在不改变代码行为的前提下,进行一系列小的修改,旨在改进系统结构。每个改造都是微不足道的,几乎不值得去做,但是所有的这鞋改造叠加在一起,就形成了对系统设计和构架的显著的改进。

    每一个软件模块都有单个职责:

        1、它运行起来所完成的功能。这也是该模块得以存在的原因。

        2、它要对应变化。几乎所有的模块在它们的生命周期中都要变化,开发者的职责保证这种改变应该尽可能的简单。一个难以改变的模块是拙劣的,即使能够工作,也需要对它inx修正。

        3、要和阅读它的人进行沟通。对模块不熟悉的开发人员应该能够比较容易地阅读并理解它。哟个无法进行沟通的模块也是拙劣的,童谣需要对它进行修正。

    在每次细微的改造之后,我们运行单元测试确保改造后没有造成任何破坏,然后去做下一次改造,如此往复,周而复始,每次改造之后都要运行测试。通过这种方式,我们可以在改造系统的同时,保持系统可以工作。重构是持续进行的, 而不是在项目结束时、发布版本时、迭代结束时、甚至每天快下班时进行的。重构是我们没隔一小时或者半小时就要去做的事情。通过重构,我们可以持续地保持尽可能干净、简单并且具有表现力的代码。

    总结:

    重构的目的是为了每天 清洁 你的代码,代码的清洁怎么强调都不过分!

    重构不仅 要使程序结构的各个部分之间相互隔离,也就是节耦合,甚至包括一个变量名、函数名的修改。

    重构应该是伴随着开发一起进行的。


思考:通过重构使得程序结构的各部分之间相互隔离,你也许会担心提取出仅仅只会调用一次的函数会对性能造成负面的影响。实际上,提取出函数所增加的可读性是值得花费额外的一些小开销的。然而,也许那些少许的开销存在于深深的内部循环中,这将会杂牌成较大的性能损失。所以此处得谨慎处理。。。

 

2015-11-03 16:30:22 uxyheaven 阅读数 18012
  • C++项目开发

    RUP(统一软件开发过程):分析、设计、编码、测试、维护 要求一开始就要有一个好的设计 XP(敏捷开发):素材(编码)、结对编程、测试驱动开发 通过以上两种方式保证我们素材的质量. 交付 迭代速度很快 重构 在不影响功能的前提下, 重构代码 通过重构实现一个好的设计

    885 人正在学习 去看看 杨波

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

敏捷开发工程实践

项目管理

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

需求管理

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

架构

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

开发

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

测试

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

变更管理

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

敏捷开发管理实践描述

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

敏捷开发工程实践描述

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

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

敏捷软件开发宣言

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

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

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

核心价值观

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

敏捷开发的原则

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

敏捷开发管理实践

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)

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

2017-03-14 15:59:48 qq_26562641 阅读数 558
  • C++项目开发

    RUP(统一软件开发过程):分析、设计、编码、测试、维护 要求一开始就要有一个好的设计 XP(敏捷开发):素材(编码)、结对编程、测试驱动开发 通过以上两种方式保证我们素材的质量. 交付 迭代速度很快 重构 在不影响功能的前提下, 重构代码 通过重构实现一个好的设计

    885 人正在学习 去看看 杨波

最近一直在研究java代码优化,web优化的思想和操作方法,无意中看到idea中有快速重构,下面给大家分享下。    

介绍了快捷键的用法。其中提及了重构神器Alt+Ctrl+Shift+T , 当时只是稍稍提及,本文重点在idea提供的重构选项。后续会有《重构,改善既有代码的设计》的读书笔记,可相互印证。

修复/改善:

 

这些如果当前光标处不支持某项重构,编辑器会提示错误以及用法。在重构设置中,也会有浮动窗口展示重构的结果。当然某些复杂的,可能无法在浮动窗口全部展示出来。

比如:选择Field,如果不在某个变量下激活,就会提示,需要在某个局部变量名或表达式下重构。

比如要将局部变量升级为成员变量,重构时会有效果的预览:

idea关于重构的就是这么多,基本上涵盖了大多数的情况,只是对于某些重构场合来说,并没有定式可以参考,所以也就没有其他一键重构的银弹。

快捷键与重构虽然看上去挺麻烦的,自己复制粘贴貌似也可以做。但是如果养成习惯,下手就是快捷键,会大大提高效率。


敏捷开发原则

阅读数 149

敏捷开发学习

阅读数 783

没有更多推荐了,返回首页