广州五羊建设官方网站,的搜索引擎优化,免费网站建设360,两栏式网站在大型企业中经常是各种软件开发模式混用#xff0c;一些采用敏捷开发#xff0c;一些则是采用传统的瀑布式或RUP#xff08;统一软件开发过程#xff09;。敏捷开发#xff0c;相对传统软件开发模式#xff0c;它主要是针对快速变化的需求#xff0c;不断优化管理流程一些采用敏捷开发一些则是采用传统的瀑布式或RUP统一软件开发过程。敏捷开发相对传统软件开发模式它主要是针对快速变化的需求不断优化管理流程最终推出优质软件。 原文作者Ulf Eriksson是一家在线问题跟踪软件公司的创始人之一他是敏捷开发的忠实粉丝已经进行了多年敏捷开发的实践。下面内容主要是作者根据自己多年经历进行的经验总结。 1. 快速迭代 相对那种半年一次的大版本发布来说小版本的需求、开发和测试更加简单快速。一些公司一年仅发布仅2~3个版本发布流程缓慢它们仍采用瀑布开发模式更严重的是对敏捷开发模式存在误解。 由一年发布2个版本转到一个月发布2个版本这也不太可能。但是现在来看快速迭代已经成为事实标准关键是要比目前的版本发布速度更快一些。 快速迭代可以逼迫团队不断优化流程、提升工作效率不要在无足轻重的事情上浪费时间。如果离deadline还有6个月那么整个工作节奏必然悠哉。如果每月发布一个版本那么较以前效率必然会更高。如果发布周期过长导致无法尽快发现用户需求进而无法及时改进产品。 2. 让测试人员和开发者参与需求讨论 需求讨论以研讨组的形式展开最有效率。研讨组需要包括测试人员和开发者这样可以更加轻松定义可测试的需求将需求分组并确定优先级。 同时该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高大家更活跃参与感更强。 确定需求时不要过度盯在细节上。需求报告过于详细就是一种不敏捷的习惯还浪费大家的时间。当然不能错过好点子但就是不要太细因为项目真正实施起来时需求将会产生很大的变动。 3. 编写可测试的需求文档 开始就要用“用户故事”User Story的方法来编写需求文档。这种方法可以让我们将注意力放在需求上而不是解决方法和实施技术上。过早的提及技术实施方案会降低对需求的注意力。 规划业务需求可以采用“3W模板”也就是
谁Who是什么What为什么Why 上面的3W实际上就是描述了相关利益者是谁他们想要什么他们为什么有这种需求。下面举一例子进行说明 谁Who是什么What为什么Why用户希望借助一个应用程序在不同服务器间传输文件为了存储项目数据 为了更加接近“用户故事”我们可以改写为 谁Who是什么What为什么Why消费者/用户想将归档过程数字化为了增强沟通提高分享效率
敏捷项目中编写用户故事有一个常用模板作为一名[用户类型]我想要[需求]以便于[原因]。应用到这个例子就是作为一名用户我想要将归档程序数字化以便于增强沟通、提高分享效率。 多数情况下需求内容需要更加充实和详细这一步要放到后面做开始不要这样。用户故事的方法有时会因过于简短、不断重复而受到批评。这里我们必须明白需求文档不是散文或诗歌应该清晰、简明地描述用户需求需求文档的重点也在于此不要管形式多变或内容是否重复这样的问题。 4. 多沟通尽量减少文档 任何项目中沟通都是一个常见的问题。好的沟通是敏捷开发的先决条件。在圈子里面混得越久越会强调良好高效的沟通的重要性。 团队要确保日常的交流面对面沟通比邮件强得多。 敏捷开发鼓励日常的协调会议和碰头会5~7人参与的会议尽量控制在10分钟内。碰头时要过一遍昨天完成了什么今天要做什么哪些问题仍待讨论。可以用Burndown Chart燃尽图来形象展示工作进度。每次迭代的时候也都要开一个计划会议和评审会议一般需要的时间可能会长些比如半天。这些会议的目的就是对工作查缺补漏。 评审会议很重要传统开发模式往往略过该环节导致一些错误做法不断重复好的做法无法推广。 开会时可以将原先的分组打散让整个团队都参与到项目的需求讨论和测试中来这样可以突出成员个人让大家更乐意参与。 5. 做好产品原型 建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档但人人都会看图。 一个常见的问题是软件新的功能与用户想要的不一致。为了避免这一问题可以模拟真实操作改进模拟操作过程中难以理解和不清楚的操作行为。 6. 及早考虑测试 及早地考虑测试在敏捷开发中很重要。传统的软件开发测试用例很晚才开始写这导致过晚发现需求中存在的问题使得改进成本过高。较早地开始编写测试用例当需求完成时可以接受的测试用例也基本一块完成了。 敏捷开发中一个常见问题就是开发者没有对已有的代码库进行充分的回归测试。迭代周期很短从开始到交付就是4周的时间这样可以对迭代的设计、实现和底层测试一块进行回归测试。 一系列迭代之后可以只针对测试活动再补充一个迭代。这个迭代可以将重点放在系统测试、与其他系统的集成度、性能等方面。敏捷开发过程中可能会导致过少的测试文档。如果迭代周期为1个月左右可以不必对测试文档过于要求但要制定好测试策略。 最后 可能大多数公司或团队还没有开始尝试敏捷开发不过可以开始从点滴做起比如开碰头会、为项目管理采用一个更加高效的管理工具等等。最后希望上面的建议能够为大家的软件开发管理带来帮助。编译/王殿进 http://www.csdn.net/article/2013-12-09/2817746-6-practical-agile-techniques
