lhp__2006
- 浏览: 304173 次
- 性别:
- 来自: 西安
-
最新评论
-
guyinyihun：
好用,谢谢分享
[转]java 类里判断字符串是iso-8859-1还是gb2312,utf-8,gbk等,判断编码类型 -
java小叶檀：
可以使用hashset retainAll实现
找相同元素 -
爱拼才会赢小超人-1983：
...
UUID -
tuspark：
这篇《serialversionuId作用》解释的更清楚，更有 ...
为何加入：private static final long serialVersionUID -
futily：
public static void middleRevers ...
java数组反转
文章列表
2.2.3 测试用例设计和测试脚步开发（测试人员）
测试的主要任务是设计FT和NFT测试用例，同时要开发自动化测试代码或测试脚本，代码和脚本要得到Review，并应该要调测通过能够运行，最后才能check in到配置库加入到持续集成环境中。
用例设计前可能需要考虑必要的测试策略和测试方案。
（关于FT、NFT，也许你的项目现在还无法实现测试自动化，此时的主要任务还是在设计和完善测试用例上。但必须明确的是能否自动化测试是敏捷项目能否成功的关键因素之一）
2.2.2 Story功能实现（开发人员）
功能代码实现：一对pair（两名开发人员）开始实现功能代码，做好UT，并及时重构。有条件的可以按TDD方式开发。关于结对编程、TDD请参阅其它资料，本文不再赘述。这里要特别强调的是开发人员要做好工具的检查工作，包括：代码规范性检查、PC-Lint或FindBugs检查、圈复杂度检查、重复代码检查、UT测试覆盖率分析等。
本地构建：构建前一定要将配置库的最新代码更新到本地，构建的方式建议在项目组统一使用脚本自动化实现，主要的活动包括：编译、链接、UT测试，只有所有UT用例（包括其他人的）测试通过才能将代码check in到配置库。Check in到配置库 ...
2.2.1 头脑风暴会议
在每个Story开发前建议都有这个头脑风暴会议，该会议由Story责任人组织和跟踪，形式不限；PO和对应这个Story的开发人员、测试人员、资料人员做一个沟通，大家要在这个Story的理解上达成一致，大体的实现方案，并且要思考如何测试这个Story，这也体现了测试先行的理念。测试项不需要象以前的测试用例那样详细，模板可参见《Story测试项模板.xls》，测试类型包括功能测试项（以下简称FT）和非功能测试项（以下简称NFT）。另外还需要讨论这个Story的设计，输出形式不限。
◤提示：头脑风暴会议可以开多次，完成的标准 ◢
1、 各个模块的接口确认清楚
2、 简单设计 ...
2.2 单个Story的完整开发
在迭代开始后，通常以一个一个Story分别完成开发的。单个的Story开发以头脑风暴会议开始，然后开发、测试、资料同时行动，各司其职。
◤提示：一些优秀实践◢
1、对于每一个Story，可以指定Story负责人，该Story负责人类似Story PL，负责该Story相关的监控管理和接口等工作，为该Story服务。当然Story相关涉及人员，也不要依赖Story负责人的管理和推动；每一个人都要自管理起来，把自己的进展情况及时展现的相关人，遇到困难和问题及时交流，只有这样才能提高团队的效率；
2、提倡Story相关开发人员结对配合，相互review，提高Stor ...
2.1 迭代计划会议
（1）重新讨论、确定本次迭代需要实现的Story，达成共同理解；
（2）若有必要的话，则继续细化Story；
（3）对Story进行优先级排序；
（4）开发、测试、资料人员认领任务，估计工作量并做出承诺，这是敏捷Scrum的重要实践之一：开发团队决定承诺完成工作量的多少，而不是由PO或项目PL安排工作量。
（5）共同制定本次迭代的迭代开发计划。要输出针对本次迭代的详细的开发计划，开发、测试、资料是以Story为单位的，所以迭代开发计划也是以Story为核心的。计划中要包括本次迭代要开发的每个Story的开发人员是谁（一对pair）？测试人员是谁（一名）？什么时候开始？什么结 ...
2 迭代开发
迭代前准备工作完成后就正式进入迭代开发，一次迭代周期建议是2到4周，每次迭代后期要有单独的SDV测试，对每次迭代版本质量的要求是要能够达到版本发布的程度。SDV测试是针对本次迭代完成的所有Story的整体测试，当然也会包括前次迭代的测试回归。每次迭代是以迭代计划会议开始的。
◤提示：关于迭代的交付质量◢
强调达到版本发布的程度并不是要求每次迭代都要进行对外的版本发布，而是强调每次迭代的质量，无论如何，决不能放松对质量的要求，要避免草草结束当前迭代快速进入下一个迭代的做法，以免形成技术债务。
1.11 制定测试策略
测试TSE负责制定测试策略，用于指导迭代开发中各层级测试工作的开展，明确各层级测试重点，提升测试覆盖，降低测试冗余，保证迭代测试活动的质量。
TSE根据版本迭代计划，结合产品风险分析，给出迭代测试策略初稿，作为总体测试策略的一部分；TSE组织PM、SE评审迭代测试策略。
迭代开发需要有如下不同层级的测试活动策略：LLT（包括UT/IT/MST）测试、Story测试、迭代SDV、发布测试，各层级测试活动的定位和分工如下：
LLT测试：由迭代开发团队中的软件开发人员完成，通过LLT测试要能够保证向负责Story验收的测试人员提交一个可验收的Story；
Story测试：由迭 ...
1.9 项目启动会议
所有团队成员参加，类似于项目开工会，团队成员介绍、项目背景介绍、项目目标、大致的计划时间点，以及迭代前准备阶段的安排和任务分工等
1.10 建立持续集成环境
项目PL指定项目组的CI-CO人员，协调CMO创建项目文件夹，并初始化配置库；CI-CO要负责搭建持续集成环境。持续集成是最有价值的优秀实践，是敏捷开发的基础，要求持续集成环境必须在迭代开始前准备好，工具推荐使用ICP-CI。
1.8 现状评估、计划制定
项目启动时建议项目PL和敏捷教练一起对一体化团队的状况做一评估，包括：团队成员对敏捷的理解程度、技能、项目周期、规模、复杂度、准备采用哪些敏捷实践等。根据评估的结果，输出一个较粗的E2E迭代计划（迭代前准备阶段后期，和每次迭代结束后，都可细化或调整该计划），同时要对迭代前准备阶段的活动有一个详细计划，包括：对评估发现的问题尽早采取一些措施（例如培训）、Story分析、配置库和持续集成环境准备等
1.7 可视化管理
可视化管理可以清晰、简单和有效的组织和展示工作状况，可视化管理的目的不仅仅是为了“可视化”，更重要的是利用这样的一种方法，打造一种精益式的、Just in time方式的软件开发环境和系统。可视化管理的方式目前有很多种：Story Wall(状态墙)、Burn Down Chart燃尽图、项目组计划墙、特性墙等等。
建议项目组准备1-2个白板、Story卡片等用于可视化展示用，通常至少要展示出Story状态墙。
◤提示：可视化的关键点◢
物理实体：可视化一定要做到物理上的实体化，大家在公开场所都容易看到，触摸到；
内容精简，易懂：信息展示一目了然，切实对团队有帮助，切忌贪多 ...
1.6 办公环境布置
安排一体化团队成员围坐在一起工作，目的是便于大家的沟通和交流；但目前大部分办公现状无法改变，所以只能让一体化团队成员尽可能的靠近，尤其不要出现开发和测试不在同一楼层的情况。 合理布置项目状态墙和开晨会的位置。
◤提示：项目PL绩效管理◢
1、 项目PL要对团队成员的工作情况实时进行记录，每月把成员的工作情况反馈给LM，让LM了解成员的情况，同时可作为成员绩效评价的参考。
2、 对于不能在项目中全部投入的成员，每周要进行一下人力投入情况的审视；
1.5 一体化团队组建
一体化团队成员包含：Product Owner（以下简称PO）、敏捷教练、项目PL、开发人员、测试人员、资料人员、CI Coordinator（以下简称CI-CO）。
PO：负责收集相关于产品的所有信息，从客户或产品的最终用户、开发团队成员、以及其他利益相关人中获取，并将这些信息转化为User Story，并进行优先级排序。PO建议由SE担任，或由TL、项目骨干等担任，但前提是此人对业务（需求）必须清楚。
敏捷教练：一个敏捷教练可以帮助团队或个人采用和提升敏捷方法和实践，同时帮助人们重新思考和改变他们以往的开发方式。目前业软各PDT都分别任命了一批敏捷教练，敏捷教练是一个 ...
1.4 输出项目SOW
PM和LM沟通项目人力情况，确定项目PL，确定项目的范围和进度要求。根据每个Story的优先级和工作量、商业价值进行排序得到优先级，最高价值的Story优先级排在前面，另外还可以考虑这几种因素：客户紧急程度、需求稳定性、依赖程度、对系统架构的影响、风险等，一般来说，客户急迫的、相对稳定的、依赖性强、影响系统架构的需求应该优先做。
PM把项目SOW和产品特性列表（产品backlog）发给项目PL、SE、TE、资料等相关人员评审。评审通过后即可作为正式的项目SOW下发给项目PL组建项目团队，开展工作。
◤提示：项目PL启动项目前要关注◢
1、人力是否满足项目启动需求 ...
1.3 概念和架构设计
敏捷开发中，注重概念和架构设计，而轻详细设计。这里的概念设计，可以看成是为什么要做这个产品或模块，强调的是产品的路线规划、市场趋势、客户价值、技术趋势等。架构设计，可以看成从整体上看，概念设计应该用什么方式实现、分几个层次、多少组件、不同层次和组件之间关系是什么。详细设计，则是具体的设计和做法、API接口等。
一个产品，特别是面向行业的产品，概念设计和架构设计非常重要，需要考虑行业未来的发展方向，产品在市场中横向和纵向的比较，技术的发展方向，和每个模块的投入和收益的比例等，这样才能尽可能保证产品沿着正确的方向前进。在产品中新增或删除一个模块需要非常谨慎，因为一旦新增模块被 ...