论道WP(三):应用程序栏
作者通过具体翔实的例子介绍了Winodws Phone 7中应用程序栏的使用方式。
该内容已经被标记书签!
标记书签错误,请重试!

作者 Mike Cohn 译者 郑柯 发布于 2011年3月4日
本文是《敏捷宣言》10年系列纪念文章之一,该系列文章将陆续在InfoQ上发布。
自打《敏捷宣言》发布以来,发生了很多变化。回看当时,宣言涉及的各种流程,包括极限编程、Scrum、动态系统开发方法(DSDM)、特性驱动开发以及其他流程等等,仅仅处于软件开发世界的边缘地带。因此,当时很容易认为这些流程不适于开发真实世界的应用。
我知道这一点,因为我当时工作的公司就是这么想的。在宣言出现前几年,我正在为一个大型企业集团某个分部的软件开发组主持Scrum开发。当时所有分部与开发相关的VP聚在一起,讨论在所有的分部中共同采纳一种通用的开发流程,我无法说服其他VP认真考虑Scrum。尽管我所在的分部取得的成果最为显著,而且我们将之归功于我们在数十个项目中使用的Scrum方法,我还是无法让其他人产生即使是尝试Scrum的想法。
即使是在我所在的分部中,我们也在质疑使用Scrum的决策。毕竟,当时统一过程(Unified Process)才是最热门的话题。人们都觉得:如果你没有使用统一过程,也许你应该用用看。我们用Scrum取得了巨大的成功,但是大家还是充满怀疑——如果使用一种完整的方法论,而不是这种称为Scrum的玩具式过程,我们是不是能够更加成功?毕竟,我们不知道还有谁也在用Scrum,而“敏捷软件开发”这个词汇当时还不存在。当整个世界似乎都在转向“统一过程”的时候,如果你是唯一没有使用的,很难不产生疑问。
在此后一个二月的早晨,我收到一封来自Ward Cunningham的邮件,其中提到:“看看我是如何度过前几天的。”他提供了一个网站链接:agilemanifesto.org,还有一张粗糙的照片,画面上是一些人围着一个白板。但是那个网站像一道闪电击中了我——说到底,我们并不孤独。突然,我知道至少有17个人跟我们有同样的感觉。后来,日复一日,越来越多,每个人都签上了各自的名字,并在agilemanifesto.org上添加了一个团结一致的简短宣言。
我们所做的事情起了一个名字——敏捷,随之像我们这样的人从各处跳了出来。“没错,我们也是那么做的。”这句话成为了早期敏捷人士的标志性语句,我们都发现自己并不孤独。
现在,十年过去了,事情发生了180度的转变。如果你现在没有使用敏捷,或是没有转向敏捷,你可能会觉得自己应该这么做。十年以来最大的变化,是人们在讨论应该使用哪种流程时,敏捷现在也有其一席之地。如果今天我是某个大型企业集团负责软件开发的VP,并且提议其他分部的VP采纳敏捷,他们不会摆手拒绝。敏捷,虽然有多种形式,现在已经成为可行的、可信赖的另一种方案。它也许不适合所有的公司或是项目,但是大家不会对其一笑置之。
十年之间,敏捷从被一笑置之到成为可信的解决方案。敏捷接下来会走向哪里?也许会发生两件事情。首先,我希望所有的“品牌”都消失。不再有Scrum,不再有XP,不再有看板或是精益,没有动态系统开发方法,也不再有水晶开发,只剩下敏捷。在二十年前面对对象的发展过程中,我们看到了这个过程。我们曾有很多种建模方法和途径,它们来自Rumbaugh、Booch、Meyer、Jacobson等人。这些差异最终被放在一遍,现在我们只有对象和UML。
下一个变化,我希望看到(而且预测必将发生)的是:在接下来的10年,面向对象世界中发生的事情会再次出现:我们不再讨论敏捷。不久前我们不再讨论对象了,因为它们已经胜出。没有人再会参加针对面向对象的大型辩论。当然,还有有些应用我们不使用对象,比如有严格性能要求的应用。也有些项目是用非OO语言开发的。但即使在这些案例中,我也怀疑开发的代码仍然收到对象的影响。我希望敏捷也能达到这一点,我们不再讨论敏捷。不再说“敏捷软件开发”,我们仅仅说“软件开发”,当然一定是敏捷的。没有人会问我我编写的Ruby代码是否面向对象。毋庸置疑。我希望某一天没有人问我项目中是否使用了敏捷,毋庸置疑。
再过十年,我希望有人让我回顾《敏捷宣言》发布后的二十年。我希望:到时候它已经称为被人遗忘的文件,就像《大宪章》【译注】一样。没错,那份落满灰尘的东西。我的生活仍然被《大宪章》影响,而且我最近被召唤作为陪审团成员,正提醒了我这一点,但是我基本上不会想到它。我希望《敏捷宣言》有类似的命运。当我十年后回顾敏捷软件开发时,我希望我们不再称其为敏捷。我希望我们不再给其赋予任何特殊的名字,而是成为日常的实践。
关于作者
Mike Cohn是Mountain Goat Software的创始人,他在其中教授并指导Scrum和敏捷开发。他是《Succeeding with Agile: Software Development with Scrum》、《敏捷估算和规划》以及《用户故事与敏捷方法》的作者。Mike拥有25年经验,曾是多家公司的技术高管,公司规模包括初创公司和财富40。Mike常常为杂志写文章,而且频繁在各种会议上演讲,Mike还是Scrum Alliance和Agile Alliance的创始成员。可以通过该网址联系到他。
【译注】:大宪章(拉丁文Magna Carta,英文GreatCharter)是英国于1215年订立的宪法,用来限制英国国王(主要是当时的约翰)的绝对权力。订立大宪章的主要原因是因为教皇、英王约翰及封建贵族对皇室权力出现不同的意见。大宪章要求皇室放弃部分权力,及尊重司法过程,接受王权受法律的限制。大宪章是英国在建立宪法政治这长远历史过程的开始英国是一个没有成文宪法的国家。他们的宪法是由一系列的文件和法案组成,其中具有奠基意义的一份,就是在1215年6月15日,由英国国王与贵族们签订的《大宪章》。这张书写在羊皮纸卷上的文件在历史上第一次限制了封建君主的权力,日后成为了英国君主立宪制的法律基石。
查看英文原文:Reflections on the 10 Years Since the Agile Manifesto
呵呵,无病呻吟,正确的软件开发方式一致都存在,也一致都有懂行的人在用,也开发出了很多优秀的软件。到是一些咨询公司没事就整新名词忽悠来、忽悠去。。。无聊呀
新生事物,从无到有不容易。敏捷确实给软件工程提供了实践基础。研究过就喜欢了。
大师,你暴露啦,哈哈。
大师不作为,人家只好花钱请咨询咯,外来和尚好念经嘛。
我认为敏捷和面向对象一样,都是更符合客观实际的一种思维方式的转变,是理想主义(瀑布式)向现实主义(敏捷)的一种转变。
到现在我公司还有人认为敏捷这套就是拿来忽悠人的,拒绝TDD,拒绝敏捷相关的任何东西
到现在我们公司上层还是不知道敏捷是什么。而且当我提议时,几乎断然拒绝。理由是,这样没规划的做法,风险太大
其实引进敏捷的初期还是很痛苦的,太多不习惯
而且,“没有银弹”,所以不要为了敏捷而敏捷
在小范围尝试,拿出切实效果就有说服力了。不用和领导上来说敏捷这样的名词,肯定会以为忽悠他们,就做一些实际的事情,之后争得他们仍可就行。就像本文作者说的,让这种做法成为习惯,开发软件就应该这么做。
在多线程并发编程中Synchronized一直是元老级角色,很多人都会称呼它为重量级锁,但是随着Java SE1.6对Synchronized进行了各种优化之后,有些情况下它并不那么重了,本文详细介绍了Java SE1.6中对于锁的性能优化,以及锁的存储结构及升级过程。
本次分享将首先介绍现代富文本编辑器的组成和实现,然后结合UEditor的开发过程,与参会者分享UEditor在设计和实现的过程中,所涉及到的核心功能的细节实现。
本次演讲视频录制于百度技术沙龙。
我们所开发的应用程序大多都需要提供一个图形用户界面(GUI)。关于GUI应用的架构设计,已经有了Form & Control、MVC,、MVP、 Passive View等多种模式。模式可以帮助我们建立优雅的架构,但前提是弄清楚模式的应用场景。弄清楚GUI应用面临的设计上的问题,有助于我们正确的挑选设计方案。
MongoDB是一种非常易用的NoSQL方案,Brian C. Dilley在这篇文章里介绍了MongoDB的优劣势,并介绍了MJORM项目。MJORM用于MongoDB,是一个没有注解的Java ORM库。
随着网络基础设施的逐步成熟,从RPC进化到Web Service,并在业界开始普遍推行SOA,再到后来的RESTful平台以及云计算中的PaaS与SaaS概念的推广,分布式架构在企业应用中开始呈现出不同的风貌,然而殊途同归,这些分布式架构的目标仍然是希望回到建造巴别塔的时代,系统之间的交流不再为不同语言与平台的隔阂而产生障碍。
精益软件开发方法因其对市场和交付的重视和在各种场景下体现出的适应能力正在获得广泛的关注。特别是在精益创业(Lean Startup)渐渐兴起和技术日新月异的今天,其"极端"的思想也变得越来越必要和可行。 InfoQ就此主题对他做了深入的采访。
8 条回复
关注此讨论 回复