软件(项目)的敏捷开发

做事的方法
用恰当的方式做事，事半功倍。

制度
大厂里流程规范很多，最开始你会不喜欢它们，后来会离不开它们。

这些墙很有趣。刚入狱的时候，你痛恨周围的高墙；
慢慢地，你习惯了生活在其中；最终你会发现自己不得不依靠它而生存。
这就叫体制化。——《肖申克的救赎》

方法演变...

甘特图
早些年的项目开发，都是围绕着项目计划开展的，把甘特图打印贴在墙上，方便团队成员看项目进展到什么地步了。

看板 + ticket

image.png

项目管理软件(比如：Backlog、Jira)

慢慢的物理的看板变成了电子看板，通过各种项目管理软件来管理跟踪这些任务，即时贴也变成了 Ticket（也有叫 Issue 的）。
逐渐的，所有与开发相关的任务也都和 Ticket 挂钩了：

• 报一个 Bug，提交一个 Ticket ；
• 提一条需求，提交一个 Ticket ；
• 要重构一下代码，提交一个 Ticket 。

看板这种基于 Ticket 来管理跟踪任务的方式，看起来繁琐，但确实是很高效的一种方式。
每一个任务(issue)的状态都可以被跟踪起来：
什么时候开始做的，谁在做，做完没有。整个团队在做什么一目了然。
Ticket 和敏捷开发中的 Backlog（任务清单）正好结合起来，通过 Ticket 可以收集管理整个项目的 Backlog 和当前 Sprint（本意为短跑比赛，引申为软件开发的一次迭代过程）的 Backlog。

有了看板后，大家每天上班第一件事就是打开看板，看看当前 Sprint 还有哪些 Ticket 没有完成，哪些已经完成，哪些正在进行中，非常直观。

• 作为项目成员来说，做完手头的事情也不用去问项目经理该干什么事情了，直接从 To Do 栏选一条 Ticket 做就是了；
• 对于项目经理，看看 To Do 栏还有多少没有被选取，就知道还剩多少 Ticket 没完成，看看 In Progress 栏就知道哪些 Ticket 正在进行中。如果有 Ticket 在这一栏待太久或者这一栏 Ticket 太多，那可能就有风险了，就可以及时介入。

动态系统开发方法
任何事情都不可能一次性圆满完成，应该用20%的时间完成80%的有用功能，以适合商业目的为准。

Scrum
Scrum 是一个用于开发和维护复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周。

在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

• 角色：谁要使用这个功能。
• 活动：需要完成什么样的功能。
• 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：作为一个<角色>, 我想要<活动>, 以便于<商业价值>