2007年12月26日

敏捷精灵日记13

[敏捷精灵日记]

  • 正确衡量生产力的公式:生产力=已经完成的工作量 – 用于修正Bug的工作量 – 用于修正错误设计的工作量
  • 任何想在短期内迅速提高生产力的想法都是杀鸡取卵的自杀式行为。
  • 任何时候,工作超过40小时,都需要恢复期,无论你怎么调整; 一周35-40小时可以这样安排:每天工作10小时,持续四天,然后休息三天。上述“压缩工作周”,不仅可以减少缺勤,在某些情况下,可以提高生产力10-70%
  • 每周四天工作制会比五天工作制效率更高。
  • 短期不超过3个礼拜的冲刺会临时提高生产力, 团队可以有策略的选择加班,可以完成最近的最后期限;加班后,生产力会有同等程度的降低,应该根据这个因素马上调整计划
  • 按照项目划分成跨功能的小团队;对于大的项目,利用’Scrum-Of-Scrums’把小团队联系在一起;制定关于创建团队、划分大团队、团队间人员流动的流程/规则
  • 混合团队会比单一团队效率更高
  • 好的管理人员会想办法鼓励团队去创新,会选择预留一定时间让团队去思考如何创新,而不会压榨员工的每一分钟。


阅读详细......

2007年12月19日

敏捷精灵日记12

[敏捷精灵日记]

  • 拥抱变化(Embrace the change)

无论是多么明智,多么正确的决定,也有可能在日后发生改 变。因此,团队要能够充分理解我们的利益干系人(Stakeholder)和客户代表为什么经常提出新的需求和设计要求,一句话,就是心中有数“唯一不变 的是变化”。团队更要信任利益干系人(Stakeholder)做出的每次决定和需求的调整都是将产品开发推向更正确的发展方向,新变化将进一步降低风 险,实现团队最大化利益,理解这是适应市场变化的必然行为。而在接受变化的同时,我们应该积极的向利益干系人(Stakeholder)和客户代表反映实 现活动中暴露出来的可能的设计缺陷和错误。在实际工作中,团队成员应该用优先级制度来划分事情和目标先后顺序,在迭代周期内对于还没有最终决定的设计方案 可以予以后来实现、测试,不用急于投入资源展开全面的开发、测试活动。这样一来,开发测试团队也会人员也将更加适应,真正拥抱变化。

  • 对一个项目开发来说,release (发布)拥抱变化。对于一个sprint/iteration,要拒绝变化。sprint计划前,product backlog都可以变化。

  • ScrumMaster需要对团队作出承诺,让团队感受到有人全心全意关注其工作,在任何情况下提供保护和援助。
  • ScrumMaster使团队在Sprint过程中免受干预
  • 教授产品负责人如何实现投资回报最大化,以及如何利用Scrum达成目标
  • 在影响Scrum正常实施的众多因素中,在sprint过程中加入新需求,大部分人都很难很难抵御这样的诱惑,是scrum的第一杀手。
  • 在一个Sprint执行过程中,如果遇到一些问题导致Sprint的原始目标不能实现,此时需要及时地 调整目标。如果不愿意调整目标,任意延长sprint的时间,就严格违反了Sprint的Time-Box特性,以后大家再遇到问题时,会自然而然的想再 延长Sprint,那么Sprint快跑的意义也就不存在了。
  • 从另外一个角度讲,如果急于看到结果而压缩sprint的时间,可能得到一定的效果,但总体上会消耗的更多的资源,让团队疲惫不堪,造成生产力低下。

阅读详细......

2007年12月15日

敏捷精灵日记11

[敏捷精灵日记]

  • 精益软件开发的七大原则:
    1. 消除浪费(eleminate waste)
    2. 强化学习,鼓励改进(Focus on learning)
    3. “注重质量”build quality in
    4. “推迟承诺”defer commitment.
    5. “尽快交付”deliver fast
    6. “尊重员工” respect people
    7. 优化整体 optimize the whole


  • 准时化开发 = 持续集成 + 迭代开发 + 多次交付。
  • 零库存 = TDD + 每次迭代都给出可以发布的版本。


阅读详细......

2007年12月12日

什么是敏捷软件开发?

敏捷软件开发不是一个具体的过程,而是一个涵盖性术语(umbrella term),用于概括具有类似基础的方式和方法。这些方法,其中包括极限编程(Extreme Programming)、动态系统开发方法(Dynamic System Development Method)、SCRUMCrystalLean等,都着眼于快速交付高质量的工作软件,并做到客户满意。

敏捷软件开发又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于"非敏捷",更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重做为软件开发中人的作用。

词源

敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者(他们发起组成了敏捷联盟)的聚会。

价值观

雪鸟会议共同起草了敏捷软件开发宣言。其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述:

人和交互重于过程和工具。

可以工作的软件重于求全责备的文档。

客户协作重于合同谈判。

随时应对变化重于循规蹈矩。

其中位于右边的内容虽然也有其价值,但是左边的内容最为重要。

原则

宣言中还包括以下原则:

对我们而言,最重要的是通过尽早和不断交付有价值的软件满足客户需要。

我们欢迎需求的变化,即使在开发后期。敏捷过程能够驾驭变化,保持客户的竞争优势。

经常交付可以工作的软件,从几星期到几个月,时间尺度越短越好。

业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。

围绕斗志高昂的人进行软件开发,给开发者提供适宜的环境,满足他们的需要,并相信他们能够完成任务。

在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

可以工作的软件是进度的主要度量标准。

敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。

对卓越技术与良好设计的不断追求将有助于提高敏捷性。

简单--尽可能减少工作量的艺术至关重要。

最好的架构、需求和设计都源自自我组织的团队。

每隔一定时间,团队都要总结如何更有效率,然后相应地调整自己的行为。

对比其他的方法

敏捷方法有时候被误认为是无计划性和纪律性的方法,实际上更确切的说法是敏捷方法强调适应性而非预见性。

适应性的方法
集中在快速适应现实的变化。当项目的需求起了变化,团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.

对比迭代方法

相比迭代式开发两者都强调在较短的开发周期提交软件,敏捷方法的周期可能更短,并且更加强调队伍中的高度协作。

对比瀑布式开发

两者没有很多的共同点,瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等。

瀑布式的主要的问题是它的严格分级导致的自由度降低,项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

相对来讲,敏捷方法则在几周或者几个月的时间内完成相对较小的功能,强调的是能将尽早将尽量小的可用的功能交付使用,并在整个项目周期中持续改善和增强。

有人可能在这样小规模的范围内的每次迭代中使用瀑布式方法,另外的人可能将选择各种工作并行进行,例如极限编程。

敏捷方法的适用性

在 敏捷方法其独特之处以外,他和其他的方法也有很多共同之处,比如迭代开发,关注互动沟通,减少中介过程的无谓资源消耗。通常可以在以下方面衡量敏捷方法的 适用性:从产品角度看,敏捷方法适用于需求萌动并且快速改变的情况,如系统有比较高的关键性、可靠性、安全性方面的要求,则可能不完全适合;从组织结构的 角度看,组织结构的文化、人员、沟通泽决定了敏捷方法是否适用。跟这些相关联的关键成功因素有:

组织文化必须支持谈判

人员彼此信任

人少但是精干

开发人员所作决定得到认可

环境设施满足成员间快速沟通之需要

最重要的因素恐怕是项目的规模。规模增长,面对面的沟通就愈加困难,因此敏捷方法适更用于较小的队伍,2040人或者更少。大规模的敏捷软件开发尚处于积极研究的领域。

另 外的问题是项目初期的大量假定或者快速收集需求可能导致项目走入误区,特别是客户对其自身需要毫无概念的情况下。与之类似,人之天性很容易造成某个人成为 主导并将项目目标和设计引入错误方向的境况。开发者经常能把不恰当的方案授予客户,并且直到最后发现问题前都能获得客户认同。虽然理论上快速交互的过程可 以限制这些错误的发生,但前提是有效的负反馈,否则错误会迅速膨胀。

方法列表

目前列入敏捷方法的有:

软件开发节奏,Software Development Rhythms

敏捷数据库技术

AD/Agile Database Techniques

敏捷建模,AM/Agile Modeling

自适应软件开发,ASD/Adaptive Software Development

水晶方法,Crystal

特性驱动开发,FDD/Feature Driven Development

动态系统开发方法,DSDM/Dynamic Systems Development Method

精益软件开发,Lean Software Development

Scrum

测试驱动开发,TDD/Test-Driven Development

XBreed

极限编程,en:XP/en:Extreme Programming


阅读详细......