敏捷开发感悟(华为实践敏捷)

一  引言
  
      近来,在BOSS系统团队敏捷开发熏陶和感染下,对敏捷开发求知是蠢蠢欲动. 心动不如行动. 咱也不能被动接受挨打吧. 这几天向战斗在BOSS一线具体参入人员问了卷,
实施敏捷开发大哥们们请教. 感觉是个好东西.它是对传统的以瀑布模式为主的项目管理一次抽取精华和改进(个人认为,PMB项目管理的理念，敏捷开发中具体方法都有它的影子，只是浓缩精华).但觉得脑子里只是一些零散的概念，没有对敏捷开发系统理解。没有整体把握，底气不足，作为敏捷开发中注重以人为主，团队自管的思想， 咱也提不出好的改进意见 . 不利于敏捷持续发展. 于是利用中午和晚上时间在网上下载一些敏捷开发文档学习 , 赶快来武装自己。与时俱进，落后就要挨打哦！
 
   系统学习了敏捷中两个方法（极限编程和Scrum）,结合以前学习的pmb以传统的过程为主，强调文档：一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的唯一信息。
有点像工厂流水线作业. 这一综合，思想就有点火化了。感触敏捷开发体现了一些我们平常生活、人生哲理。就不再太罗嗦，言归正卷了。
 
    
二  敏捷开发所体现的哲理
 
    1、与时俱进，不断改进，不断完善理想
 
       敏捷开发中一个重要的思想就是要在具体项目中不断改进。主张要不断完善，发现问题，勇于针对具体的问题，引起敏捷方法实践
     勇于重构代码。这些理念在我们生活中也同样受用。古人云：知错就改，人无完人。也是要求我们要勇于承认自己的不足，只要我们有勇气
     发现问题，分析问题，勇于改进。这样我们才能够前进。哲学上讲矛盾的原理也是一样的。
 
    2、集中力量解决重点问题，小步前进，稳扎稳打,步步为营
      
      敏捷开发注重迭代开发，增量的进行工作，小步前进,不停的思考、反省和总结，不停地进行自我调整、完善、改进. 这种方法很明显是能够
    及时发现问题、总结问题，降低项目中的需求风险和开发进度风险（需求列表排了优先级，前期就可以把客户确认的重点需求投入精力做好，
    后面迭代sprint周期能够根据前一个周期srpint情况来及时调整和改进）.
 
    3、注重以人为本的思想，注重参入、沟通、反馈
 
        敏捷开发中的极限编程方法论中实践原理中很多体现了这些理念。如：让客户编写user Story,让客户参入具体的功能需求编写过程中；sprint周期
    中定期加强为客户的沟通；客户与开发人员尽量在一起办公；开发人员集中办公，及时沟通；结对编程；隐喻（一些好的规范，专业术语提前在团队
    中集成共识） ,代码共用，晨会等.
        
         这些方法在我们实际生活同样实用.毕竟任何东西还是要由人来做的。因此在各个场合都会存在调动人的积极因素来影响环境和事物。
 
     4、简单原则
 
          极限编程体现跟踪客户的需求变化，既然需求是变化的，所以对于目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，
     实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，增加了软件的复杂度，开发的

     迭代周期就会加长。简单设计包括四方面含义：

                  1、通过测试。2、避免重复代码。3、明确表达每步编码的目的，代码可读性强。

 

       简单哲理在我们生活中也是无处不见，感觉最明显是我们穿的衣服更简朴和舒适，更适合我们个性展示；还有大家经常说复杂问题简单化,简单生活,

    快乐生活等都体现对人生豁达、快乐的态度.

 

     ......

 

三  建议

 

    1、民主参入度有待加强

      

       这几天我问了近十几位一线参入BOSS和CRM敏捷开发人员（大部分是合作方）。主要涉及对敏捷的认知，参入度，参入角色等。发现大家基本还是认同敏捷，

      但是对一些具体的实践方法还是存在模糊的认识，甚至抵触心理。比如：结队编程 （实际上结队编程在运用时是要根据实际情况而定，有一定边界条件。

      像对新员工，对核心关健业务，对sprint迭代检查过程中发现大家编程问题等，这时可以实施结队编程）.其次有就是对敏捷基本都没有一个完整的概念。如：

      敏捷中的基本思想，敏捷中几个主要方法，敏捷每个方法用途和使用的条件等。最后，就是参入访问的人基本都没有接触过敏捷开发软件，对一些天天写在墙上的

      “燃尽图”都不知道，缺少参入意识（写这个时，徐志明发Mingle的使用知会,希望大家在使用这个软件时对敏捷起到加深理解作用。应早该一点发给我们啊！） 。

 

        a  敏捷开发人员是以人为本，着重的实施还是得靠大家，需要大家共同的参入、支持和理解。希望领导在具体实施过程中让更多的人参与进入。

             参入过程中要加强PL的职责和引导大家作用。让更多一线工作人员，特别是合作方，有一个认同感，尊重感。调动他们的积极性和主动性

        b  加强团队组织建设，落实负责人责任制。现在感觉BOSS团队上层参入讨论敏捷很活跃，根据实际的项目运用了敏捷开发中权限编程、Scrum和传统方法结合，

           政策和方向都是正确的，但是到下面pl下一级具体落实下，需要pl对敏捷开发能够灵活运用，引导本组人员进行敏捷开发学习，讨论、参入.

 

    2、 每日晨报内容要根据具体的情况而定

 

       我们进行的晨报大家现在都认可了，大实现中也取得一定效果。但是感觉有些组还是基于它所表现的三种基本的形式（今天做了什么，明天做什么，所遇到困难）.

       个人觉得晨报的内容要根据项目、各个小组具体的情况而定，不可一概而定,基于形式。

 

          a、 根据sprint周期后总结中发现问题，针对性在下一阶段的sprint周期中引入晨报内容。如：在sprint周期总结中发现大家编程不规范，在Daily Scrum meeting

              注重检查编码规范问题；如：上次CRM团队检查代码质量时发现一些问题，在下几个Daily Scrum meeting中注重检查代码质量问题，至到问题解决为至。

         

          b、 根据项目开发不同阶段制定Daily Scrum meeting；

 

         个人认为引为这个东东，还是为了解决问题。在过程中不断改进。

 

    3、 技术专家人员支持、重视有待加强

 

         来华为两年了，感觉这边是很重视业务的，不注重技术。毕竟BOSS业务比较复杂，业务重要是不言而遇。但是在实际的BOSS维护中，发现很多的二线问题、bug单

       都是由技术引起。而一些有经验的老员工，管理人员很少参入到技术当中把关。以至BOSS一些问题单每月每天循环出现。虽然现在引入了测试驱动开发、持久集成等

       方法，但是一些核心业务还是需要技术专家来监督。

 

       a 、 对一些核心代码，关键业务，除了要进行测试外，更重要是专家技术人家承担起负责，对其功能指导、监督、检查，

            必要时可结队编程；

       b、  在团队内部要形成一种气氛和文化，技术和业务都重要。甚至在待遇方面要落实；

 

    .............

 

     看见BOSS团队根据我们实际出发引入敏捷开发，甚感高兴，有喜的事，现在已取一定成果。愿我以上的感悟对我们团队有所帮助和启发