Hegel2011的博客

读书 - 工作 - 生活 - 笔记

Ship It

这是此次6本其中3本项目管理书籍中读起来最快速的一本。如果说《用户故事》是告诉你需求怎么收集,《Manage It!》是 告诉大家如何给项目选择模型、设置生命周期,那么这本书则是开发中关于项目构建的干货,同时也牵涉到了一点项目团队组织的问题。

全篇最精彩的部分在于基础设施章节。提出了基础设施的存在是为了解决让人头疼的问题,而且是用轻松的方式予以解决。 版本库特性跟踪软件项目待办事宜软件构件机自动构建系统均属于此类。它们确实是工具和方法 但又不仅仅只是方法。实际上基础设施通过提供便利的方式轻松地解决了在PM中提到的那些需要处理的问题。对于节约成本、方便沟通、 加速进度、确定工作范围、提高质量都有巨大的促进作用,而不仅仅只是解决某一领域的问题。真正的进步只能在于人和基础设施, 这些才是可持续可重复的。

里面的实践大部分应该说我已经在平时的工作、项目管理中实践起来。当然有些东西是没有的,比如构件机,比如自动测试。直到现在 我依然认为写自动测试带来的工作量的增加很可能是得不偿失的。而且Web UI的测试难点依然没有真正好的办法解决。但其他几条应用已久 而且确实效果还是很不错的。另外自动构建至今也没流行开来。对于Rails等基于脚本语言的开发方法来说,自动构建还算简单,但对于Java来说可能CruiseControl 还是过于复杂了。

这本书的原版成版于2005年,很多思路和37signals的类似,确实是中小型团队合作项目的典范。

前面已经提到,此书关注的是内部项目怎么开发,所以无论需求怎么搜集(用户故事、用户案例、用户场景)最终都需要把产品分解 为特性,特性分解为任务清单。所有的任务清单都需要记录,如果没有记录就像从来没有发生过一样。合作过程中, 基础设施提供保障,任务清单则是主要沟通交流的对象,也是控制彼此节奏和提交物质量的重要根据。每日例会的内容 和清单相关,代码审查也和清单相关。可以说,基础设施+任务清单+沟通+动手=软件的优良构建

曳光弹的开发其实就是概要设计、分模块开发的意思。强调能独立的组件就独立,彼此通过接口来交互。只要接口稳定,内部 实现可以随意变化。这样替换模块也就比较方便。而且各个模块也比较容易水平扩展,哪里有瓶颈只要增加相应的处理资源即可。 所谓曳光弹,就是先把各组成部分串联起来,让系统可以动起来,类似于提供出一个原型,可以让用户触摸、点击、反馈,这几块 当然是软件开发尤其是应用软件开发应该的样子。

Included file 'twitter_sharing.html' not found in _includes directory