作者：手机用户2502913993 | 来源：互联网 | 2023-08-23 07:26
背景 自从我们使用scrum进行项目开发后，出现了这样那样的问题，有些是因为我们对scrum的理解不到位，有些则是客观因素导致的，针对这些问题，在每次迭代的总结会上，我们
背景
自从我们使用scrum进行项目开发后，出现了这样那样的问题，有些是因为我们对scrum的理解不到位，有些则是客观因素导致的，针对这些问题，在每次迭代的总结会上，我们进行了反思，并根据具体环境对scrum进行了一一调整，想通过几篇文章和大家分享一下我的经验。
我说的不一定正确，只是描述问题，然后说说我对问题的看法，采取的解决方案，希望使用敏捷开发的大牛提供宝贵意见。
有时候我们需要结对编程
我不是个擅长讲故事的人，但写这种经验性的小文章，又不得不从故事说起，大家就继续听我唠吧。
我们的项目有一个专门维护开发环境和攻克疑难问题的小组，这个小组的主要责任是扫清其他产品开发组遇到的各种各样棘手的问题，并且维护一个稳定，易用，统一的开发，持续构建集成，测试环境。
我在负责项目的同时，也跟着这个小组处理一些问题。在处理这些问题的过程中，有几次我们采用了结对编程，感觉效果还可以。
例如，一次解决jenkins远程部署的问题，一个让人感觉很简单的问题，我把这个问题拆成了两步，先完成本地部署，然后再完成远程。但我做了整整两天，依然无果。最开始，我使用deploy
it插件，部署到tomcat下成功了，但换成jboss就失败了。
后来经过思考，我觉得，即使部署jboss成功了，这种简单插件根本不能满足我们的需求，我们自动部署是部署很多个jar，和war，而且很可能不是部署的远端同一台服务器上。
所以我开始尝试使用自定义脚本，写自定义脚本不是我擅长的，所以我找来项目组的小崔，因为他当初写过很多操作jboss的脚本，我们结对来完成这块，我提需求，然后由他指导我写脚本，大概2个小时的样子，我们就搞定了，后面就是优化的事情了。
到此为止，我们完成了使用jenkins自动本地部署，接下来就是远程部署了，我们使用的服务器是Win Server 2008，我在服务器上建立一个共享文件夹，通过在本地建立磁盘映射来关联远程的共享文件夹，然后通过脚本把需要部署的项目放入映射盘中。我手动复制到文件夹一点问题也没有，但使用脚本就死活找不到路径，Why？解决了一个下午，无果。
我想我的思维走入了死角，我需要一个人跟我结对，我找来项目组的小新，我们结对解决这个问题，我给他提供了我找到的一些解决方案，然后我们尝试了一些方法，最后在一个外国的论坛上找到了答案。这个论坛上提供的方法，我之前试过，但没有成功，后来发现，我是漏掉了一个步骤，在小新的帮助下，我们没用多长时间就解决了。
再例如，一次解决单点登录跨域，css和js丢失，小海做了几天，快做吐了，也是死了活，活了死，最后我，小新，小海，我们三个结对解决这个问题，我们想利用框架自身的特性去解决这个问题，但我们联系了前端框架的创作者，他表示暂时不支持该功能。晴天霹雳啊，难道我们要为此换掉整个前端框架吗？如果换掉，可想产品组的人们会是什么反应？会吃了我们。让他们重新做前端这块，估计是不行了。我们不得不继续寻找替代方案，大家在一起，思维的确活跃，我们尝试了很多次后，终于敲定了一个折中方案，代价就是损失了一些部署上的灵活性。
还有一些故事，不再说了，在几次结对中，我们总结出了一些东东，跟大家分享下：
1、结对编程，拓宽思路，避免一个人钻入死胡同。所谓，当局者迷，旁观者清。
2、增加了解决问题的耐心，如果一个人遇到棘手的问题，迟迟不能解决，脾气容易暴躁，容易放弃。如果有人作伴，可以更有耐心，可以在互相调侃中解决问题。
3、结对编程，在解决未知领域问题时，有奇效。最好是两个人有一定技术积累，至少一个人已经有所研究。切忌两个新手一起从零开始。
4、结对编程可以使知识互补，让人学到新东西，在解决问题中体会快乐。
以上是我的直观感受，可以看出，我更提倡在解决复杂问题时结对，日常的开发工作，我觉得可以采用火星人陈勇提到的松结对方式，具体我还没有尝试过，试过后再来和大家分享。
敏捷开发实践（4）-有时候我们需要结对编程,布布扣,bubuko.com
京公网安备 11010802041100号