If you don’t do agile,you are agile

Posted: 八月 7, 2011 in Develope

  上周正式开始使用scrum,初识scrum,有一些想法,特此记录!
  在引进scrum之前,我公司一直采用的是瀑布式的方式进行软件管理,其中涉及到太多的流程,比如:
    1.在开发软件之前需要做好所有的需求文档,否则不能进行开发(这需要太多的需求分析,而且时常难以把握真正的需求)
    2.所有的部门都是独立的,销售、开发、测试等都是独立分开的,所有的工作都是以销售为导向的,后端的开发人员难以参与到具体的需求调研中(这需要花费大量的人力)
    3.整个开发过程需要大量的文档来支撑,比如:需求文档,系统设计,概要设计,详细设计,单元测试(这通常要花费太多精力来编写文档)
  我们需要做出改变吗?Of course!
  敏捷倡导的是以人为本,拥抱变化!以人为本就是把人做为整个工作中的核心,强调人在软件开发工作中的价值;拥抱变化就是随时响应需求改变带来的变化。但是,这能解决好传统瀑布式的开发方式带来的诸多问题吗?我暂时现在还没有能力来回答这个问题。
  在上一周的scrum工作中,我们完成了product backlog、user story、sprint backlog的建立以及task的分配。整个过程我感觉确实和以往的开发方式挺不一样的,首先是文档的产入产出上,以往都是一纸文档,QA有测试文档,开发有需求文档,但是在敏捷过程中我们到任务的分配结束还没有产生任何文档;其次是参与人员的不同,以往我们只要开发人员知道具体要开发的内容,等开发好了之后为QA写好相应的test case。在采用敏捷时,需要所有利益相关的人(PO,SM,TM,QA)参与进来,并提意见。QA也有发言权,大家一起讨论出具体的task的具体优先级,开发之前所有参与人员都要对需求有所了解;再次,我们在讨论的过程中有很多的分歧,例如:如何来判断story?如何细分story?如何来评估优先级?如何估测sprint需要的时间(包括开发和测试的时间)?
  整个user story的开发流程:
  技术选型–>UI设计–>编码&测试–>code review–>DB review–>fix bug–>documented
  当以上步骤都完成之后才算一个user story的完成,这和传统的开发流程稍微有些不同,大体还是吻合的,最大的区别就是:
     1.开发和测试是同时进行的

    2.文档只需要最后完成之后的一个说明文档

    3.安排的时间较短,一般为2-4周

  虽然从表面上开来会提高效率,但是不知道在具体实施的过程中是不是会遇到很多不顺呢?

  在敏捷的同时,随之而来的就是CI,AUTO Building&Testing,VSTS,但是anyway,我们做这些无非是为了开发出有价值并且可以使用的软件。我相信接下来会有很多事情发生,让我拭目以待吧!

Advertisements

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s