Eleven's Blog

  好久前在网络上看到的,具体是从拿看到的实在不记得了,觉得挺有用,发来共享下了.. 瀑布模型/改进的瀑布模型 虽然瀑布模型仍然存在很多的问题有待解决,但瀑布模型仍然是最基本的和最效的一种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求->分析->设计->编码->测试的阶段进行,每一个阶段都可以定义明确的产出物和验证准则.瀑布模型在每一个阶段完成后都可以组织相关的评审和验证

  大型软件项目需要很多人的能力合作，花费一年或数年的时间才能完成。为了提高工作效率，保证工作质量，软件开发人员的组织、分工与管理是一项十分重要和复杂的工作，它直接影响到软件项目的成功与失败。首先，由于软件开以人员的个人素质与差异很大，因此对软件开发人员的选择、分工十分关键。1970年，Sackman对12名程序员用两个不同的程序进 行试验，结论是：程序排错、调试时间差别为18：1;程序编制时

 2008 Jolt  Award 大奖获奖名单Jolt Award Winners Announced<!--By Jon Erickson --><!--Posted: March 6, 2008 12:25 AM-->Dr. Dobbs has announced the winners of the 18th annual Jolt Product Exc

 以前读过《蓝血十杰》，说的是十位哈佛毕业生如何拯救了福特汽车公司的故事。今天我来搞一个开源软件十杰。 No.1 自然非伟大的 RMS 莫属了。Richard Stallman，GNU 的创始人，GCC 和Emacs 的作者。GPL 的发明人。 No.2 Linux Fan 的教父，Linus Torvalds，Linux 的创始人和领导者。 No.3 Apache 的作者 Bri

 敏 捷项目管理是以迭代和功能为推动力的。功能的推动性表现在它将计划和执行的主要重点从任务转变为产品功能。这是与传统项目管理以任务为推动力的重要一个区 别。我们将整个需求分解为细粒度的多个功能点，只有每个功能点的开发和测试全部完成才对进度贡献和客户承诺有意义。这与挣值中的0-100法则是相吻合 的。 按需求和功能点进行WBS分解可能更难于管理，但是它跟开发人员的实际工作方式根据容易

敏捷开发包括一系列的方法，主流的有如下七种：XPXP（极限编程）的思想源自Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做 出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。SCRUMSCRUM是一种迭代的增量化过程，用于产品开发或工作管理

作者观察到许多能产生优秀团队的特性： ◆ 流程：Scrum，精益和XP。另外还有一些传统的流程，如RUP（统一软件过程），PMBOK（项目管理知识体系），等等。 ◆ 创造环境的条件：处于同一地点的团队、团队房间、随时可见的图表、白板等等。 然而他们自身发现，规则和实践可能会给一个团队带来太多流程和信息上的负担。相对的，作者建议专注于使团队成长的部分。按他们的经验，这可以分解成“3+2”。

在软件开发领域，人们越来越多地提到需求。和其他领域一样，这里的需求源自用户的“需要”，而不同则在于开发软件系统最困难的部分就是准确说明开发什么，这就是软件项目的需求。为什么我们如此多的关注需求？原因恰恰在于我们无法有效地获取需求，我们无法准确地表述需求，而需求的变化对于整个项目的成本、周期影响极大，所谓“一石激起千层浪”。所以，想让项目获得成功，首先要做好需求分析。什么是需求？要了解需

通常，架构要么是在Word文档中描述的一些软件系统中无形的、概念性的方面，要么就完全是由技术驱动的（“我们使用了一个XML架构”）。这两种方式都很糟糕：前者很难派上用场，而后者架构上的概念被技术宣传所掩盖。相关厂商内容 BEA虚拟化技术让你无需再为计算容量而担心 书籍：使用Visual Studio Team Foundation Se

 都在谈论中印之间的软件大战，其实没有可争论的，我们相差太远！但并不是我们的程序员技不如人，而是缺少系统分析员，特别是高素质的系统分析员。究竟系统分析员对一个软件项目来说有多么重要呢？下面一个案例可以说明：    某行业需要一个远程项目申报和管理的系统，第一个系统分析员带了10个程序员用了一年半，花了30万，硬是把项目做砸了，要说失败原因其实也挺委屈，由于 需要数据汇总和分析，系统分析员选择技

 在过去的几年中，单元测试逐渐成为我编写软件的核心内容，在这里要感谢一种叫做极端编程-XP(注1)(见“资源”一节)的简便程序设计方 法。这种方法要求我为新加入的每个函数都编写单元测试，并且维护这些测试。没有通过单元测试，我就不能将任何一个的代码加到模块中。在代码基数增长的同 时，这些测试允许开发者有依据地将改变集成起来。起初，我认为这些单元测试就足以应付全局，没有必要涉及到功能测试。噢，又错

 作为测试工程师，在日常工作中接触最多的当然是团队中的开发工程师，如何和开发工程师进行有效的交流是测试工程师面对的重要问题。一般来说，在一个团队中，总是有开发人员喜欢和不喜欢的测试工程师，这两者之间的工作效率和效果都有很大的差异。    当然，不能武断地说测试人员不喜欢的测试工程师就一定是效率低下的测试工程师，或者说是不合格的测试工程师，但一般来说，那些容易得到开发人员认可的工程师在测试时总能

偶然看到,转来下..我参加了西安市某大学举办的毕业生供需招聘会，为我院招聘教师。大部分前来应聘的大学生都表现出综合素质较好，能力较强，学习成绩较好等令人满意的特点，但也有部分毕业生的表现不尽如人意，希望引起在校大学生们的注意。　　多进教室，少去网吧　　在招聘会的前一天下午3点左右，为了对西安市各大学有更多的了解，我和另一名老师来到某大学校门右侧的一家网吧上网查资料。走进网吧一看，里面生

敏捷宣言：个体和迭代，超越过程和工具 工作的软件，超越完整的文档   客户协作，超越合同谈判   响应变更，超越履行计划 敏捷原则： 1. 优先级最高的是，通过早期和持续交付有价值的软件来满足客户。 2. 欢迎变更需求，即使在开发的后期提出。敏捷过程为客户的竞争优势而控制变更。 3. 以两周到两月为周期，频繁地交付可运行的软件，首推较短的时间定量。 4. 在整个项目过程中，每一天开发人

 1.软件开发最终是由人来执行和完成而不是机器。# Software development is performed by human beings. This notion was first popularized by Gerald Weinberg in 1971, with a book entitled The Psychology of Computer Programming

 《敏捷软件开发（原则、模式与实践）》（美）Robert C.Martin 著        邓辉 译        孟岩 审笔记笔记摘录：Eleven第一部分 敏捷开发第1章 敏捷实践        教堂尖顶上的风标，即使由钢铁制成，如果不懂得顺应风势的艺术，一样会被暴风立即摧毁。                                                ——海因里希.海涅（

 　极限编程(Extreme Programming,XP)简单地讲是一些相互关联的准则和惯例的集合，其中一些关注的是基本的活动，比如配置管理，但其中大多数关注的是团队成员之间以及团队与应用系统的企业团体之间的交流通信和文化方面的相关问题。XP建议采用循环迭代开发方法。 　　建模是软件开发中的一个重要组成部 分，一个模型描述的是软件的某个方面的完整内容。通过建模能简化软件和软件过程。往往一

  敏捷建模思想，是由以下一系列文章组成： 1  敏捷建模的价值观  2  敏捷建模的原则  3  敏捷建模的实践  4  敏捷建模是（不是）什么？  5  模型何时是敏捷的？  6  你是在敏捷建模吗？  7  敏捷建模何时是有（没有）意义的？  8  AM的实践是如何组合的？  9  那，你想成为一个敏捷建模者吗?  10 建模的误区  本文来自敏捷中国站点

 英文原文：http://www.agilemodeling.com/essays/modelStorming.htm Model Storming是一种实时的建模方式： 你找到了一个需要解决的问题，你马上抓起一小撮团队里可以帮助你的同事，这个小组一起研讨解决这个问题，接下来每个人像刚才一样继续工作。这对于敏捷项目来说是很普遍的事情。使用极限编程的人称这个为站立的设计会议(stand-

作者 Deborah Hartmann译者 郑柯 发布于 2008年4月20日 下午11时10分 社区Agile主题协作,领导能力,团队协作标签协作技术,管理,人际沟通,自组织团队 敏 捷的“自组织团队”模式需要团队成员们具备新的技能——包括他们曾寄希望于项目经理具备的人际交往技能。对于正处于向“自组织”转变之中的团队来说，