敏捷宣言 + 测试管理

已经是第五次听敏捷培训了,不过感觉还是发生了很大变化,Agile好象正在向好的方向发展.

Just Enough ,

不需要客户不需要的功能,不要自做主张增加项目的范围.

以前一个项目不知道文档怎么样才能达到验收的目标,结果写了很多文档,老板们拼命追求先进技术和先进的业务,随意增加项目范围,并且没有人把如何验 收项目和结项定义清楚,把问题搞得越来越复杂,解决方案和技术完全超过了实际团队的实际能力,最后项目以失败告终,领导和团队全部走了,想想真的是教训 啊.

不知道目标,或者目标超过了我们的实际能力,哪怕再努力也无法meet,那么这样的目标就是应当砍掉或推迟执行的.项目的plan能力真的是太重要了.

Changing needs ,

需求在一个Iteration中(2-3周)不变,但是在结束后重新规划一次.所以现场客户的小项目其实用这种方式是比较合适的.

iterative,  high quality .

High quality

质量为第一,必要时砍功能以保证交付和质量.

collaborative,

我最看好standup meeting,每天的站立会议,每个人讲一分钟,清清楚楚. 锻炼人的总结能力,也有利于交流和项目状态的跟踪.

handover of requirement --&gtdeveloper --&gttester ,

这点我的感受也非常深,如果某个人的信息不全面的话,那么他非常容易犯无心之过,而这是组织应当帮助他们的.有心之错才是应当惩罚的.

并且前馈大于反馈,事前的提醒告知大于事后的批评和指责.

done 定义,这是我当时最迷惑的一点,谁可以定义这项任务做完,开发人员显然不应当是,那么还是测试人员或产品人员验收更重要.

项目的结束条件是需要预先定义的,当然也可以后面遗留一些在某个版本,只是管理上更复杂些.

个人交互胜过流程和工具,这点我非常赞同,在我看来越简单越清晰的图和积极的交流和Just do ,包括接口定义远胜过几十页的文档.但是最后还是要留下文档,以便将来的Reuse和Improve.

测试

Test plan and Test case 

测试环境和测试计划很重要其次才是测试用例

敏捷测试计划 里面的内容我认为非常有用,Test Schedule (测试的时间进度规划) ,test case  (测试用例) Test Result (测试结果), Test Environment(测试环境) ,我个人的感觉通信测试中环境是比较复杂的,往往会占1/3的时间,特别是和外界的协调和接口定义,大概云计算会稍微好点.

敏捷测试计划,沟通测试策略,质量目标,资源估算. 这几方面也挺重要的,特别是需要多少人日,多少环境和外部支持,什么样的Bug数可以接受,自动测试的方法等都是很重要的课题.

RUP中 将其分为 Test plan/Test design /function test/ Integration test. System test , 基本还是差不多. 其中很迷惑我的System test 经常不过导致当时的Iteration被耽误好象是每个公司的情况,呵呵. 只能重新定义和规划了.

拥抱变化 首先要知道变化. 里面涉及到Collboration , life cycle management  (JAZZ) .

测试脚本生成, 测试环境准备,手工测试, 要了解需求变更的可能性,问题发生的风险,需求或用例的优先级

Script. 脚本和探索式测试(Explore) . 里面的编译,部署,发布,冒烟,自服务测试(和H比较象) .

评价一个产品的指标 ,云计算

成本(分为采购,管理成本,折旧,劳动力,软件部署,升级成本),平台管理能力,容易部署, 使用更便宜,可适应变化的能力,(所以要对资源进行抽象和标准化),按用量收费,并可以弹性收缩) 

不合势的流程反而降低效率,这一点我也感受很深,小项目和大项目就完全不同.敏捷的思想其实还是希望把大项目分解为小项目,以降低风险.

license , SAAS,云计算 都是三中不同的模式.
老师比喻为买车,租车和打的,个人觉得云计算的计费模式可能会决定了其未来的使用前景.

服务存储利用率,自服务能力,交付测试能力,变更管理,发布管理,计费,存储都是将来云计算的重要Topic, 可惜我现在不做计费业务了,否则唉.

云计算分为创建,注册,使用,不用.

 

 有requirement composer 进行管理.项目数据的收集和继续集成.RTC,My developers ,wiki等等都是很好的工具.

Agile里面强调人的因素,我觉得这是对以前CMMI的最大改进,难怪越来越流行了.

大项目的敏捷管理是我最关心的话题.记了一下:

1.强调价值,范围,Vision 远景规划.

2.持续的验证(包括需求和架构) . 我做过的一个支持新协议,EDIFACT项目就是一个列子,架构必须要开发出原形验证,否则风险非常大,不能把概念化阶段的想法当成项目的最终目标,这是新项目中最困难的一点,也是需要积极努力的一点.

3.用户的参与(包括了Stakeholder和客户的沟通),这也是我过去做得不够的,必要时就是要碰面开会,确定下结论,并定期调整,不能模糊和拖沓.

4.自组织,强调与人沟通和工作的主动性.

5.不断反馈,这一点也很重要. (大错误如果能及时被修正,肯定不会成为大错误) ./

敏捷的度量还是原来那些,生产力,任务工作量,覆盖率,缺陷修复率

 

强调目标驱动.

强调风险和价值驱动.

演进式架构

模型要早日验证

--大项目的教训啊.

参与的人员有 Domain expert , team leader, Independent tester ,scrum master, product owner, architecture ,System Integrater .

强调respect,互相尊重 , 信守承诺,互相尊重,  Responsibility ,摈弃浪费,保证质量.

这些方面现在的公司还是不错的.

强调协作,协调和结论. 

大型项目Agile阶段划分

分为: 先期,构造,移交, 这个解决了我以前的疑惑 .. 赞一下

1. 早期的架构做到业务需求 ,架构包含可用性,性能可扩展性,风险识别几方面就可以了.

 早期不要做得太多,四周就够了,否则会是一种浪费.

2. 构造: 就是开发和测试,里面包括了架构修复,Re-factory,TDD,SI 等等传统实践,这里不想写了.

3.移交阶段,包括了移交计划,测试,修复稳当,安装,用户手册,架构,概要设计,培训等任务

***企业级的度量

这也是里面最重要的Topic,企业的文化，战略目标，业务目标，必需遵循的企业规范，代码规范，知识产权，企业架构，数据管理等等．

IBM强调的是有计划的敏捷，全生命周期的管理．

大项目中的八大因素:

1.地域上的分布,复杂度 增加,成功率下降

2. 团队规模,Agile要求团队不要超过9个人.否则沟通成本大大提高,效率下降.

3.确保没有法律和规范的要求

4.领域的复杂度.(如通信行业中的RNC,MSC)
5.组织的分布

6.技术复杂度

7.组织复杂度  (最令人头痛而又稳妥的矩阵式管理) .

8.企业级要求(企业级内部产品整合)

规模越大,成功率越高. (RDC,RMC工具中有各种摸板)

最后强调了分解目标和执行的能力

有意义的创新 来自于历史和未来的数据分析.

最后讲到了文档和数据报表展现的方式.呵呵,美观度还是差点, 不过让我挺惊讶的是Rose被RSA替代了,一流的思想,二流的软件,三流的界面,好象这那些功能,你却必须要选择多次才能达到你的目的..

last but not least , 记录了几个指标,看看以后是否用得上:

项目管理:

任务偏差, 任务工时,任务进度偏差,项目性能,资源需求 ,供应量,资源利用率 , 风险度量,财务度量.

 

需求管理

已测试, 已实现需求, 需求缺陷, 需求传递, 需求分布,需求波动趋势, 需求跟踪矩阵,

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24478210/viewspace-707214/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24478210/viewspace-707214/