Reading Notes: Practices of an Agile Developer

 

"45 Habits of Highly Effective Programmers - The Way of Agile Development"

 English original title "Practices of an Agile Developer : Working in the Real World"

"The way you choose to go, you choose the destination it leads to." -- Harry Emerson Fosdick (American Christian modernist theologian)

"Even if you're on the right track, if you just stop, you're still going to be knocked out." -- Will Rogers (famous American actor)

"A hundred words are worse than a deed, a thousand thoughts are worse than a single action."

 

1. Attitude is everything

Focus on getting things done.

Dealing with problems with the wrong people: denying others does not help; respecting others, raising concerns, and discussing.

2. The only constant is change

"Only change is eternal" - Heraclitus

3. Grasp the development rhythm

Randomly arranged work schedules, without any rules, make people have no idea what will happen tomorrow.

Controlling time and maintaining a development rhythm is to avoid problems piling up and prevent everything from happening at the same time.

4. Let design guide rather than manipulate development

"The design at the current stage is just based on your current understanding of the requirements, and once you start coding, everything changes."

Design can be divided into two levels: strategy and tactics. Up-front design is strategic and is usually only needed when the requirements are not deeply understood. It should only describe the general strategy and should not delve into specific details.

"If you don't know what you're talking about, it's impossible to describe it precisely." --John von Neumann

"Story: In 1804, Lewis and Clark performed a feat of crossing the United States, their "design" was to traverse the wilderness. However, they had no idea what problems they would encounter when crossing the colonies. They only knew their goal and constraints, but don't know the details of the journey. Software projects are designed similarly. You can't know what's going to happen without crossing the colony. So don't waste time planning ahead on how to cross the river on foot, only if When you get to the bank, you can really assess and plan how to cross. Only then do you start the real tactical design."

"Good design should be correct, not precise."

“计划是没有价值的,但计划的过程是必不可少的。” -- 美国总统,艾森豪威尔

5、使用短迭代,增量发布

“软件开发不是精细的制造业,而是创新活动。规划几年之后客户才能真正使用的项目,注定是行不通的。”

软件在被开发出来之前是不确定的,在开发过程总是存在着变化,短迭代可以防止在错误的道路上走的太远,这样可以及时发现错误并进行纠正。

“短迭代让人感觉非常专注且具效率。你能看到一个实际并且确切的目标。严格的最终期限迫使你做出一些艰难的决策,没有遗留下长期悬而未决的问题。”

“如果每个迭代的时间不够用,要么是任务太大,要么是迭代的时间太短。”

6、敏捷协作:定期安排会面时间

“也许你个人很讨厌开会,但是沟通是项目成功的关键。”

立会:站着开的会议。这可以保证会议快速进行,大部分人不喜欢站着进行长时间的谈话。

定期例会的好处:

  • 让团队成员知道项目其他部分的进展。
  • 帮助团队识别是否在某些事情上进行了重复劳动。
  • 鼓励向前的动力:看到比尔报告的进度都在前进,会对彼此形成激励。

7、敏捷协作:架构师必须写代码

“一个设计要解决的是眼前面临的特定问题,随着设计的实现,对问题的理解也会发生改变。设计会随着时间而演进。”

8、敏捷协作:及时通报进展与问题

“接受一个任务,也就意味着做出了要准时交付的承诺。不过,遇到各种问题而导致延迟,这种情况并不少见。如果等到截止时间才发布坏消息,这就等于是为经理和技术主管提供了对你进行微观管理的机会。他们会担心你再次让他们失望,并开始每天多次检查你的工作进度。

及时通报进展与问题,有情况发生时,就不会让别人感到突然,并且他们也很愿意了解目前的进展状况。他们会知道何时应提供帮助,而且你也获得了他们的信任。”

 

原文:读书笔记:Practices of an Agile Developer - Working in the Real World

 

《高效程序员的45个习惯 -- 敏捷开发修炼之道》

 英文原书名 《Practices of an Agile Developer : Working in the Real World》

“选定了要走的路,就是选定了它通往的目的地。” -- Harry Emerson Fosdick (美国基督教现代主义神学家)

“即使你已经在正确的轨道上,但如果只是停止不前,也仍然会被淘汰出局。” -- Will Rogers (美国著名演员)

“百言不如一行,千虑不如一动。”

 

1、态度决定一切

将注意力集中在处理做事上。

处理问题时要对事不对人:否定他人无助于事;尊重他人,提出疑虑并进行讨论。

2、唯一不变的就是变化

“唯有变化是永恒的” -- 赫拉克利特

3、把握开发节奏

随意安排的工作计划,没有任何规律,让人根本不知道明天会发生什么。

控制时间,保持开发节奏,是为了避免问题堆积,防止所有事情同时发生。

4、让设计指导而不是操纵开发

“当前阶段的设计只是基于你目前对需求的理解,一旦开始编码,一切都会改变。”

设计可以分2个层面:战略与战术。前期的设计属于战略,通常只有在没有深入理解需求的时候需要这样的设计。它应该只描述总体的战略,不应该深入到具体的细节。

“如果你自己都不清楚所谈论的东西,就根本不可能精确的描述它。” -- 约翰.冯.诺依曼

“故 事:在1804年,Lewis和Clark进行了横穿美国的壮举,他们的“设计”就是穿越蛮荒。但是,他们不知道在穿越殖民地时会遇到什么样的问题。他们 只知道自己的目标和约束条件,但是不知道旅途的细节。软件项目的设计也与此类似。在没有穿越殖民地的时候,你不可能知道会出现什么情况。所以,不要事先浪 费时间规划如何徒步穿越河流,只有当你走到河岸边的时候,才能真正评估和规划如何穿越。只有到那时,你才开始真正的战术设计。”

“好的设计应该是正确的,而不是精确的。”

“计划是没有价值的,但计划的过程是必不可少的。” -- 美国总统,艾森豪威尔

5、使用短迭代,增量发布

“软件开发不是精细的制造业,而是创新活动。规划几年之后客户才能真正使用的项目,注定是行不通的。”

软件在被开发出来之前是不确定的,在开发过程总是存在着变化,短迭代可以防止在错误的道路上走的太远,这样可以及时发现错误并进行纠正。

“短迭代让人感觉非常专注且具效率。你能看到一个实际并且确切的目标。严格的最终期限迫使你做出一些艰难的决策,没有遗留下长期悬而未决的问题。”

“如果每个迭代的时间不够用,要么是任务太大,要么是迭代的时间太短。”

6、敏捷协作:定期安排会面时间

“也许你个人很讨厌开会,但是沟通是项目成功的关键。”

立会:站着开的会议。这可以保证会议快速进行,大部分人不喜欢站着进行长时间的谈话。

定期例会的好处:

  • 让团队成员知道项目其他部分的进展。
  • 帮助团队识别是否在某些事情上进行了重复劳动。
  • 鼓励向前的动力:看到比尔报告的进度都在前进,会对彼此形成激励。

7、敏捷协作:架构师必须写代码

“一个设计要解决的是眼前面临的特定问题,随着设计的实现,对问题的理解也会发生改变。设计会随着时间而演进。”

8、敏捷协作:及时通报进展与问题

“接受一个任务,也就意味着做出了要准时交付的承诺。不过,遇到各种问题而导致延迟,这种情况并不少见。如果等到截止时间才发布坏消息,这就等于是为经理和技术主管提供了对你进行微观管理的机会。他们会担心你再次让他们失望,并开始每天多次检查你的工作进度。

及时通报进展与问题,有情况发生时,就不会让别人感到突然,并且他们也很愿意了解目前的进展状况。他们会知道何时应提供帮助,而且你也获得了他们的信任。”

 

原文:读书笔记:Practices of an Agile Developer - Working in the Real World

 

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326862961&siteId=291194637