《敏捷需求分析》的相关内容

重新开个新帖： 最进一直在研究用户故事，有些心得同大家交流下，欢迎排砖： 我认为用户故事同用例最大的区别在于： 使用的方式 用例被看作需求的主要成果，用来作为设计，实现，测试的前置条件。并且作为工件在项目中需要保留。 相反 用户故事作为获取需求的开始，起到提纲的作用，最初的用户故事，可看作将要满足的功能的站位符，提醒我们有这么回事。 在UP中你会看到：有特性和用例的区别。 在XP中只有用户故事。 ...

今天为了监视gigix这个小子,于是发现了下面一段话: 引用嘉宾[主持人]： RUP有没有简化版本，适合中型或者小型项目的？怎么样判断裁减后的RUP，还能体现RUP的精髓？ [2004-12-8 15:54:00] 嘉宾[Ivar Jacobson]： 使用RUP要做裁减的时候有几个地方只要稍微留意，可以适合各种不同的公司的要求。包括第一是使用用例，就是你在使用RUP的过程中，用例的使用是非常 ...

敏捷软件开发图书概览 本文发表于程序员杂志2006年第5期 “敏捷软件开发宣言：我们正在通过亲身实践和帮助其他人实践，揭示更好的软件开发方法，通过这项工作，我们认为： 人和交流胜过过程和工具 可工作的软件胜过面面俱到的文档 客户协作胜过合同谈判 响应变化胜过遵循计划 虽然右项也有价值，但是我们认为左项更重要。” —— Kent Bec ...

要说RUP，就要先说UP。 UP可以用下面的话来概括——用例驱动、以构架为中心、迭代和增量的开发过程。 acobson在《Object-Oriented Software Engineering : A Use Case Drivern Approach》中给的定义是这样的：当希望改变系统的行为时，重建相对应的参与者和用例模型。整个系统的基础构架将有用户所希望使用系统行为进行的操作来控制。由于控制 ...

敏捷软件开发图书概览 本文发表于程序员杂志2006年第5期 “敏捷软件开发宣言：我们正在通过亲身实践和帮助其他人实践，揭示更好的软件开发方法，通过这项工作，我们认为： 人和交流胜过过程和工具 可工作的软件胜过面面俱到的文档 客户协作胜过合同谈判 响应变化胜过遵循计划 虽然右项也有价值，但是我们认为左项更重要。” —— Kent Bec ...

“敏捷软件开发宣言：我们正在通过亲身实践和帮助其他人实践，揭示更好的软件开发方法，通过这项工作，我们认为： 人和交流胜过过程和工具 可工作的软件胜过面面俱到的文档 客户协作胜过合同谈判 响应变化胜过遵循计划 虽然右项也有价值，但是我们认为左项更重要。” —— Kent Beck，Mike Beedle，Arie van Bennekum，Alistair Cockburn，Ward Cunning ...

敏捷软件开发图书概览 本文发表于程序员杂志2006年第5期 “ 敏捷软件开发宣言：我们正在通过亲身实践和帮助其他人实践，揭示更好的软件开发方法，通过这项工作，我们认为： 人和交流胜过过程和工具 可工作的软件胜过面面俱到的文档 客户协作胜过合同谈判 响应变化胜过遵循计划 虽然右项也有价值，但是我们认为左项更重要。 ” —— ...

当“敏捷”日益成为整个软件业的热门词汇，作为优秀的开发者、成功的项目经理，我们是否有足够的理由不去关心敏捷？我们帮你列出了6个“不必关心敏捷”的理由，以及对这些理由的深入解释。如果这些理由仍然不能打消你对敏捷的兴趣，首届“敏捷中国”开发者大会即将来到你的身边。你现在就可以报名参加本次大会，与Martin Fowler和众多敏捷 ...

一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。这样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。本文描述了敏捷开发的技巧：如何以用户故事管理项目. 敏捷开发技巧：以用户故事管理项目 Wingel 发表于 2007-02-12 08:08:13 作者:Wingel 来源:Wingel' blog 摘自:Matrix ...

敏捷不是一个过程，是一类过程的统称，它们有一个共性，就是符合敏捷价值观，遵循敏捷的原则。 敏捷的价值观如下： 个体和交互 胜过 过程和工具  可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判  响应变化 胜过 遵循计划  由价值观引出的12条敏捷原则：  1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 2、即使到了开发的后期，也欢迎改 ...

每个组织都喜欢吹捧其敏捷性，尽管事态并没有很快发生。当组织宣称是敏捷的，但实际上并非如此时，架构师就陷入了两难的境地。可以使用五个关键预测指标发现组织是否缺乏真正的敏捷性。了解这些预测指标，并获得帮助组织往更敏捷的方向推进的技巧。 组织敏捷性 意味着组织能够快速和敏捷地对内部问题、外部威胁和不断变化的客户需求作出反应。最高管理层喜欢这个术语，因为它使组织听起来很时髦，并且能够处理其发展方向中 ...

对于任何一个软件开发人员来说，架构师都是一个令人向往的角色。就连世界首富比尔盖茨在2000年卸任公司CEO的同时，也担任了微软公司的荣誉角色“首席软件架构师”，可见“架构师”这一称谓的吸引力。架构师是公司的“金领”，有着非常高的收入，很少需要考虑生存的问题，从而有更多的精力思考关键技术问题，形成“强者愈强”的良性循环。部分优秀的开发人员在工作了一定时间后，就要开始考虑自己的未来到底向哪个方向发展。 ...

在J2EE技术体系中，往往被灌输了太多容器的概念，什么EJB容器、Servlet容器等等，而开发过程也在开发、配置、部署之间迭代与反复；如此一来常会出现令人尴尬的状况：往往花几分钟时间去改一个Bug、却要再花双倍或者更多时间去部署和测试，开发工程师们不得不中断思路，看着服务器如蜗牛般启动，并在开发工具和部署工具之间来回切换。 事实上，配置也好、部署也罢，都是开发过程中一个必不可少的阶段。如何通过 ...

对于一个组织来说，同一组开发人员来完成多个项目，这是常有的事儿。在这种状况下，应该如何组织团队呢？他们的工作又该如何计划和分配呢？ 如果可分配的资源较多（比如说，可以为每个项目分配6至10个开发人员），而且已经知道这些项目的大小和相对优先级，一般来说，将开发人员划分为两个或多个团队就可以了。 反过来说，如果每个项目能够分配到的人员很少（每个项目只能有1到3个开发人员），而且项目的大小和相对优 ...