敏捷项目管理

伪敏捷开发-用敏捷的框架来做事:有角色的划分,任务的分解,有各种会议,也有sprint - 但迭代过程是随意、松散的、没有任何约束的,所以失败。正确的方法如下:

1-明确了短期目标,一个迭代在两周左右,可以明确告诉客户,在一个迭代周期内,只能完成200个里面的40个,先做最有价值的前20个。

2-便于进度控制和风险预测。

3-检视与调整,逐步完善的过程 , 迭代结束之后,产生可交付的成果,给客户演示,及早获得反馈,小步前进,不停思考,反省和总结。不停地进行自我检视,调整和完善,一步步走向卓越。

灵活运用敏捷开发

项目负责人还要懂得“做人”。和客户方负责人、联系人保持良好的关系是非常非常重要的

敏捷开发中,注重概念和架构设计,而轻详细设计

概念设计: 可以看出为何要做这个模块,强调的是产品路线规划,市场趋势,客户价值 和技术趋势等

架构设计,可以看成从整体上看,概念设计应该用什么方式实现、分几个层次、多少组件、不同层次和组件之间关系是什么。

详细设计,则是具体的设计和做法、API接口等。

SWOT 分析,在敏捷开发中,更加注重客户需求。对产品进行SWOT分析,就能选出最小工作量,但能获得最大价值的模块。

业务和客户驱动而非技术驱动:敏捷开发强调在整个开发周期内,业务人员和开发人员中必须天天都在一起工作,确保技术人员能够开发出客户需要的产品。

时刻考虑版本的兼容性, 当设计变动、API接口重构、配置文件变更时,要时刻考虑产品的架构、规划路线图,老版本的兼容性,及迁移平滑性。否则,随着版本的增多,必将面对着大量的维护工作。

轻文档而非文档, 强调沟通的重要性, 但并不意味着无文档,在敏捷开发过程中,适量的文档还是很有帮助,有助于整体思路,加快沟通和讨论;

产品敏捷开发中,每个迭代结束,都会有一个产品迭代演示大会,把这个月的开发结果演示给组员、业务人员、售前,甚至客户,并收集反馈。此外,在开发的过程中,产品的业务人员和售前时刻保持与产品开发团队的沟通和工作,保证开发出来的产品是符合业务需求。

充分利用资源和时间,敏捷开发后,迭代开发、强调沟通、缩减文档,在每个迭代初期就可以充分地利用开发、测试人员的时间,达到效率最大化。

每日交付

产品开发过程中,每天都会做自动化Build,并生成可以交付的产品。业务人员、客户都可以试用并提供反馈和新需求。

充分自动化

需要自动化去支持变化,在变化的同时保证质量和开发速度,包括编译自动化、单元测试自动化、功能测试自动化、UI测试自动化、集成测试自动化等。

架构师和Scrum Master的重要性

1) 产品架构师

一个好的产品,特别是面向行业的产品,要具有长期的生命力,需要具有下图所示的产品模型:

成熟的模块:指的是推出市场有一段时间,这些功能模块因满足客户的需求而被广泛使用。随着市场趋于稳定,大量竞争对手的产品也推出类似的功能。这些成熟模块都是产品的基本模块,不代表产品的竞争力。产品中如果只具有这些功能模块,随着需求和竞争的激烈,慢慢会走向灭亡。如90年代的BP机一样,当手机一旦推出,这个产品也就走向灭亡。

发展中的模块:指的是刚推出市场并且具有强劲的市场生命力、符合客户当前几年的业务发展需求,正在被大客户所接受的功能模块。这些功能模块是产品占领市场的动力,是继成熟的功能模块后,产品的新的增长动力。

研究中的下一代产品方向:指的是还没有推出市场、正在研究中的、符合未来行业五到十年发展方向的模块。当然如果能创造出未来的发展方向,则是最高境界。如任天堂的Wii、苹果公司的iPhone。

一个行业软件产品要保持长期的生命力,在整个产品的生命周期架构规划中,需要考虑到这三种模块和特性,只有这样才能保持产品的先进性和长久生命力。

敏捷开发也强调拥抱市场变化,这对产品架构师提出了很高的要求——深厚的业务背景、创新能力、技术洞察力和架构思想。

2) Scrum Master

其工作内容和开发组长没什么太大的区别:安排任务、协调资源、控制进度和解决难题。Scrum Master会协调解决每天碰到的问题,确保产品进度和质量。

每天早上需要主持小组成员进行一个10分钟左右Scrum会议。每个组员汇报昨天完成的任务,是否完成任务以及碰到的问题,最后是今天打算完成的任务。Scrum Master会协调解决每天碰到的问题,确保产品进度和质量。具体到业务中,Scrum Master各自负责架构中的不同模块,并和开发人员一起把模块分解成一个个单独的、可以衡量的用例,然后协调开发人员高质量的完成任务。

发表评论
留言与评论(共有 0 条评论)
   
验证码:

相关文章

推荐文章

'); })();