lated对《敏捷武士》的笔记(8)

敏捷武士
  • 书名: 敏捷武士
  • 作者: [加]Jonathan Rasmusson
  • 副标题: 看敏捷高手交付卓越软件
  • 页数: 185
  • 出版社: 人民邮电出版社
  • 出版年: 2012-6-25
  • 第124页
    在敏捷项目中,需要完成如下这些任务。 编写自动化测试。 不断地演进并提高我们的设计。 持续集成代码,生产可运行的软件 确保我们的代码符合客户谈论系统时使用的语言。
    2013-08-21 20:49:16 回应
  • 第134页
    你昨天为了改变现状做了些什么。 你今天打算如何将其完成。 你打算如何清除那些挡在前进道路上的障碍。
    2013-08-21 21:24:18 回应
  • 第149页
    单元测试之所以很有价值,原因在于一旦将其自动化并使其容易运行后,每当对软件有所改变,我们都可以运行一次测试,然后立刻就能明白是否破坏了一些东西。
    2013-08-22 06:34:56 回应
  • 第158页
    重构的核心要义其实就是:要时刻提醒自己,软件是由我么自己编写并维护的。如果不能轻松地修改软件,工作起来毫无乐趣,那么当需要修改或添加新功能时,我们又怎能从中感到由衷的喜悦呢?
    2013-08-24 15:24:18 回应
  • 第5页
    在敏捷项目中,总故事列表就是项目待做事项列表。它包含了所有的高级别特性(用户故事),而这些正是客户希望在他们的软件中能见到的。客户对其设定优先级,开发团队会对其进行估算,而这正是形成项目计划的基础。 敏捷项目中的核心就是迭代,在一周至两周内选取客户最重要的故事,然后建起转化为可运 行的、测试过的软件。 团队成员通过测算团队速率来决定需要承担多少工作(每个迭代周期可以完成多少)。通过追踪速率并预测未来所能完成的任务量,你的计划就可以实事求是,从而避免团队夸下海口。 如果你和客户面临的任务过多,那就先做唯一能做的事--少做一些。在范围方面要灵活处置,也就是要学会平衡计划,并将承诺变为现实。 当现实与计划相悖时,就应该改变计划。适应性强的计划是敏捷交付的基石。
    2013-08-24 17:52:46 回应
  • 第7页
    三条简单原则 1)在项目的初期不可能收集到所有的需求。 2)不管你收集到什么需求,最终他们肯定都会发生变化。 3)总会有任务超时、超支。
    2013-08-25 06:56:23 回应
  • 第11页
    集中办公 怎样才能极大地提高团队的生产效率呢?答案是让每个人都坐在一起。 集中办公的团队效率就是要高一些。问题不仅可以很快地在现场得到解决,而且彼此间的交流也会更加顺畅,并能很快建立起信任。集中办公的小型团队竞争力是非常强的。 虽然相比紧凑型集中办公的团队,分布式团队总会有些劣势,但仍可以用很多办法来加以弥补。 比如,在项目的初始阶段,为了将所有人都召集在一起,你要预留一些时间。哪怕是只有几天也好(如果能延长到几周就更好了),大家在这段时间内互相认识一下、开个玩笑、一起吃个饭,这非常有助于你把形形色色的人聚集在一起,打造成一个紧凑高效的团队。因此,在开始阶段,就要将所有人都聚在一起。
    2013-08-25 07:03:03 回应
  • 第70页
    比尔韦克提出过一个理论,首字母缩写为INVEST,也就是“独立的、可协商的、有价值的、可估算的、小型与可测试的”(Independent,Negotiable,Valuable,Estimatable,Small and Testable)。
    2013-08-25 11:59:04 回应