Category Archives: 敏捷软件

敏捷软件

敏捷软件的十二条原则

update1:关于working的含义,官方是“可工作的”,意在描述软件的一种状态,即能在一定程度上满足用户需求并可以正常运 行。而在机械制造行业,working用来描述一个零组件的设计状态,凡是没有经过审核发布用于实际生产的零组件,都可以称为working part。而这篇宣言里的working,我想也包含了两层意思,一是可工作,二是仍然处于设计状态中的,没有最终确定的阶段性的一个版本。

在阅读这十二条原则的时候,我参考官方的中文翻译版本,对英文的原文有些不同的理解,于是对照如下(未加粗字体是官方的中英文)

We follow these principles:
我们遵循以下原则:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
我们最要紧的事,就是尽快和不断地向客户交付有价值的软件,使他们满意。

Welcome changing requirements, even late in development.
欣然面对需求变化,即使在开发后期也一样。
Agile processes harness change for the customer’s competitive advantage.
为了客户的竞争优势,敏捷过程掌控变化。
为了客户的竞争优势,通过敏捷过程把控这些变化。

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
不断地交付可工作的软件,可以是一两周或者一两个月,周期要尽量短。

Business people and developers must work together daily throughout the project.
业务人员和开发人员必须相互合作,项目中的每一天都不例外。
项目自始至终的每一天,业务人员和开发人员都必须通力合作。

Build projects around motivated individuals.
激发个体的斗志,以他们为核心搭建项目。
围绕积极的团队成员,构建项目。
Give them the environment and support they need, and trust them to get the job done.
提供所需的环境和支援,辅以信任,从而达成目标。
为了达成目标,给他们提供所需的环境和支持,并充分信任。

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。

Working software is the primary measure of progress.
可工作的软件是进度的首要度量标准。
不断改进的软件是进度的首要度量标准。

Agile processes promote sustainable development.
敏捷过程倡导可持续开发。
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
责任人、开发人员和用户要能够共同维持其步调稳定延续。

Continuous attention to technical excellence and good design enhances agility.
坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。

Simplicity–the art of maximizing the amount of work not done–is essential.
以简洁为本,它是极力减少不必要工作量的艺术。
必须简洁,它是挖掘未完成的工作的一种艺术。(从另一个角度看,只有减少了不必要的工作量,才能发现更多需要完成而未完成的工作)

The best architectures, requirements, and designs emerge from self-organizing teams.
最好的架构、需求和设计出自自组织团队。

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
团队定期地反思如何能提高成效,并依此调整自身的举止表现。
团队定期反省怎样提高成效,并相应地调节和校正自身的表现。

敏捷软件

从FireFox升级看敏捷软件(二)

面向互联网的软件研发有很多特点,例如:

1. 面向的用户不是某个人或组织,而是整个互联网的所有网民;

2. 软件的研发工作总是由研发单位自行发起,而不是软件的用户,所以不需要双方订立研发合同;

3. 软件的需求仍然由用户决定,但用户很多时候并不知道自己有哪些需求;

4. 用户多种多样,互联网应用水平参差不齐;

5. 不仅要满足基本的应用需求,还需要具有易用性,美观,轻量,易获取等潜在需求;

6. 最终用户无法直接面对面和研发单位沟通功能需求,而需要通过其他有效渠道进行反馈;

7. 用户需求多样,容易变化,部分有时效性,受舆论、文化、时事、金融等各行各业的影响,新需求层出不穷,总之非常复杂;

8. 大多数用户需求均来自个体,很少有专业领域的软件研发;

9. 同样需要专业的项目管理控制研发,在保证软件质量的前提下,协调周期、范围、成本等各方面的平衡;

10. 软件发布后,必须根据用户的反馈不断进行修正,并尽快发布新版本;

11. 软件需要适应多种系统平台;

12. 软件需要遵守法律法规;

13. 软件研发完成后,需要公开发布,无法保密,因而也很容易被拷贝;

14. 软件的公开发售以及开源组织、黑客组织的努力,使竞争门槛降低,促使大多数软件低价甚至免费;

15. 通常都要求用户接入互联网才可以获得与使用该软件;

16. 用户根据软件的实用性等因素判断是否愿意使用该软件,是否愿意遵守软件使用协议;

17. 软件的使用率不再由使用合同来保证,而需要通过专业的运营来维护;

18. 软件的价值不是简单地以软件的功能来衡量,而是以软件用户的数量、粘性等其他多种指标来衡量;

19. …。

这种状况使得软件研发必须积极面对需求变化,响应及时,快速迭代。

在敏捷软件的概念里:

个体和互动 高于 流程和工具

流程和工具是为了提高多人协作的效率和改善工作效率,降低沟通成本;而在实际工作中,当需求变化的不确定性导致很难提炼固 定不变的流程,以及很难保证团队成员随时拥有统一熟练的工具时,或者流程经常被打乱,以及使用工具的操作时间大于直接沟通的时间时,成员个体的自动自发的 积极态度和成员之间的快速互动就成了重点。如果想到流程和工具的设置,起初也是为了个体间能积极快速互动的话,就不难理解了。

工作的软件 高于 详尽的文档

编写文档通常要占用很大一部分时间。为了快速将可使用的软件交付用户,并使用户快速上手,编写一份详尽的使用文档并不是明 智之选;相反,能让用户在无需阅读文档的情况下,就能一目了然地明白和掌握软件的使用方法,是软件是否可工作的一个重要目标。同时,这里的用户还包括团队 内的测试人员等人。

客户合作 高于 合同谈判

没有研发合同,也没有使用合同,一切全凭用户自愿来使用软件。当出现问题时,解决问题的方法不是拿合同上模棱两可的词语互 相推诿,而是和用户共同积极地面对问题,分析和解决掉。尤其对于一些非常热心主动帮助测试bug的用户,研发人员花费时间与其交谈,了解和确认bug,这 是经常发生的事情。

响应变化 高于 遵循计划

互联网的信息快速传播的特性,使得网民对于信息的快速更新也表现出很多集体无意识、盲目崇拜、一窝蜂等无法预测的行为,而 这些行为里潜藏了很多需求。把握这些需求和变化的能力极大地影响了软件的使用率,也就是软件的价值;因此,研发计划虽然仍然会有,但及时响应各种变化的能 力却更为重要。

由此可见敏捷之重要。

无觅相关文章插件,快速提升流量