论文部分内容阅读
摘要：自上世纪“软件危机”发生后，经过最近二十年的实践与应用，敏捷开发被证实是一种有效的新型软件开发方法并发展起来，甚至被其他行业所借鉴。作者认为，取得高层的支持，根据敏捷开发的特点组建团队，运用师徒结对模式和可持续发展的运营理念，帮助团队理解敏捷的实质并实践真正敏捷意义上的团队管理，是有效的解决之道。
关键词：敏捷开发；团队建设；师徒结对模式；培训
中图分类号：TP311 文献标识码：A 文章编号：1007-9599 （2013） 02-0000-02
上世纪60年代中期，大容量、高速度的计算机出现，使得计算机的应用范围迅速扩大，而软件的可靠性问题也越来越突出，软件危机开始爆发。如今，超出预期的开发周期和经济成本、不尽人意的软件质量、官僚的体系制度、迅速变化的市场环境等因素，使得繁冗、笨重的软件开发过程越来越不能适应现实的需要，导致软件项目的失败率很高。敏捷开发便是在这种背景下应运而生[1]。
1 相关概念
软件开发活动的目的是有效地得到一些工作产物，即一个可运行的有意义的系统，及其支持文档等。软件开发是一种非常复杂的脑力劳动，需要通过团队协作完成。软件开发方法，是软件开发过程中所遵循的方法和步骤。关于组成软件开发的活动，已提出了各种模型，如：软件生存周期、软件开发模型、软件过程等。这些模型都包含了以下经典的阶段：分析、设计、实现及交付、维护。通过软件开发的实践证明，比如在开发的早期阶段多做努力，会较显著地减少在后来的测试和维护阶段的风险和费用。因此，针对分析和设计阶段的软件方法特别受到重视。其他阶段的方法，从程序设计发展的初期起就是研究的重点，已经发展得比较成熟，如程序设计，维护过程等。
新型的软件开发方法——敏捷开发是一种关注价值、消除浪費、以人为核心、迭代、循序渐进的开发方法。在软件开发中，软件项目的建构被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成。在此过程中，软件一直处于可使用状态。较之于瀑布式开发，后者的主要问题是它的严格分级导致自由度降低，项目早期即做出承诺导致对后期需求的变化难以调整，代价高昂，这在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。而敏捷开发则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。相比迭代式开发，两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并更加强调队伍中的高度协作[2]。
2 在国内运用敏捷开发可能遇到的问题及分析
2.1 职业化程度有限造成的问题
敏捷开发针对快速变化的需求，提出的价值观包括重要一点：人与人之间的交互，优先于过程和工具。其特点是：针对问题的要点重点，进行最直接的沟通交流，得到快速有效的解决办法。而有效沟通也是职业化程度的要求之一。国内对于职业化教育的力度有限，特别是二三线城市的职业化水平偏低，因而在运用敏捷开发时，会遇到项目组成员之间相互沟通时的障碍。比如即使发现有关键问题存在，下级碍于情面“不便”提出，或是“以上级的意见为准”。某些情况下，由于官本位作祟，上级对于不同意见或变化不够包容，减弱了沟通的有效性，并进一步抑制了创新的火花。这样的氛围加重了形式化，导致团队未能直面关键问题并进行有效解决，更谈不上对于变化的快速反应。这样，实际未达到敏捷的效果。
2.2 缺乏对敏捷开发的本质理解，由于生搬硬套造成的问题
有一种普遍的误解是：只要运用了最佳实践中的方法，便可以得到预期的效果。而实际上，如果没有理解方法的真正内涵，仅仅使用方法的外壳即形式是解决不了根本问题的。比如国外多年的敏捷开发经验告诉我们，敏捷开发中有一些值得推荐的例行团队活动，如每日立会（Daily Standup Meeting）、回顾（Retrospectives）、看板法（Kanban）等。作者曾亲身经历过该问题造成的差异：某团队领导甲在熟悉了敏捷开发的形式（What）后，在原有的基础上进行了改造，几乎使用了所有敏捷开发提倡的活动。遗憾的是，甲只是运用了敏捷的形式，而缺乏敏捷的精神，比如做回顾时，没有把重点放在解决问题上，反而变成抱怨诉苦大会，不但基本问题没有解决，还因为开发形式的变化和失控反而消耗了开发效率，导致士气低迷。与之形成对比的团队领导乙，对于敏捷开发的理解到位（Why/What/Where/When/How），不断摸索并根据实际情况做灵活的改进，因此该团队在开发成果，效率，团队士气等维度上远远超过了前者，团队面貌焕然一新。
2.3 工作陋习带来的负迁移造成的问题
敏捷开发的重要特点之一是：以人为核心，关注价值，消除浪费。开发人员积极主动的内驱力是团队的宝贵财富。国内的工作环境，提倡奉献精神，辅以形式。有效的奉献可以为参与者带来自我肯定与激励，而无效的奉献则是应避免的，如即使任务完成了，也被要求参与集体加班等；开会等活动应以解决问题作为始终目标，而不应是因为它是例行活动而展开。若无效的奉献成了企业文化，则与敏捷的精神相悖，从以往经验来看，容易造成软件项目的风险陡增，人员流动频繁，导致公司缺乏积累与沉淀。
3 运用团队建设实施敏捷开发的步骤
3.1 取得高层的支持
首先应和高层进行充分的沟通，确认取得支持与后援，最好高层本身对于敏捷是高度理解的，其作风也符合敏捷的精神，则是比较理想的情况。若高层本身对于敏捷开发的本质存在怀疑或不认同，则会直接影响之后开展的效果，并在遇到困难时陷入进退两难的境地，很难达到敏捷开发的效果。这对于敏捷开发的实施先驱者尤为重要。
3.2 搭建合理的团队结构与运行理念
一种已被证明有效而简单的组队模式是师徒结对模式，即领导者与被领导者之间是师徒关系，一个“师傅”带3至5个“徒弟”，企业对“师徒”进行整体考核。要与“师傅”明确其职责，包括：计划、估算、跟进、进度、质量、徒弟成长等。对于运行理念，提倡在工作中学习，在获得成果的同时，提升个人价值。“师傅”在过程中指导“徒弟”并把握进度，对“徒弟”完成的最终结果负责。也正因为这个模式，不建议给“师傅”过重的个人开发任务，把“徒弟”培养好并帮助他们发挥出生产力，这比个人生产力要持久，更具长远意义[3]。
3.3 重视培训与交流的作用
开发成员间产生共识，从而自发自动地工作，其积极作用远大于被动接受命令。因此，培训与及时交流的作用非常重要。利用培训来解决成员的共同疑问（4W1H），使团队在大方向上共同朝一个目标努力。同时“师傅”要有“无我”的心态：鼓励“徒弟”畅所欲言并独立思考——追求最简单有效的方法，而不只是“师傅”的方法。“师傅”利用指导检查点的机会与“徒弟”进行充分的交流与火花的碰撞，同时这也是“徒弟”向“师傅”学习业务技术和敏捷精髓的好机会，既鼓励了“徒弟”，也为将来的下一个“师傅”奠定了培养基础，是长远的可持续发展的计划。
参考文献：
[1]陈勇.敏捷开发专栏[EB/OL].http：//blog.csdn.net/cheny_com
[2]佚名.维基百科，自由的百科全书下的条目之敏捷软件开发[EB/OL].http：//zh.wikipedia.org/wiki/%E6%95%8F%E6%8D%B7%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91.
[3]贾子河，段永刚，蒋博，段珊珊.轻松Scrum之旅—敏捷开发故事[M].电子工业出版社，2009（1）.
关键词：敏捷开发；团队建设；师徒结对模式；培训
中图分类号：TP311 文献标识码：A 文章编号：1007-9599 （2013） 02-0000-02
上世纪60年代中期，大容量、高速度的计算机出现，使得计算机的应用范围迅速扩大，而软件的可靠性问题也越来越突出，软件危机开始爆发。如今，超出预期的开发周期和经济成本、不尽人意的软件质量、官僚的体系制度、迅速变化的市场环境等因素，使得繁冗、笨重的软件开发过程越来越不能适应现实的需要，导致软件项目的失败率很高。敏捷开发便是在这种背景下应运而生[1]。
1 相关概念
软件开发活动的目的是有效地得到一些工作产物，即一个可运行的有意义的系统，及其支持文档等。软件开发是一种非常复杂的脑力劳动，需要通过团队协作完成。软件开发方法，是软件开发过程中所遵循的方法和步骤。关于组成软件开发的活动，已提出了各种模型，如：软件生存周期、软件开发模型、软件过程等。这些模型都包含了以下经典的阶段：分析、设计、实现及交付、维护。通过软件开发的实践证明，比如在开发的早期阶段多做努力，会较显著地减少在后来的测试和维护阶段的风险和费用。因此，针对分析和设计阶段的软件方法特别受到重视。其他阶段的方法，从程序设计发展的初期起就是研究的重点，已经发展得比较成熟，如程序设计，维护过程等。
新型的软件开发方法——敏捷开发是一种关注价值、消除浪費、以人为核心、迭代、循序渐进的开发方法。在软件开发中，软件项目的建构被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成。在此过程中，软件一直处于可使用状态。较之于瀑布式开发，后者的主要问题是它的严格分级导致自由度降低，项目早期即做出承诺导致对后期需求的变化难以调整，代价高昂，这在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。而敏捷开发则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。相比迭代式开发，两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并更加强调队伍中的高度协作[2]。
2 在国内运用敏捷开发可能遇到的问题及分析
2.1 职业化程度有限造成的问题
敏捷开发针对快速变化的需求，提出的价值观包括重要一点：人与人之间的交互，优先于过程和工具。其特点是：针对问题的要点重点，进行最直接的沟通交流，得到快速有效的解决办法。而有效沟通也是职业化程度的要求之一。国内对于职业化教育的力度有限，特别是二三线城市的职业化水平偏低，因而在运用敏捷开发时，会遇到项目组成员之间相互沟通时的障碍。比如即使发现有关键问题存在，下级碍于情面“不便”提出，或是“以上级的意见为准”。某些情况下，由于官本位作祟，上级对于不同意见或变化不够包容，减弱了沟通的有效性，并进一步抑制了创新的火花。这样的氛围加重了形式化，导致团队未能直面关键问题并进行有效解决，更谈不上对于变化的快速反应。这样，实际未达到敏捷的效果。
2.2 缺乏对敏捷开发的本质理解，由于生搬硬套造成的问题
有一种普遍的误解是：只要运用了最佳实践中的方法，便可以得到预期的效果。而实际上，如果没有理解方法的真正内涵，仅仅使用方法的外壳即形式是解决不了根本问题的。比如国外多年的敏捷开发经验告诉我们，敏捷开发中有一些值得推荐的例行团队活动，如每日立会（Daily Standup Meeting）、回顾（Retrospectives）、看板法（Kanban）等。作者曾亲身经历过该问题造成的差异：某团队领导甲在熟悉了敏捷开发的形式（What）后，在原有的基础上进行了改造，几乎使用了所有敏捷开发提倡的活动。遗憾的是，甲只是运用了敏捷的形式，而缺乏敏捷的精神，比如做回顾时，没有把重点放在解决问题上，反而变成抱怨诉苦大会，不但基本问题没有解决，还因为开发形式的变化和失控反而消耗了开发效率，导致士气低迷。与之形成对比的团队领导乙，对于敏捷开发的理解到位（Why/What/Where/When/How），不断摸索并根据实际情况做灵活的改进，因此该团队在开发成果，效率，团队士气等维度上远远超过了前者，团队面貌焕然一新。
2.3 工作陋习带来的负迁移造成的问题
敏捷开发的重要特点之一是：以人为核心，关注价值，消除浪费。开发人员积极主动的内驱力是团队的宝贵财富。国内的工作环境，提倡奉献精神，辅以形式。有效的奉献可以为参与者带来自我肯定与激励，而无效的奉献则是应避免的，如即使任务完成了，也被要求参与集体加班等；开会等活动应以解决问题作为始终目标，而不应是因为它是例行活动而展开。若无效的奉献成了企业文化，则与敏捷的精神相悖，从以往经验来看，容易造成软件项目的风险陡增，人员流动频繁，导致公司缺乏积累与沉淀。
3 运用团队建设实施敏捷开发的步骤
3.1 取得高层的支持
首先应和高层进行充分的沟通，确认取得支持与后援，最好高层本身对于敏捷是高度理解的，其作风也符合敏捷的精神，则是比较理想的情况。若高层本身对于敏捷开发的本质存在怀疑或不认同，则会直接影响之后开展的效果，并在遇到困难时陷入进退两难的境地，很难达到敏捷开发的效果。这对于敏捷开发的实施先驱者尤为重要。
3.2 搭建合理的团队结构与运行理念
一种已被证明有效而简单的组队模式是师徒结对模式，即领导者与被领导者之间是师徒关系，一个“师傅”带3至5个“徒弟”，企业对“师徒”进行整体考核。要与“师傅”明确其职责，包括：计划、估算、跟进、进度、质量、徒弟成长等。对于运行理念，提倡在工作中学习，在获得成果的同时，提升个人价值。“师傅”在过程中指导“徒弟”并把握进度，对“徒弟”完成的最终结果负责。也正因为这个模式，不建议给“师傅”过重的个人开发任务，把“徒弟”培养好并帮助他们发挥出生产力，这比个人生产力要持久，更具长远意义[3]。
3.3 重视培训与交流的作用
开发成员间产生共识，从而自发自动地工作，其积极作用远大于被动接受命令。因此，培训与及时交流的作用非常重要。利用培训来解决成员的共同疑问（4W1H），使团队在大方向上共同朝一个目标努力。同时“师傅”要有“无我”的心态：鼓励“徒弟”畅所欲言并独立思考——追求最简单有效的方法，而不只是“师傅”的方法。“师傅”利用指导检查点的机会与“徒弟”进行充分的交流与火花的碰撞，同时这也是“徒弟”向“师傅”学习业务技术和敏捷精髓的好机会，既鼓励了“徒弟”，也为将来的下一个“师傅”奠定了培养基础，是长远的可持续发展的计划。
参考文献：
[1]陈勇.敏捷开发专栏[EB/OL].http：//blog.csdn.net/cheny_com
[2]佚名.维基百科，自由的百科全书下的条目之敏捷软件开发[EB/OL].http：//zh.wikipedia.org/wiki/%E6%95%8F%E6%8D%B7%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91.
[3]贾子河，段永刚，蒋博，段珊珊.轻松Scrum之旅—敏捷开发故事[M].电子工业出版社，2009（1）.