FreeOZ论坛

标题: 谁有关于敏捷开发的PDF或者PPT比较好推荐一下 [打印本页]

作者: xblues 时间: 21-4-2010 14:42
提示: 作者被禁止或删除, 无法发言 标题: 谁有关于敏捷开发的PDF或者PPT比较好推荐一下
谢谢！

作者: coredump 时间: 21-4-2010 14:54
http://docs.google.com/present/v ... kboard&cwj=true

作者: xblues 时间: 22-4-2010 10:59
提示: 作者被禁止或删除, 无法发言 标题: 回复 #2 coredump 的帖子
上面那个教程不错，很简洁明了。
具体介绍了敏捷方法和极限编程。

我想知道在具体开发组里面，这个极限编程用的多么？真的跟一般的开发方式很不一样啊，首先就是那个配对编程，然后就是那个便条形式的需求，再有就是和程序员新密接触的客户代表。

谁是专门搞开发的，说说你们项目组里运用敏捷的实际情况吧。

作者: coredump 时间: 22-4-2010 11:05
标题: 回复 #3 xblues 的帖子
不能全部照搬的，哪个适合用就用哪个。

一般来说，测试驱动开发和持续集成采用度较高，还有stand-up meeting 。

结对编程，一般来说可以弱化为code review，每个提交都放在review board里，找人看一下，不一定非得2个人一个键盘那样极端。

作者: xblues 时间: 22-4-2010 11:16
提示: 作者被禁止或删除, 无法发言 标题: 敏捷开发体会
http://tech.it168.com/a2009/0508/275/000000275467.shtml

1) 注重概念和架构设计，而轻详细设计
2) SWOT分析： Strengths, Weaknesses, Opportunities, and Threats
3) 业务和客户驱动，而非技术驱动(业务人员和开发人员必须天天都在一起工作)
4) 时刻考虑版本兼容性
5) 轻文档，但非无文档:文档包括：概念设计文档、架构图、当前版本要实现的功能列表，以及SWOT分析。而且这些文档，大多是几页PPT，书写和维护工作都很小。

传统设计

敏捷开发

主要不同：
敏捷开发把总体的详细设计文档去掉，取而代之的是针对各个功能模块的详细设计，取消原来统一的封闭式开发，把整体开发工作分成很多模块，按逐个模块完成。

优点：
市场和需求驱动，拥抱变化
充分利用资源和时间
每日交付
充分自动化：编译自动化、单元测试自动化、功能测试自动化、UI测试自动化、集成测试自动化

作者: xblues 时间: 22-4-2010 11:17
提示: 作者被禁止或删除, 无法发言 标题: 回复 #4 coredump 的帖子
两个人一个键盘，从而杜绝了上FreeOZ的可能性！！！
因为一个人发贴，另外一个人只好看着，会吵架的！

作者: coredump 时间: 22-4-2010 14:03
标题: 回复 #6 xblues 的帖子

作者: xblues 时间: 22-4-2010 14:26
提示: 作者被禁止或删除, 无法发言 标题: 回复 #7 coredump 的帖子
老丐，你们是不是一个人霸占一个键盘（但是共用一台显示器！）？

作者: coredump 时间: 22-4-2010 14:43
标题: 回复 #8 xblues 的帖子
我是2太机器，3个手机一起霸占1个显示器和一个键盘

我在旁边伺候它们，被它们蹂躏

作者: xblues 时间: 22-4-2010 14:46
提示: 作者被禁止或删除, 无法发言 蹂躏？无图无真相！

作者: xblues 时间: 22-4-2010 19:53
提示: 作者被禁止或删除, 无法发言 http://group.mosh.cn/g/1552/topic-index-tid-11626.html

1、敏捷开发与传统软件工程的比较
传统软件工程：规范化的文档，持续改进的软件过程
敏捷开发：密切的交流与合作，逐步细化的开发过程
两者的区别好比重型武装部队与特种部队的区别
人员变更大，人数较多，成员分数，模块通信量大，耦合性强，维护时间长，开发过程有长期性，社会性的项目不益采取敏捷开发方法

2、4条核心价值观
（1）个体和交互胜过过程和工具
敏捷开发很强调个人能力
它以沟通和个人能力代替了定义死了的过程
（2）可以工作的软件胜过面面俱到的文档
它强调迭代式的开发，以开发的一个个版本形象的说明了需求，便于客户联想，也便于团队沟通演示
（3）客户合作胜过合同谈判
这条有过项目经验的人都能理解，与客户成为朋友比固定死的合同有用得多
（4）响应变化胜过遵循计划
它强调沟通，从而更积极的拥抱变化，并随时调整

3、敏捷开发的基本原则
（1）尽早、持续交付有价值的中间软件
（2）响应变化创造竞争优势
（3）业务人员与开发人员一起工作
它的目的是强调大家建立频繁密切的交流
这是一种帮助大家沟通的方法
这里的业务人员是指需求人员，开发的时候当然需要了
但是肯定不直接参与软件编写过程
（4）团队内部面对面的沟通
（5）根据完成了的功能调整工作进度
这是一种帮助大家沟通的方法
这里的业务人员是指需求人员，开发的时候当然需要了
但是肯定不直接参与软件编写过程
业务人员指的是了解客户需求的人员
熟悉业务的人
（6）重构代码，保持代码健壮
（7）尽快完成目前已知的需求
强调把不了解的需求放到以后，不考虑太多可能性
不考虑太多可能性是指不考虑变化的可能性
先做好已知的，定义好的，持续形成新版本，客户可能会想到需要什么
很多客户并不是一开始就知道自己要什么
你给他一个东西用用，他会觉得好，还需要什么
或者哪里不好，需要改动
很多时候客户有很多需求，我们需要做的是帮他找到重点，理清流程，帮助客户提高主要的工作的效率才是目的
大家要始终知道，敏捷开发是一种开发方法，遵照执行可以对你的工作提供效率，而不是必须遵守的。

作者: xblues 时间: 22-4-2010 19:59
提示: 作者被禁止或删除, 无法发言 标题: 这段写的很好！
二、极限编程简介
个人觉得极限编程是一系列方法的组合
1、特点：轻量、柔性、充满乐趣
2、XP的价值观
（1）沟通
（2）简单
（3）反馈
（4）勇气
其实前三点刚才敏捷开发方法已经讲了，重点就是勇气
不是重点，是我要讲的重点
勇气其实和拥抱变化是一个意思
勇气还指不断的重构代码
勇气就是甚至引导客户去变化
使之成为一种竞争优势
3、基本原则
（1）快速反馈
（2）简单性假设
（3）逐步修改
（4）提倡更改
（5）优质工作
第（5）点是很多优秀的程序员容易犯的错误
很多优秀的程序员喜欢设计，觉得思路是最重要的，很多时候把思路理顺了，不愿意把问题完全解决好，总是留些小尾巴。但是后面又更不愿意回有修补好
比如很多人写TRY加个CATCH，然后就不写出错处理，想等最后一起写，实际上再不会回头看了

三、重要概念解释
这里的概念实际上很多就是一些小方法，我重点讲解一下，希望能引起大家的兴趣，使大家更详细的研究XP方法

用户故事:
就是面对面的请用户描叙自己工作的步骤，可以用UML，也可一用小卡片
也可以用最平实的语言描叙，当然你一定要记录下来，这个是需求分析的依据
迭代式开发：
迭代方法有没有人不懂？
迭代式开发就是不断的交付新版本，但是不是修改性质的，而是不段精化的
隐喻：
我觉得就是对事物的约定俗成的叫法
比如很多人把DOTNET高手叫大内高手（DOTNET读音和大内读音很近似）
这里的约定俗成是为了更方便的交流，更愉快的沟通，大家把平时这些比喻收集起来，和客户交流，和团队成员交流的时候就可以这样说
就象现在把女朋友叫老婆，难道你会不懂吗？
简单设计：
粗略的设计，不考虑各种可能情况，只设计主要类
测试先行：
测试先行是现在很提倡的开发方法，是很值得研究的
好比砌砖头，先拉一个水平线，每砌一快砖都对比一下
如果你全部砌完了再看对得齐不齐是不是有点晚了
测试先行的方法之一就是写每个模块之前先写测试代码，并且在每次改动之前测试一次
这样是很正确的思路，其实一点也不复杂，就象在学校写程序的时候，要也MIAN（）方法测试一下结果，你写好了以后，再测试就很方便了。而且不用进行很复杂的测试
重构：
我用三个词解释，就是重思考，重设计，重编码。
不断的找时间重构自己的代码是提高自己能力的很重要的方式
结对编程：
结对编程不是结队编程，是2个人，不是更多
有谁亲自试过
我个人不喜欢结对编程，但是建议大家工作不忙的时候可以试试，至少可以提高大家的交流度
结对编程主要目的是让大家更好的交流
敏捷开发的基本原则就是沟通
持续集成：
将所有模块经常性的整合，以及时发现与系统有冲突的问题
典型的就是微软团队的：每日构造
微软的每日构造甚至到了变态的地步，要求每天集成测试，发现问题，就算是凌晨也会找到你，要你立即修改
现场客户：
这是一种夸张的说法，其实就是经常和客户面对面的交流，演示，和现场开发差不多
编码标准：
团队采取统一的编码标准，避免就个人习惯，个人爱好等细节问题产生争论。

总之极限编程就是要求团队与客户密切的沟通，团队最好是长期合作，和客户交朋友。
希望本次讨论能让大家更加热爱编程，更积极的于他人沟通，更热情的拥抱变化。
并预祝大家能利用此方法更充分的发挥自己的潜力，在职业道路上一帆风顺。

作者: xblues 时间: 22-4-2010 20:24
提示: 作者被禁止或删除, 无法发言 标题: 态度不同
http://jamesshore.com/Blog/Should-We-Adopt-Scrum-or-XP.html

Scrum's focus is "let's create a self-organizing team" and
XP's focus is "let's create excellent software."

SCRUM提供了一个管理方法
XP重点在如何精炼软件本身

作者: hoopoos 时间: 23-4-2010 11:59
其实我以前在上海工作的几年，欧洲团队早就引入了敏捷开发的模式，只不过他们没有明确的提出这些概念，可能是认为我们只需要follow不需要去搞的那么清楚。

总结起来是最重要的下面几点，非常有用

一，分阶段的迭代开发，新功能需求或者修补需求会按照优先级和重要程度以及难度排序，分割成若干milestone，每个milestone是一个独立的需求分析开发测试的完整周期。

二，需求queue被划分成树型的结构，最末端为不可再分的一个需求，然后与此对应，有相应的树形开发queue和测试queue。有三个teamREQ，DEV，QA的相应人员各自认领queue中的ticket

三，重视会议交流而非文档，通常每天早上会有一个简短的全team stand up的会议通报各自的进度，然后不定期有需求组的人员主持小型会议向developer和tester做需求解释

我们当时的team是做ERP产品的，虽然竞争不过SAP，但是设计和管理的水平还是比较高的，在美国人全面带领IT领域技术进步的时候，欧洲人也有他们自己对于先进理论的实现，在学术上欧洲和美国是不分上下的，在实践上美国的技术更流行，但是欧洲也有他们自己的技术。

作者: Melodyy 时间: 23-4-2010 21:09
这本书不错：
Applying UML and Patterns (Craig Larman)
-- An Introduction to Object-Oriented Analysis and Design and Iterative Development

有比较全面系统的介绍。

作者: JBengonsen 时间: 25-4-2010 20:48
如果是Agile Development, 推荐 敏捷软件开发：原则、模式与实践这本书，英文名是Agile Software Development: Principles, Patterns and Practices

欢迎光临 FreeOZ论坛 (https://www.freeoz.org/ibbs/)