Android无卡版本与多版本管理

大部分客户都是机卡分离的,但某些特殊的网络就要求是机卡一体的(即无卡版本)。我们的基于MTK6517+CBP7.2C的方案,原本是不支持无卡版本的。最初的方案是VIA修改CDMA端Modem,只要RIL的Interface不变,理论上应该可以直接使用的。这样尝试后,发现在实验室手机连接8960可以找网被叫,但无信号显示,也无法主叫。在Android启动的时候,正常情况下会查询RUIM卡的信息,比较重要的如ICCID,但无卡版本找不到,所以上层系统会认为机器没有插卡不会打开协议栈。解决办法法是在获取ICCID的时候,添加判断,若为空则强制付个值,这样流程可以继续,信号可以正常显示。另一个问题,无法显示卡的名称,正常情况下,卡中的一个文件会记录卡默认的名称如”联通新时空”,但无卡版本获取不到,解决办法是,通过读取写入手机当中的MCC,MNC,在手机中查表匹配出对应的名称。最奇怪的一个问题,无卡版本进入设置当中的”移动网络”设置项后,会自动掉网,且不可恢复。分析代码发现,此项与网络设置当中的System Select有关,VIA结论是客户提供的PRL不规范,其中Roming Indicator全为零,应该为1才对,修改PRL后问题解决。

  我们的E760项目,GSM+CDMA(450M )己做了差不多十多个国家,缅甸,乌兹别克斯坦,乌克兰,摩尔多瓦,德国,瑞典…,基于同一Base版本,要做出大量的分支,对之后的代码修改,同步,版本编译发布管理都提出了相当的挑战,解决办法—图形化。


 
 

KunLun阶段总结:代码提交,Bug管理,编译遇到问题及改进后的流程

我们的KunLun项目己进行了近半年,Android项目的开发需求,Bug数量,第三方,及要沟通解决的问题都较非智能机多了很多,这段时间总结了之前项目中有关代码提交,Bug管理,多版本编译几个方面遇到的问题,及针对这些问题的改进方法.目的是尽量减少人为出错的可能,提高效率,确保项目进度按时完成。

1.代码提交

原有流程: 原有问题: 代码审核人或配置管理员不在,导致漏提,忘提,找不到提交记录等问题,原有是直线型流程,任一点出问题都导致代码提交失败.

(more…)

项目经理与软件PM的分工协作

      不知道大家所在的软件公司是怎么分工的,项目经理很多,软件PM倒只是在我们公司有.看管理类的书籍,杂志,文章上也没提及此职的.软件PM的定位众说纷纭,我的理解是一个项目软件开发部分的负责人,在项目经理制定的进度内保证开发工作的顺利完成,对项目经理负责.他们之间的合作很重要,以下以一天的工作为反例,说明他们的分工与合作的重要性.

一.引子
     软件PM的一天的工作 :  H5生产软件镜像的制作–2h           
                                                Brew的移植开发–2h
                                                Brew在新版本的合成–3h
                                                电信反馈Bug的分析–2h
     项目经理 : 因电信版本号的问题一天找软件PM不下10次,平均40多分钟一次.

二.问题
      A : 事务性的工作严重影响了软件PM的开发工作
      B : 过多的内耗严重影响了开发的时间与精力 

(more…)

以顾客为中心的研发流程

传统的研发和创新对企业到底有多大的价值?哥伦比亚大学商学院教授拉里·塞尔登和沃顿商学院的研究者伊恩·麦克米伦用了好几年的时间,对标准普尔500家公司进行了研究。结果表明,尽管许多公司斥巨资于传统的产品和技术研发,但这些投资并没有得到市场的认可。而对传统的产品和技术研发投入极少、更多把重点放在顾客研发工作上的公司,其市盈率始终高于市场平均水平。

由此,他们得出了这样一个结论:投资者并不认为公司传统的研发和创新能够在未来为企业带来滚滚财源。为了提高企业的市场价值,企业应该改变它们原来的研发模式,采纳他们提出的“顾客中心型研发和创新”。

“顾客中心型研发和创新”的核心是一套严格的顾客研发流程,它包括以下3个阶段:

阶段1:建立和发展核心顾客
在这个阶段,企业要确定自己的核心顾客是哪些人,并制定出相应的价值主张,使公司的产品或服务与顾客的期望更加合拍。
比如,20世纪80年代,世界著名行李箱厂商Tumi公司将那些经常乘飞机出差的男性商旅人士选定为它的核心顾客,这些人更看重的是打包、开包的便利性,而不是行李箱包的耐用性、款式或大小。因此,Tumi公司设计了尽可能方便打包和开包的行李箱。

阶段2:延伸
这个阶段包括公司能力的延伸和细分市场的延伸。
公司可通过延伸公司能力,为现有的核心顾客开发出新的产品。比如,Tumi公司在1991年为经常乘飞机出差的男性商旅人士开发了便于携带手提电脑的行李箱。
要延伸细分市场,必须发掘潜在的“光环”顾客,也就是与现有顾客存在类似需求的顾客。比如,Tumi公司在1999年就把自己的核心顾客延伸到了女性商旅人士领域。它根据男性与女性在需求上的细微差别,开发了方便女性顾客携带衣服、鞋子、化妆品和钱包的行李箱。

阶段3:开拓
首先是能力开拓。公司先要确定自己要发展哪些新的能力,要开发哪些新的产品或服务。例如,Tumi公司发现,在国际商旅人士中,顾客携带的IT产品越来越多,而Tumi可以为这些顾客提供连通性产品,使他们在全世界都能使用IT设备。
然后是细分市场开拓。要开拓的细分市场应该与公司的核心顾客毫不相关,但是公司可以利用现有的能力满足这个市场的要求。比如,2000年,Tumi公司开始进军年轻男性旅客这个细分市场,并针对该市场顾客注重时尚和精通数码产品的特点,成功推出了款式前卫、颜色炫目的T-Tech系列产品。

在上述所有这些阶段,公司都必须关注:
1、积极地扫描市场,及时发现顾客需求发生变化的征兆。
2、公司的价值主张对顾客的吸引力日益减弱的迹象。
3、尽早发现技术方面的颠覆性变化,以免被颠覆性的技术变革打个措手不及。
4、顾客研发流程的核心人员是一线员工,而不是总部的研发工程师,让最贴近顾客的一线员工参与研发和创新,激发员工的积极性,获得大量的顾客信息。

总之,你越是以顾客为中心,竞争对手就越是不容易了解你的竞争优势,你战胜对手的次数也会越多。而“以顾客为中心”可以精确地定义为:员工们有着“与顾客共赢”的心态。顾客赢了,员工赢了,何愁公司不赢?
 

软件架构文档

     
软件架构文档是企业应用开发过程中的重要一环,理解一个项目中的架构文档的关键是理解它在项目生命周期中所扮演的角色。
一个项目产生架构文档的根本原因是为了交流、分析、记录和保存(比如,跟踪决策过程使之不会随着时间而流失)。一个项目产生的架构文档的数量和类型应当反映该项目为了创造产品所需的交流及分析。
架构文档在项目中用于在上至其管理团队,从架构师或首席设计师到开发者,以及随着时间的流逝,未来的维护者和开发者之间进行沟通所用。仅这个简单的声明就引出了三个问题,它们的答案有助于决定文档的数量和类型。项目中出现了多少疏漏?有多少开发人员在开发产品,他们的水平如何?以及该产品将使用多久?疏漏越多,说明需要更多的文档用来交流管理。开发者越多和他们的开发水平越低,就意味着开发者需要更多的指导。而产品使用时间越长,则需要越多用于和未来该产品的开发者们交流的文档。
架构文档的交流部分包括与管理层,开发者们沟通和在软件生命周期中的交流。分析需求可能来自为了决定产品的质量(包括性能,安全,可靠性等)的内部原因或来自如兼容某些规则或标准的需求。
在这个虚拟研讨会中,InfoQ希望能从顶级的软件架构专家们那里找到软件架构文档的重要性和如何记录架构,特别是在敏捷软件开发环境中。
回答我们问题的小组成员有:
Len
Bass
,SEI的高级技术成员,《Software
Architecture in Practice
》和即将面世的《Documenting
Software Architectures: Views and Beyond
》的第二版 的作者之一。
Grady
Booch,
IBM荣誉科学家,《Handbook
of Software Architecture
》的作者。
Paulo
Merson
,SEI的高级技术成员,《Documenting
Software Architectures: Views and Beyond
》的作者之一。
Eoin
Woods
, Barclays Global Investors应用程序架构组的领导人,《Software Systems
Architecture: Working With Stakeholders Using Viewpoints and
Perspectives
》作者之一。
在使用敏捷和精益开发方法(如SCRUM,极限编程,看板等)的开发团队中,软件架构文档的作用是什么?
Len:架构文档的作用并不因为开发方法的不同而变化。文档并不是唯一的交流方法,在敏捷中如SCRUM或XP面对面交流等方法取代了一部分文档的需求。但并没有替代对于设计决策的详细交流的文档需求。面对面的会议很难正确表达它们。敏捷方法并不能处理跨时间的交流或向管理层的交流。
在敏捷方法中,所减少的文档是面对面交流能够解决的那部分沟通需求,但不会有更多减少。
Grady:对于那些使用更形式化的方法的团队来说其角色也一样。简单来说,记录一个软件密集型系统的架构有如下几个目的:让团队推敲重要决定,去记录组织的重要事件,对于每一次迭代的专门管理提供一些基本资料。对于这些轻量级的方法,架构文档更多地用于反映实际建造的系统,而不是将要设计的系统。
Paulo:软件架构的角色通常来说是为了在不精确且动态变化的需求与可运行的代码实现之间搭起桥梁。
架构文档捕捉设计决策,它是个指导实现(最主要)的部件,能够在早期用于评估所设想的解决方案的方向是否正确,还有助于任务分配和跟踪。但是对于敏捷呢,如果说敏捷开发是架构文档的对立面显然不对。敏捷并不是为了避免设计,而是避免预先大量设计(BDUF)。更深远广泛的架构策略是预先制定的,但许多其他的决策会推迟直到需要时才做。比如说,数据模型经常会被充分的预先讨论以避免之后的大变更。另一方面,在对于那些在下一个版本发布中的要开发的特性,它们的序列图和接口定义文档可以在实现前几天来完成。
敏捷开发者应该是有设计能力的,而敏捷架构师应该是有编写代码的技能的。
因此设计决策的交流就会更短而且更容易聚焦。实践来看是什么样的呢?
  • 多一些图表,少一些散文
  • 设计只要足够编程即可
  • 图表中多使参考已有的架构(或设计模式的应用方式)。具有相似特性或流程的设计可以用很少的文档,因为解决方案能够从参考的设计那里推断出来
  • 使用概图而不是正式的全面的图
  • 设计图被划掉而不是更新,这样好过保留过时的设计。如下图是我经常使用的一个可视化标记
 
Eoin:可能听起来很明显,但是这个问题的回答实际上取决于团队,项目和相关的背景。一个架构描述,如同任何可交付的产品,是需要为了某个目标和受众而创建的,否则只是浪费时间。有时候读者就是创建者本人(为了帮助分析或只是一个备忘录),但是有时候通常会是更广泛的人群,他们对任何重大的交付都有兴趣。
我个人来说,我从来没有发现在敏捷开发和软件架构中有什么巨大的矛盾。即使我知道这并不是每个人的经验……也许只是我比较幸运。我的经验很清楚,不管是敏捷还是其他,简明的架构描述,并随着项目的进度进行增量开发能给开发团队提供一个有用的背景环境。
一个好的项目描述捕获设计的那些从代码看来并不明显的方面(比如部署设计,外部接口或系统监视方法)并且解释这个系统是如何满足它的非功能性需求的(典型的包括硬件,安全和性能的需求)。如果没有人对这些感兴趣,那么就没有必要存在架构描述,但是我发现这很少见。
还有一点值得提到的是架构描述会有很多种形式,在敏捷团队中厚厚的文档常常是有效性最低的那个。重要的是在创建架构描述时你不断收集的信息及进行的分析而不是你所用的文档模版。一个架构描述必须是一个有效沟通的媒介,包括wiki,模型,数据库,电子表格以及一组短小且重点明确的文档都可能是比重量级大型文档更适合捕捉和交流架构设计信息的方式。
当基于DSL(领域特定语言)来记录应用程序的架构文档时有没有特殊的模式可遵从?
Eoin:我还没有在某个生产系统上用过DSL,但是我不觉得实现技术的不同会对我记录架构文档的方式有很大影响。你仍然需要去定义系统环境、功能结构、部署环境、信息结构及运营环境等,而且还要解释非功能性需求是如何达到的。你需要在每个部分(或视图)描述你的设计的基本元素。可能因为实用技术不同而有所不同,但你仍然需要描述一些相同的内容。
Len:如果扩展DSL语言,概要文件和原型,额外的建模语言以及元模型等定义了符号(有的有,有的没有),那么他们会有助于使文档更加简明。如果读者和作者都理解这些额外符号的话就能够减少成本。
Grady:不是的,任何描述软件架构文档的方式的本质是为了让相关者明确他们关注内容的视图。确认视图上的内容取决于领域和开发文化。
Paulo:架构文档包括多个体现系统结构的视图。
用DSL并不影响这些视图,比如部署视图或运行时视图(又叫组件和连接器或进程)。使用DSL使得架构中的模块(或者叫代码)视图更明显,这个视图显示了实现单元,它们如何在模块和子模块中组织的,以及它们之间不同的关联和依赖。在任何一个视图中,标识出描述各种元素的类型很重要。DSL规定了良好定义的的一组元素类型和关系。特别是当DSL和其他语言混用在一个完整解决方案中的情况,在架构文档中标识出元素类型非常重要。在实际中的大部分情况下,概览图就是你需要的全部。因此你使用不同的形状或颜色标识不同的元素类型的时候也标明了在文档中一个长方形和一个椭圆形分别代表不同的意思。而且别忘了也要区分线条和箭头。
DSL经常和自动化工具,类库或代码生成器一同出现。因此明确实现的范围及哪些是由工具实现的也很重要。上下文结构图会有所帮助。当使用代码生成器的时候,要确保生成了哪一类的运行元素以及它们的属性。找出是否单进程/线程,使用何种通信协议,使用什么数据存储机制以及访问质量相关方面,比如安全,性能和互操作性等。我曾经参加用Microsoft
Visual
Studio定义DSL模型的演示,很难忘。但即使你用DSL你也可以用一个通用的建模语言如UML来记录设计。UML概要文件经常用于定义从UML符号衍生来的定义领域相关的符号。
新的动态Java模块规范(比如OSGi)的哪些方面符合软件架构文档的工作?
Paulo:软件架构师们通常关注在架构文档中的模块视图(也叫代码视图)。他们花时间解释在程序包和子程序包中实现单元是如何组织的,模块间如何相互依赖,它们如何按水平或按层次组织的,以及特殊事务的消息流程。创建架构的这个代码视图固然重要,但架构师们常常忽略运行时视图和部署视图。记述这些视图需要对运行环境、平台结构、组建模型很好的理解。运行时视图体现了实现单元如何被转换为线程,进程,Servlet,DLL等其它组件,还体现了数据存储、基础结构服务、外部服务、通信机制(如
JMS,SOAP,http,本地或远程方法调用)等方面。运行时视图允许你来推算运行时特性,如性能、安全及可用性等难以看着程序包和类图就能估计出的部分。部署视图不仅体现了硬件基础架构,而且解释了部件如何打包到一起并部署的。这些视图有助于能够帮助对服务能力,性能,安全性和其他属性的估计。
现在让我来解释清楚你的问题。如果你在架构一个OSGi应用程序,你应该理解在OSGi运行环境和它们的生命周期中都有哪些种组件。我的唯一OSGi经验是开发一个Eclipse插件,它有点隐藏OSGi框架的意思,你只需要创建声明(manifest)文件。但让我问OSGi应用程序架构师们一些问题:
  1. 你的架构文档体现了每个部署包里都有什么java包/类吗?
  2. 在运行时,对于每一个包都有对应的线程吗?或者每一个包的服务都有一个独立的线程吗?
  3. 对于以上任何一种方式,你的文档都列明了这些线程吗?
  4. 每一次服务调用都创建一个新的线程实例吗,类似于每一个http请求同一个servlet的多线程实例?
  5. 如果我想要部署一个被多个包调用的jar文件,文档里能知道我应该把它放哪吗?
  6. OSGi的发布-订阅机制发送的事件是同步的还是异步的?
  7. 你的运行视图区分了调用的类型和使用的协议(比如http)吗?
  8. 文档体现了服务注册的交互吗?这肯定会影响可用性,性能和安全。
第一部分的答案是创建架构的运行和部署视图来反映运行环境的组件类型,通信机制和基础服务。
第二部分的答案是关于易变性。我们的结构文档模版中有专门关于它的一节。在变更指导部分我们描述了让系统变得可配置的解决方案的机制。以下是一些变化机制例子:
  • 替换提供同样接口的组件
  • 组件复制
  • 组件可选的包含(插件和附件)
  • 构建时组装配置
类似于OSGi的框架给了你这些开箱即用的变化机制。架构的运行时情况可能会随组件的不同而变化。架构文档应该在变更指导中记录什么组件会变化,有什么可选项或配置及其影响,什么条件下可能会触发特殊的选项,和每个选项的绑定时间(对于OSGi可能是运行时,但也可能是构建或部署时)。
Eoin:任何让一个系统的组件结构在运行时(就设计时而言)更加可见是一件很好的事情,现在当我们从设计进行到代码时,我们丢弃了很多这样的信息(因此需要一个架构描述–参见前述答案!)我最近在学习OSGi并且看起来它解决了这个高度关注的问题,帮助系统功能结构更容易被理解。同样的,像OSGi这样的模块技术只是帮助展示了架构结构的一种,而在实践中,还需要考虑其他种类。因此即便它们可能提供了很多其他技术上的好处来证明他们自己,它们依然不允许我们放弃我们的架构描述。
Len:一个标准的视图软件架构是模块分解视图。每一个视图中的模块都代表了一个封装范围。OSGi是指定封装范围的一种方式,它很适合模块分解视图。
Grady:OSGi主要关注
Kruchten所说的实现视图,也就是与组件的物理打包及在随后为部署视图做准备相关的事情。它们处理了这些组件生存的物理拓扑结构。这样,从一个架构的角度来,OSGi只是一个特殊的封装打包技术。
UML的特性如”配置文件” 和
“模版” 是如何帮助记录软件架构的?
Grady:这些是主要的UML可扩展性机制……但是以我的经验来看,基本的UML语言已经足够记录大多数软件集约型系统的架构核心部分了。
Paulo:UML最初是为了给面向对象系统建模而形成的,现在被看作通用的建模语言。意味着同样的符号能够被用来代表很多不同的事物。比如,一个叫Dispatcher的UML组件可以很好地代表Java
EE中一个Servlet或在OS内核的一个线程。你可以定义模版来使UML符号专门化,如果你知道你的一些组件将会是servlet,就把它们模版化为<<servlet>>。
如果使用正确的话,模版会自动的把你的UML图表达得更清楚。UML自带一些标准模版,但我们也可随意创建自己的模版。一个UML配置文件是一组有机组合的UML模版。UML中有一个Java
EE的配置文件,一个.NET的配置文件,一个SOA的,一个系统工程的以及更多其他的配置文件。 重用或重新创建模版及配置文件都是个很好的主意。
Eoin:一句话,我认为他们是救生圈。
UML2的扩展特性是很突出的特点之一,并且该特点也让UML可用于很多不同的领域。很好利用它的人很少,但是现代UML工具已经最终支持了语言的扩展能力并且能用模版和配置文件来调整UML使之适合更手头的工作所使用特定的语言。只需要很少工作,你就能定制一个定制化UML版本专门用于表达你的架构中的那些结构。其结果是有了一个基于UML的架构描述语言和现成的工具支持,因此能克服多数基于研究的ADL语言(如xADL,Acme或Darwin)引进(采用)时的主要障碍之一。
有一些新规范描述了在SOA中进行服务设计时的UML概要文件和元模型,比如面向服务架构的建模语言(SoaML)。在使用SOA和云计算架构模型的应用程序中架构文档应该如何来做呢?
Eoin:我的观点是SOA和云计算是相对独立的技术(即使一个能让另一个更容易)。SOA是一种架构风格,它指导你将系统设计成一组松耦合的通信服务;云计算是一个部署模型,它通过运行时平台的虚拟化来简化系统所驻存服务器的提供,运维和管理。他们都是与位置独立相关的技术,但是从不同角度解决该问题。比如DSL,我并不认为这些技术从根本上改变了你需要从架构描述中捕获的内容或者最多需要捕获多少。然而,就像我们上面所讨论的,定制型的建模语言(如SoaML)肯定有助于让记录某些架构类型的过程更加直截了当。
PauloSOA是一个架构风格,能够用很多技术来实现,比如SOAP
Web服务,REST,消息系统,BPEL和ESB。
我认为在实际中当你创建一个基于SOA的架构时候,很快你就要明确你将要使用的技术。
比如,我认为如果在SOA设计中一个服务提供商组件被模板化为<<dll>>或者<<servlet>>而不是通常的<
<participant>>,对于读者来说这就更加一针见血。想一想,软件开发者们不得不不断跟进新的编程语言、脚本语言、技术、开发框架、设计模式、IDE和插件、建模工具以及开发技术的增长速度。
作为一个软件开发者,如果UML概要文件本身很简单,且包含了我已经熟悉的解决方案的元素模板,那我就愿意去学习它。我认为一个技术无关的UML概要文件(比如SoaML)受到广大架构师的欢迎是很难的。如果你用的建模工具支持它的话,熟悉这个配置文件当然非常重要。不管有没有UML概要文件,要正确记录采用SOA、云计算、OSGi、P2P或其他架构方式的应用程序,关键是要包含一个用于明确表达该方式的特定的元素类型及关系类型的架构视图。
Grady:没错,它关系到哪些是重要的设计决策的决定。在选择使用服务的系统中,消息本身的设计(不只是点对点的服务)是非常重要的(但也经常被忘记)。在云计算的场合(顺便提一下,这个词汇在当下更迎合市场而不是技术),更多关注的是部署视图的元素。
哪些是软件架构师们在记录他们的软件架构时需要牢记的最佳实践和“陷阱”(gotchas)?
Len
  • 软件架构师们需要牢记生成文档的目的,过度或不足都是对文档目的错误判断的表现。
  • 项目并不是使用文档作为经年沟通的最佳决定因素,因为随着时间的消逝,大部分项目组成员将不再担任维护和升级的工作,文档是否存在对于他们没有什么利害关系。
  • Wiki被证明为维护架构文档的一种有效的媒介。
Grady:我想到三件事情:不要过度文档,对每一个迭代保证文档的新鲜度,一定要注意那些不易从代码本身抽取出来的视图及横切关注点。
Paulo
  • 用多个视图来记录架构。
  • 总是记得在你的图表中做记号。
  • 如果你使用了一个设计或架构的模式,请让你的读者知道。
  • 遵循模版。
  • 只有当某些信息对相关的人有用的时候才花时间记录。
  • 记录重要的设计决策的理由。
  • 记得检查你所设计的内容。
Eoin:我想起的第一件事就是 SEI 的《记录软件架构》(Documenting
Software
Architectures)一书中有一个很好的列表,七个“优秀文档规则”,目前也是他们在网站上公开的技术报告之一(SEI-2000-SR4)。
我认为对这个问题的全面回答可能需要一本书,但我认为记录软件架构时必须牢记的一些更重要的以下几点:
  • 记录时有明确的目的。
  • 对明确的受众来创建架构描述。
  • 描述精确,即使你希望抽象。
  • 谨慎定义你使用的符号,这样其他人能够清楚地明白他们的意思。
  • 使用一组软件架构观点定义作为辅助备忘录来指导描述的内容。
  • 不要让文档成为关注的焦点,你所从中获得的过程,内容和交流才是最重要的事情。
  • 迭代地描述架构,经常检查并确保它的正确性及有效性。
在当前的经济和市场情况下,企业中的软件架构文档如何能对该公司有所帮助?
Grady:这是一个把架构像工艺品一样看待的精髓之处,在IEEE软件的架构部分,在我的专栏里我刚写了一篇关于这个主题的好几页的文章。
Paulo:Steve McConnell、Barry
Boehm和其他一些人已经发现源自需求或架构的一些缺陷很难修复。换句话说,一个稳健的架构是有回报的。你的软件架构师有很多经验并且对模式、目前的技术、建模工具和语言非常了解并不重要,因为如果这个家伙创建了一个非常独特巧妙地设计但是开发者们并不理解它,这个项目并不会从这个好架构中受益。软件文档用于交流想法时很容易失败。一个原因是软件工程师通常没有受过写技术文档培训。好的架构文档可以推动:
       架构评估
       软件重用
       成功的采购计划或征求书
       项目管理任务(估计,分配作业,跟踪)
总之,详细程度恰到好处的好文档会提高软件项目成功的几率。
Eoin:如果能被很好的开发及使用,架构描述和一直进行的架构检查能提供给组织更多的在建系统(以及那些已经存在的系统)的可见性来解答以下类似的疑问:
        我们的系统有正确的功能吗(个别地或共同地)?
        我们的系统之间有重复吗?
        我们的系统是持续一致的方式来开发的吗?
        我们有没有过度的复杂、灵活、协作、安全或其他潜在的昂贵系统的特性?

        我们是不是建立了一个不够灵活的系统,它会导致我们接下来会花费很多来改进它?

        我们有没有犯成本方面的错误?
Len软件架构文档是为以上的目的服务的。他们帮助一个企业实现它所期望的对项目监管、强化开发者们交流,强化经年年的交流以及对设计的分析等目标。
你认为软件架构文档的未来会是什么样?
Eoin:我希望未来我们需要较少的软件架构文档因为我们将能够在代码和运行时系统中看到架构!今天我们需要很多架构文档的原因之一是我们手头的技术还不能直接地表示架构结构。我希望能看到我们的架构结构体作为一流的实现结构,而且架构文档能够发展并用于捕捉决策,逻辑和分析,而不只是捕获结构。在达到这一理想的过程中,我希望在DSL和ADL(架构描述语言)领域的工作能更直接指引前进的方向,当我们改善描述语言的时候,我们也在致力于寻找如何把信息准确嵌入运行时系统中的方法。
Paulo:软件架构原则还是个很新的概念,当一个架构师创建出架构文档后,它能很容易地被一个从来没有和这个架构师合作过的一个开发者所理解,实现这一目标还有很长的路要走。达到这个目标的方法是让新的架构师在学校学习软件架构而不是在实战中不断的尝试和出错。这种教育包括软件架构的正确表现形式以让其他人更好地消化和理解。通向良好的软件架构的教育这个方向的重要工作包括:
Grady Booch在软件架构手册方面的工作以及SEI开发的课程和出版物等。
Grady:当下在架构框架相关方面:TOGAF、NEA、DoDAFMoDAFFSAMZachman等已经花了很多精力。好消息是有一个这些框架和方法相关的充满活力的对话在进行中—但是我希望随着时间他们之间会有洗牌或变得更简化。
Len:理想的开发环境是文档只需要按一下按钮就可得到。这需要一个集成的开发、需求管理及项目管理的环境。尽管离它的到来还需很长时间,它依然是一个值得我们努力的目标。

 

项目经理在敏捷中的职责

书里的敏捷不谈管理者的角色,而是谈教练/促进者。本文首先解说了各行业通常意义上的项目经理角色,然后试图将其与敏捷中的教练/促进者角色相对应。在这一探讨中,本文也试图拓宽教练/促进者的工作范围。
在探讨敏捷中的项目经理角色前,让我们首先看看各行业中到底为什么需要管理者。
  1. 人无完人

    人类头脑的工作方式是非常复杂的。世上没有两个脑袋想法一模一样。就像两个指纹绝对不可能重合,两个个体的工作方式也不可能哪怕90%合辙。美妙的自然,创造出如此多而各不相同的个体,实在让人赞叹。但是,商业目标对所有利益相关方都保持“唯一而相同”。这里提到的人,代表所有参与项目的利益相关方,他们来自不同部门,如(a)项目团队成员、(b)业务用户、(c)管理层和出资人。每个项目在每个地方都需要管理人员,从而做到:

    1. 让人们与项目目标保持一致并调优其工作方式。
    2. 发挥人们最佳能力。
    3. 帮助人们保持专注和激励。

      如果项目中每个人都是完美的,那无论什么行业的任何项目都不可能失败,不管是瀑布还是敏捷的软件开发模式,完美的人总能造就完美的项目。
  1. 控制改变

    生活中唯一不变的就是改变。什么事物都会变,不管是有形的(如需求)还是无形的(如人员)。

    1. 需求就像风,总是吹拂(就是改变)。
    2. 人的经验和阅历每天都在改变[比如,我明天的经验比今天将+1天]。这会带来改变,对我的:
      1. 抱负
      2. 技能
      3. 信念
      4. 态度
      5. 任何其他软硬技能
    1. 业务和市场瞬息万变。因此,客户的期望可能改变。
    2. 技术领域时时发生着改变和创新——软件项目环境、架构和设计、开发流程都可能改变。
    3. 资源流动在长期项目中不可避免。
    4. 就数学意义而言,计划是一个时间函数。无论是在项目组、项目还是Sprint层面上,不管你计划如何周密——它可能明天就无效了。计划中的所有属性(任何层面的任何计划种类)都有时限,有些近在明天。当所有事情不断地、不可预期地发生改变,昨天的计划如何能在明天有效呢。在这一语境中,管理者的角色是:

                                   1.
给予人们持续激励,让人们全心投入到项目中。

                                  
2.以实际的过渡计划应对资源流动,将对业务的影响降到最低。

                           
      3.时刻注意计划,让计划与时俱进,采取相应的额外步骤来管理影响和改变。

                          
       4.因为人员和计划都是动态的,所以要与利益相关方就影响和应对策略保持持续沟通。

  1. 交流导致嫌隙和冲突
    1. 沟通交流是所有快乐之源,也是所有冲突之源。
    2. 它是一种艺术,总是需要勤勉不怠、深思熟虑,提前想到信息会如何被受众解读,是否会冒犯某人,是否足以保证信息的传递顺畅到位。世上少有人具备这一艺术。
    3. 开发人员通常太注重技术,于是(有意或者无意地)忽略了这一精巧艺术。

      项目经理在很大程度上控制着沟通交流职能。他/她应当在团队成员愿意承担时对其下放部分责任。

  1. 流程并非完美
    1. 没有完全理想的流程(比如软件开发方法,不管敏捷或瀑布,都不完美,没有理想的流程来忠诚地定义客户-供应商关系,而且就算有,也几乎不可能按照其实质精神来履行)。
    2. 就算一个流程对某人或在某种情况下运行绝对良好,它对不同环境下的另一个人也许就会可怕地失败。

      管理者应该让团队关注于结果,而非总是担心流程。“流程为我所用,我不为流程所用”——意思是,遵循流程并非最终目标,它只是达成某种结果的工具。管理者应该与团队一起,决定流程的哪部分对该项目最佳,并只适用那个部分。

  1. 流程实施不当
    1. 流程实施总是意味着更多的工作,更多的辛劳,更多的跟踪记录,而这些是任何通常意义上的开发团队力图避免的。流程开销被很多人当成是罪魁祸首。
    2. 一个特定流程在整个项目期间被100%原汁原味地实施,是很罕见的。

      如果任何对流程的违背可能导致混乱并对项目产生负面影响,管理者需要干预并保证对所有优良实践的高度遵守。

如果以上5个原因都不成立,就没有什么行业需要管理者了。但是很不幸,以上5者在每种行业、每家公司、每个项目和每次sprint全都存在。投资人和利益相关者必须在任何项目中得到好的投资回报(RoI),所以需要有人来摆平这些事情,并且仍然帮助达成项目的业务目标。所有上述五个属性实质上都不是技术相关的,可以通过应用管理实践来很好地应对。而扮演这一角色、将管理实践带入项目的人,在企业界就叫做“管理者”。但这不是说,管理者们有万灵仙丹来让上述这些达到完美,但是他们能帮助人员和流程得到调优,监控并应用横向思维的管理概念,来产出创造性的解决方案,以使上述五点不会大范围地影响业务目标。这一角色的一个子集,在敏捷用语中被描述为教练/促进者。
敏捷创造了一个新词汇,叫“自组织团队”。我个人是自组织团队的忠实粉丝。它在很多时候运行良好,尤其是在那些人们于公共生活中展现高度责任和义务标准的文化中,这是因为人们把这些高标准同样带进了办公室,完美地匹配了“自组织”团队。让每个雇员都工作于自组织的模式中,是所有公司的梦想。但是就像所有人类各不相同一样,不是每个人都适合“自组织”的团队。比如,不是每个医生都能成为外科医生、牙医或者整形医生,但是每个医生仍然都对社会有用。相似地,不可能期待每个人都能以“自组织的风格”工作。然而,同样是这些(不适合自组织定义的)个人,假如以不同方式处理,仍然可以成为很棒的贡献者。这里就是项目经理角色变得特别有帮助的地方,他可以通过多多少少(依赖于个体情况)的监管,让团队成员做出最佳的工作。敏捷使用“教练/促进者”一词来代表这种角色。另一方面,这一角色在人们稍稍偏离自组织状态时也工作良好。在如下3种情况中,教练/促进者或许必须延展其工作范围。
  1. 人们过度偏离自组织状态(比如非常无组织、非常不专注、情绪化等等)。
  2. 人们的软技巧与业务需求不相匹配(比如,不能做到积极主动,害怕讲话,沟通不良,时间管理差等等)。这些软技巧的缺乏,不可能让真实的潜力转化为绩效。
  3. 人们得了企业病(比如诽谤中伤,嫉贤妒能,自吹自擂,知识垄断,阿谀奉承等等)。技术上讲,假如有强力的管理者(而非教练)以持续的监督来控制他们,在影响到团队互动之前就扼杀这些苗头,仍然可能使这些人有所产出。
我在此的意思是,我们应当对所有专业人员具备高度的包容。但是处理和发挥一个个体的长处,方法因人而异,没有适用于每个人的通行法则。组织在这一点上应当反省。所有国家都有很好的技术人员,他们可以是好的贡献者,但也许不能自组织。这就是教练/促进者会转为更像一个项目经理的地方。这些人也许会犯错,也许需要引导和监管,也许缺乏软技巧,如此等等。在教练/促进者的有限范围内,让这些类型的人员与敏捷相适应来完成工作,会成为一个噩梦。我对各种各样的人充满尊重,也坚信这些人可以成为好的贡献者,但是你需要延展教练的职责范围,给与其某种权力来强硬地表明“什么该做,什么不该做”。这里项目经理的角色就变得有帮助。下表展示了一些觉得需要项目经理的其他领域。
情境编号
事实
敏捷如何有用
敏捷帮不上忙的地方
(而管理者可以!)
备注
1
人无完人
举行每日进度会议,让他们保持专注,让产品负责人保持需求与业务相一致。
1.专注点是否在正确方向上?
2.产品负责人是否每个冲刺都改变目标?
3.责任是否真正分担?如果每人都觉得别人更有经验、懂得更多,所以更要负责,该怎么办?
4.人们是否以敏捷之名掩盖自己能力的不足?
5.团队是否做到真正自组织?
6.人们是寻找外部原因作为借口,还是真正有所改善?
7.团队中是否有某人正抢占所有功劳,而损害了团队动力?
8.是否有人垄断了知识,不与团队分享?
具备横向思维的管理者可以想出创新的办法来管理不完美之处。
教练可以用合适方式提出如何做事,但如果人们不遵循又如何?比如,要是团队在演示后不听取产品负责人的反馈呢?这是可接受的,还是必须强制听取?
2
控制改变
敏捷在每个冲刺开始时欢迎新的需求,而Scrum
Master在冲刺中防止范围蠕变。
1.Scrum Master是否正确履行职责?
2.测试人员是否按时做了工作?
3.人们的软技巧和承诺是否正在改变?
4.客户是否突然开始不信任敏捷?
5.客户是否突然开始期待不切实际的事情?
敏捷以需求优先级来照管改变,但只是一部分。
产品负责人可以发挥影响力,在冲刺进行中增加故事,可团队不知道如何应对?
任何方法都无法应对无形的改变。
3
沟通不适当
敏捷用站会提供了每日沟通的机会,也用回顾会议创造了大家畅所欲言的平台。
1.团队是否真正提出障碍?
2.团队是否积极主动地沟通所有事项?
3.受众是否完全理解了沟通内容?
4.我们的沟通中是否有语言或文化的隔阂?
5.分布式的沟通是否成了瓶颈?用户体验是否良好?
6.是否所有email都得到回复,并达到预期、质量良好?
公司沟通是与懂得写程序非常不同的课题,也是很困难的课题。
管理学研究解释了沟通的艺术性。
任何流程都不能处理软技巧。
4
流程不完美
敏捷在软件开发中有效。
每个方法论都有其局限,最终是人来使项目成功。
差的敏捷不如没有敏捷。
5
流程实施不恰当
敏捷是一个实施依赖于人的流程。
1.人们是否遵循流程?
2.流程可否改善?
3.流程的哪些子集适合我的项目?
4.例外在哪里,何时偏离流程没有关系?
一个简单例子——在敏捷中,团队是否进行大量的结对编程?
最佳实践何时真的成为我项目的最佳实践?
如果情况出错,项目经理可以拓展其角色至教练/促进者之外。他/她可以控制那些本质上不适合敏捷或是意图上不愿意敏捷的团队成员。我想要指出3个业内普遍流行的神话,他们在敏捷的语境中更加显著。
1号神话:管理者们有万灵仙丹。
事实:处理人的头脑非常复杂,极其有挑战性。这里没有科学,只有纯粹的艺术。不管你做什么,总有不可管理的人,不可控制的改变。以我的愚见,一个好的管理者能够:
  1. 完全解决50%的问题,
  2. 部分解决15%的问题,
  3. 通过沟通让问题显而易见,让15%的问题看上去没有影响或者超出范围,
  4. 20%的问题总归存在(有些特定情况下的人和有些改变就是无法管理)。我们必须接受这一点。
请注意,如上这些数字只是我的经验表达,不是基于任何科学的研究调查。
管理者也是人,像其他人一样并不完美。“全方位思考(holistic
approach)”的管理是另一个概念。它是一项完全不同的职业,其设计就是为了管理不完美的人和流程。具备相当经验和学识的人可以带来很多价值。
2号神话:管理者们总是限制自由。
事实:对某些霸道的管理者可能是如此。但是实际上,好的管理者创造一个环境,提高表现,让人们发挥出最佳水准。有经验和见识的管理者可能暂时性地限制团队的自由,但其目标最终只是帮助人。有时候人们不能提前看到这一点,因为(a)缺乏经验(b)工作环境过于宽松(c)总是伴随着短视的傲慢心态(d)其他任何未言明的原因。
也有可能是,不胜任的人员惧怕被曝光,于是感觉管理者限制自由。渴望做出成绩的人应当提高自己的标准,利用管理者的经验来弥补不足,并与他/她紧密工作,以获得更多责任,让管理者可以放心休息。
3号神话:管理者不应该有权威。
事实:有些国家和文化从来就灌输公共生活中的责任义务观念,这些情况下是不需要权威的,教练/促进者在这类环境中将如鱼得水。但是权威的概念在有些仍在演化而未达到成熟阶段的社会更有意义。为了控制上述5个原因(本文开头所提),任何管理者在那些环境中都需要权威。没有权威的管理者就像没有油的汽车。研究显示,人的思想在心理上(尤其是成年期)就像硬铁条一样难于弯曲。要把钢铁塑造成漂亮的器具,权威是必需的。当全世界都变得非常勤勉、负责、成熟,以自组织的方式达到高效的时候——全球的管理学院都要关门大吉了。
结论
敏捷是一种很好的软件开发方法,它帮助克服了传统瀑布流程的一些不足。但是敏捷不是使项目成功的王牌。项目中进行工作表现的还是同一批人,而一有人的存在,就总有挑战。这个世界(以及人)充满了问题和缺憾。科学家们通过创新科技来帮助社会,类似地,管理这个职业帮助人们在受到制约的情况下仍能获得商业和职业上的成功。没有什么方法论可以排除管理者,除非是由完美的人来执行。流程是一套指导方针,有流程的地方就有偏差,有人的地方——就有问题。为了管理人和问题、控制偏差和改变——每个项目都需要专业管理的帮助。与此同时,管理者们也是人,他们也同属于这个由缺憾构成的世界,某些管理决策也可能失败。利益相关方必须接受这一点。在一定的环境中,管理者可能需要权威来应用一定的措施,来保证项目的最佳利益。这些措施可能在团队成员中遇到阻力,因此为了应用它们——有时候教练/促进者工作良好,而在有些情况下,具备权威的管理者才可以。
关于作者
Vinay Aggarwal是印度Xebia IT
Architects的交付经理。他在IT业界有11年的经验。他拥有工程学学士学位,是PMI认证的项目管理专家(PMP)和经认证的Scrum
Master(CSM)。曾在IBM和埃森哲等公司任职。他在瀑布和敏捷(Scrum)方法论上都有很多经验。他信奉横向思维,并将管理学概念应用于解决各种交付上的挑战。

 

面向对象设计 工具箱

面向对象是一强大的工具,来构建现在复杂强大的应用系统。以面向对象以中心,从最基本的面向对象的语言,基础,原则,设计模式,架构模式,到顶层的系统架构来说明,丰富这些工具箱中的内容,会让我们的设计工作更加游刃有余。
OO语言:
以Java为代表,还有C#(Ruby之类的动态语言),C++也是,但不全是。详细了解可参考维基百科
OO基础:
其实就是OO语言中所表现出来的,也是OO语言的特点。包括四个方面:
    一,抽象
    二,封装
    三,多态
    四,继承
(注:原则,设计模式只是人们总结以往的经验,提炼出来的设计当中好的方法,原则而己,避免以后再出现同样的问题。理论上讲只要有OO基础,你也能写出任何程序,只是过程及日后维护扩展会比较艰辛点:)
OO原则:
    一、
"开放-封闭"原则(OCP)
    二、里氏代换原则(LSP)        
    三、 依赖倒置原则(DIP)
    四、 接口隔离原则(ISP)
    五、 合成/聚合复用原则(CARP)
    六、 迪米特法则(LoD)
更通俗点来描述:
    1.封装变化
    2.多用组合,少用继承
    3.针对接口编程,不针对实现编程
    4.为交互对象之间的松耦合设计而努力
    5.类应该对扩展开放,对修改关闭
    6.依赖抽象,不要依赖具体的类
     (这里不做详细的讲述,否则就不只是一本书能容下的了:)
OO设计模式:
一,创建型模式:
  1. 简单工厂(Simple Factory)模式
  2. 工厂方法(Factory
    Method)模式
  3. 抽象工厂(Abstract
    Factory)模式
  4. 单例Singleton
    Pattern
  5. 建造者(Builder)模式
  6. 原型(Prototype)模式
二,结构模式:
  1. 适配器模式(Adapter):Match interfaces
    of different classes
  2. 合成模式(Composite):A tree structure
    of simple and composite objects
  3. 装饰模式(Decorator):Add
    responsibilities to objects dynamically
  4. 代理模式(Proxy):An object representing another object
  5. 享元模式(Flyweight):A fine-grained
    instance used for efficient sharing
  6. 门面模式(Facade):A single class
    that represents an entire subsystem
  7. 桥梁模式(Bridge):Separates an
    object interface from its implementation
三,行为模式:
  1. Chain of Resp.(责任链模式)A way of
    passing a request between a chain of objects
  2. Command(命令模式)Encapsulate a
    command request as an object
  3. Interpreter(解释器模式)A way to
    include language elements in a program
  4. Iterator(迭代子模式)Sequentially
    access the elements of a collection
  5. Mediator(中介者模式)Defines
    simplified communication between classes
  6. Memento(备忘录模式)Capture and
    restore an object’s internal state
  7. Observer(观察者模式)A way of
    notifying change to a number of classes
  8. State(状态模式)Alter an
    object’s behavior when its state changes
  9. Strategy(策略模式)Encapsulates
    an algorithm inside a class
  10. Template Method(模版方法模式)Defer the
    exact steps of an algorithm to a subclass
  11. Visitor(访问者模式)Defines a
    new operation to a class without change
 

架构模式:

比如IOCAOP,MVC,Layered,pipeline等等,框架模式决定了整个系统中某部分程序的总体结构。(其主要目的也是用来降低组件间的耦合度,封装变化)

系统架构:
比如你要做一个像Myspace一样巨大的网站,他的前台,后台,数据缓冲机制,数据库的选择,服务器均载平衡等等,都是系统架构要考虑的。
这些工具就是用来帮助你构建你的软件金字塔的工具,准备好了吗,建设你的软件帝国
🙂
参考资料:
        《Head First
设计模式》
《敏捷软件开发:原则、模式与实践》

 

软件之美

      
除了我的家庭,软件是我的挚爱。通过它,我可以创造出美的东西。软件之美在于它的功能,在于它的内部结构,还在于团队创建它的过程。对用户来说,通过直观,简单的界面呈现出恰当特性的程序就是美的。对软件设计者来说,被简单,直观地分割,并具有最小内部耦合的内部结构就是美的。对开发人员和管理者来说,每周都会取得重大进展,并且生产出无缺陷代码的具有活力的团队就是美的。美存在于所有这些层次之中,它们都是本书内容的一部分。
 

VIA组 实施Scrum可行性的方案

现在在公司做基于VIA的方案,VIA组包括UI,驱动两部分。接到项目后大致的流程是,首先从UI组找一个做软件PM主跟项目,然后项目PM会安排项目日期,包括硬件,驱动,软件。在确定项目日期后,软件PM开始着手来准备软件的基版,在VSS中上传软件代码,再然后开始软件的开发迭代。驱动更新,UI的更新都提交到VSS中,直到最后发布版本。
现在突出的问题是:软件的进度无法保障,软件的质量很难控制到位。
具体的原因分析为:1. 用户不断变化的需求
                  2.
VIA方案版本的不断更新
                  3. 工程师资源紧张
                  4.
项目前期的评估没有与工程师进行讨论,对工作量及可能遇到的难点估计不足
现在公司VIA的项目有个很大的特点是,开发过程的重点在用户需求及Bug的修改上,因为用的是VIA给的参考设计来做基版,基本功能都以实现,所以项目软件的开发过程可分为两个部分,需求的开发,Bug的修改。这两部分也是我们的主要工作内容。
用敏捷的项目管理方法来实施这部分软件的开发工作,对项目的进度,质量及资源的分配将会更加可控与合理。具体的方案如下:
1.划分BackLog:在得到用户需求与VIA给的Base版软件的基础上,进行分析,哪些是己实现的功能,哪些是需要我们添加的功能,哪些是需要VIA支持才能完成的功能。把这些都详细分成一个个条目。 如:
        条目1.自己完成添加短信防火墙;
     条目2.在VIA的协助下完成阿拉伯输入法的添加;
     条目3.发短信后的UI提示不正确的Bug;
这次拆分Backlog按功能来划分,有些功能会很大,有些则会很小,把这些故事点都罗列出来,进步一下的时间评估,及资源的分配。
2.制定Spring计划:每个Spring是一个阶段的工作,如2个星期,每个Spring结束都会给出一个演示版本,VIA这里可以表示为对外发布一版测试版。长度2周为好,时间过短会造成频繁发布版本的麻烦,时间太长不符合VIA项目的特点,因为VIA的重点是需求的实现及Bug的修改,而不是完全从头开发。由于我们人数有限,所以只能划分一个Spring了。然后由工程师来一起评估每个故事点所需要的时间,其Own是谁,之后把所有信息帖在如图的一张画板上,这样项目的进度,当前的问题,责任人都非常清楚。右边的是燃进图,记录了当前项目的总体状态,便于以后对Spring的评估与分析。Unplanned
Items 可以修改Bug产生的Bug,或测试新发现的Bug,数量较少时可以由工程师自行解决,较多时则需要重新制定Spring来完成,如此进行迭代。
 
看板的好处还有,项目经理可以明确知道每个项目当前的状态,就不用一直骚扰我们工程师了:)
3.对Spring进行验收。每2周对外发布测试版本,需要的是完整的测试版本,可以交给测试部及开发部区域测试的可验证版本。当所有的Spring结束后,测试没有问题,交给客户进行测试验收。
以上只是大致的流程,细节还有很多,最突出的是一个人同时有很多项目,这样就要按个人来重新划分故事点,按优先级对项目进行评估,与项目经理,部门经理进行评估,同样给出项目进度的看板来。
实施Srcum后,项目的进度可以有较为明确的日期,也可以尽早的暴露问题,工程师也可以有了自己较为明确的目标。项目进度可控,就不会产生为赶工期而牺牲了软件质量,测试力度也会尽可能的充分。
总的来说,相信VIA组实施Scrum后,会有助于提高生产力。