wengge
- 浏览: 39477 次
- 性别:
- 来自: 杭州
-
最新评论
文章列表
Agile
敏捷开发。
Backlog
一项工作。
Build
指已经编译、构建好的一个可运行的软件版本。
Burndown Chart
用来显示当前还剩下多少工作未完成的图形化工具。通常以时间为横轴，以本
次迭代要完成的工作为纵轴。
Code Review
代码审核， ...
公司去年下半年刚刚通过CMM5 认证，对于国内企业来说，通过这个认证需要相当的实力和软件管理水平。当然，从软件管理上来讲，我们采用的是传统的瀑布模式，但是目前我们也想在公司的一些部门推广使用敏捷的办法，尤其是Scrum。公司现有的规章制度不能改变，还是要严格遵守CMM/CMMI 的一些要求，我不是特别清楚Scrum 与CMM/CMMI 的关系，另外还有ISO9001的这样的质量标准，他们之间有冲突吗？
ISO9001 是一个国际标准，即《ISO9001：2000 质量管理体系——要求》ISO9001标准起源于制造业，其标准结构、质量体系特点都与制造业非常吻合。随着市场经济的发展和 ...
IBM Rational Team Concert（RTC）是第一个基于Jazz 技术的商业产品，也是Rational 的下一代协作软件交付平台。
RTC 特别适合敏捷开发团队，主要提供了3 大块内容，分别是工作项管理（Work Items）、版本控制管理和构建管理。RTC 是基于Eclipse 的，所以采Eclipse 开发IDE的团队使用RTC 将是非常方便的。这样做，RTC 提供的3 大块内容又和开发本身无缝式地集成在了一起。
RTC 能够带来很大程度上的信息透明化，各种角色的用户都可以获取自己感兴趣的信息，还可以通过RSS 自动获取。用户可以随时了解团队开发过程中 ...
Scrum 十分强调Sprint 回顾会议的重要性。从我们团队实施Scrum 这段时间以来的经验和教训来看，我也认为定期的回顾是很有必要的。
Sprint 回顾会议，顾名思义，是为了在Sprint 刚刚结束的时候及时总结这个Sprint 中的得与失，使团队在各方面持续成长。这就像一次比赛，在中场休息的时候，教练为队员们指出比赛中的亮点和不足，让他们在接下来的比赛中能更好地发挥。这跟Sprint 评审会议有本质上的不同，想必你也了解，我就不多说了。
在项目开发过程中，有一个原则是，问题被发现和处理得越早，付出的代价就越小。但问题是我们在紧张的开发任务中有时候很难发现这些错误 ...
Scrum 把软件开发项目中的各种角色形象地分为两类，一类是“鸡”，一类是“猪”。 故事的来历是这样的。 一只鸡和一头猪是朋友。一天，鸡对猪说：“咱们合伙开个餐馆吧！”猪觉得挺有意思，说道：“这个主意不错，那咱们的餐馆该叫什么名字呢？”鸡说：“叫火腿和鸡蛋吧。”猪马上不干了，说：“那谢谢了，我不参与了。如果要开这个餐馆，我得把自己全部贡献出来，需要全身心地投入，而你只需要投入一部分就行了
在Scrum 中，不实际参与项目开发的一些管理者是“鸡”，而全身心投入的项目团队成员是“猪”。
Sprint 回顾会议由产品责任人、Scrum 团队和Scrum Master 参加，会议中需要讨论有哪些好的建议或方法应该被采纳，在Sprint 中有什么做法不可取，有哪些做法效果很好，应该继续下去。
Sprint 结束后，Scrum 团队回顾刚结束的Sprint，对其进行总结和反思，使整个团队能持续成长。
Sprint 回顾会议的形式可以比较随意，主要做到以下这些方面就可以了。
Scrum Master 首先给大家看Sprint Backlog，总结这个Sprint，大家讨论在这个
Sprint 中发生的一些比较重要的事件。与会人员轮流发言，每个人都有机会发表 ...
Sprint 评审会议在Sprint 结束时召开，由开发团队展示这个Sprint 中完成的功能，长度为两个小时左右，不需要PPT，一般是已经完成功能的Demo，而且客户、管理层、Product Owner 以及其他开发人员等都可以参加。在每个Sprint 结束 ...
Sprint Backlog 里的项目我们通常用User Story 来描述，User Story 是从用户角度对系统的某个功能模块所作的简短描述。一个User Story 描述了项目中的一个小功能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么 ...
- 2011-06-08 15:24
- 浏览 1403
- 评论(0)
产品Backlog 指根据初始需求分解出的任务列表，包括功能性的和非功能性的所有功能，由Product Owner 为Product Backlog 中的任务确定优先级别，当开发团队开始某个任务的时候，再精确定义和分解这个任务。
产品Backlog 是产品所要具备的所有功能的总纲。当一个项目刚刚开始时，没人能够事先预见到所有的任务和需求，并为之制定一个充分、详细而又包罗万象的计划。可行的方式是，先为一个项目写下所有它应该具备的显著特征和功能，数量不必很多，最好够让团队的第1 个Sprint 有活可干。
随着Sprint 的进行，生产出可发布的产品增量，客户对产品的直观认识 ...
有的人对采用敏捷开发是否能真的有效提高效率并生产出成功的产品表示怀疑。他们认为，在敏捷方法中，由于没有经理的管理和约束，团队和项目必然是一团糟，仿佛越是上层越有这种想法。敏捷开发的理念是信任开发团队，信任每一个人。试想一下，如果你们这个团队对你们的项目充满激情，而老板又充分信任你们，那么你们必会将更多的时间花在如何有效地提高生产率、如何创新地完成某个功能等方面，而不是按老板的意思按部就班地工作了，这样还会节省很多时间并简化流程，例如开会、向老板报告、请示老板、等老板批准等。就像咱们刚才的那个游戏结果所揭示的那样，充分调动参与项目的人员的主动性，让他们自我组织、自我管理，由团队自身来掌握项目进 ...
个体和交互重于过程和工具
敏捷方法认为，人是软件开发中最重要的因素。开发团队成员之间有效的交流、沟
通与协作，比单纯的编程能力更为重要。人与人面对面的交流，是最有效、最迅速的交
换信息的方式
可以工作的软件重于面面俱到的文档
过多的文档需要开发人员花费大量时间来维护。文档应该是为程序服务的，因此应
当短小精悍、易于维护，而且主题突出。敏捷方法认为最根本的文档就是源码。
客户协作重于合同谈判
客户对产品的需求是不断变化的，试图在合同中规定项目的细节和进度显然无法应
对不断变化的需求。只有开发团队和客户之间真诚的协作，加上频繁的客户反馈，才能
...