出家如初,成佛有余

不可能完成项目的Scrum实践

Posted in Uncategorized by chuanliang on 2010/06/26

     某一天老板或者销售人员跑过来亲切和蔼地拍拍你说:有个战略性产品需要在一个月之内开发出来,对搞定几个重点大商户至关重要,时间没有商量的余地。党组织从众多的党员同志中选择了你,这是党对你的信任,也是考验你的时候了。在生活的压力和生命的尊严之间,你只好泪流满面地接了下来。

1、不可能完成项目的典型特征

    对于互联网公司及做传统系统集成的公司的同志们而言,接到这样不可能完成的项目开发任务的情况已经司空见惯了。这些不可能完成项目的典型特征如下:

  • 老板说:项目对公司具有战略意义,必须搞定
  • 项目突发:销售跑过来告诉你,一个月内必须搞定这个项目
  • 需求不明确
  • 对现有系统架构有较大冲击,改动风险很大
  • 项目给的时间很短且交付时间固定(time boxing) ,只能够倒推
  • 销售过度承诺,必须实现狂复杂、狂大的需求
  • 资源有限
  • 设计诸多部门协调,很难短期搞定

2 、失败项目的典型症状

  • 项目组所有成员及利益相关者对项目愿景及目标没有达成一致
  • 为了赶进度,压缩需求分析、系统设计时间,需求理解尚未统一就投入开发
  • 每个人只关心自己负责的一小块业务,对系统整体需求、架构、设计没有达成一致
  • 为了赶进度,只关注功能的完成而忽视了功能实现的质量,导致大规模的返工
  • 为了赶进度,不进行统一设计,由各模块负责人自己设计,设计存在较大缺陷
  • 公用问题没有专人负责,工作重复
  • 项目组成员沟通不畅,出问题后才沟通,导致无谓的时间浪费
  • 项目组没有形成团队文化,团队成员只是为了完成项目目标而加班赶工,没有归属感

3、不可能完成项目的Scrum实践

    对于这样的不可能完成项目的管理使用Scrum这样的Time Boxing迭代开发过程很恰当,关于实践方法有兴趣的可以参考脑图。

    impossible project Scrum practice

原图点击下载

 

4、参考资料:

Quick-Kill Project Management

Quick-Kill 项目管理(完成“不可能的”任务)

用“看板图”实现敏捷项目的可视化

硝烟中的Scrum和XP

EssUP迭代核心——时间盒 Time boxing

 

Advertisements

互联网敏捷开发配置管理策略思考

Posted in Uncategorized by chuanliang on 2010/06/16

    由于互联网行业需求变化快、开发迭代周期短、上线频繁的现实状况决定了合理的软件配置管理策略对于软件质量保证、协作开发效率至关重要。

    目前公司配置管理在策略上采用的是不稳定主干(unstable trunk)模式,所有的项目都在同一主干上进行修改,在每周上线后并没有明确的stable分支版本,基本上是靠SCM人员手工拷贝代码来管理维护的。这就引起了很多问题:

   1)、多个项目组开发人员都可能并发对同样代码进行修改,造成了严重的代码冲突问题。例如张三修改了a.java并上QA测试服务器,在QA测试过程中,李四也对a.java进行修改并上QA,李四的代码覆盖了张三的代码。由于是SCM人员并不清楚代码冲突情况,这样张三和李四的代码上QA很容易相互影响并很难查具体原因

   2)、由于没有明确stable分支版本,导致上QA、上生产只能采用增量更新,上QA、上生产出问题后的代码回滚很麻烦,严重影响了测试、上线效率。对于生产环境运行的代码的具体版本并没有明确的管理,导致生产系统出问题后要排查问题也很难查。

   3)、由于核心基础包没有与上层应用隔离,导致大家都会对核心包进行修改,修改后代码质量并没有有效控制。于是出现因为修改基础包影响整个系统功能等现象

  类似的问题很多。要在新的项目实施及后期运营中避免类似问题的重现,至少要从如下几个方面来:

  1)、分支管理策略:采用适当的分支管理策略来保证开发库、测试库、发布库的隔离

  2)、适当引入每日编译、持续集成、Code Review等敏捷开发的最佳实践

  3)、采用自动化脚本完成上QA、上生产的部署工作,避免人工失误

  4)、对核心框架、后台应用、前端页面开发采用不同的配置管理策略

 

1、分支策略(Branching Strategy)

   代码分支管理策略一般分为3种(参考Branching Strategy Questioned

  1)、不稳定主干策略(The unstable trunk strategy)

subversion,git,Mercurial,配置管理,敏捷开发,分支,branching strategy

   此种分支策略使用主干作为新功能开发主线,分支用作发布。此种分支管理策略被广泛的应用于开源项目。比如freebsd的发布就是一个典型的例子。freebsd的主干永远是current,也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定,达到一个发布的里程碑以后,从主干分出来一个stable分支。freebsd是每个大版本一个分支。也就是说4.x,5.x,6,x各一个分支。每个发布分支上只有bug修改和现有功能的完善,而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后,就会有一次发布。发布的时候会在稳定分支上再分出来一个 release分支。
   此种分支管理策略比较适合诸如传统软件产品的开发模式,例如微软Windows开发,对于互联网开发不是很适合。已经在主干上集成的新功能,如果达不到里程碑的要求,稳定分支就不能创建,很有可能影响下一个发布的计划。还有一个问题就是bug修改必须在各个分支之间合并。

  2)、稳定主干策略(The stable trunk)

subversion,git,Mercurial,配置管理,敏捷开发,分支,branching strategy

    此种分支策略使用主干作为稳定版的发布。主干上永远是稳定版本,可以随时发布。bug的修改和新功能的增加,全部在分支上进行。而且每个bug和新功能都有不同的开发分支,完全分离。而对主干上的每一次发布都做一个标签而不是分支。分支上的开发和测试完毕以后才合并到主干。
    这种发布方法的好处是每次发布的内容调整起来比较容易。如果某个新功能或者bug在下一次发布之前无法完成,就不可能合并到主干,也就不会影响其他变更的发布。另外,每个分支的生命期比较短,唯一长期存在的就是主干,这样每次合并的风险很小。每次发布之前,只要比较主干上的最新版本和上一次发布的版本就能够知道这次发布的文件范围了。
   此种分支策略的缺点之一是如果某个开发分支因为功能比较复杂,或者应发布计划的要求而长期没有合并到主干上,很可能在最后合并的时候出现冲突。另外由于对于每一分支都要进行测试才能够合并到主干中,测试工作量较大。

  3)、敏捷发布策略(The agile release strategy)

subversion,git,Mercurial,配置管理,敏捷开发,分支,branching strategy

    此种模式在采用敏捷开发模式(例如Scrum)的项目中广泛采用,这些项目有固定的迭代周期(例如Scrum中每个Sprint的两周时间),新的功能开发都在Task branch(Feature branch)上进行,在接近迭代周期的发布阶段时候,新建Release branch来完成本迭代周期的发布,各Task branch(Feature branch)的功能merge到Release Branch中。在完成发布后,Release branch的功能merge到Trunk和尚在进行的Task branch中。

    采用敏捷发布策略要求主干的版本:
  • 任何时候都可以发布 :在任何时候,产品所有者都可以基于主干的最新版本,发布新版本的产品
  • 希望尽早发布

  此种模式较适合敏捷开发软件的要求,但对程序员及SCM要求较高。

  关于敏捷发布策略可以参考:多个敏捷团队之间的版本控制

 

2、配置管理策略

   根据目前公司的实际情况,建议采用稳定主干策略为主(The stable trunk。参考淘宝网最佳实践之ABS自动编译 可以看到,淘宝也采用了类似的版本管理策略。

   具体操作策略如下(尚需要细化):

   1)、trunk保持稳定,保证可以随时发布。trunk只有SCM人员才具有写权限,开发人员等只有读权限。

   2)、为降低SCM分支管理的压力,branch的权限可以授予给指定的几个组长

   3)、在每一个项目开始前,采用Branch per feature(Branch per Task)的分支管理模式(Common Branching Patterns),由各组长或SCM人员按照branch管理规范建立对应项目的开发分支development branch,例如airline_product1_feature_leader_date、airline_product2_bug_leader_date。

       项目定义:新功能开发、bug修复、需求变更等

   4)、在每周的上线发布后,在主干建立基线release版本(通过svn tag),以当前的主干作为基线,建立下一发布周期的test branch

   5)、开发人员在所在项目的development branch完成开发及集成测试后提交上线单,由SCM人员根据项目上线单的分支名称merge分支代码到本发布周期的test branch,进行测试。如果在测试过程中有新的上线单且有可能与其他上线单存在冲突,则在merge到test branch的过程中,SCM人员可以很容易及时排查问题。

       只要对上线单命名按照规范进行定义(例如与分支名称相同),此部分工作可以由脚本来自动化,存在冲突再人工干预。

   6)、测试人员完成本发布周期test branch所有上线单的功能测试后,由SCM人员将本发布周期的test branch合并到trunk,并通过打tag来release 一个上线版本

   7)、系统人员利用自动化部署脚本从trunk检出对应的release版本进行上线部署

     此部分工作采用自动化脚本完成,自动化脚本主要完成如下操作:从trunk检出完整的release 版本并打包,并包含部署包的md5验证码-> 上传部署包到生产系统各服务器->校验发布包的md5验证码是否正确,保证文件正确传输->完整备份生产系统的运行包->部署生产系统

   8)、每日晚上对trunk进行持续集成,保证能够正常编译和部署。工具建议采用hudson

   9)、对于核心代码及后台代码的修改,采用Pre-commit review模式,必须通过code review后,才能够提交到trunk中。工具可以采用reviewboard

   10)、其他一些值得讨论的问题

    开发分支的生命周期问题:上线后,原有的development branch变为只读的或者可以定期删除掉。

    紧急上线策略:紧急上线不遵循每周两次的上线周期,因此对于需要紧急上线的程序可以从trunk检出最近的release版本代码建立临时测试分支(test branch),紧急上线仍然需要按照规范建立对应的development branch,然后与临时测试分支合并,测试通过后上线,同时由SCM人员将紧急上线的development branch合并到当前的测试分支,继续进行测试。

    不同项目的配置管理策略:对核心框架、后台应用、前端页面开发可以采用不同的配置管理策略,例如核心框架可以采用不稳定主干策略(The unstable trunk strategy);后台应用采用稳定主干策略(The stable trunk

  

3、版本控制工具选择

  SVN的集中管理模式较为适合目前公司协作开发的需要,例如SVN所提供的集中式权限控制,对代码、二进制文件及文档的集中管理,类似TortoiseSVN的支持工具以及Eclipse 插件等。而Git/Mercurial(hg)的分布式管理特性,很适合开发人员本地版本开发管理。

   因此可以结合SVN和Git/Mercurial(hg)来作为版本控制工具。用SVN进行集中管理,用Mercurial(hg)在多个不同机器上进行开发,功能完善并测试完成后再提交至 SVN Repository。可以借助git-svn、HgSubversion、hgsvn这样的工具来结合使用。考虑到目前的开发环境为Windows环境,建议采用Mercurial。

  值得一提的是SVN从1.5版本开始,对branching merge的支持有很大的提升,大大简化了分支合并的难度,可以参考What’s New in Subversion 1.6?

4、一些工具

code review

    http://www.reviewboard.org/

持续集成

    https://hudson.dev.java.net/

自动部署

    http://www.smartfrog.org/

    http://www.capify.org

商业软件中采用atlassian的系列产品倒是不错的选择:Jira+Crucible+FishEye+Bamboo

 

5、参考文档

  http://www.programmer.com.cn/3223/

  http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.commonpatterns.feature

  http://martinfowler.com/bliki/FeatureBranch.html

  http://codicesoftware.blogspot.com/2010/03/branching-strategies.html

  http://msdn.microsoft.com/en-us/library/bb668955.aspx

  http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx

  http://www.cmcrossroads.com/bradapp/acme/branching/

  http://www.vance.com/steve/perforce/Branching_Strategies.html

  http://blog.gravityfree.ca/2009/02/using-feature-branches.html

  http://blogs.open.collab.net/svn/2008/07/subversion-merg.html

  http://thinkernel.bokee.com/4518935.html

  http://www.infoq.com/cn/articles/agile-version-control

 

敏捷架构思考

Posted in Uncategorized by chuanliang on 2010/06/05

1、敏捷软件开发不需要架构设计?

    相对于传统瀑布式开发过程及RUP这样的重量级开发过程而言,敏捷软件“重视与客户的沟通;小步快跑,尽早交付;迭代式开发,拥抱变化”等实践正好符合互联网要求快速迭代、坚持以用户为中心的设计(UCD)等特征相吻合,因此敏捷软甲开发过程成为了互联网软件开发的标准模式。

    一直以来都觉得敏捷软件是“轻架构设计”的,不管是XP、Scrum、FDD、Getting Real等敏捷软件开发过程对待设计(Design)的理念都遵循了演进式设计 (evolutionary design) 而非计划性的设计(Planned Design)。

    而且由于类似于Ruby on Rails、SSH(Struts+Spring+Hibernate)、Django、CakePHP这样快速开发架构的出现,技术架构已经成为流行的术语,一个刚毕业的小孩也能够大谈架构设计、设计模式、架构模式,传统的架构设计似乎已经没有太多的必要。

    但在实践过程中,会发现轻架构设计的一堆严重后果,诸如:陷入了"code and fix" 的恶梦;系统越来越复杂和混乱,架构完全失控;

    再读Martin Fowler的《Is Design Dead?》,才发现自己对于敏捷软件的理解是如此的教条:

  Continuous integration、testing 和 refactoring 这些有效的实作方法让 evolutionary design 看似很有道理。但是我们尚未找出其间的平衡点。我相信,不论外界对 XP 存有什么印象,XP 不仅仅是 testing、coding 和 refactoring。在 coding 之前还有 design 的必要。部份的 design 在 coding 之前准备,大部份的 design 则发生在实作每一项详列的功能之前。总之,在 up-front design 和 refactoring 之间可以找到新的平衡。

   大师不愧为大师,能够准确把握住事物的本质,能够把握住过犹不及的度。其实任何方法论都有其应用的边界,方法论没有问题,错误的根源在于使用方法论的人的教条主义。

2、形形色色的架构

敏捷软件,敏捷架构,agile architecture,agile modeling,软件架构,Agile Enterprise Architecture

    “架构”这词成为了一个技术领域时尚的话题,每一个人都在谈论架构,似乎不谈架构就没有技术品位,于是乎出现了一堆与架构有关的术语,包括:软件架构(Software Architecture)、系统架构(System Architecture)、企业架构(Enterprise Architecture )、信息架构(Information Architecture )、应用架构(Application Architecture )、IT架构(IT Architecture)、产品架构(Product Architecture)、业务架构(Business Architecture)、技术架构(Technology Architecture)、解决方案架构(Solution Architecture)、基础架构(Infrastructure Architecture)、领域架构(Domain Architecture)

3、敏捷架构

    敏捷模型驱动开发(Agile Model Driven Development)中对于Agile Architecture Modeling有比较清晰的描述,也回答了为何在敏捷软件开发过程中需要进行架构设计的原因:

    1)、Improved productivity. You can think through some of the critical technical issues facing your project and potentially avoid going down fruitless technical paths.

    2)、Reduced technical risk. Your team gains the advantage of having a guiding vision without the disadvantage of having to overbuild your system – just because you’ve modeled it doesn’t mean you have to build it.   

    3)、Reduced development time.  Initial agile architecture modeling enables you to make better cost and time estimates for your project, two pieces of information which management will want.  

    4)、Improved communication.  Having a high-level architecture model helps you to communicate what you think you’re going to build and how you think that you’ll build it, two more critical pieces of information desired by management.

    5)、Scaling agile software development.  Your initial architecture model will be a key work product in any "agile at scale" efforts because it provides the technical direction required by sub-teams to define and guide their efforts within the overall project.

    6)、Improved team organization. Effective teams are organized around the architecture or line of business, not around job function.  As you scale to larger and/or distributed teams the sub-teams should each be responsible for one or more sub-systems — you don’t want to organize your sub-teams around job function (e.g. an architecture team, a development team, a testing team, …) because that requires you to increase the documentation and bureaucracy overhead which in turn increases risk, cost, and time to value.

   相对于其他的敏捷软件开发过程,在Agile Model Driven Development(AMDD)中明确包括了初始需求分析与架构建模,这个过程发生在敏捷项目开发的第0次迭代中。所谓第0次迭代,就相当于项目的热身活动,是项目得以启动的基础。

敏捷软件,敏捷架构,agile architecture,agile modeling,软件架构,Agile Enterprise Architecture 

    Agile Enterprise Architecture 中谈到了敏捷软件架构的一些指导思想:

    1)、Focus on people, not technology or techniques

    2)、Keep it simple

    3)、Work iteratively and incrementally

    4)、Roll up your sleeves

    5)、Look at the whole picture

    6)、Make enterprise architecture attractive to your customers

4、关于架构的一些思考

4.1、架构!=技术架构

    敏捷架构并不只是指技术架构本身,正如前面提到的,还包括产品架构、业务架构、信息架构、应用架构等等。

    技术架构不单纯只是技术实现本身,还承载了业务架构、产品架构、信息架构、应用架构的具体实现,纯粹的技术框架本身没有太多的价值。纯粹的技术框架的架构可以一次性完成,但对于业务架构、产品架构的架构必须随着公司对于行业深入的了解才能逐步完善,对于业务需求的管理能力成为一个公司发展的决定性因素。

    对于一个运营型的互联网公司,核心的竞争力之一在于对所服务的行业业务及客户深刻的理解并具备将这种行业经验转化为产品及服务的能力。互联网在服务过程中积累的不单纯只是技术架构的积累,更为重要的是行业需求的积累,而这需要对应的业务架构和产品架构来作为持续积累的框架。技术架构可以较为容易获取和变迁,但行业经验却难以短期突破。

    对于中国这些互联网公司而言,基本上没有太多原创的产品,尚没有能力做到技术驱动、创新驱动的层次,大家还停留在做简单的行业应用上,公司间的竞争基本上也停留在应用开发能力及运营能力的竞争。因此对于中国互联网公司而言,合理的业务架构及产品架构比技术架构本身意义更为重要。

4.2、架构是管理出来的,而不是架构出来的

    在中国公司比较典型的情景:

    1)、公司原有架构师及开发人员因为某种原因离职,公司招聘一个新的架构师

    2)、新的架构师被公司寄予较大期望,由于维护老的架构吃力不讨好,而架构师要急于证明自己的能力,最为简单有效的办法就是重做一套系统。

    3)、新的架构师将原有的架构推倒再重新做一遍,并承诺了完美的架构:能够解决目前产品、运营、财务人员们面临的所有问题

    4)、新的架构上线后架构师及技术人员不断应付开发新的需求和迁移老的需求,疲于奔命,没有精力去整体把控架构,于是将架构的维护权限移交给每一个开发人员

    5)、销售、运营、财务发现与当初承诺的需求不符合,投诉不断;架构师认为已经完成系统架构,剩下的都是开发的问题、产品的问题

    6)、新的架构被否定掉,开发人员们或是离职或是沉沦

    7)、同样的悲剧不断上演

    一个好的架构不是一蹴而就的,没有一个架构是一次性完美地架构出来的,完美架构的诀窍就在于持续维护、持续完善。任何架构都有一个从孕育->诞生->成长->成熟->衰退的演进过程,没有经历风雨的完美架构只能是温室中的鲜花。

    对于架构的持续完善不单纯只是一个技术问题,而是一个研发管理的核心问题,架构的完善应当贯穿于市场管理流程、需求管理流程、产品研发流程各大流程中。对于架构的管理必须有专门的组织机构、流程制度来保障。

    可以说一个好的架构不是架构出来的,而是管理出来的,对于架构的管理体现了一个公司的研发管理能力。

 

5、参考文档

    Is Design Dead?

    Agile Architecture: Strategies for Scaling Agile Development

    Agile Enterprise Architecture

    The Agile Unified Process (AUP)