总结会议

临下班开了个上线总结会，总结了这次上线遇到的问题。程序员们还是淳朴的，相互之间容易交流，不大会藏着掖着。
总结出几个问题

1. 项目周期太长
2. 临时需求的处理
3. ued修改过频
4. 产品需求模糊

商讨的解决方案主要有两个。

1. 提高上线频率。
   上线就如考试，有种正式感。不上线的时候，可能会留下许多小问题。长时间不上线会积累很多问题，上线时问题会非常多。频繁上线则相当于定期解决这些问题。同时，频繁上线会倒逼产品尽快理清需求，否则他们一直不理需求，多了之后他们自己也乱了。ued也不容易一改再改，完全闲的蛋疼。
2. scrum敏捷开发。
   遇到的每个问题前人都遇到过，大部分都有成熟解决方案。scrum是让5-9人一组，有专门的产品负责人和项目计划者（称为scrum master),每天都需要回答三个问题：
   a) 自上次Scrum会议后的1天里你做了什么？
   b) 从现在到下次Scrum会议的1天时间里你准备做什么？
   c) 你在工作中遇到了哪些困难？
   我想如果这个执行得好，问题会解决一大半。大部分问题都是沟通的问题。每天有机会一起交流，不但增加感情，更能提高工作效率，进步更快。这种模式更容易发现问题，出了问题大家能出谋划策。
   如果有紧急需求，所有人也能立刻商量，去制定新的计划。达成一致比什么都重要。

其实想想解决方法也没什么特别的，很多人都能想到。但为什么之前没有实行起来呢？因为流程和规定不是谁都能制定的，必须要是安总这种级别的才能让大家信服。
这次上线主要问题还是在于大家没有一个统一的流程。所有人没有一个参考标准的时候，基本都是逮着什么做什么，自然容易乱。一个好的流程能让大家知道自己在做什么，别人在做什么，什么是最重要的。
最后发表点感慨。今天的会议让我深深的感到我们原来是个初创公司，标准的做事方法都没有形成。看到了很多问题，并且大家也在谋求解决。这是一个团队成长的过程，于我来说很有价值。我对这种很感兴趣。今天的讨论也算有一定成果，但后面的执行仍然是个问题，包括安总，包括我们。安总是否能让ued和产品对自己的问题引起重视，让他们更多顺从我们？我们能不能将scrum执行好？我很害怕scrum会成为鸡肋，弃之可惜，食之无味。不管怎么说，我很想尽力去做。