敏捷迭代开发

2004-1  

电子工业出版社  

[美]CraigLarman  

342  

488000  

张承义  

无  

　　 对于迭代开发，著名的方法大师Craig
Larman通过统计意义上的重要研究，以及大规模的项目案例分析，为读者呈现了最具有说服力的观点。Larman简要而又涵盖大量信息的总结，是驱动敏捷和迭代过程的关键所在；这个总结还详细阐述了4个重要的迭代方法--Scrum、XP、UP和Evo，全书主要包括了以下几个方面的内容：
　　 ●迭代方法对于减少项目风险的令人信服的证据
　　 ●FAQ
　　 ●敏捷与迭代的价值与实践
　　 ●许多实用的敏捷与迭代技巧
　　 ●适用于敏捷／迭代项目主管的新管理技能
　　 ●Scrum、XP、UP和Evo的关键性实践
　　 无论你是IT主管、项目经理、软件工程专业的学生还是软件开发人员，Craig
Larman都将帮助你理解敏捷和迭代开发的优点，并在整个组织中推行它，从而将这些优点变为现实。

　　Craig
Larman是Valtech公司的首席科学家。而Valtech公司是一家国际化的技术咨询公司，在欧洲、亚洲和北美洲都设有分支机构。同时，他还兼任独立顾问、团队教练、演讲人等职务。
　Craig是(Applying UML and Patterns：An Introduction to
Object-OrientedAnalysis and
Design(UML和模式应用：面向对象分析与设计导论)》的作者。此书是OOA／D和迭代开发方面全球最为畅销的书籍，被译成多种语言，并在世界范围的工业和大学中广泛运用。

译者序
序
第1章　简介
　软件是新产品开发
　后续内容预告
　web资源
第2章　迭代和渐进
　迭代开发
　风险驱动和客户驱动的迭代计划
　时间箱迭代开发
　迭代期间，外部利益相关人员不能变更迭代内容
　渐进和自适应开发
　渐进需求分析
　早期"排名前10"的高级需求以及技能性分析
　渐进和自适应计划
　递增交付
　渐进交付
　最常见的错误
　特定的迭代和渐进方法
　后续内容预告
　推荐读物
第3章　敏捷
　敏捷开发
　方法分类
　敏捷宣言和原则
　敏捷项目管理
　拥抱沟通和反馈
　以人为本的编程
　简单的实践和项目工具
　经验型过程与规定型及指令型过程
　基于原则与基于规则
　可持续规程--人员接触
　团队作为复杂的自适应系统
　敏捷是在夸大其词吗?
　特定的敏捷方法
　后续内容预告
　推荐读物
第4章　故事
　后续内容预告
第5章　动机
　软件项目中变化的事实
　迭代开发的关键动机
　迭代地迎接需求挑战
　瀑布型的问题
　后续内容预告
第6章　证据
　总结
　研究的证据
　早期迭代项目的证据
　标准体系的证据
　专家和思想领袖的证据
　迭代开发的商业案例
　瀑布型有效的历史事件?
　后续内容预告
　推荐读物
第7章　scrum
　方法概览
　生命周期
　工件、角色和实践
　价值观
　常见错误和误解
　样板项目
　过程混合
　采用的策略
　现实与幻想
　优势与"其他"
　历史
　后续内容预告
　推荐读物
第8章　极限编程
　方法概览
　生命周期
　工件、角色和实践
　价值观
　常见错误和误解
　样板项目
　过程混合
　采用的策略
　现实与幻想
　优势与"其他"
　历史
　后续内容预告
　推荐读物
第9章　统一过程
　方法概览
　生命周期
　工件、角色和实践
　价值观
　常见错误和误解
　样板项目
　过程混合
　采用的策略
　现实与幻想
　优势与"其他"
　历史
　后续内容预告
　推荐读物
第10章　evo
　方法概览
　生命周期
　工件、角色和实践
　价值观
　常见的错误和误解
　样板项目
　过程混合
　采用的策略
　现实与幻想
　优势与"其他"
　历史
　后续内容预告
　推荐读物
第11章　实践技巧
　项目管理
　环境
　需求
　测试
第12章　常见问题解答
　问题列表
　问题和解答
参考文献
索引

无

敏捷迭代开发 PDF格式下载

不错，是好书，翻译的不怎么样

　　2008年春，项目做的对敏捷有了点兴趣，花了两个晚上浏览了《敏捷迭代开发——管理者指南》，理念式的书，看起来比较轻松，摘录一些自己的体会。
　　
　　原文在 http://iamsujie.com/7000/7008/，欢迎大家来探讨相关话题
　　
　　有些需求在开始的时候是提不出来的，或者说没法细化的，强行的过渡需求分析是浪费时间的行为，到后来多半还是要改。
　　
　　瀑布（其实Royce大大提出的瀑布模型初衷里也是有迭代思想的，不过被后人误读了）的问题是最后集中暴露矛盾，当然对需求固定的项目还是不错的。
　　
　　敏捷迭代开发，如果断章取义是极其危险的，比如没有迭代的测试跟上，到最后发现问题的时候就已经晚了。
　　
　　介绍了四种敏捷的模式：Scrum、XP（极限编程）、UP（统一过程）、Evo（Evolutionary Project Management），他们的共同点如下：
　　
　　Ø 拥抱变化，大问题分而治之，先解决最核心的，风险最大的部分。
　　
　　Ø 会议室中集体工作，每日例会（<20min），站立会议，充分利用白板和墙壁。
　　
　　（iamsujie补：每日例会每个人说三句话：昨天做了什么，今天要做什么，碰到什么问题。）
　　
　　Ø 较短的迭代周期，通常一周到一个月，团队人数不要太多（小于十几人），太多了可分割为多个团队。
　　
　　Ø 一个迭代周期内绝不再加任务，有多的需求放入以后的迭代，如果迭代周期内任务无法完成，可以为了时间点的要求，移出一部分任务到下一个迭代。
　　
　　Ø 把迭代周期内的事情列出来，很小时间粒度（天为单位）的跟踪。
　　
　　Ø 不停的发布/交付，让需求方看到结果，获取反馈。
　　
　　Ø 需求方充分投入，包括需求人员一起办公，验收测试的迭代。
　　
　　Ø 需求方代表要有话语权，不然半途杀出个老板说三道四是极其郁闷的。
　　
　　Ø 轻文档，通过开发和测试来细化和纠正。
　　
　　Ø 程序员自主选择任务点，安排时间点。
　　
　　Ø 反对加班，这点其实很难做到，特别是在中国，呵呵。
　　
　　Ø 极其多的口头沟通，其实这点对团队成员要求很高，特别是对中国的技术人员。
　　
　　Ø 强调测试，更早的测试（TC编写早于coding），重度的测试，测试驱动项目。