敏捷软件开发
CavenRan
我大学本科学的是计算机科学与技术专业,顺便也修了经济学学位;毕业后在北京工作了2年,用C++做SIP方面的东西;06年回重庆,开始做软件外包,现在公司这边做的都是C#和.NET这方面的项目,主要面对欧美客户;个人对项目管理和敏捷软件开发有特别爱好,希望这方面跟大家多交流。
展开
-
敏捷软件开发中的26条金科玉律
l 在开始案例2之前,必须使案例1能完全正常工作这条玉律在厨房里面的说法是:“在开始做下一道菜前,先把当前这道菜上给客户”。软件开发最大的问题是一大堆事情并发进行,因此其中的一些工作就不可避免地会在后期被丢弃,这就意味着努力被浪费。先专注于案例1;使它完全能够正常工作;运行相关的测试;书写与之关联的文档;嵌入所有相关的代码;然后才能开始下一个任务; l 决不要允许构建失败非翻译 2009-10-30 14:21:00 · 869 阅读 · 0 评论 -
敏捷软件开发最佳实践之-Scrum站立会议
什么是站立会议?站立会议是敏捷软件开发方法论Scrum的相关技术之一,亦可称之为Scrum的最佳实践。具体形式为每天的同一时间,一个敏捷开发团队的所有成员面对面站在一起,进行一个为期15~20分钟的短会。在会议上,每个人要依次回答以下三个问题:1)从上次站立会议到现在,你完成了什么2)从现在到下次站立会议,你将要做什么3)你遇到什么阻碍,需要其它人如何帮你站立会议的意义和作用是原创 2010-01-13 17:28:00 · 1817 阅读 · 0 评论 -
精益方法的原则之延迟决策
精益制造的第十三条原则为 "不急于作决策,以共识为基础,彻底考虑所有可能的选择,并快速执行决策" 说的是不要因为时间紧迫或者人多难以协调,就采取武断式地决策方法比较“快”地做出决策来。而应该在决策前尽量找到所有可能的方案,充分讨论、沟通、评估、甚而试验每种选择,以此达成团队的共识,在共识的基础上再进行最终决策,以确保做出最佳的决定 - “决策”慢。 另一个层面是,一旦决策制定了原创 2010-01-19 17:46:00 · 1968 阅读 · 0 评论 -
敏捷软件开发宣言
http://www.agilemanifesto.org/ 个体和交互 胜于 过程和工具; [注] 以人为本的思想,利用工具的是人,遵循过程的也是人,如果有最好的工具和过程,而个体却没有很好的去利用工具,遵循过程的话,工具和过程也不能发挥预计的效果;另外,流程和工具的一部分作用也是为了团队成员更好地交互;所以个体和交互是跟本,过程和工具固然重要,却是辅; 可以工作的软件翻译 2009-12-02 17:30:00 · 1137 阅读 · 0 评论 -
敏捷软件开发12条原则
敏捷软件开发遵循的原则 1. 我们最优先做的工作是通过尽早地、持续地交付有价值的软件来使客户满意; 2. 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势; 3. 以几周或者几个月为单位,经常性地交付可以工作的软件,交付的时间间隔越短越好; 4. 业务人员和程序员必须在整个项目周期中,每天都在一起工作; 5. 围绕被激励起来的个体构建项目。给他们提供所需翻译 2009-12-16 11:41:00 · 920 阅读 · 0 评论 -
软件开发过程中的7大浪费
1. 额外的功能特性 根据Standish Group的调查报告,传统的软件开发过程制造了大量人们不需要的功能特性(7% always used,13% often used,16% sometimes used,19% rarely used,45% never used)。每个功能的实现,都要经历软件开发的整个生命周期:需求分析、设计、编码、测试、发布和维护,这需要耗费大量的人力、物力和财原创 2009-12-16 11:44:00 · 5036 阅读 · 0 评论 -
关于软件需求必须知道的事情
<br /><br />“客户的需求在一开始就能被定义好,并且描述清楚,并且在相当长一段时间内保持不变”,这种情况只存在于理想中,现实世界并不是这样。<br /><br /><br />现实是:<br />* 只有非常少的客户能在项目开始时就清楚地知道自己想要什么并定义好细节,绝大多数客户(也许90%以上)只是对项目的需求有个模糊的概念,而且无法想像最终想要的产品长什么样;<br />* 即使客户清楚地知道自己想要什么,其中很多人也无法明确地把这种需求表述出来;<br />* 即使他能够清楚地表达自己的要求原创 2010-08-31 17:08:00 · 530 阅读 · 0 评论 -
导致项目失败的两大隐形杀手
<br /> 根据个人的项目管理经验和生活经验,我觉得“明枪易躲,暗箭难防”这句话实在是太有道理了。用在项目管理方面,就是指那些相对比较大的、明显的问题往往都容易识别,比较好预防或者解决,项目一般不太容易失败在这些地方;而那些相对较小的,经常发生的琐碎问题,却通常都比较隐蔽,不太容易预防和控制,而它们最终会在无形中杀死项目。就好像一颗大树,在雷电之中都没有倒下,最终却死在一群小昆虫的口里。 言归正传,现在我要揪出个人认为导致项目失败的两大隐形杀手:范围蔓延和过度承诺。 “过度承诺”,最常见原创 2010-08-31 17:16:00 · 576 阅读 · 0 评论