转载。。。
公司在上CMMI ,虽然很多人都觉得那是那是形象工程。公司的同事说,上CMMI可以忽悠一下政府可以,最怕的就是领导把上CMCMI还真当回事了。在项目里面试用了几个月没感觉到很大起色,曾经有人说中国根本就不适合去追求印度式的那种软件开发过程,印度人太死板,适合做这些没有创造力的活儿。中国国情不同,中国的开发人员都是一群很有创造力的人,他们的创造力曾经给一些错误的开发方法磨灭了,曾经的一段时间,大家极力推崇印度的软件开发过程,现在聪明的人清醒过来了,通过采用敏捷开发方法能有效的降低软件开发成,Thoughtwork中国公司一直采用敏捷开发就是个很好的证明。可是国内很多软件公司缺乏创新,还是老一套。 工作中要勇于尝试,看看Scrum是否真的合适我们项目还要从实践中得出整理, 下面是我给团队定义的一些开发规范 团队中的一些基本原则: 开发、共享、坦诚、快乐的工作,团队所有成员是一个整体、不应为任何问题追究到个人, 而应把它归为团队集体责任,所有人都是平等的地位和责任集体所有制。 开发要求: 1、 遵循《项目开发规范》和CheckStyle的要求写代码 2、实行TDD开发 TDD能给设计带来好处: 迫使你在编写代码之前,考虑更多对象之间的交互 迫使你把对象的创建封装在一个更好的层次上 写出更加小而内聚的方法,从而使方法的重用及纠错变得更加方便、快速。 3、实行老鸟带新鸟的原则 项目过程定义 项目过程说明: 每一次迭代时间周期为30天(sprint) 一个sprint周期内需要完成的模块(backlog) 1、每天早上10-15分钟站立会议(morning meet) 报告的主题是:今天完成了什么?、是否遇到了障碍?、即将要做什么? 2、每周二、四晚上代码检查(code check) 一个人写的代码至少两个人检查测试,进行代码复查的人需要针对程序提出意见或建议,然后反馈给代码开发员 3、每2周项目回顾(review meeting) 开发团队中成员需要在会议上说明自己实现了哪些功能、并作展示自己的工作成果。 寻找项目和团队中存在的问题,并作后续的工作给予改进 4、每月初项目计划会议( sprint planning meeting) 一般为一天时间(7小时)。该会议需要制定的任务是:产品Owner(业务人员)和团队成员将自己的功能模块(backlog)分解成小的功能模块, 决定在即将进行的sprint里需要完成多少小功能模块,确定好这个Product Backlog的任务优先级。另外,该会议还需详细地讨论如何能够按照需 求完成这些小功能模块。制定的这些模块的工作量以小时计算。 5、每周五下午技术会议(technologic session) 项目中遇到的一些困难、难题、陌生的技术或是你得最佳实践都可以拿出来共享与讨论 会议上,可以抛出任何疑问大家讨论,不同的思考会让大家对问题了解更加深刻,讨论也可以帮助我们解决一些疑难症状。 6、协作、反馈(Feedback) BA在每天在晨会后总结一封报告邮件给客户(客户代表)和PM,让客户(客户代表)能及时了解进度情况。 每周一总结Bug明细并发给小组全体成员。 BA尽量保持每日与客户代表沟通、讨论各个业务细节,力保每个业务细节的正确性。 Dev可从开发者,以及整体系统架构设计者角度考虑一下需求的可行性,是否能以最简单的方式提供同样的功能。 一些聪明的做法 不做简单重复的劳动,让这些工作给机器代替。(手工执行简单的任务只会让你变得更傻) 快捷化常用命令 必要时候结对编程 下面一个是Nokia的Scrum标准:可以拿来做参考 迭代要有固定的时长(TimeBox),不能超过六个星期。 每一次迭代的结尾,代码必须经过QA的测试。 Scrum团队必须有产品负责人,而且团队都清楚这个人是谁。 产品负责人必须有产品的Backlog,其中包括团队对它进行的估算。 团队必须有一个燃尽图,而且要了解他们自己的生产效率。 在一个Sprint中,外人不能干涉团队的工作。 Backlog是Scrum的核心,从根本上说,他就是一个需求、或故事,或特性组成的列表,并且按照重要性进行了排序,一定是客户想要的东西,并且用客户的语音进行描述,没一个条目是一个故事(Story),建议每个故事包含这些字段: ID(统一标示) Name(名称) Imp(重要程度) Est(初始估算) How to demo(如何做演示) Notes(其它) 每一个故事有3+1个变量(范围、重要性、估算)+质量,无论如何不能在质量上让步。 质量分为内部质量和外部质量: 外部质量是用户可以感知的,如运行缓慢,让人迷糊的界面等。 内部质量一般指用户看不见的原素,它对系统的可维护性有深远的影响,如系统设计的一致性、测试覆盖率、代码可读性等。 记住,在松散的沙滩上永远不能建立起精美的楼阁,经验证明牺牲内部质量是一个糟糕透顶的想法,现在省下来的一点时间,接下来的日子,你就要一直为它付出代价。 在Scrum中一切事情都是有时间盒的,到时必须交货。 “这个Sprint让大家不太好过,但是我们应该看到它的正面影响,整个团队从中获益匪浅,下个迭代会议会更有效率。” 学会按照时间盒安排工作,学会制定各种合乎情理的时间盒,这对sprint会议的长度同样有效。 典型的Sprint时间表,每一个小时休息10分钟: 30分钟的总体介绍,概括产品的Backlog。 20分钟的时间估算。 1个小时的Story选择,计算生产率。 1个小时的站立会议安排和将故事拆分为任务。 比较理想的一个Sprint长度为3个星期,(目前公司每日的Build版本,发布到测试部进行测试,应该是一个自动化测试的过程,而人工测试的应该是每个月发布的正常版本) 半死不活的目标比什么都没有强。 在Sprint中包含多少个故事由团队决定,而不是产品的负责人或其它人,但是产品负责人要对sprint中放入哪些Story产生影响。 自动生成故事卡的脚本下载地址: http://blog.crisp.se/henrikkniberg/2007/12/18/1197973740000.html 计划指派的点数:0、1/2、1、2、3、5、8、13、20、40、100、?、Coffee。 (编辑:李大同)
【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!
|