SM日志

最近几天实在是太忙了——忙着scrum团队本身的交付、忙着部门年终联欢晚会的彩排、忙着团队自己的团队魔术表演、忙着工会小组年终的总结报告和2012年上半年的计划、忙着和敏捷教练沟通工作的计划等等，忙的是不可开交，落下了两天的日志。人是有惰性的，一旦有了第一次，第二次就有了名正言顺的借口，真是个不好的开端。

今天比较有感触的是和教练的沟通，谈了很多问题。早上立会立会进行了一半时教练来到了办公室提出了第一个要求，将每日立会改至9:00进行，这样方便他们参加（教练的工作时间和我们不一样） 。之前一直都没有过常驻的教练，突然有了真是有些受宠若惊，呵呵。之后沟通团队的工作内容以及工作如何开展起来，涉及的方面很多，最后总结，主要的中心思想是——目前我们的团队应该做的正确的事情是什么。扩展开来，主要有几个方面的考虑。

1.团队与项目的关系。

    敏捷团队还是试点项目，团队做的事情也是大项目分下来的，以“传统的瀑布模型开发方式和管理方式”已经取得了成功，那么敏捷到底哪里好，为什么要开展敏捷呢？一方面是高层的推动，一方面是敏捷的流行。但是项目的经验理论导致大部分领导对敏捷也是抱着怀疑的态度，尽管是答应敏捷团队进驻到项目中，但还是带着眼镜看待着。这个无可厚非，那么，这里的问题就出来了。传统的工作模式能够满足项目的正常运作，尽管它有着各种的弊端，浪费了多少资源，至少它是能够满足版本的发布计划的。敏捷的价值应该如何体现？

    首先是思想的转变，我们不能再天天喊着“我们需要项目的支持”“开展敏捷需要什么样的资源”，这样理直气壮的去做出要求了。我们应该考虑的是，项目需要什么，项目（领导）上最关注的是什么？那么为了得到开展敏捷试点，得到项目的肯定，所需要的前期投入（初期项目的投入，敏捷方式初期的低效率——这是另外一个论题），就需要团队从项目来考虑，以项目的需求作为至高目标，而不是为了开展敏捷而作为至高目标，尽管从个人和我们团队来说，还是在潜意识里面认为以敏捷方法做事是最重要的，毕竟对个人的成长是有好处的。所以这里的思想转变就是从项目需要出发，满足项目的需求和领导们的要求，以此再来进行团队自身的要求，那么这些要求也会变得理直气壮了。

    我们需要项目和领导的支持。从目前项目的运作来看，项目对子系统和团队是抱着怀疑态度的，是一种不信任（这里涉及的很多细节了不多赘述）。管理的不透明，开发方式的不透明，导致项目领导不知道为什么要开展敏捷，开展敏捷到底有什么必要（传统的开发方式一样是OK的）。我们团队的价值、团队的氛围、精神面貌、工作态度和热情、CI的价值、scrum的管理方式等等，他们都看不到，还是简单的我要什么，你们给我做什么的简单运作。这样不利于项目和领导理解团队的运作和敏捷的好处，我们需要项目的理解和支持，就要让他们参与到敏捷的运作中来。action是由部门领导出面，调动项目的领导做PO（我们实在是推不动啊，面子太小，还好部长十分的支持），使团队的管理对项目呈“白盒化”的管理状态。

    再次，我们需要对比。在项目中，我们的团队是唯一的使用scrum模式运作的，其它的团队还是以传统的模式工作着。为了突出我们团队的价值，使团队的工作更加有说服力，需要对比，需要直观的对比。呵呵，后面的action是，调查“对手”的开发效率、测试效率、协作模式、管理方式（这些我们都十分清楚，重要的是数据）。

2.自动化测试如何开展。

    两个方面。一是在遗留代码的基础上，如何开展，讨论了测试的金字塔和测试流水线的一些问题。二是如何体现自动化测试的价值，也就是如何展现，或者说怎么汇报和写报告，呵呵。由于时间关系暂时还没有定论，不过已经有了一些考量，后期再详细的讨论。

 

    总体来说收获还是很大的，最主要的是如果能得到项目100%的支持，后期的工作应该是十分愉快的，晚上的时候教练告知了一个好的消息，项目的一个大领导会来作为团队的PO，呵呵这里真的要赞美一下部门领导和教练的执行力！

    另外也收集到了一些领导们的疑惑，以及对开展敏捷的一些看法。领导们看问题的层次还是很高的，也引发了我们的思考。希望以后能给他们一个满意的答复。