潮动九州网站建设,做的好的茶叶网站好,wordpress微信登录开发文档,公司网站开发费用兴田德润官方网站客户#xff1a;我们的客户以银行为主#xff0c;他们很注重质量#xff0c;所以一直很注重评审。他们对需求评审、代码走查等也很赞同#xff0c;也能找到缺陷#xff0c;对提升质量有作用。但他们最困惑的是通过设计评审很难发现缺陷。 我#xff1a;你听说过敏捷的结对…客户我们的客户以银行为主他们很注重质量所以一直很注重评审。他们对需求评审、代码走查等也很赞同也能找到缺陷对提升质量有作用。但他们最困惑的是通过设计评审很难发现缺陷。 我你听说过敏捷的结对编程吗 客户听过也给客户做过培训但是一般管理层都接受不了用两个人干一个人的活所以几乎都没有团队在实际工作中使用。 我单做培训确实难以推动并持续必须按3步走按部就班才有效果让我分享一下。
背景
4月
现场结对编程培训之前8个月首次见这家客户的总监。他们想用一年时间改进软件开发质量。事后知道原来他们有个超过12月的大型项目因为验收时质量不达标不能通过风险的验收测试被拒收。因为公司是老字号不想影响声誉请求客户给机会让他们重头再做客户同意但估计产生的损失超过100万所以高层下定决心必须改进软件质量避免类似情况再发生。
7月
与客户签了CMMI服务合同后首先做差距分析 首先收集各领导的关注点。 某部门经理最担心的是系统维护如果有人员离职新人要花很长时间才能上手。 技术总监更担心是有些交付后的缺陷会很花工作量如某系统交付后开始使用的时候很正常但过了9个月用户量和数据量都增加了偶尔会出现有些报表出错我们架构师、工程师等花了3个半月才发现其中某接口的参数有问题。 另外发现开发人员水平参差也没有做好单元测试和代码评审代码可读性低其他程序员难以理解在分析后的汇报里建议利用TDD和面向对象的设计原则改善编码规范并加强培训推行结对编程培训提高代码的可读性方便日后维护。 最后发现很多项目资源不足没有充分的时间确保代码的质量。
给管理层汇报 因缺陷绝大部分都是后期测试才发现、缺陷修改的总工作量很大估计占项目总工作量30%建议加强开发单元测试。 因代码都是个别程序员负责建议团队用结对编程除了能提高质量也防止一人离开其他人无法跟进的风险。 也预警管理层开始时要预留15-25%时间给开发团队当后面返工量减少以后的总工作量会降低生产率提升。
2天培训课
第一天讲面向对象设计原理设计模式测试驱动开发 第二天讲结对编程 问在软件工程常被忽略的最大风险是什么 答不称职的开发人员。据估计美国需要的程序员数量超过20万。这完全是误导。这不是数量问题。我们有质量问题一位糟糕的程序员一年内便很容易就会产生两个新岗位的工作量。如果我们有更多优秀的程序员并且能够轻松识别他们我们需要的就会减少而不是增多。
“也有人说“卓越的程序员比优秀的程序员不仅是好一些而是倍数级的差异。” 请问你们觉得团队里程序员的水平也存在很大的差异” 培训开始对应以上幻灯片我问大家。
你们是否觉得
交付后的软件难以维护其他人难以读懂其他人的代码员工离职后其他成员难以跟进和维护代码总体设计不好如缺乏良好架构不灵活系统交付后有些缺陷需要很长时间才能修复好
如大家希望提高代码质量必须从人入手。
如果你们团队也有同样问题有什么好的解决办法呢培训 编码的最佳学习方式并非读书而是动手做所以单靠搞内部培训效果有限。有什么好方法帮助开发人员提升
代码评审
就算评审规范做得很好能帮助初级程序员提升吗 很难因为代码都已经写完了。 比如我跟另一位老师看团队的代码他们都写了起码几千行。我们的结论就是虽然代码的设计很有问题但已经到了这个地步除非重写否则单靠修正部分代码并没有帮助。这也是代码评审常常难以做好的主要原因。而且大家都要面子如果在评审里直接说他设计有问题也可能会影响到大家的关系所以在设计评审时难以找出缺陷这很正常。 团队主管看程序员代码 只能把关防止严重错误对程序员提升没有作用所以评审不能有效保证代码质量也不能帮助团队能力提升。 当写完了几千行代码后就很难在评审时要求开发改动。程序员会觉得又不是不对测试也跑得通为什么要改。所以代码的质量问题应在写的时候就避免这是结对编程的原理。你可以把结对编程看成是提高团队之间互相交流的培训方法。因为结对编程是在编码时针对具体问题集思广益进行解决很容易落地效果会比培训或评审好。 两个人互相讨论写代码才就是有效的培训不能单挑单靠设计和编码规范和指南。
培训设计
有些人误以为
结对编程必须要找一位合适的搭档人与人之间是否合得来最重要结对时只是在旁边看以为仅仅是教同伴应怎么做以为只是看作为人手编译器只看代码是否写对能否通过编译
我们针对这些重点设计一天培训。
培训重点
要培训有效必须利用练习让学员动手动脑筋。 结对编程和实践说明 练习#1和讨论代码阅读 结对编程说明 练习#2和讨论设计和结对编程 练习#3和讨论Code Review和Pair Programming 练习#4 怎样开始结对编程10分钟结对编程 讨论10分钟正确结对编程 练习#5队伍结对编程 Pair-Solo Programming
练习一用10条代码实例每一条分A与B两种方式写问学员那种更容易读懂说明代码应怎样写才能让一般人容易读懂 练习二先自己按面向对象做总体设计 然后两人结对分享设计做出最终设计学员讨论结对是否有效 然后解释若要持久必须轮流替换伙伴也介绍各类结对方式的利弊例如
Public-private pair programming ; pair - solo programming
练习四先2人试试结对 练习五六人为一队轮流合作写程序让学生体验交换。详见附件
经验分享
结对编程需要2人对话沟通例如某人写代码时另外一个人提问题有些不习惯编写代码边说话沟通培训时预先写好台词。如果想多了解结对编程如何沟通可参考书的实例。 有些程序员比较内向不想说话我们会用角色扮演 先写好台词让他们展示在结对编程时如何沟通。 帮助他们先打出一步鼓励尝试。 注如果想了解结对编程如何沟通可以参照Robert MARTIN先生的保龄球游戏实例参考书里第6章了解两个人如何从需求、总体类设计、按TDD写单元测试用例、然后写代码让它通过一步一步最终完成整个程序。
总结
培训开始时用例子说明结对编程除了能帮助团队知识分享和提高团队精神以外更能
提高代码质量和可读性编码规范提高代码复用加强测试驱动开发
利用互动练习让学员亲身体验结对编程的原则
一边写代码一边说提问如这方法是否归为这个类每人带纸和笔最好铅笔不断想复用
--- *** *** ---
客户我猜你说的3步是 第一步高层认同软件质量问题的严重性为此交过学费知道损失多大 第二步管理层不仅了解软件的质量问题和改善措施更需要内部立项做培训和投入资源人力做过程改进 第三步才是具体的培训课。因为缺乏第一步和第二步所以之前做完了结对编程培训后没有效果 我厉害完全对。结对编程只是改进的一种方法如果高层不关注、不立项、不投入资源不会有改进效果。 结对编程这方法在70年代已经开始与TDD、代码重构已经都经过验证能有效改善质量减少返工。所以结对编程本身没问题要解决的问题是总体质量改进。 若要成功推行结对编程必须先说服管理层投入时间和资源但投资会有好回报。 结对只是一种有效的改进方法团队必须有每个迭代回顾持续提升的好习惯不可能单靠管理层下命令来推行更好是团队自己有改进的动力选择使用结对编程来提升质量减少返工。 本章最佳实践对应
CMMI 单元测试PR 2.X 3.X 所有实践 XP 结对编程代码共同拥有 都是XP里的实践
附件
Ex 5
时间组一组二组三1A 和 B 结对并打开信封XC和D结对并打开信封YE和F结对并打开信封Z看清楚需求然后把X掉了看清楚需求然后把Y掉了看清楚需求然后把Z掉了A和B 开始结对编程A写B看C和D开始结对编程C写D看E和F开始结对编程E写F看2过了4分钟转换3F和A结对编程X F写A看B和C结对编程Y B写C看D 和E结对编程Z D写E看4过了4分钟转换5E和F结对编程XE写F看A和B结对编程YA写B看C和D结对编程ZC写D看6过了4分钟转换7……完……
