磕磕绊绊的Scrum之行(七)我们具体是怎么做的

简单地说,就是整个完整交付品远超开发团队交付能力的情况下(我相信大多数时候都是这样的),如何去尽可能准时交付并且保障交付品的功能满足及良好的设计,还有质量的保证。

对传统的开发过程,项目中往往会有权衡之事发生,最常见的就是,管他三七二十一,我们把功能实现了就行了,先不管架构、质量,整一个可以跑的东西出来,整上线再慢慢来修修补补。这种情况导致的最恶劣的后果就是质量问题导致不断延期,架构的不合理导致整套系统的生命周期很短。

对一个成熟的敏捷团队的开发过程,如采用Scrum的模式是,我们会在第一时间编写产品积压事项(Product Backlog)来代替传统的需求用例,然后根据Backlog的优先级、依赖顺序进行分组,划一个时间周期为一个Sprint,将一组Backlog加入到这个Sprint中形成Sprint Backlog,指定Backlog负责人、开发人员,开评估会议,定义每个Backlog如何分解成8小时一份的Task来进行完成。每天的状态会更新在看板上,遇到的问题被标记为阻碍Backlog,一个Sprint的目标,就是消灭所有的Product Backlog和阻碍Backlog.

再说一下架构设计方面。在这个开发过程中,没有架构设计的概念。是因为:
1.我们默认我们无法提出良好的架构——通常这样的系统由很多子系统组成,在Project Architecture这一级设计上,我们仅仅提出“我们将采用分布式架构设计,子系统各自的数据库不允许外部子系统直接访问”这样一个概念,除此之外,定义采用何种平台、何种语言、开发环境、发布环境和数据库类型等等,物理架构基本上可以定义,逻辑架构出一个轮廓。无文档产出,无签字确认。
2.在Application Architecture这一级别,我们会定义采用什么样的设计方法,如我们现在的一个业务系统,我们采用领域驱动设计的方法进行设计和开发。在这个过程中,我们发现以前对分布式架构的“如何分布式”的认知有一些偏差,于是,我们在这里将“如何分布式”定义得更准确了,我们将基于业务重用度而不是“隔离应用操作”来定义分布式架构,从另一个角度上来说,我们把整个构架从物理部署上演进到了逻辑应用上,但之所以可以改变的原因是我们是增量交付,架构部分没有文档需要修改,也没有具体的项目解决方案需要重写。
3.持续重构。在我们这个项目中由于时间比较紧,每次我们只会做最关键的重构,而把更新的设计思路体现在下一个Sprint中,这样,至少大部分的结构是优秀的,不断改善的。

mouge评论道:

我觉得你有点大方法论倾向。
当你面面俱到地,按步就班地实施一个方法论时,并让自己感觉已经掌控全局时,其实敏捷已经死亡。
我认为的敏捷可能就是某几个关键能调动具体人员积极性和激活创意的实践,白板,卡片,信息墙等让人兴奋的手段,而不是一大堆漂亮,整洁的文档和规范。把sprint做得完美,让老板高兴的图表,架构驱动的开发,我认为都和敏捷背道而驰,华而不实的东西。敏捷所需要的是无处不在的测试,适应变化的重构以及真正协作的团队。
我:
事情具体怎么做,是根据具体的情况,因为背景和资源都掌握在我的手上,所以,我是决策者。这个贴子只记录项目的真实过程,对于各位朋友的建议,我觉得可行会采纳,其它一笑置之。

© 2018 Silent River All Rights Reserved. 本站访客数人次 本站总访问量
Theme by hiero