zoukankan      html  css  js  c++  java
  • 敏捷开发“松结对编程”实践日常工作篇

    团队中常见的一种情况计划、估算、设计的时候大家还在一起,但编程的时候就会分开。分开看似是安全的,但是却充满隐患。

      2001年,一位招聘考试前三名(一共120员工)的程序员的两个月的成果被彻底放弃重写,原因是里边包含3000多个常数,而且很难修改(码 流参数),重写的人座位距离他只有4米,重写也只花费了2周;2002年,一位月薪7000(那时候北京房价才3000多)的程序员编写了一个月的 4000多行代码,在一个下午被重写为50多行,座位距离他只有5米的项目经理疑惑加惊讶地问:“你真的没学过c++ template?”。

      这就是团队的距离,即使是高薪聘请来的程序员也难免犯错。难道我们只能避免下一次问题发生,而不能避免这次问题发生?

      前检查点

      前检查点就是在做某功能的最初一段时间,师傅与徒弟结对编程,完成最初最重要的设计。

      “开始做X功能的时候叫我一声,咱们敲定一下具体怎么做。”这个是师傅的前检查点标准语法。尽管在共同估算的时候大家还是略有共识,但是限于计 划会的有限时间,徒弟未必真的知道怎么做。在刚开始的一两个小时里边,师傅带领徒弟一起把基本的结构理清楚,最好写上一些基本代码,让徒弟有一个直观的概 念。

      在上面提到的2周的重写工作中,重写者和被重写者一起工作了1.5天,重新设计了打包类、递归函数等最难缠的部分;被重写者在剩下的两周里边完 成了工作,而且很出色。倘若这一切发生在两个月前该多好。那次事故之后,我们订立了更严格的代码审查制度,所有代码均由部门技术最好的人审查后才进代码 库;之后再来的新人,均指派师傅,并由师傅保证其代码质量;将人员划分为需指导的/免于指导的/可指导的/可培训的四级(10年后我在NEC参观交流时发 现了几乎完全相同的分级制度)。

      前检查点的工作作用是打下设计的基础,保证工作顺利进行。如果一切按照前检查点的设计进行,徒弟可以继续独立工作,如果有偏离,要询问师傅。

      前检查点的学习作用是显而易见的,师傅平时工作的精华都展示在徒弟面前。而且这种展示是动态的,在结对编程的状态下,徒弟可以完整地看到师傅是怎样入手工作,怎样

      后检查点

      后检查点就是某事做完后,师傅检查一下徒弟的结果,保证达到验收标准。

      曾经分配给我一个刚毕业半年的组员,刚来没多久就经常看到他上网玩,过去一问,原来工作做完了(真的非常快),惊奇之余赶紧看看结果:功能是有 了而且实现得也很好,就是总有点瑕疵:要么按钮不正,要么界面上有错字。后来就改成每次任务完成都赶紧喊我去看看,修正后继续下一个。他后来能力超群,在 此公司作为“台柱子”10年,现在还在。

      其实多数新人在大学中都形成了“能运行就行”的概念,并不懂商业软件开发的标准。本人也一样,毕业5年还不知道delete内存(C++),每 次都是多预留点C盘空间,这样程序就能多运行一段时间,下班之后关机重启就可以了……这样的软件肯定无法在服务器上长期运行的。

      后检查点的工作作用是可用来进行代码审查,以确保软件产品的质量,之后会提到。

      后检查点的学习作用是帮助新人学习商业软件的开发标准,逐步养成好的习惯。

      日常工作

      除了在任务前后的时间点外,日常8小时也应该保持良好的沟通。在一次极端的环境中,我们曾经将其发挥到极致。

      当时我们以很高的日薪临时聘用了两个不错的程序员。他们技术虽然很好,但是却对业务一无所知,也没有提前看过文档。因为总共也没有多少天,当然不能把任何一分钟花费在熟悉业务上,所以……

      1. 每天早上(包括第一天)

      整个软件被大致分为三类功能区,互相关联。组长(我)也自己编程,负责其中一类功能。

      有20分钟的晨会,组长会把一个简单的设计文档的一部分拿出来讲解给两个人,同时指出今天要做的工作要给予其中的哪些内容,他们提问我回答。散会前我们会就没人的工作做一个简单的估算(当年还不会扑克牌估算,太可惜了),确保当日是可以完成的。

      晨会会提到技术问题,而不是每日立会中说的只说进度。但技术问题一般只涉及到要求,比如“做分段计价模型的时候,不要在C++里边做For循 环,看能不能在SQL里边解决,如果解决不了来找我”“好,我试试。(或)这可能吗?”凡是有问题的就会稍微深入一点;凡是“我试试”的,都放过,但如果 试验的结果不通就必须找组长讨论而不能自行解决。

      小组加组长只有3个人,所以所有人都参加这个20分钟会,包括肯定不做某任务的人,也听组长和别人的讨论。

      2. 每天下午1:30点左右

      就是吃饱饭犯困的时候,组长会分别和大家在计算机前碰头一下,主要是看当日的工作是否可能在下班前完成(坚持不加班);另外就是看是否和晨会上预想的一样。

      其实就算是短短的半天时间,事情就可能有变。有一次其中一个程序员在一上午写了大约4屏幕的代码(一般每天才写这么多),而功能却遥遥无期。原来他不知道有个函数可以快速实现这些功能,正在自己造轮子,他本应该告诉组长所遇到的困难。

      程序员很少在这个时候求助,他们总是相信自己能最终解决问题……因此在转型为自组织团队的时候,担心程序员会偷懒的想法整体上是多余的,更需要预防的是蛮干/过于乐观/激进/需求镀金/消息闭塞/无法互相学习等问题。

      3. 每天下午下班前

      当时6点钟有《七龙珠》(工作场所有台电视),两位对此都很着迷,所以我们基本到点就看片,看完后散伙回家。

      因为也不能让电视台调整播出时间,基本上下午5点就要开始打扫战场:组长分别找两位,看最终结果是否完成,并做一下修改。同时还要做代码审查(请看下一篇详述)。

      由于估算不会太准确,我们专门把所有三不管的小功能梳理出来,谁提前做完了,谁就找其中一个把剩下的闲工夫占上,结果其中一位几乎包揽了全部。

      4. 晚上

      对,组长晚上还要工作。在他们走后组长会在晚上做个集成,把几个人做的功能合成在一起运行。当时也没有持续集成工具,所以只能手工。

      在正常项目的正常团队中,这个工作应该在第二天的工作时间完成,也就是说或者找专人(或轮流),或者让组长做,或者让自动工具做最好。推荐小组内轮流负责此事,因此可以让大家理解别人的工作、整体的工作,乃至与组外人员的集成工作等内容,为组员成长为组长打下基础。

      5. 随时

      可以已经注意到我们没有“每日立会”,一则当年还不知道Scrum,二则感觉一个3~5人的团队还要靠开会交流实在迂腐。比如在篇首提到的两次事故中,团队都没有少开会,但都因为缺少随时的沟通而导致大错。

      其实任何伸伸懒腰的时间都可以进行沟通。不过一般不要“太随时”,应该以师傅的时间为主,也就是如果徒弟遇到了问题,但可以绕过去先走着,就先 来一句“我这有问题,有空帮忙看看”+“好,再过15分钟”。这样既不会让徒弟被卡住,也不会让师傅因为经常被打断而导致无法工作。但师傅可以随时发起交 流,因为他们是去帮助徒弟的,聊的也是徒弟的事情,不存在打扰的说法。

      注:上述部分内容仅限于特定环境中,但思路很多时候都是可取的。

  • 相关阅读:
    使用JDBC连接MySql时出现:The server time zone value '�й���׼ʱ��' is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration
    Mysql Lost connection to MySQL server at ‘reading initial communication packet', system error: 0
    mysql-基本命令
    C# 监听值的变化
    DataGrid样式
    C# 获取当前日期时间
    C# 中生成随机数
    递归和迭代
    PHP 时间转几分几秒
    PHP 根据整数ID,生成唯一字符串
  • 原文地址:https://www.cnblogs.com/hxwzwiy/p/2419145.html
Copyright © 2011-2022 走看看