团队出现这样的场景大家一般怎么处理

这‘谁’开始没个确定？

 

downpour说到痛处了，其实我昨天仔细想了下，问题产生主要源自一下几点：
1.产品本身：产品本身处于一个较为特殊的废旧立新阶段，有些地方需要推倒重来，有些需要对原有功能的进行扩充，但是新引入的组件或者模块必须很好地向下兼容，这部分往往需要架构师开始就做好一个全局的统筹，这立马引出了接下来的一个问题--管理
2.管理混乱：现状就是，没有周期的小组例会，没有真正意义的项目经理（为啥没有暂且不讨论了，离题。当然也没有严格意义的项目计划，进度控制、甚至一些规范的制定），没有真正意义的架构师，架构师在公司组织节点中跟普通程序员同级，提出措施也没有任何效力保证，所以接下来问题3产生只是时间问题
3.开发人员。每个开发人员经历、背景都不一样，架构师提倡的有时比开发人员想的还昏头，但是架构师的意义很大程度在于打造一种“开发秩序”：做什么、基于什么做、做的时候遵循什么、每个功能怎样划分里程碑、什么情况下代码可以提交等等，如果这些措施没有任何效力保证，一切只能是海市蜃楼。
所以有一阵开发，真的是按照downpour说的那样，开发一个功能点，update最新代码，集成，测试，没问题，提交。我也觉得这样按模块提交不妥，但是为了避免回到以前那个经常将svn（不管是开发还是生产环境）当回收站的阶段，多少算是点进步吧。
    感谢老抛提供的冒烟测试做法，包括scrum,有阵也研读过，大道理说出来，其实大家都很认可，但是有时做起来才发现，每个公司都会存在这样那样特殊的“国情”，令人困惑甚至苦恼。作为一名普通的开发人员，哪怕一时改变不了现状，心里多少得保留一份标尺。
    月经贴。

1.
已经被证明过了的最佳实践不用的话,
就不是国情问题
应该是"透明"的工作内容了.
2.
冒烟是个技术活,
动动手写写.......
与人文无关

冒烟是个技术活，但是当你开始尝试推行冒烟后无半点响应，就不是纯技术问题了，前阵在内部用hudson搭了一持续集成环境，bugzilla也推过，最后闹半天发现还是自己在折腾。

在美国Google(谷歌公司)的总部门厅，也摆着几盏熔岩灯

我公司没这设备.

我想说的是.
你不能先假定团队的所有人都与你作对.
他们有可能对制度作对
但你要把脚后跟放在他们一边
制度不好就看看为什么不爽
把制度改好总比去招到适合制度的人更简单.

对于合并代码的工作.....
还没看到什么好工具
一般用肉眼

1.把svn全down到A的机器上.如果全down了A还能跑,那就是svn的问题
(你先去检查svn的问题,冶病冶根)
2.由A来改所有有问题的代码.
(这次是第一次出问题,如果不争一下,下回还会有,所以这回A作的对.)