能实际解决问题的方式才是好的开发方式。
问题一，写的代码出Bug了，是先找到问题原因，找到责任人，还是先处理问题？
不是每一个问题都值得被追责的，指责也不能修复bug。发生问题后，关键是解决问题。问题解决后，再做复盘。复盘的目的也不是追责，而是为了防止问题再次发生。一个重大的错误应该被当作是一次学习而不是指责他人的机会。团队成员们在一起工作，应互相帮助，而不是互相指责。把矛头对准问题的解决办法，而不是人。
问题二、快速实现功能让项目上线，还是追求研发质量？
欲速则不达，项目经常伴随着时间压力，这种压力会让你走捷径，只看眼前利益。而随着后期用户的增长或系统的复杂度增加，原来写的代码就会出现问题，了解需求背后的目标，以及程序要达到的一个要求，能减少后期返工的问题。
问题三、发现程序有缺陷，需要时间重构。但是新需求又很多，我该怎么办？
反馈是敏捷开发的基础，一旦发现原来实现有问题，就要立即做出决策，改变实现方式。这种情况有时候很难，需要你在团队内承认自己的问题，对于敏捷团队来说，这很正常。如果你没有犯过任何错误，就说明你可能没有努力去工作。
问题四、我们在讨论需求的时候，到底是对事还是对人呢？
对事不对人。我们每个人或多或少都有一些自我主义。你很可能见过，对方案设计的讨论失控变成了情绪化的指责——做决定是基于谁提出了这个观点，而不是权衡观点本身的利弊。
很多争论都是主观判断引起的，而解决的方案就是改变沟通方式。最好的沟通方式是yes,and 或者yes, if。先肯定其观点，再提出疑虑或者新的东西。举个例子，同事A针对项目提出了一个实现方式，你觉得有问题。但不要直接说这个问题，应该先肯定yes，谢谢A提供的方案，我们是不是还需要考虑多端登录的问题?（and贡献新东西）。
问题五、写的代码由于人员变动，导致没人能维护。
所有的系统开发久了都会变得很复杂，因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外，你还需要从更高的层面来了解大部分代码的功能，这样就可以理解系统各个功能块之间是如何交互的。我有一个观点，每一个开发人员都应该理解需求背后的目标或者理由。只有理解需求，你才懂你的代码。想要解决无法维护代码问题，需要从源头开始做规范。
1、经常做代码审核，让团队内的其他成员检查你运行的代码。在你不说明的情况下，其他同事能看懂，间接说明你的代码风格很清晰
2、做好单元测试，单元测试帮助你很自然地把代码分层，分成很多可管理的小块，这样就会得到设计更好、更清晰的代码。同时，它能直观看到结果是否与你所想的一致。
问题六、我能力不行，开会时不应该提出自己的见解
团队存在的意义就是承认一个人干不过来，需要团队一起去干。每个人都会犯错。如果你准备提出一个想法，却担心有可能被嘲笑，或者你要提出一个建议，却担心自己丢面子，那么你就不会主动提出自己的建议了。然而，好的软件开发作品和好的软件设计，都需要大量的创造力和洞察力。分享并融合各种不同的想法和观点，远胜于单个想法为项目带来的价值。
我们每个人都会有好的想法，也会有不对的想法，团队中的每个人都需要自由地表达观点。即使你的建议不被全盘接受，也能对最终解决问题有所帮助。不要害怕受到批评。记住，任何一个专家都是从这里开始的。你不需要很出色才能起步，但是你必须起步才能变得很出色。
问题7、领导在会议上决定执行一个错误的决策，你作为下级，是否当众提出疑问？
如果你非常确定决策有问题，我建议还是要提的，只是要注意提建议的方式。（最好的方式是在会前提出）
如果你没提出，一旦方案被确定了（不管是什么样的方案），每个团队成员都必须通力合作，努力实现这个方案。
其他有效技巧：
设定最终期限：没有最好的答案，只有更合适的方案。设定期限能够帮助你做出决策，让工作继续进行。
逆向思维：团队中的每个成员都应该意识到权衡的必要性。一种客观对待问题的办法是：先是积极地看到它的正面，然后再努力地从反面去认识它。目的是要找出优点最多缺点最少的那个方案，而这个好办法可以尽可能地发现其优缺点。这也有助于少带个人感情。
设立主持人：主持人的重要任务是控制每个环节的时间，确保会议目标始终是聚焦的，防止过度发散。特别是在讨论环节，要维持讨论秩序，同一时间只能有一个对话，且一个时间只能一个人讲话。
