敏捷实施笔记：第1章 沟通

         Scrum作为一个项目的管理框架，他解决的不是如何写代码的问题，而是解决项目管理的问题。既然是管理问题，那是否可以试用与整个公司，而不仅仅是项目组呢？

         首先要确认管理的核心是什么？个人觉得管理的核心就是沟通，如果沟通没有任何问题，那什么管理制度问题都不大。

我先回顾一下之前项目中出现的问题，可能也是很多技术团队出现的问题。顺便看看Scrum是怎么解决的。

         比如有些程序员在开发的时候遇到了困难，但是又觉得自己能解决，于是就埋头苦干。当项目经理问起时，很多程序员的回答是还差一点，但是这一点很有可能需要花费大量时间，影响到整个项目的进度。Scrum要求任务细分到最长为天的工作单位时间，并且每天开10~15钟的Daily Meeting，配合Brundown Chart，可以实时跟踪项目。

         我们的大量项目有时效性，导致前期没有时间做详细的概要设计，于是需求细分就留给了项目组，在遇到功能点有多种表现形式时，有些程序员喜欢猜，“我觉得客户肯定喜欢这个，我觉得客户肯定不想这么做”。到最后发现功能不对时，只能重新修改。Scrum会要求产品经理参与到整个项目的流程，功能验收的标准由产品经理定，而非技术经理，这样就保证了需求的正确性。

         我们所有的项目是分策划组和项目组，按照瀑布模型，策划组规划了基础需求后，移交到项目组，从概要设计开始就是技术人员的事了。策划组是互联网传播和用户行为习惯研究的专家，项目组是技术专家，那么对于小到一个输入框在什么时候应该出现这样的小问题，应该由谁来验收？策划组是直接维护需求和保证项目正确性的人员。但是因为细节过多，技术人员往往不愿意提出这个那个的问题，而把这些东西都遗留到了项目交付之后。于是又产生了大量的修改。Scrum规定Product Owner不能是项目组的人，并且Product Owner需要全程跟踪项目，他是功能的验收者，他制定验收标准。当然他每天只需要抽出10分钟，所以也不会耽误太多时间。

         之前我们项目还发生过一次事故，就是项目在执行过程中，设计部分由另一个团队完成，当这份设计到我们手里时，发现有很多地方不符合规范。当时项目时间比较紧，我们就在此设计稿上进行了修改，虽然多次提到需要和外部设计团队沟通，但是最后大家都不想多说，于是就这么执行下去了。最后和客户确认是，因为多处于设计团队的设计稿不一致，而导致了很多问题，项目只能延期上线。这个本身应该可以及早解决的问题却在最后时刻爆发了。Scrum要求每天遇到任何问题，必须计入Barriers Backlog中，并且由Master解决，必须解决。

         当然还可能存在其他问题，我们发现这些问题其实都是沟通问题，我们可以概括为“沟通恐惧症”，可能是因为懒，可能是因为觉得没有必要，可能是不想添麻烦，可能是自尊心作祟……，但是就是不想多说，只想先做吧，做了再说。

虽然知道这些通过沟通都能解决，那为什么需要Scrum？就现在我的理解是，Scrum可以在不付出过多沟通成本的基础上，为我们约束和规范了沟通方式，让松散的沟通变得紧凑，让局部非透明的沟通变成透明化。

         从项目推及公司整体运营，或许Scrum也可以给我们一个启示？

         （上述只是Scrum解决沟通问题好处及我个人的理解。其他的在陆续总结。）