Scrum，幸福来得挺突然

是这样的，原来的需求收集流程中，产品负责人要按照要求写繁杂的需求文档，而且文档要经过开发和QA的review，如果存在问题（通常是存在问题的），要打回去重新修正，多的时候会修正几遍才能定稿，这样折腾下来，7-8个需求是需要7-8天时间才能进入开发。
Scrum之后，产品负责人可以省去复杂的文档，在sprint计划会议上把需求沟通给团队（开发和QA），重点讲做什么和为什么做，然后团队来定义怎么做，确定需求细节。原来的7-8个需求一个下午足矣。
对比而言，冗余的流程是低效的病根（也是官僚习气的发端），对团队作用的强调和目标驱动（而不是角色职责驱动）是对症的药。
还是那句话，与问题相处要比改变现状更容易，一边是流程低效但是有大量灰色时间可以享受安逸，一边是“短距离地全速奔跑”的辛苦和Sprint回顾时的成就感以及过程中的知识长进，不同人会有不同选择。
再者，我还是觉得如果能认清存在的问题，完全可以按照常识去改进，Scrum在这里只是一个拐杖，辅助一下而已，这也是我在介绍Scrum的第一张slide探讨“药和良好的生活习惯那个更重要”原因。

lz你附件里资料我都看完了。我查了一下scrum master还有认证培训，不过好像都很贵，最便宜的也要7500RMB。我想问一下，你觉得有必要去弄这张证书吗？还有一个问题，你上海哪里的IT公司啊？真想到你公司里面做事情～
我现在这公司我想搞scrum阻力很大。要是在你公司我想我会做的开心点。

我以前写的关于scrum的一点经验：


My trivial experience of scrum

I asked some questions in this group and I got some very helpful suggestions.
Here is my trivial and painful experience of scrum. Hope it will help you to
avoid these mistakes I made.



Last year, my boss, other 9 people, and I left our last company and joined this
company. We are supposed to build a similar product that we had built. Our new
company is big, but not mature. It has no regular software development process
and we have to create one for our team.

In the last company we worked, these things are clearly defined. We had to use
a strict V-model which is forced by filling many forms ad by a separated QA
department. When we worked on a project, we just tightly followed our process
manual.

But I never like that process. We never finished the plan on time, we wrote too
many useless documents, we cheated when we filled these audition forms....

So, last year when we began, I thought maybe we should use something more
efficient as we don't have enough human power. ( I led a *small* team in the
last company, it had 15 people).


I suggested to use scrum. But,as you can expect, I failed.


Here is some problems I met :

=====


1. Backlog is not considered as a formal requirement.

For my colleagues, requirement should be a "specification" which clearly
defined the features of our product after 6 months, and could be given to sales
man as a market.
So although I translated the "specification" into a backlog, my boss only read
it once and continued to ask for "newer" specification.

He thought the format of backlog is too informal, features(backlog) items are
not grouped by logic so he could not see clearly what the product could do.



2. No long term plan (predict)

Scrum doesn't have the concept of long term plan and my boss felt it was hard to
believe we can not tell him what features after 6 months or 1 year.


3. No detailed plan for everyone

My colleagues are used to be told "you have to do xxx in 4 days and if you could
not finish you work overtime", so they feel really uncomfortable when there
isn't a form predict what he should next Thursday afternoon.


4. Daily stand up meeting

Many feel it's very annoying to have a meeting everyday, even if it only took 10
minutes, and it is also useless to know what other people had done yesterday.

"My module do not use database, why should I know that someone else changed db?"
"I just started working but this damn meeting stopped me!"


5. No concept of a "project"

"Requirement Analysis -> Design -> Coding -> UT -> IT -> ST". We are used to
this model of software development, and we are used to plan how long each phase
will take.
Clearly, this style of plan do not fit scrum's plan sytle.

And each phase should output a formally accepted document before next phase
start. Which is also not compatible with scrum's concept of "done".

My boss feel that no project means no management.


6. Pair programming

"Don't you have something more important to do? I can do it myself!" When I
suggest pair with my colleagues, most of the time they would say that.


7. TDD

Most our code is written in C with glib, I tried to TDD, but it's really hard.
Need to write too many code of mock object.
I just succeed to use it in the python part of the system.


--------

I tried to apply scrum to our development process for 2 sprint then I gave up.
On the plan meeting of the 3 sprint, one of my colleague intensively opposed
continuing scrum.
He took some backlog items and told me he could finish this in one week without
any help if I stop waste his time.


After a year, I think now I could see the whole thing calmly. I made several
mistake:

1. Although we are a new team, but most of us are highly trained with a high
ceremony process.
I had no chance to apply an agile process at once.
If I really want to succeed, I should start with more tiny steps.


2. I should find problems and suggest to resolve them with new method, I should
not force something just because I think it's good.


3. I didn't see from on my colleagues' side. Actually, I now can see that they
had strong reason when the oppose.


--------

To be honest, after a year, the team is in chaos. We are not using scrum, but
we do not have any formal process also. We just *decide* what features will be
include in next version and we assign the task to one of us. God knows if he /
she could finish it on time and if he / she working or just surfing internet. I
was frustrated , I used most of my time coding and I didn't consider management
or process anymore.


But now my boss could not bear the chaos anymore, and I am asked to build a
formal development process.
Don't know what to do.

你没有得到高层和下面的人支持啊~
你没有让大家在最初2个sprint里看见任何实行scrum的好处。

像我们是写framework的，整个team人就5个，每个人都要负责很多的东西。有时一个项目从头到尾都是一个人完成，只是会和team的成员一起review设计，代码，测试，文档。像我们这样的怎么用scrum？

个人感觉，不是所有类型的team都适合采用scrum的方式。
scrum只是个方法。不觉得这个方法可以解决所有问题。而且当时的作者也提到“这是他们的做法，希望对其他人有所启发”。

to 黑暗浪子：
    我们采用Scrum是看到它有解决我们问题的希望，既然已经用药治好了病并且养成了一些好的生活习惯，干嘛非要再去考个医师资格？当然，立志做医生的除外。
    还有，为了体验一个开发方法的快乐离开一个公司加入另一个公司，这个初衷挺雷的，慎重慎重，如果现在的公司真的没有任何吸引你的东西，再做决定吧。

To ablmf：
    看过了你的实施经历，感觉你已经找到了一些答案，我想补充的也就是“黑暗浪子”的建议：一要得到上层和团队成员的支持，二要让大家尽快地看到效果尝到甜头。你总结的小步骤实施很必要，我们就是先从简单的几个实践开始的，然后逐渐加入新的实践，每个实践都要经过1-2个sprint来验证，最后大家投票表决是否保留，因为没有论证出好的措施，结对编程和单元测试我们到现在也没有实施，这不影响Scrum给我们带来的快乐。

To ldd600：
    记得有资料提到实施Scrum的理想团队size是7加减2，不过这不重要，如果你们现在过得很舒服的话，干嘛要去改变呢？

高层原先是做过程改进的，也是博览群书的人物，他并不认同Agile的过程，而是比较喜欢“远期规划”的CMM方式，他只是让我去试试。

下面的同事的话，其实包括我，在前面一间公司养成的习惯就是：告诉我我要干啥，什么时间完成，你就不用管了。所以他们还是不认同scrum这样没有人指挥他们的做法的。

当然，当年的沟通和讨论没有做到位，有点强迫的意味。

还有一个就是当时人数有10个，情况也就复杂化了。

@ohmygodlzl

结对编程比较好实施一点，效果也很明显，你应该试试。

我的观察：

1. 老人带新人，老人如果比较理解结对的窍门，新人会学的非常快。
2. 结对的效果比review要好。review的时候，大部分人其实在打瞌睡。
3. 结对至少可以减少一个人每天上网时间2个小时，两个人就是4个小时。

我不觉得这个是“中国特色“，除非wikipedia上这一条是中国人写的：

Benefits

    * Learning and training: Knowledge passes easily between pair programmers: they share knowledge of the specifics of the system, and they pick up programming techniques from each other as they work.[2][4] New hires quickly pick up the practices of the team through pairing.[5]