经管08018_XP起步:其它部分

“XP起步”部分,到现在已经把正确的思维习惯介绍完毕。

而这些方面:
1、简单设计;
2、共享代码所有权;
3、编码标准;
4、每周40小时工作制
会自然的依序出现。

其它的:
1、现场客户;
2、验收测试;
3、教练和跟踪者
就可能要花花一些时间。

一、简单设计:
1、运行所有测试;
2、不包括重复代码;
3、清楚地表现出程序员对全部代码的意图;
4、包括尽可能少的类和方法。

简单的才会保留下来!

如何做到简单设计:
1、首先写验收测试;
2、保持每个类只负责一件事;
3、使用Demeter法则;——待介绍
4、使用定性的概念;——待介绍
5、使用CRC卡片(白板)来探索;——付诸行动!离开电脑(开发环境),在白板前进行设计

二、代码所有权
开发团队中的每个人都具有权力和义务修改它。
纪律——单元测试+代码版本控制

三、现场客户
如果客户没有给你提供一个全职的、一流的合作人员,请求他们免除这个项目。
因为他们不是认真的。
例外:
1、管理者或者开发者之一就是领域专家;
2、做探索性工作,客户也不知道自己想要什么;
3、已经有良好的沟通渠道。

四、验收测试
知道你什么时候做完。
单元测试给开发人员信心;验收测试给客户信心。
验收测试是开发者和客户直接的合同。
如何写验收测试?什么时候写验收测试?测试什么?
自动化验收测试。
功能测试与单元测试。功能测试应该是开发人员跟很多测试人员共同完成。

五、编码标准
保持团队不会被无用的小事弄得心烦意乱。
格式化编辑工具+好的易于执行的协议!

六、加班不是答案
“可持续发展”!
加班:你不想工作的时候而花费在工作上的时间。

七、一幅画胜过千言万语
找到好的“比喻”

八、寻求指导
跟一个伟大的老师学习1天,胜过自己勤奋的学习1000天。

九、保持记录
搜集数据、保持记录、做好跟踪:
1、鼓励每个人更好的估算;
2、更好的识别项目进度;
3、识别出问题的范围。
跟踪:
1、估算和实际执行的情况;
2、创建的和通过的验收测试。

wiki!

经管08017_XP起步:持续集成及过程至上

“持续集成”:降低风险、更易查错、保持速度。
 
如何持续集成:
1、每个配对做足够的单元测试;
2、“集成机器”——公用;
3、保持代码最新;(版本控制和管理)
 
到达任何地方都没有捷径可走。
始终停留在过程中,不要偏离方向,注意:
1、提高注意力;
2、使漂流趋势更明显;
3、保持领先;
4、行为规律;
5、避免最后期限的压力;
6、首先考虑广度;——产品的业务价值
7、与客户重新协商;
8、一起坚持
9、推迟非业务的细目;
10、偶尔加班;
11、了解并跟踪方法的效果。

经管08016_XP起步:关于“重构”

使代码运行,使代码正确,使代码运行得更快。
 
重构,使代码正确。
重构,使代码简单。
 
增加代码比删除代码更容易。
使变化成为可能。
将所学知识运用到代码中。
 
使变化的风险减小,使优化更容易。
 
如何重构:
1、先编写运行测试;
2、先编写代码,然后在重构代码;
3、将增加新的功能视为重构代码的机会;
4、将纠正错误视为重构的机会。
 
何时重构:
不要拖延时间,看到机会就重构。
 
什么时候不需要重构:
1、在代码不能工作或者需要重写代码的时候;
2、在不确定如何能使重构进行得更好的情况下;
3、不要凌驾于客户的需要之上进行重构。

经管08015_XP起步:关于“结对编程”

结对编程的好处:
1、代码质量
2、速度——代码、沟通
3、降低风险——交叉培训

如下几个因素增加了项目失败的风险:
1、进度缓慢;
2、缺乏充分的沟通;
3、过分依赖于个人英雄主义行为。

如何进行结对编程:
1、驾驶员和领航员——互换:
2、交换配对——不要在一个任务进行的过程中交换配对
3、经常休息
4、坐在汽车后座对司机有影响的人
5、花一些时间学习工具
6、花一些时间来创建共同的词汇表
7、将设计讨论局限在一个小范围内
8、不要放弃
9、物理环境要适合结对编程
10、开发环境标准化
11、排除异己!
12、尊重和爱!

什么时候不需要结对编程:
1、探索新的事物;
2、针对有可能产生错误的问题上,有多种想法时。

在结对编程和单独编程之间寻找折中。

经管08014_XP起步:关于“测试”

成功并不是不允许犯错误,而是不能犯同样的错误。

测试用例:
1、保持代码的简洁
2、将测试用例视为文档(比文档更直观、更详细、更有效、更有价值,并且永远是最新的)

编写测试用例:
1、测试例运行失败
2、重构代码、重构测试用例

测试/代码 步骤:
1、编写一个测试用例;
2、编译这个测试用例;
3、编写足够的测试用例编译所需要的代码;
4、运行测试用例,测试失败;
5、编写足够的测试用例通过所需要的代码;
6、运行测试用例,测试通过;
7、为达到代码简洁清晰的目的,重构代码,一次且仅一次;
8、重复以上步骤。

采用尽量小的步骤、经常编写测试用例、采用尽量小的步骤。
写小的测试用例、少的代码、使测试通过。
做一次修改、如果测试失败、一定是这个修改引起。

测试什么:积累的过程!——学习已有的开源项目。

如何开始:用测试框架(如jUnit),调用部件库、方法、功能编写代码。

测试的挑战:
1、测试用户界面:用户界面与后台业务逻辑分离
2、在一个小的空间中做测试
3、测试Web
4、测试需要运行速度足够快

经管08013_XP起步:关于“计划”——迭代计划

不允许做修改的计划就不是一个好的计划。

故事卡片分类注意:
1、商业价值以及其他能帮助客户决定优先级的事情;
2、开发团队的开发速度。

每次迭代开始时,预留一些时间,审查上一次迭代工作。
每次迭代开始时,做迭代计划,通常为半天到两天。
迭代计划是发行版本计划的缩影。

迭代计划中涉及的工作:
1、演示并讨论上一次迭代中所完成的工作。  <1H
2、讨论下次迭代中应包括的内容。 1H-2H
3、任务探讨。 4H-8H
4、迭代计划验证。 4H-8H
    一次做一项任务
    装满您的袋子
(时间估算依据8-10的项目)

估算是一种艺术。需要经验,没有经验靠猜测。
讲求速度!

XP方法中:没有分析阶段、设计阶段、测试阶段和维护阶段。
XP方法中:重要的就是计划和实施计划。
    计划中:
        客户陈述他们希望实现的功能(故事)
        开发人员努力将其变成现实(迭代)
       
两者都要清楚项目的进展情况(对上一次迭代的审查)
    计划的实施:
        写出我们希望实现的功能(测试)
        努力将其变为现实(代码)
       
确保我们已经清晰的理解了我们实现的功能(重构)

经管08011_XP起步:关于“计划”

我们并不能总是时刻控制局面,但是,通过使用简单的规则和工具我们可以避免做愚蠢的事情。
  129
业务决策和技术决策的分离!使客户和开发人员各自明确自己的角色。
1、业务决策:决定费用如何分配等问题的,以获得更好的利益回报;
2、技术决策:决定为实现业务目标应该采用哪些方法,以及采用这些方法的费用估算。
1、客户:决定应该完成的工作以及按什么顺序(优先级)完成这些工作;
2、开发人员:决定完成这些工作的方法并估算完成这些工作所需要的时间。
 
制订项目计划的原则如下:
1、允许项目之初有不完整的需求;
2、所有团队成员都应该参与计划,但是角色一定要清晰;
3、所有参与者要持续的保持沟通;
4、通过频繁地调整计划来适应开发过程的变化;
 
需求是一种对话,而非文档。
在做计划及工作量估算的时候,必须做的事情:
1、确定项目的基本需要;
2、将这些需要分解成小的、重要的用户故事;
3、确定详细的验收准则(例如验收测试),这些验收准则是验证用户的需求故事是否能完全实现。
——达成这些的最好的方法:
让业务人员和开发人员一起工作!
 
两个开发人员在白板前进行的对话是最有效的沟通方法;其次是业务人员和技术人员之间巧妙地运用故事卡片。
 
当客户的“黄金所有者”“目标定义者”不是一个人,尽量让他们意见一致。
 
客户不喜欢某一个估算值通常是因为以下的两种原因之一:
1、认为整个故事的价值不需要花费那么多费用:故事不像最初表达时那样重要,或者可以用更简单的故事代替,费用也相应减少;
2、客户没有意识到故事的复杂本质:好的教育机会,开发人员向客户解释实现故事必须做的事情,挑最难处理的一两件解释。
  
引进可行的工具——CASE卡片板辅助软件工程
卡片:故事及其细分任务的概要描述+优先级
故事卡片+任务卡片=更好的沟通
卡片优先级的确定!!!
1、高——能实现系统性能的最新而必要的功能;——没有这些故事,产品就无法发布;
2、中——真正有价值而必要的功能;        
——没有这些故事,产品就不会在市场上占据重要地位;
3、低——有了这些功能系统将变得更完美;    ——有这些故事当然更好。
 
的确,二八原理;我们80%的精力总是被耗费在细节上,而不是主要功能上。
优先级的划分,真的非常重要!好钢用在刀刃上!
  
  148
极限小时——一个小时的时间对产品的最初版本做计划、进度表、开发以及质量保证:
1、10分钟——用户故事及结构峰值:业务团队-(项目保管员-索引卡片正面撰写故事;质量保证人员-卡片背面编写测试;)开发团队-画原型图;

2、10分钟——估算优先级和范围:必须有的;没有会造成很大损失的;有了会更好的。
3、 5分钟——最初承诺的时间表:开发团队对每一次迭代的大概时间都要做出承诺。
4、10分钟——第一次迭代:开发人员看是否需要将故事分解成任务,并接受任务、配对;质量保证人员决定各个配对何时通过测试;管理员与市场人员进行沟通-添加故事/随时回答开发人员问题。

5、 5分钟——计划第二次迭代:调整期望的效率和估算;开发团队需要知道他们要做的工作;业务团队要知道他们所期望的结果。
6、10分钟——第二次迭代:同4;业务人员开始考虑在将来的展示会上如何展示预期产品。
7、 5分钟——发布版本和新的承诺时间表:展示会及下一版本产品宣传。
8、 5分钟——大型展示会。

经管08010_XP起步:关于“沟通”

多数谈话都是在有证人的情况下,某个人发表的长篇大论。
——Margaret Miller

任何软件开发项目的成功都直接与沟通成正比!

为了让他们了解你现在的一切,你会:
为他们写文档吗?
写每周状态报告吗?(我甚至被要求每天写工作报告)
如果在同一座办公楼里工作,给他们发过电子邮件么?
如果你很关心他们的近况,你会安排一间会议室,邀请所有你关心的朋友,然后规定他们答应你在最短的时间里做很多的事情吗?

——很遗憾,这些事情我都碰到过,但是我希望你不再会这么做!

XP通过以下4种实践帮助和促进开发人员做面对面的沟通:
1、结对编程(并经常改变配对)——通过口头讲述和解释代替大多数的文字文档,通过配对传播信息:应对人员流动风险。只在需要文档的时候编写最需要的文档,将更多的时间放在查看代码和与人交流上,会收获更大!

2、每天早上召开站立例会——提出自己的困难;找到能帮助自己的人;发布开发和准备过程中的惊喜;确保每天开始时都在做正确的事情。不要过分讨论细节问题!让牛人说话和分享,而不要神秘感或者有所保留;控制例会时间。

3、计划(实质上就是与客户的相互之间的谈话)——交流、沟通、倾听。客户和开发人员沟通。
4、鼓励即席沟通的团队气氛和环境——四处看看,当人们遇到棘手的问题寻求帮助时、在同班陷入困难时拉他一把,帮助需要帮助的人!工作场所布局合理,不要隔间!要白板!要大桌子!

沟通沟通沟通沟通!

经管08007_XP的理念:树立正确的态度

在一个充满谎言与欺骗的环境中,XP是不可能发挥作用的。
尝试XP需要勇气。
 
1、诚实和信任——XP不需要外交辞令。透明化、公开化。客户和开发人员坦诚相待、按计划行事。
    计划:
       
很多重量型开发方法预先做详细的计划,大部分计划都是建立在猜测的基础上,都会与实际产生偏差。
       
XP中做计划基于这样的前提:需要每一步都确认我们知道什么,不知道什么。我们根据初步需求(故事)的初步估算形成了一个初步的项目计划。

       
在一个迭代开始前,将详细的计划整合在一起。
       
迭代间隔简短,可以保证开发人员和客户的频繁及时沟通,了解项目进展。
    结对编码:
        坦诚相待、共同拥有代码。
        工作环境应该有很少或没有空间屏障。
        每天的站会上,交流最近的工作情况。
当然,XP也需要机智和变通。
   
2、谦逊
加入到极限编程软件工作室来吧……因为在这里你每天都感觉在进步!
允许自己犯错误,每个人都会犯错误!
XP团队中的每个成员都应该经常感觉自己很笨,这才是健康的。

 
3、甜蜜的自由
无拘无束的讲真话!
客户跟开发人员之间互相信任、坦诚相待,而不是开发人员给客户虚假的难以达到的许诺!
互相支持的环境、互相学习,共同进步!
对别人和自己诚实,必须谦逊;做到谦逊,就可教也;可教后,就会进步;进步了,就可以运用学到的知识获取更大的成功。

经管08006_XP的理念:非传统战略——克服来自经理和开发人员的抵触

XP让人感觉很不舒服,人们会抵制它。这种抵制来自恐惧和骄傲。通过将使用XP作为一种战略,可以客服这些情绪,增加获胜的机会。

1968年奥林匹克运动会,Fosbury带着他的“Fosbury跳”一路过关斩将,获得金牌并创下了新的奥运会记录。“Fosbury跳”不同于以往面对横杆劈腿跳的方式,而采用后背过杆并且肩膀先着地。坦白说,这看上去很蠢!但是,人们很难用传统方式击败使用非传统方式的获胜者。

XP就是一种非传统战略!使用它,可以开发出按时交付并具有很高商业价值的伟大软件,而且不需要开发人员加班加点的工作!使用XP,会增加获胜的机会!

最后,不要只为XP而关注XP,不要成功一个狂热的XP追星族,反而忽略了产品方面的问题!

XP只是手段,而不是目标!

克服来自经理的抵触
——经理们会反对使用XP,因为他们在方法选择上有着错误的假设。将问题的焦点放在降低软件开发费用上,他们就不再反对了。
1、了解经理的目标,帮助经理成功
2、开发成本——研发和修改的金钱、时间;留住高级开发人员;普通开发人员的贡献。
3、可能的反对意见:
   
XP不成熟——不试过又怎么知道呢?实践是检验真理的唯一标准!现在的状态就没有风险么?就是最好的么?穷则变!
    XP过分简单——kiss,简单就是美;XP简单,但是不过分;大部分文档不必要。
    结对编程成本太高——一个臭皮匠,弄死三个诸葛亮:-)
   
全职现场客户难以应付——防止开发人员等待客户或者猜测需求;典型的需求文档只有15%是完整的,7%是正确的。
   
XP太不正式——不要试图用有趣的PowerPoint幻灯片和PDF文档来掩盖问题。提供足够的文档,但绝不要提供不必要的文档:计划游戏、系统隐喻、需求故事、测试用例(关注结果)。

   
“XP的局限”——不要将XP当做百宝箱,什么都从里面拿,要知道他是一个整体,单一的实践可能立即产生正面的影响,从而让人们接受随后采用的其他实践,但是有可能造成不良后果。如:开发人员仅偶尔结对编程、不再编写文档,这样会缺少有价值的反馈。

   
克服来自开发人员的抵触
——开发人员会反对使用XP,因为他们可能看不到XP的优势。将问题的焦点放在XP的支持环境上,他们就不再反对了。
1、开发人员,喜欢跟机器交流,不喜欢跟人沟通。
2、开发人员希望:
    开发软件,而不是编写文档或整日开会;
    为自己开发的软件产品而自豪;
    工作中得到乐趣;
    一旦软件发行,再也不用去维护该产品。喜欢新的挑战,而不是给老代码补补丁。
3、可能的反对意见:
   
XP过分简单——真正含义是:“我学过其他软件方法,我的工作也因此取得了成绩,我不想再倒退。除此之外,在编程上我已经不像以前那么出色了,因为我还要花很多时间做一些‘更高级别的事情’。”

   
我不喜欢结对编程——开发人员不习惯成群的狩猎;而且认为没有个人代码的拥有权,就很难成为编程英雄。强调知识共享、改进代码质量及增强士气。(开发人员不喜欢代码被审查,也不喜欢审查别人的代码,尽管审查已经被证实在保证软件质量方面起着巨人的作用。几项研究同时表明,代码审查是对代码质量的最大贡献,甚至超过了测试!)结对编程比同行评审有过之而无不及!

   
XP稀奇古怪——编写代码前先编写测试用例并运行测试用例–代码变简单,因为仅需要通过测试即可,也不再担心别人修改自己的代码,测试用例也被当做很好的文档;允许不断改进设计以符合变化的需求–渐进的递增的设计,需求中的变化不是大量修改的借口;结对编程,经常要共享单个键盘和鼠标。

   
XP没有提供足够的信息——开发人员不喜欢创建文档,甚至一个都不想创建,但是他们喜欢有足够的信息指导工作。经常有没有足够的设计文档,过分依赖需求故事代替规格说明书,XP导致失败!把代码当做最好的文档!XP不是建议不编写文档,而是说不应该花时间去创建不毕业的文档。

   
——必要的文档:面向维护——wiki风格的常见问题数据库(10个类一页);技术备忘录(20个类一页);清晰一致的验收测试规则;测试用例和代码

    ——每天一个短会;测试用例针对逻辑而不是UI;需求和估算写在卡片上。