Free To Feel

Heading to entrepreneur.


Joshua Chi
Github

Agile Development

时隔一年再读agile,理解更加深入,遂做些读书笔记.

C1, C2
1.
响应变化 胜过遵循计划
为下两周做详细计划
为下三个月做粗略计划
再以后就做及粗糙的计划
2.
尽早交付,越早越好
3.
人被认为项目取得成功的重要因素
4.
团队内部,面对面交谈
5.
程序员与客户工作在一起
6.
任务分配给敏捷团队,而不是某个敏捷团队成员。团队也是自组织的。
7.
前期的需求 只需要了解个大致。只有在产品的特性都整合在一起的时候,才是关注需求的时候,因为这个时候需求往往变动很大。
8.
专家知识通过结对编程,成员共享
9.
持续集成 = svn足够了
10.
加班?好的安排,连发部前一个星期的加班都不需要。
11.
充满积极讨论的屋子,生产效率不但不会降低,反而提高。- 密歇根大学研究得出
12.
消除重复代码 - 抽象
13.
重构是持续进行的
C3
---------------------------------------
1.
通过一两天去原型化一两个feature,去探测团队开发速度是必要的;
对不明确的feature细分为更小,可以估算的时间成本的feature。当开发速度更准确些时,对任务时间进行更准确的估算更新
2.
迭代一旦开始,客户不可以再次改变
3.
项目的知识应该充分的被团队每个成员了解
4.
迭代的终点,进度估算。本次迭代的半数素材应该被完成,如果没有需要移除一些素材
C4
------------------------------------------
1.
与其说测试驱动的测试只测试的话,我更认为他是一种目标,只是一种可以测试的目标,每次的编码都是为了实现这个目标。也就是说编码的工作最后的结果和最终的测试应该是属于的集合关系,而不是被属于的关系。
TDD - 站在使用者的角度来看待程序
2.
测试代码应该保证简单,越简单的测试被运行的机会越多
C5
------------------------------------------
1.
重构的两点:
a,节约下次使用的成本;
b,使得代码易读,易于维护
C6
--------------------------------------------
1.
XP结对编程中规定,当有人请求帮助的时候,不能说‘不’

C1, C2

响应变化 胜过遵循计划

为下两周做详细计划

为下三个月做粗略计划

再以后就做及粗糙的计划

尽早交付,越早越好

人被认为项目取得成功的重要因素

团队内部,面对面交谈

程序员与客户工作在一起

任务分配给敏捷团队,而不是某个敏捷团队成员。团队也是自组织的。

前期的需求 只需要了解个大致。只有在产品的特性都整合在一起的时候,才是关注需求的时候,因为这个时候需求往往变动很大。

专家知识通过结对编程,成员共享

持续集成 = svn足够了

加班?好的安排,连发部前一个星期的加班都不需要。

充满积极讨论的屋子,生产效率不但不会降低,反而提高。- 密歇根大学研究得出

消除重复代码 - 抽象

重构是持续进行的

C3


通过一两天去原型化一两个feature,去探测团队开发速度是必要的;

对不明确的feature细分为更小,可以估算的时间成本的feature。当开发速度更准确些时,对任务时间进行更准确的估算更新

迭代一旦开始,客户不可以再次改变

项目的知识应该充分的被团队每个成员了解

迭代的终点,进度估算。本次迭代的半数素材应该被完成,如果没有需要移除一些素材

C4


与其说测试驱动的测试只测试的话,我更认为他是一种目标,只是一种可以测试的目标,每次的编码都是为了实现这个目标。也就是说编码的工作最后的结果和最终的测试应该是属于的集合关系,而不是被属于的关系。

TDD - 站在使用者的角度来看待程序

测试代码应该保证简单,越简单的测试被运行的机会越多

C5


重构的两点:

a,节约下次使用的成本;

b,使得代码易读,易于维护

C6


XP结对编程中规定,当有人请求帮助的时候,不能说‘不’

comments powered by Disqus