如何将失败的项目重回正轨？

Question

您一定听说过失败/失败项目的原型故事:

1. 一支缺乏经验的程序员团队全天候工作
2. 修复错误只是为了引入新的错误
3. 客户尖叫他甚至不能做基本的东西(保存/查询)等.
4. 程序员过去常常会通过规范来进行即兴创作
5. 没有自动化的单元测试会加剧这种情况
6. 在实际上没有遵循在纸上看起来不错的架构文档
7. 使用的第三方组件首先成为尚未经过健身测试的瓶颈
8. 里程碑错过后的里程碑
9. 由于没有人同意实际需要完成的工作量,团队无法提出交付日期
10. 没有技术领导/或牛仔编码员可以承担技术问题

现在,如果你被带入#10那么你的第一步是什么？

更新:首先:感谢你们所有人都在努力.好吧......我被带进#10.当我们向客户提出建议时,我是最初的建筑师.然后,不幸的是,由于我被分配到其他地方,我无法承担交付责任.:)

假设它是现有桌面应用程序的Web化.我现在被带进#10.遗憾的是,逃跑不是一种选择.我确信这仍然可以通过遵循敏捷的最佳实践来逆转,并且只是想挖掘社区的想法.

更大的问题可能是:如果开发团队没有规范,只有运行应用程序的(基线)代码,原始解决方案要求查看代码并动态提取业务规则.现在,没有经验的程序员不愿意看VB 6.0代码并想要文档!那么如果你要实现敏捷流程,你如何解决这个问题呢？

Answer 1

Vyas,我觉得我可以写下这个问题.我之前的工作涉及恢复一年后开发失败的KVM项目.规格以用户手册和开发人员使用类似产品的形式出现.我最后教C到3个汇编程序员并从头开始重新构建.我们在4个月内将产品成功推向市场.(然后我辞职了.去看看.)

我要做的一些事情,特别是对于缺乏经验的团队:

1.一支缺乏经验的程序员团队全天候工作
10.没有技术领导/或牛仔编码员能够承担技术问题

• 给他们一个(短暂的)休息时间从项目到"充电".也许是一天,也许是一个下午,或者也许是一顿长长的午餐.它将标志着"旧"项目的结束和成功的开始.
• 得到他们的同意,当他们回来时,他们会把他们的屁股弄掉,并保证你会成为他们的首选,拉拉队员和防弹衣.你们共同组成了一个团队,你们的工作就是打造自己的道路,消除分心,引导他们.
• 计划立即取得成功,无论多么小,并保持"可以做"的态度.

8.里程碑错过后的里程碑
9.团队无法提出交付日期,因为没有人同意实际需要完成的工作量
3.客户尖叫他甚至不能做基本的事情(保存/查询)等

• 小咬一口! 尽可能地打破每一块,然后处理小部件.您将尽早识别"陷阱"并更好地确定整个项目的范围.
• 定义您的接口.任何时候你可以隔离一个块,做它. 这允许并行开发,因为您已经决定了参数,前置条件,假设,内部发生的事情以及返回值.您可以将其存根,并独立构建其他模块和测试.
• 优先. 专注于首先影响客户的缺陷和问题.新功能最后.如有必要,推迟功能而不是提供有缺陷的代码.
• 分配责任. 志愿者是首选,每个人都在他/她的专业领域,但每个人必须对每项任务负责.
• 跟踪缺陷,并记录有助于您重现,定位和修复它们的所有内容.记录任何剩余的交货时间,以便客户不会感到惊讶.

4.程序员过去常常使用规范进行即兴创作
6.在实际上没有遵循在纸上看起来不错的架构文档

• 您将随时创建规格详细信息,每个部分都在需要之前创建.只要每个人都理解当前的任务并且你已经了解了全局,那就不必是漂亮,完整甚至是书面形式.
• 当开发人员准备好对其进行编码时,一次讨论一个实现.如有必要,自己编写骨架,让团队填写"胆量".你想让他们专注于每项任务,而不是"即兴创作".
• 随时可以回答问题.您的主要目标是保持团队的工作效率.

2.修复错误只是为了引入新的错误
5.没有自动化的单元测试会对情况产生影响

• 尽快计划并开始单元测试.如果可能,请在团队外部注册资源.
• 在小问题变大之前解决它们 - 或者隐藏它们.对每个小块的信心可以建立对整体的信心.

7.使用的第三方组件首先成为未经过健身测试的瓶颈

• 当你没有编码时,头脑风暴解决方案.如果可能的话,不要让他们阻止你的进步.你能封装或编码它们吗？替换他们？

一般建议:

• 保持领先于团队. 在团队遇到问题之前预测并尝试解决问题.在需要之前收集任何必要的信息.
• 不断沟通. 明确表示您不需要任何意外,并且每天都会征求关注,问题,状态,路障等.鼓励协作并在整个团队中分享"发现".
• 庆祝每一次成功. 赞美一个聪明的解决方案,在问题解决后带上甜甜圈,演示一个新的工作特征......任何能够表明你欣赏他们的团队的东西.
• 完成每项任务,然后继续前进.不要浪费时间调整,增强或改造任何不是成功的直接障碍的东西.
• 信守对团队,客户和管理层的承诺.

祝你好运 - 请让我们发布!

Answer 2

逃跑或找一份新工作.这是一场死亡游行,他们需要一只scape山羊.

通常情况下,死亡游行将涉及通过要求团队成员特别艰苦地工作,周末或者试图"在问题上抛出(足够的)身体"而不同的结果,通常导致职业倦怠的绝望尝试来纠正项目的进程.

Answer 3

冻结版本,并开始修复程序问题....优先处理客户投诉(公司的业务部门可以优先处理)并使程序运行.一旦解决了最大问题,请开始清理代码.将任务分配给其他开发人员,并开始对所有新代码实施编码实践.

如果你可以做任何你想做的事情,那么看看真正的问题是什么并处理它们.如果这意味着组建一个新团队从头开始全面开发软件,那就这样吧.但你应该尝试至少修复主要的错误.不要费心引入新功能,它们只会使问题复杂化,并且一个不起作用的程序和不处理问题会导致客户失败.

Answer 4

10号显然是最严重的问题,或者至少是所有其他问题的根源.找一个具有创造力和能力来交付项目的人,让他们自由地做任何事情 - 包括重新开始.

Answer 5

我希望你收到的报酬非常好.无论如何,我的计划将按以下顺序执行:

0)停止在整个团队中添加功能或功能.在执行以下步骤并执行步骤5时,允许解决错误,然后停止错误修复和恢复功能开发:

1)应用我称之为逆向人员配置法:较弱的团队成员会减慢速度越来越快的团队成员,一般来说,迟到的软件项目需要移除,而不是添加.因此,您需要评估团队成员作为个人贡献者的质量.消除团队中较弱的员工,因为可能有一些人.最好通过查看他们的代码并检查他们的错误修复并找出谁使代码变得更糟而不是更好并将其切割为团队来完成.现在不是指导的时候,你需要最好的人来改变在最佳时期"固定"情况.如果你不能解雇他们或重新分配他们,让他们喝咖啡或其他人留下的东西.

2)评估代码本身.识别代码中未构造良好和/或未被很好抽象的区域.如果区域代码构造不好和/或显然对它应该做的是脆弱的,则将其作为重写目标.这一点感觉很痛苦,但从长远来看,它会节省你的时间.重复出现的错误和/或修复历史将有助于识别无法挽救的代码.如果代码区域或模块从根本上构建得很好,但在接口级别上没有很好地抽象,那么它应该适合于重新分解.这将节省大量时间并且是有用的代码.保留重写区域,重新考虑区域和合适区域的列表.

3)定义一个新的合理架构,您相信这将为您最终在功能和特性中的位置提供强大而完整的解决方案.该架构可能不是最佳的开始清洁,但实际上与您希望的位置相匹配.

4)与利益相关者合作,决定什么将使可接受的第一个版本试图为"后期"版本提供尽可能多的功能.也许你不能削减任何东西,但如果可以,现在是时候做了.

5)停止后台错误修复工作并将定义的工作分配给(剩余)团队,以估计其余功能的合理新实施计划.他们需要拥有时间表.汇总时间表并保持相当保守.现在,您可以合理地预测何时可以实现可行且可靠的功能.

6)实现剩余的功能,然后通过解决剩余的错误来加强发布.我假设在这里观察所有正常的良好软件开发实践,如源代码控制,单元测试等.

7)尽可能多地移除障碍物,以尽可能快地让团队摆脱困境.

8)监控问题,并尽可能地将手弄脏.提供在您可以提供帮助的范围内承担更糟糕的问题,并使团队中的所有成员保持高效.

祝好运!