基本上我们有一排排的程序员，他们每天都会做一些平凡的任务。这将涉及编写不是非常有效的代码，不进行单元测试，并且经常与应用程序集成得很差。更不用说在工作时间和工作时间方面没有问责制。我不是试图让人们被解雇或让生活变得悲惨。我想要的只是流线敏捷（我们公司禁止使用这个词）流程。这会涉及设置像Hudson集成服务器这样的东西吗？与项目管理软件绑定的版本控制？
答案 0 :(得分：7)
答案 1 :(得分：4)
根据我的经验，很难成为变革的唯一驱动力。如果你没有管理层的支持，那就更糟了。如果您没有管理支持，则需要双管齐下的攻击：a）招募开发人员以努力做到更好，以及b）向管理层证明您的改进如何影响底线。如果您认为自己确实拥有管理支持（或者可以获得管理支持），那么您仍需要团队成员的支持。
您应该介绍工具（正如其他人所建议的那样），例如Hudson和单元测试框架，这些工具可以更容易地做正确的事情。但是引入只有你使用的工具会在一段时间后变得令人沮丧。您还需要向组织中的其他开发人员介绍这些想法，并希望他们有学习新知识的愿望并应用于使他们（工作）生活更美好。
开始每周一次的棕色包，以查看工具，新语言，解决问题的方法和评论文章。基本上任何介绍新想法的东西，让人们超越下一个错误修复的范围。 （这也将告诉你谁将接受更好的做法。）
展示您的工作流程。结对编程可能在你的组织中有一个坏名字，但让别人偶尔“帮助我”（即使你真的不需要帮助）让你有机会向他们展示新的东西。这种情况也可能相反。当你看到有人在努力完成一些可以实现自动化的手动任务时，可以教给他们一个新技巧。 （有趣的是，我认为当他们提出要求时，更有可能产生影响，“很好。你是怎么这么容易做到的？”）
表现出对自己工作的自豪感，并尝试从团队中鼓励自己的工作。继续问你的团队和同行的问题，“如果你使用它，你会想要这个怎么样？”以及“我们怎样才能让这个更易于维护/更容易扩展？”
聘请优秀的开发人员。参与招聘流程并确保新员工展示他们的编码能力和学习意愿。
最后，与敏捷实践（我毫不犹豫地推荐）相比，它似乎很简陋，但我认为Joel Test仍然具有相关性（我是否会获得提及的奖励积分？）。我不知道您的组织排名有多高，但无论您是单个开发人员还是管理人员，您都可以做很多好的建议。
答案 2 :(得分：3)
一些想法：
顺便说一句，“工作流程中的”工具辅助“问责制”是一个糟糕的坏主意。它扼杀了创新，并导致他们浪费了很多（我的意思是）时间来制作他们工作的标志。膨胀的文档，膨胀的提交日志，......那些东西。最小化而非真正以电子方式严格执行的问责制要好得多。你的工人已经知道他们雇用了什么，你可以在很大程度上限制自己控制他们工作的中间和最终结果的质量。
如果你想做一些过于宽松的工作实践，有时会带着预约走到人们的办公室，也许很少没有预约来讨论他们的问题以及当前的工作和想法。也许偶尔会带来一些食物和其他零食...任何可靠地显示“你”或任何经理或员工真正关心工作和工作人员的事情都会使团队的其余部分更加关心 - 这就是最有帮助的事情。与技术工人打交道。
答案 3 :(得分：2)
我将开始构建团队，引入持续集成服务器和分布式版本控制。
你的公司管理层显然不相信敏捷，很可能相信控制（tm）（或至少是控制的幻觉）。很可能你的管理层喜欢层次结构，因为没有什么比层次结构更能提供更好的控制幻觉。
在团队中，首席开发人员扮演集成管理器的角色，这对他们来说是个不错的选择。如果您有不安全的管理，也可以使用“集成协调员”。他的工作实际上只是开发，当CI服务器闪烁红灯时大喊大叫（这很重要）每周从CI服务器发送声纳报告，并将一些计划与实际情况发送给管理层。他们会感觉自己掌控并花了整整一周试图通过所有数字。
另一项任务是与其他集成协调员会面，讨论不同团队工作的整合。这是分布式VCS的用武之地，因为它允许灵活的，流程驱动的变更流程。
（确保您的管理层不会阅读其余内容）
您的管理层现在看到了一个经典的层级结构，了解并希望看到足够的进展让开发人员独自一人。
开发人员现在拥有可以部署敏捷实践的环境。你已经有了scrum-of-scrums原型的原型。
与您的管理层建立信任非常重要。从长远来看，它不会没有管理层的支持。如果您的管理层不想采取信念的飞跃，您可以通过向他们提供他们想要的东西来说服他们，但是按照您的条件。通过积极主动和前进一步来影响管理相对容易。如果可以显示出可证明的结果，那么大多数管理人员会发现比干预开发更好的事情。
现在有些管理人员非常不安全，他们需要对所有事情进行微观管理，并确保每个人都更加不安全。
答案 4 :(得分：1)