起因：
由于需求总是在不断的变化，越来越多的公司开始尝试SCRUM，希望这种新致的开发流程能够最大程度的降低需求变化的影响，如期交付客户满意的产品。
什么是SCRUM：
SCRUM是一个迭代的、增量的产品开发以及工作管理流程。其中包含了风险控制，解决最优先需求，团队高效协作等各种思想。
通常什么样的项目适合SCRUM：
SCRUM的项目通常会有一些共性。
1. 项目的需求较容易改变。
2. 项目周期较长。（通常大于3次迭代）
3. 项目分期开发，迭代增量。
理想SCRUM团队的特点：
1. 项目人数较少。这有助于项目成员之间的彼此了解，也有助于Scrum Master了解每个人的状况。
2. 项目成员乐于沟通。由于需求的不断变化，SCRUM团队往往比其他的团队需要更多的沟通；而团队成员之间的交流和了解也有助于提高项目的开发效率（比如碰到新技术时，直面的请教要比摸索需要的时间短的多）。
3. 项目成员有较强的凝聚力，能够在工作时间全身投入，在休息时间好好放松。就像字面理解sprint一样，要冲刺的时候，自然要精神集中；而要不断的冲刺，又要学会放松自己。
我的SCRUM：
自己目前所处的环境有点半SCRUM的状态，也许许多公司里的项目Leader有相同的窘境。我们不是通常所说的SCRUM Master，因为和客户的沟通并不是点对点的，可能还有市场部，老板等多点形成的网络关系。
客户自然是站在客户的一边，老板和市场部则都有可能，有时站在客户一边，有时站在我们一边。如何良好控制需求变化成为我不得不仔细思考的问题。
计划与时间的矛盾：
需求并不能够总是在每个sprint开始就详细到每个细节。
例子一、一个见过的类似模块通常开发时间是20小时人。当组员开发到一半的时候突然发现其中以细节需要客户确认；结果客户10天后才给予答复。
例子二、客户和自己不再同一个时区，几乎所有交流依赖于邮件，最快答复往往也得等到第二天。例子三、在一个sprint进行到一半时，客户告知：计划会议时所提的需求不是我们真正想要的需求，我们想要的是…
例子四、组员A在开发时被某技术block住了，而又没能及时提出，他以为在XX日前能完成某模块。
例子五、组员B在sprint中，家里出现意外，不得不离开。
……
总结与疑问：
例子一和例子二遇到的问题本质是相同的：客户不能对需求做出及时回复。
例子三，在项目中期，客户大规模改动需求。宣告sprint失败？为开发团队争取更多的时间？如何做？
例子四，daily meeting很重要。及时了解团队成员的状态。
例子五，我们需要为意外做多少准备？
各种可能出现的问题，我们该如何估计时间？根据不同的客户预留多少Buffer？为意外预留多少Buffer？
最新评论