敏捷软件开发 读书摘记2——【团队 & 方法集】

来源:互联网 发布:红米note2网络设置 编辑:程序博客网 时间:2024/04/28 17:36

1、职业的亚文化:

项目经理 需要一种有条不紊的态度,这样才能整理和预测出交付日期和成本以及项目内部复杂的依赖关系。

OO程序员 需要安静的时间,抽象思考的能力和处理编程接口同步演进的不确定性的能力。

需求分析师 依赖于周密的思考,一次一行地对需求和接口尽性检查、寻找错误。

市场人员 得益于强大的想象力、人际交往能力和对付市场(和程序员)不断抛给他们惊喜的能力。

(P121);

2、Dee Hock 说过:“

    简单、清楚的目标和原则能引起负责、聪明的行为。

    负责的规则和章程能引起简单、愚蠢的行为。”(P124);

3、过程微缩(Process miniature):

一个团队要求新来的人在第一周从需求到交付完整地开发一段软件。这个为期一周的练习目的在于:向新来的人介绍团队成员、角色、标准以及各种物品在公司中的物理位置。(P150);

4、应该、应当之类的词标明了粉饰。没有它们,软件照样能成功交付。(P153);

5、7 条在设计和评估方法集时有用的原则:

    1)交互式的、面对面的沟通是交换信息时最便宜并且最快速的通道。

    2)方法集中过多的重量代价很高。

    3)团队越大,所需的方法集越重。

    4)项目的关键度越高,适用的正规度也越高。

    5)增加反馈和沟通能够降低对于中间交付物的需求。

    6)【纪律、技巧和理解】 与 【过程、形式和文档】 化正相反。

    7)可以牺牲非瓶颈活动的频率。(P159);

6、设计师不能得到必要的安静来完成他们的工作,原因是文档工作的负担和过高的分神比率。(P161);

7、第 5 中 7 大原则组合使用后的后果:

    1)向项目增加人手是昂贵的;

    2)团队的规模增长有很大的跳跃性(24 不同水平程序员 vs 6 Smalltalk程序员);

    3)应当改进团队,而不是扩大团队;

    4)不同的项目需要不同的方法集;

    5)方法越轻越好,直到他们用尽精力为止;

    6)方法集应该能够伸缩适应

(P169~173)

8、沟通负载会随着人数的增加而升高。

6 个人能够在一个房间工作,20 个人可以在很近的几个房间里工作,40 个人一层楼,100 个一栋楼。(P172);

9、极限编程适合C4到E14分类的项目(P172);

10、需要的是一个短小的、可读的文档,这样每个新团队才会把它读一遍。(P188)

原创粉丝点击