敏捷思想

敏捷思想（共9篇）

敏捷思想 篇1

0 引言

随着信息化的快速发展, 计算机软件在社会生活各个领域的应用日趋广泛, 对软件质量的要求也越来越高。随着我国软件工程化水平不断提高, 人们已深刻意识到软件测试是衡量和保证软件产品质量最直接的手段, 软件测试在整个软件生命周期中的地位得到了极大提升。为了提高软件测试的专业化和标准化水平, 总装备部颁布了GJB2725A《测试实验室和校准实验室通用要求》标准。该标准规定了实验室的质量方针和质量目标, 规范了软件测评实验室的各项工作。

在软件工程化实践过程中, 敏捷开发过程由于能很好地适应需求不确定与需求变更的软件开发流程, 受到了业界的广泛关注与欢迎。敏捷开发过程已经逐渐上升为敏捷思想, 深刻地影响着软件开发各领域。在软件测试领域也经常发生由于需求不确定、需求变更等情况导致的软件开发计划阶段性变更、软件测试时间被压缩等现象, 测试人员面对软件需求的变更, 将大量时间浪费在文档上, 而没有将时间集中在软件实际测试中。本文结合敏捷开发思想, 针对软件测试过程提出改进办法。实践表明, 本文的方法能够更好、更高效地完成软件测评工作。

1 基于GJB2725A的软件测评过程

基于GJB2725A标准体系的软件测评不仅关注技术层面, 还包括组织、技术和人员3个方面[1]。本组织基于GJB2725A标准建立了一套软件测评实验室体系, 下面对该软件测评实验室进行简单介绍。

实验室测评体系对测评过程的组织进行了合理设置, 保证有专门的角色负责追踪项目进展, 以及进行缺陷控制、版本变更及跟踪等活动。由实验室最高管理者任命各软件测评项目的测试组, 包括测试负责人、测试人员、监测人员、配置管理员, 并任命质量监督员对项目实施监督。

软件测试过程中只有保证对测试过程每一步的输入输出及相关工作产品进行严格的版本控制, 才能保证测试质量管理活动的有序、有效开展。本组织标准的软件测评过程要求测试人员与开发人员每一次被测件与文档交接工作都有相关记录并纳入受控库管理。因此, 在整个测试过程中除了产生传统的软件测试文档外, 还会针对项目相关方对受控库中材料的提取、变更、新建等行为产生相应的配置管理单据。

目前的测评工作基于文档进行过程管理, 且主要测评工作都集中在测试策划、测试设计与测试执行3个阶段。3个阶段的测评工作产品呈现出强耦合关系, 例如软件测试设计阶段中测试用例的设计依赖于上一阶段的测试计划产品, 测试执行阶段又依赖于测试设计阶段编写的测试用例。

基于文档的渐进式阶段过程规范了测评过程中开发方与测试方的工作顺序, 各执行阶段之间的强耦合也保证了整个测评工作与用户需求的可追溯性。虽然该测评过程很好地满足了“瀑布模型”思想, 有利于软件利益相关方明确掌握测评过程全部细节, 但其测评过程的规范性在一定程度上是以牺牲灵活性为代价的。而且由于某些型号软件面临着研发时间短、研制任务重等特点, 导致在软件开发完成后仍会有较大规模的变更, 这对软件测评过程提出了挑战, 其中最大的挑战即测试文档的“适应性”变更。

目前每一版入库的测试文档都是在一阶段完成后产生的内容完整的测试产品, 因此当测试需求发生变更时, 尤其是当变更情况出现在测评过程后期时, 往往会“牵一发而动全身”, 测试人员为保证测试文档记录的前后一致性, 不得不从测试需求阶段的工作产品开始补充修改。使用相互独立的Word文档记录测试过程的方式导致测试人员深陷记录补充的泥潭, 投入大量精力对文档进行反复修改。因此, 可以考虑引入“敏捷”思想对测评流程进行改进, 同时利用自动化工具进行需求和测试用例管理, 以减少人工在编写文档方面的时间投入, 从而将更多精力投入到测试方法的研究及测试执行上。

2 引入敏捷思想改进软件测评过程

2.1 测评过程敏捷化

软件从业人员已经提出并实践了多种敏捷测试过程、敏捷测试方法, 例如文献[2]就详细介绍了敏捷测试的核心及具体实践步骤。但目前多数敏捷测试方法是将整个测试过程 (测试策划、测试设计、测试执行) 分解为多轮冲刺进行, 提议减少甚至省略测试文档的编写, 而这种敏捷测试模式并不符合GJB2725A标准中对记录控制的要求。因此既要使测评过程符合GJB2725A标准, 又要能够适应需求不确定性带来的挑战。基于以往型号项目开发的实际情况, 将测试执行前的需求分析、测试策划、测试设计3个阶段分为多个迭代阶段进行, 当积累到一定测试工作量后再执行测试, 合并后各迭代阶段的工作流程如图1所示。

首先, 在每个阶段的计划会议上, 从组织资产库中了解组织生产率, 与开发人员沟通当前已确定的需求, 进而估算本阶段可完成的工作及需要的时间, 然后相应制定本阶段的冲刺计划。具体要求如下:

(1) 每阶段的计划会议可分为两个步骤进行。首先邀请利益相关方 (如开发人员、用户等) 参与, 可在计划会议上共同完成对《软件需求规格说明》文档的评审, 让利益相关方共同对项目需求中的确定项与不确定项进行识别并标识, 将确定项纳入本阶段任务列表。然后, 软件测评团队根据任务列表进行内部任务指派, 制定时间节点以保证工作效率。

(2) 对于项目启动初期即表现出需求不稳定特点的项目, 可考虑在不同时间段多次进行分析策划过程, 并在每一次策划总结会议上邀请利益相关方对本阶段完成的产品增量包括测试需求规格说明、测试计划、测试说明等文档进行评审, 若已经被标记为确定项的需求描述没有变更, 则本阶段文档延续至下一阶段, 若本阶段确定项的需求描述有变更, 则将测试文档的相关部分标记并删除, 将变更的需求纳入下一阶段任务列表。同时, 利益相关方还应对上一阶段计划中被识别为不确定项的需求再次进行确认, 若有已确定的需求, 则修改其标识, 由测试人员将其纳入本阶段任务列表中。

会议上配置管理人员应对当前阶段的测试产品进行版本固化和控制, 这样, 当后续迭代阶段中需求变更出现反复时, 可快速从上一阶段文档中恢复对相应测试需求的测试项和测试用例设计。需要注意的是, 待需求较稳定后再考虑将测试执行并入迭代阶段。

(3) 测试执行后的阶段总结会议可以和下一阶段的计划会议合并, 对当前已完成的测试情况进行总结并统计目前的测试覆盖率, 并将未覆盖的测试需求纳入下一阶段工作计划。倘若是配置项软件测试项目, 可视情况将部分 (10%左右) 未覆盖的需求点留待系统测试验证。

2.2 测评文档编写敏捷化

目前测评项目中文档的编写工作随测试进度分为多阶段进行, 在每一阶段完成后形成一份完整的记录文档, 且每一份文档中都包含与前一阶段工作相关的“追溯”内容, 例如测试项与测试需求之间的正逆向追溯、测试用例与测试项之间的正逆向追溯。这样完整的记录文档无形中给后期的文档变更造成了一定程度的阻碍。因此对测试文档的编写工作提出以下建议:

(1) 记录形式的变更。当前所有测试文档均以Word文档形式记录, 对于每一个测试项和测试用例的描述则以表格的方式进行叙述。为保证测试需求到测试实例的可追溯性, 在每一份文档后还编写了正逆向追溯表, 但在实践中却暴露出测试文档编写工作量大、需求修改时多个文档间的追溯易乱两大弊病。针对这两个问题, 本组织实行测试文档记录方式的多样性, 引入Excel文档进行记录。在Word文档中记录测试计划、测试说明中的公共部分, 包括范围、引用文档、测试依据、测试描述、测试环境等信息, 这一部分信息通常在项目开始前就可以确定且后期很少变更, 而关于测试项和测试用例的具体描述信息可放在Excel中填写, 并作为附件被引用。这样可以将测试需求、测试项、测试用例的具体描述放在一份文档的多个表格中, 借助Excel表格管理的优势可以更便捷地实现软件需求—测试需求—测试项—测试用例的多层追溯, 保证测试覆盖率。

(2) 文档编写的阶段性。基于上文中提出的测试分析过程迭代进行, 相应记录文档的编写工作也可以阶段性进行。在首次迭代过程中, 可以将文档的公共部分, 包括已确定的软件需求对应的相关测试需求、测试计划、测试说明编写完成, 对于未确定的软件需求, 应在文档中列出其名称作为标识, 留待下一阶段继续补充, 这样也可避免软件需求的遗漏。追溯可留到最后一阶段再进行整理和汇总, 文档全部完成后再统一入受控库, 此后再出现变更则按照现行体系文件规定执行变更流程。对于阶段性完成的文档可通过特殊的命名方式作为版本依据, 例如“时间_版本”形式等。

2.3 测试管理工具应用

信息化发展使设备的软件配置规模越来越大, 依靠Word或Excel进行测试文档的管理也会越来越复杂。在条件合适时, 应当引入测试管理工具实现对测试需求、测试用例、缺陷跟踪进行高效管理。目前市场上的测试管理工具种类繁多, 其中HP公司推出的基于Web的测试工具TestDirector比较具有代表性, 其功能比较齐全, 能够系统地控制整个测试过程, 并创建整个测试工作流框架, 还可以与HP公司的其它工具进行集成, 市场使用率也较高[3]。

当然, TestDirector作为一款商用软件, 也存在着费用较高等问题, 并且其强大的测试过程管理功能要求用户完全依照它制定的测试过程进行, 可能与测评实验室现存体系存在冲突。鉴于此, 也可以考虑使用多个开源免费的工具共同辅助测评, 例如可针对缺陷管理环节使用Bugzilla缺陷管理工具, 使开发人员对代码缺陷的修复可以与测试执行同步进行, 大大缩短了测试人员出具测试报告并等待回归测试的时间。

3 敏捷化软件测评过程优势分析

将测评过程按照上述方式进行敏捷化改进后, 主要有以下几大优势: (1) 将一个软件测评项目分为时间上不连续的多个阶段进行, 使同一测评团队可同时进行多个测评项目, 提高时间利用率; (2) 阶段性的文档编写方式减少了频繁出入库次数, 减轻了配置管理员的工作量; (3) 使用测试管理工具记录、保存、生成需求分析, 测试计划、用例及缺陷数据, 可极大程度地减少文档编写工作量, 减小测试文档厚度, 且测试管理工具自带的图表统计功能可更形象地反映当前的测评项目实际状态。

4 结语

本文首先描述了基于GJB2725A标准的本组织软件测评过程, 并分析了该过程在实际运用中可能存在的问题。然后结合当前颇受推崇的“敏捷”思想提出了对当前测评过程和测评文档编写的敏捷化改进建议, 并提出在测评过程中应用测试管理工具提高工作效率, 以降低测试人员的无效工作量。关于如何将测试管理工具更好地应用于测评过程, 还需今后进行更深入的研究和探索。

参考文献

[1]崔丽娜.基于CNAS准则的软件测试方法与实践[D].北京:北京邮电大学, 2012.

[2]徐飞.敏捷测试过程[J].软件导刊, 2011, 10 (4) :23-24.

[3]李长星, 时静.Test Director在测试管理中的应用[J].电子测试, 2013 (2) :76-79.

敏捷思想 篇2

一些敏捷实践者在盐湖城的敏捷圆桌会议中也对敏捷开发中的常见问题进行了讨论，Sean Landis会后在个人博客上总结了常见的十一个问题：

1. 技术负债在敏捷团队中会快速的膨胀。

2. 敏捷软件开发团队会想当然地认为每个团队成员都专业，称职并富有责任心。如果事实不是如此，项目开发很快会变得举步维艰。

3. 由于对敏捷开发实践的错误理解，导致团队不合理地频繁交付，疲于奔命。

4. 实施敏捷的门槛太高，敏捷开发需要更强的团队和个人的纪律性，勇于承诺和高度的公开性，但对一个不成熟的组织来说这个门槛太高。

5. 绩效差的团队成员很难在高度公开的敏捷团队中掩饰自己能力的不足。好的团队往往能够采取一定的措施来帮助这类成员。但如果没有采取措施，这些成员往往会想方设法通过消极怠工来掩饰自己能力的不足。

6. 敏捷团队容易过份关注眼前的短期目标，而忽视长期的战略目标。尽管在短期内能够取得成功，长期注定还是会失败。

7. Product Owner承担了太多的责任，不堪重负，从而成为团队的瓶颈。

8. 敏捷的效用被过度夸大，大家的期望值太高，很多人认为导入敏捷能以最小的投入解决实际开发中的所有问题。

9. 可能出现另一种形式的“相互诟病”。成功的敏捷开发团队一般不会成为产品开发的瓶颈，因此其他部门不能以这个为借口来指责开发团队，但是这有可能进一步演变成为政治游戏。

10. 当Product Owner开始决定开发的方向，他就会被过度授权。敏捷开发中缺乏足够的审查和平衡机制。

11. 敏捷实践大多是针对程序员的，很难在组织内平衡工作量。缺乏对团队中的非程序员提供更好的文档以及培训支持。

Chris Tyler在个人博客（注，可能需要爬墙）中针对这些问题做出了回答。

问题一，是事实，但这并不是敏捷本身的问题，只不过是在敏捷导入和实施过程中没有引起足够的重视。经验丰富的敏捷教练往往十分重视工程类实践，会强调重构在迭代中的重要性。很多的敏捷实践(比如TDD，持续集成，重构)及很多敏捷开发者提倡的原则(比如S.O.L.I.D原则，Clean Code,Implementation Patterns )都能帮助敏捷团队避免过多的技术负债。Uncle Bob甚至认为应该在最初的敏捷宣言中加入第五条原则“Craftsmanship over Crap”，来强调技术的对成功的敏捷项目的重要性。

问题二，是事实，但这恰恰又是敏捷的卖点。我们应该做到：谦虚有耐心；勇于承诺；团队成员互信互助，而不是互相指责批评；承认自己的能力不足，不断追求进步，需要的时候寻求团队成员的帮助。很多方法论认为只能通过审查监控的手段来确保项目的顺利运行，而敏捷团队更多的是依靠个人的责任心。在优秀的敏捷团队中，能力较弱的的团队成员会感受到来自其他成员的压力，要不然尽力做好，要不然只有走人。

问题三，说老实话，在了解敏捷之前，研发团队才是疲于奔命。敏捷原理打破了传统的思维模式。人很容易犯错误，但是很多敏捷实践(结对编程，持续集成，TDD)能够帮助开发团队及早发现问题，纠正错误。因此敏捷反而把我们从传统的思想束缚中解脱出来。可能是由于对敏捷的过度宣传，导致大家对敏捷期望值过高，认为敏捷开发是解决所有问题的万灵药。其实我们导入敏捷也是受种种因素（客户环境，团队对敏捷的认识程度，成员的能力）限制的。如果能够从其他更成熟的敏捷团队或者敏捷教练那里吸取经验这样会更好，否则只能合理的逐步的导入实践。很多敏捷项目确实存在过于频繁的交付，那是由于人们迫于各种压力，“好大喜功”的天性而忽略了敏捷其实一直在强调的“根据每个迭代能够实际发布量”（也就是真正能够达到Done标准的工作量）来调整下一个迭代工作量，

管理资料

如果团队不能自主调整工作量，这其实已经偏离了敏捷。

问题四，是事实。但是这并不意味着不能在不成熟的组织中导入敏捷实践。这类组织可以逐步地导入敏捷实践。很多人太过心急，想“一口吃一个胖子”，但这往往是不切实际的。当然，同时必须要注意的是，不能因为采取逐步导入的手段，而降低敏捷定义的门槛(Ron Jeffries有一篇文章“Agile Is, Not, Maybe”)。

问题五，绝对是事实，敏捷需要勇气，但是这绝对是好事。态度决定一切！敏捷团队所不能容忍的是那种故意偷懒的成员。每个人都会经历从学徒到专家的过程（获得技能的Dreyfus模型，及Apprenticeship Patterns: Guidance For The Aspiring Software Craftsman）。由于每个人的能力不同，背景不同，能达到的高度也是不一样的。团队成员应该承认个体差异，努力帮助较弱的团队成员，使其快速成长。

问题六，可能是事实，但是这在非敏捷团队中也屡见不鲜。不可否认的是在敏捷项目中，很多人过分强调了YAGNI，因而在早期忽视了一些战略性的目标，尤其是业务需求目标，从而导致后期重构十分困难。YAGNI是很有用的，但是需要其他实践比如TDD和BDD（行为驱动设计）的支持。Kent Beck在极限编程一书中讲述了怎样借助TDD，实现演进式设计。另外需要注意的是，这其实在很大程度上是一个平衡的问题，怎样在YAGNI与预先设计之间做平衡。

问题七，也是事实。但是作为对产品最有热情的人，Product Owner难道不愿意花时间和精力帮助团队开发出符合需要的产品么？敏捷极大地缩短了从需求到软件的周期。再也不会出现Product Owner等上6个月或者更长的时间，结果发现做出来的并不是自己想要的东西的情况。Product Owner可以在短时间内就能看到软件，及时作出调整，因此敏捷极大地减少了开发成本以及相应的机会成本。公司高层的支持也是十分必要的。没有高层的承诺和授权，不可能组成全功能的团队。

问题八，这可能也是事实。其实在其他方法论风行的时候，也遇到过类似的批评，比如RUP。大家都期望找到一种能够解决所有软件开发痛苦的方法论。作为有经验的敏捷实践者，教练，经理和架构师，对敏捷的宣传应当适度，尽管敏捷确实能够解决很多软件开发中遇到的问题，但是它毕竟不是万灵药。不要使他人有过高的期望。

问题九，这绝对是事实。Chris Tyler提出的建议是，尽早与其他部门沟通，大家的最终目标是一致的，各个部门应当一起寻找生产系统的瓶颈，然后努力突破瓶颈（参见约束理论）。基于这个共同目标，各个部门一起对流程进行修改，就会减少相互诟病。

问题十，这并不是一个问题！Product Owner应该控制产品发展的方向。Product Owner应当熟悉业务，明确他最终想要什么。尽管开发团队要利用技术手段，提供解决方案，满足业务需求。但作为开发团队不应该对业务方面干涉太多。

问题十一，对于这个Chris Tyler既同意也不同意。敏捷团队是全功能的团队。如果业务分析师、Product Owner没有和团队在一起参与开发，那不是真正的敏捷。敏捷教练、经理也应该承担培训团队中除了工程师以外的成员的职责。对某些团队来说，文档会是一个问题，因为客户总是要求开发团队提供文档。其实行为驱动测试BDD就是一种既能够提供需求文档又能够照顾到代码实现的好方法。敏捷中也有文档（参见“敏捷的文档”），只不过是文档的形式发生了变化，变成了XUnit测试以及代码。进一步BDD可以成为业务人员和开发人员的桥梁，能够使业务人员更好地理解XUnit测试以及代码（另外其实还有Fit）。对于已经习惯于基于类似于IEEE的那种需求管理方式的Product Owner和公司高层们，对开发文档形式的改变，他们应当保持开放和学习的心态，充分信任团队，而不是给开发团队带来阻碍。

最后，Chris Taylor总结到，敏捷理论很美好，但是实践起来还是会有各种各样的问题，也有可能失败。其实理论描述的是理想情况，实际情况往往不尽相同。但是我们不能因为这个就放弃向理想努力。尽管过去有很多团队导入敏捷失败，我们还是不能全面否定敏捷，毕竟也有很多成功的敏捷团队。正如敏捷项目团队在开发中不断进行反省修正一样，我们也要通过反省来加深对敏捷的理解和认识。

作者简介：滕振宇（ Daniel Teng），Irdeto BSS高级软件经理，CSP。对Scrum、精益软件开发、系统架构设计、领域驱动设计有多年研究，有着丰富的实践经验以及教练经验。创建并领导 Irdeto BSS上海开发团队并成功导入Scrum以及极限编程的一些实践。

敏捷思想 篇3

一、精益思想

精益:精, 即少而精, 不投入多余的生产要素, 只是在适当的时间生产必要数量的市场急需产品 (或下道工序急需的产品) ;益, 即所有经营活动都要有益有效, 具有经济效益。精益来源于精益生产, 是美国麻省理工学院数位国际汽车计划组织 (IMVP) 的专家对日本丰田准时化生产JIT生产方式的赞誉称呼。

精益思想运用于需求相对稳定, 市场可测的环境下, 它的核心就是消除一切无效劳动和浪费, 把目标确定在尽善尽美上, 通过不断地降低成本、提高质量、增强生产灵活性、实现无废品和零库存等手段确保企业在市场竞争中的优势。

精益思想就是找出企业的价值链, 正确识别增值与不增值的活动, 通过优化增值活动, 减少或消除不增值活动达到高效益、低成本的目的。其中, 流动和拉动是精益思想实现价值的中坚。精益思想要求创造价值的各个活动 (步骤) 流动起来, 强调的是不间断地“流动”, 将所有的停滞作为浪费, 尽可能地消除。“拉动”就是按客户的需求投入和产出, 使顾客精确地在他们需要的时间得到需要的东西。

二、敏捷思想

敏捷思想是在需求多变的市场环境下, 企业需随市场变化做出判断和预测, 采取灵活策略, 对市场做出快速响应。敏捷思想的出发点是基于对未来产品和市场多元化和个人化特征的分析, 它的实现需要相关企业的协作。

“敏捷性”是指企业运用复杂的通信基础设施将技术、雇员和管理迅速地组装起来, 以应对不断变化和不可预测的市场环境中的顾客需求。它体现在:持续变化性 (产品、技术、管理模式) 、快速反应性 (以适应市场的变化) 、质量高标准、低费用。它能够使企业把握住市场机遇, 及时动态地重组生产系统, 用最短时间向市场推出最有利润的、用户认可的、高质量的产品。

三、价值链

价值链最早是由迈克尔·波特提出的, 他认为, 价值链是企业生产的产品或服务增值的环节或链条, 价值链中的每项活动都增加了产品或服务的价值。同时认为, 企业的竞争力来自于企业的某些特征环节的竞争优势, 抓住了关键环节, 就抓住了整个价值链。

价值链分为基本增值活动和辅助性增值活动两大部分。基本增值活动, 即一般意义上的“生产经营环节”, 如材料供应、成品开发、生产运行、成品储运、市场营销和售后服务。这些活动都与商品实体的加工流转直接相关。辅助性增值活动, 包括组织建设、人事管理、技术开发和采购管理。

四、价值链优化

企业价值链优化就是要正确识别企业各种增值和不增值活动, 优化增值活动, 减少、降低非增值活动, 使价值链的每个环节都是必要的、有效的。识别一项活动是否增值, 关键看它是否为后项活动提供了所需要的东西、是否降低了后续活动的成本、是否改善了后续活动的质量。识别了价值活动我们就可以具体对价值链进行优化。

优化价值链有许多方法, 我们现在采用目前比较流行的精益敏捷思想对价值链进行优化。它就是把价值链的生产活动分为了两部分, 前部分是半成品生产, 生产多样的通用部件。后部分是成品生产, 根据顾客需求迅速地把半成品部件组装成成品部件。这样就能对顾客的需求做出迅速的反应, 提高整个价值链的灵活性。这个分界点称为顾客需求切入点, 也就是从预测生产转向按需求生产的转折点。该点的左边以预测为驱动, 右边以需求为驱动。右边由于需求是多样的和经常变动的但是可以实际掌握的, 可以采用敏捷运作来获得较高的客户服务水平和销售利润;左边由于对最终需求无法掌握, 只能根据预测进行生产。此时, 如何提高产品质量并削减成本成为其关键制胜要素。而“精益生产”模式正好适应这方面的需要。 (图1)

(一) 基于精益生产的上游价值链优化。

精益思想来源于精益生产, 精益生产的特点就是消除一切浪费, 是当前最佳的一种组织生产方式, 通过精益生产的模式来优化上游价值链。

1、生产过程采用拉动式准时化生产。

前道工序依照后道工序的需求进行生产, 强调物流平衡, 尽量降低库存, 上一道工序加工完的零件立即可以进入下一道工序。组织生产线依靠一种称为看板的形式, 即从最后一道工序通过看板向上一道工序传递信息。看板旨在传达信息:“何物, 何时, 生产多少数量, 以何方式生产、搬运”。一旦主生产计划确定以后, 就会向各个生产车间下达生产指令, 然后每一个生产车间又向前面的各道工序下达生产指令, 最后再向仓库管理部门、采购部门下达相应的指令。这些生产指令的传递都是通过看板来完成的。看板管理能够有效降低库存, 防止过量生产、过量运送, 能有效地降低成本, 使生产更加有序协调。

2、采用全面质量管理。

强调质量是生产出来而非检验出来的, 由生产中的质量管理来保证最终质量。生产过程中对质量的检验与控制在每一道工序都进行。重在培养每位员工的质量意识, 在每一道工序进行时注意质量的检测与控制, 保证及时发现质量问题。如果在生产过程中发现质量问题, 根据情况, 可以立即停止生产, 直至解决问题, 从而保证不出现对不合格品的无效加工。对于出现的质量问题, 一般是组织相关的技术与生产人员作为一个小组, 一起协作, 尽快解决。

3、建立工作团队。

团队能够更好、更灵活地完成工作任务, 企业建立的工作团队并不完全按行政组织来划分, 而主要根据业务的关系来划分。团队成员强调一专多能, 要求能够比较熟悉团队内其他工作人员的工作, 保证工作协调的顺利进行。团队人员工作业绩的评定受团队内部评价的影响。团队工作的基本氛围是信任, 以一种长期的监督控制为主, 而避免对每一步工作的稽核, 提高工作效率。团队的组织是变动的, 针对不同的事物, 建立不同的团队, 同一个人可能属于不同的团队。

4、流程优化

(1) 取消所有不必要的工作环节和内容。有必要取消的工作, 自然不必再花时间研究如何改进。某个处理、某道手续, 首先要研究是否可以取消, 这是改善工作程序、提高工作效率的最高原则。

(2) 合并必要的工作。如工作环节不能取消, 可进而研究能否合并。分工的目的, 或是由于专业需要, 为了提高工作效率;或是因工作量超过某些人员所能承受的负担。如果不是这样, 就需要合并。有时为了提高效率、简化工作甚至不必过多地考虑专业分工, 而且特别需要考虑保持满负荷工作。

(3) 程序的合理重排。取消和合并以后, 还要将所有程序按照合理的逻辑重排顺序, 或者在改变其他要素顺序后, 重新安排工作顺序和步骤。在这一过程中还可进一步发现可以取消和合并的内容, 使作业更有条理, 工作效率更高。

(4) 简化所必需的工作环节。对程序的改进, 除去可取消和合并之外, 余下的还可进行必要的简化, 这种简化是对工作内容和处理环节本身的简化。

(二) 基于敏捷运作的下游价值链优化。

价值链的下游主要以顾客需求核心, 采用敏捷运作, 要求企业建立强大的信息网络, 能从客户、供应商、竞争对手那里获得及时的、足够的信息, 并有效地进行传递。建立一个柔性团队, 能根据顾客的需求, 迅速把需要的人才组织起来, 对标准化的零件进行组装, 及时地给客户提供个性化的服务。

优化下游价值链关键是要在企业内部建立一个高效的信息网络系统, 实施供应链管理系统 (SCM) 和企业资源管理系统 (ERP) , 对供应商、制造商、销售商、顾客所构成网络中的物流、信息流、资金流进行动态地管理。

敏捷运作最关键的就是保持它的柔性和灵活性, 与其他相关企业建立动态联盟是最好的方法。保持自己的核心竞争产品, 其他的产品和配件可以外包给其他企业, 而那些企业的核心产品恰好是这些产品, 他们之间结成联盟, 就会形成强大的竞争力, 并且可以根据市场的变化迅速地组织成产, 以最快的速度占领客户市场。

在如今的市场环境下, 要尽可能地使用合适的信息技术, 不断推动市场信息向价值链的上游渗透, 而在信息停止渗透时, 向上游不断发展精益生产, 向下游尽可能寻求“敏捷”。换句话说, 就是在产品个性化之前, 企业主要生产标准化、模块化的半成品, 用精益的思想优化流程, 不存在一丝的浪费, 尽可能地降低成本。当顾客有需求时, 能迅速地组装成成品, 做出快速反应。

摘要：企业价值链是企业生产产品或提供服务增值的环节或链条, 是企业利润的源泉。企业要想在激烈的竞争中取得胜利就必须优化自己的价值链。企业优化价值链的方法很多, 本文主要从目前比较流行的精益思想和敏捷思想入手, 引入需求切入点概念, 提出价值链优化的“精益—敏捷方法”。

关键词：价值链,精益思想,敏捷思想

参考文献

[1]邓伟, 吴祈宗.敏捷制造理念的系统诠释.北京理工大学管理与经济学院.企业管理, 2007.

[2]杨林.虚拟价值链:价值链研究的新发展.宜春学院.哈尔滨学院学报, 2002.11.

敏捷“蓝天使” 篇4

Laura 对“蓝天使”模型作了如下解释：

每个人都能成为“蓝天使”中的一员，但在谁能加入团队的问题上，当前团队掌握有绝对的话语权。很明显，他们要挑选最佳中的最佳，要求不仅有高超的技术，而且能够展现出团队和海军最好的风貌。

你只能在这个团队服务3年：一年用来熟悉同伴，一年用来做到最好，最后一年用来培养替代你的人。

这个阶段结束以后，你就得回到平常的生活，

管理资料

这为团队的新成员让出了空位，确保了新人能最大程度地掌握你曾学过的“如何成长为最佳”的全部知识，从而帮助整个组织的提升。

Laura 接着阐述了如何把这样的模型应用在软件组织里面。她观察了组织中不同人会受到的影响，其中包括明星开发人员、CIO、被接纳进计划的开发人员经理、以及一个普通开发人员，但她发现每个人都能从中受益。

这种计划能在你的组织里运行么?欢迎留下你的意见，以及对是否能运行的原因分析。

查看英文原文：An Agile Blue Angels Team

敏捷思想 篇5

华为战略Marketing总裁徐文伟先生“全联接世界的敏捷商业“主题演讲

华为企业网络产品线总裁刘少伟先生介绍敏捷网络全景作

华为企业BG总裁阎力大先生作“创新力——商业引擎的新动力”主题演讲

2014年5月25日~26日, 为期两天的2014华为网络大会 (HNC2014) 在北京国际会议中心拉开帷幕, 全方位阐释了本届大会的主题——“敏捷已来·Weaving The Future”, 即一个全联接的世界, 敏捷的商业, 敏捷的网络, 已经到来。敏捷网络是业界首个以业务和用户体验为中心的网络, 自2013年发布以来, 华为的敏捷网络在全球已在近200个网络进行商用部署, 广泛应用于政府、金融、医疗、大企业、交通、教育、广电等7大行业。敏捷网络也为行业客户构筑起智能交通、无线城市、智慧商场、智慧参观等特色方案。2014年的华为网络大会, 意在与行业伙伴共同分享与探讨敏捷网络的实践与未来, 帮助企业快速步入敏捷时代。

在华为网络大会上, 对于即将到来的敏捷时代, 华为战略Marketing总裁徐文伟先生说到, “联接已经成为一种常态, 是人类文明最基本的需求, 我们无法在没有网络的环境中生存和工作, 就像空气和水一样, 它将融入到我们生活的每一个角落, 无所不在。”徐文伟对企业的未来展望道, “所有的企业都会成为互联网企业, 所有的网络都需要敏捷起来, 所有的商业都应该立足于敏捷网络, 从关注技术和连通转变到关注业务和用户体验, 实现从‘尽力而为’到‘尽在掌控’的巨大转变, 从而不断开辟创新模式, 持续建立差异化竞争优势。在全联接的世界里, 让网络更敏捷地为业务服务。”

2013年, 华为全球首个发布了敏捷网络及其架构, 并提出三大敏捷:业务敏捷——全球第一个业务随行的网络、管理敏捷——全球第一个能感知IP质量的网络、演进敏捷——全球第一个软件定义的园区网络, 能给企业带来卓越的体验、高效的运维、快速的创新。敏捷网络能帮助企业获得领先4倍的业务创新速度。

目前, 全球已有近200个商用网络采用了华为敏捷网络。在数据中心领域, 华为帮助中石油构建“两地三中心”的亚太最大云数据中心网络, 通过Cloud Engine数据中心交换机连接了7万多台10GE服务器, 960TBps无阻塞网络平台其性能是业界的三倍, 满足中石油海量数据存储、大数据分析所需要网络容量和性能, 支撑中石油未来10年的业务发展需求。在园区领域, 西南民大通过应用华为的敏捷网络解决方案, 解决了该校信息化改造的所有需求, 方案采用业界首款敏捷交换机S12700实现了有线和无线深度融合, 全网有线无线统一认证, 大大提高网络的可用性和管理性, 其灵活的全可编程架构能够适应不断发展的校园网络要求和未来演进。

2014年华为网络大会上, 华为对敏捷网络方案范围作了全面扩展, 展示了一个端到端、惠及产业链的敏捷网络架构, 包含了敏捷分支、敏捷园区、敏捷数据中心、敏捷广域四大解决方案, 以及其核心——敏捷控制器。华为企业网络产品线总裁刘少伟表示, “数据中心已经成为企业商业的核心, 企业分支也在成为一个新的计算中心, 它们对连接的需求越来越高, 为此华为在网络大会上发布了敏捷数据中心云联接解决方案和敏捷分支解决方案。”基于软件定义的思想, 华为对敏捷网络的独特价值带到了数据中心网络和分支网络, 此次新发布包括:

1) 敏捷数据中心云联接解决方案, 第一次实现了ICT的云端融合管理, 大幅度提升了云计算的部署和管理效率, 让物理网络和计算存储资源一样, 成为云的一部分, 网络和计算相互协同, 相互可视, 让云计算变得简单。

2) 敏捷分支解决方案, 第一次将移动分支和物联分支纳入架构, 第一次实现了零本地维护的融合ICT分支, 通过敏捷控制器的集中控制和敏捷网关的虚拟架构, 让随时随地的人联和无所不在的物联成为可能。

3) 敏捷控制器是开放的敏捷网络的核心, 它构建了全网智能策略系统, 将网络从以设备和技术、连通为中心, 变为以业务、用户和体验为中心, 实现上层业务对到物理网络定义、控制和管理的全自动化, 无论在分支、园区、数据中心还是广域互联, 敏捷控制器都是敏捷网络的业务与控制中心。

经过此次发布, 敏捷网络进一步加速了企业的创新和新业务的上线速度, 让企业具备快速响应能力和创新能力敏捷网络已经来到企业客户身边, 无论是数据中心网络、分支网络还是园区及广域网络。

敏捷网络将更加开放合作, 新发布的云联接方案能与业界主流的云平台, 例如VMware、微软、Open Stack及华为Fusion Sphere实现了无缝对接。刘少伟谈到, 华为将把敏捷控制器的南北向接口开放, 从而给行业客户一个开放的自定义空间, 与合作伙伴一起构建起敏捷商业的实践, 让他们更聚集在业务的变革和转型上。刘少伟补充道:“今天我们召开网络大会, 正是希望号召行业的合作伙伴与华为一起探讨敏捷网络在行业的应用, 构建一个开放、共赢、协作的对话空间。”本次大会共有30余家合作伙伴展示了敏捷网络在行业的解决方案和实践。

敏捷网络所倡导的“让网络更敏捷地为业务服务”将为企业未来实现敏捷商业带来前所未有的新价值。华为企业BG总裁阎力大表示, 企业需要持续创新, 充分利用云计算、物联网和大数据去创造新的数字价值和业务价值。华为是业界少数能够同时提供丰富的服务器、存储和网络产品的公司, 将企业的云计算、物联网和大数据三者联为一体, 可以重构企业ICT架构, 构筑企业新的敏捷商业竞争力。

浅析敏捷制造 篇6

在20世纪80年代的时候, 因为美国市场上出现了大量的由德国和日本生产的高质量产品大量占用了美国的市场, 迫使美国原先的制造策略由着重产品的成本从而转为产品的质量。进入了90年代, 由于产品更新换代的速度加快, 市场上的竞争更加转向严峻。日本生产的汽车更新换代的速度比美国快了一倍多, 美国制造商所关注的焦点转变为速度。因此, 美国必须缩短产品开发周期, 来取得实质性的进展。

美国政府为了改变现状, 从而把制造业发展战略目标瞄向21世纪。为了重新夺取美国在世界上制造行业上的龙头老大位置, 美国政府因此资助了里海大学的雅柯卡研究院和美国通用汽车公司二者组织了一百多家相关的公司, 耗费大量人力物力分析研究400多篇优秀报告之后, 提出了一份尤为重要的发展战略决策《21世纪制造企业战略》。在1988年敏捷制造这个全新的新概念第一次被提及, 孕育而生。1990年向世界半公开之后, 马上引起了全世界国家的看重。1992年美国联邦政府将这种初新的制造模式敏捷制造当成21世纪制造业的新型战略。

2 敏捷制造基本原理

必须运用专业化和标准化的信息集成和电脑网络相结合的结构作为基础, 各个企业采用分布式的结构相互连接, 创建虚拟制造下的环境。把竞争合当作首要原则, 从虚拟制造的环境下进行动态选取、择优录取成员, 构成虚拟环境下的企业, 加快生产的速度。

下面从三个方面来理解敏捷制造的内涵分别从市场/用户、合作伙伴和企业能力来深度解析。

2.1 敏捷制造的初始点是及时的对市场/用户需求的响应

由于市场/用户需求日益多样化和个性化, 企业要想要想在全球化市场中竞争取胜, 就需要能够快速响应市场/用户的需求, 这就是敏捷制造思想的出发点。

为了对市场/用户需求做出快速响应, 企业必须首先考虑:a.市场用户是谁;b.什么是市场/用户的需要;c.企业对市场产生的及时回应是否值得?对于这些问题的明确回答依赖于信息技术和企业信息网。在明确以上问题的基础上企业才能对市场/用户的需求做出快速响应, 快速设计且制造高质量成本又低的产品, 以次来满足市场/用户的需求。

2.2 敏捷制造必须不断加强该企业的能力

为了能对市场/用户提出的需求做出快速回应, 企业必须不断提高能力。企业能力是企业在市场中生存的综合能力表现, 对企业能力的衡量要综合考虑企业对市场/用户的响应速度以及企业产品的质量和成本, 为了提高企业能力, 企业必须采用先进制造系统技术, 并依靠信息技术建设企业信息网, 在此基础上企业还要实现技术、管理和人员的全面集成。

2.3 敏捷制造强调采用动态组织

为了能够以最少的投资、最快的反应速度对市场/用户的需求做出响应, 敏捷制造采用灵活多变的动态组织。动态组织是为了以最少的投资、最快的反应速度对市场的需求做出响应, 有两个或两个以上的成员组成的一种有时限的相互依赖、合作和信任的组织、成员可以是来自企业内部的某些部门, 也可以是企业外部的公司, 每个成员只做自己擅长的工作, 一旦成品或者项目任务完成组织即自行解体, 各成员可立即转入其他产品或项目。动态组织发展的最高阶段是虚拟组织或者虚拟企业, 这是一种对市场/用户需求做出快速反应的企业组织形式, 它是有两个或两个以上的而且也成员组成的在有限的时间和范围内进行合作的而相互依赖和相互信任的组织。

3 敏捷制造技术应用

国内外的各大公司及企业对敏捷制造技术都进行了深入的研究并取得了一定的成果, 对敏捷制造的应用也更为成熟了, 这对于敏捷制造的发展来说是非常有利的。这预示着敏捷制造的应用将会更加的广泛, 将在各个行业中得到应用。

日前, 已经有上百个美国公司、企业在开展和敏捷制造有关的实践性活动。欧洲也有不少公司正在进行企业改造和重组。美国生产工业压缩机的Ingersoll-R公司, 1988年建立动态公司采用敏捷制造过程后, 开发技术水平比原来更先进的压缩机只需以前的1/3到1/2的时间, 价格方面也从原先的50万美元变为如今的12.5到25万美元。在这之前原来开发新产品仅设计就消耗工时8到12个月, 从样机制造到试验评定耗时一年到一年半不等。可想而知敏捷技术给该公司带来的利益是有多么巨大。

4 技术发展的趋势

工艺设计从先前的用经验来判断变为定量分析标志着先进制造技术的一个重要发展趋势, 在敏捷制造组建的系统上, 人、技术与组织构成了最基本的三要素。构筑和实施敏捷制造模式需要多种技术层面上的支持, 在先进技术相互匹配的基础上才能充分发挥制造模式带来的优势。因此解决问题的关键首要有关键技术打好基础, 敏捷制造中主要有如下关键技术:1) 并行工程 (CE) 技术;2) 虚拟制造 (VM) 技术;3) 网络技术;4) 模块化技术;5) 系统集成技术;6) 动态联盟;7) 产品数据管PDM技术贯通了如上技术才能真正的掌握敏捷制造技术。从而确定工艺参数, 优化工艺方案, 预测加工质量, 计算机视觉技术、人工智能技术、机器人技术、数字化信息处理技术的加入, 造就了制造技术向着高效化的工艺, 生产过程机器人、数字化的控制以及智能化的方向进行发展。

对敏捷概念的深入研究、内涵以及实践更好地应用于中小企业因为敏捷制造拥有技术、资源等多方面优势。在美国敏捷化协会工作的专家认为资源被限制的中小企业, 以后极大可能成为敏捷制造的关键力量。往后对敏捷的概念、内涵以及实践的深入研究将会更加对其发展作出贡献。

5 总结

应用软件敏捷定制 篇7

1 应用软件编程模型的提出

.NET是微软公司推出的新一代互联网软件和服务战略，是一种面向网络、支持各种用户终端的开发平台环境。.NET平台创建了组件，并将组件作为其基本的元素。从本质上看，.NET组件是一个用任何.NET语言以插件形式开发的可互换的软件部件，它可以与其他应用程序实现互操作。.NET组件是以程序集[1](Assembly)的形式表现的。

.NET组件的最大优点在于，它深化了“模块化”编程的思想，为开发人员提供了一个“搭积木”的编程模型：多个组件模块通过一定的引用逻辑组装成一个有机的整体，即一个应用系统。这样就降低了系统设计的难度，同时增强了应用软件的可维护性。

然而，.NET组件也存在一些不足之处。⑴复用程度较低。众所周知，软件复用可以降低软件开发的复杂度，提高开发效率。但目前许多开发人员所积累的组件都是针对某个具体的应用项目而设计的，难以被其他应用软件所复用[2]。即使复用了个别组件，也由于复用粒度不大而不能取得明显效果。⑵耦合程度较高。同前文所述，多个组件是通过源代码级的引用关系而组合成一个整体的，这个整体具有不可分割性。即使仅仅修改其中的一个组件都得重新编译、部署整个应用系统。这样就增加了系统扩展和更新的难度。

如何弥补上述不足呢?首先，可以提取某一应用领域的共性，建立若干个基于复用目的的公共组件，并将这些组件按一定应用逻辑封装成一个复用粒度更大的应用框架，该应用框架提供对外扩展的接口，该接口就像电脑主机的USB接口一样，可以即插即用。然后，可以根据用户的具体业务需求分批完成若干个支持上述接口的专用组件———插件。最后，应用框架和插件通过接口即插即用而组合成一个应用软件。这样，就形成了“可定制应用软件=应用框架+插件”的编程模型。该模型的突出特点如下：(1)基于.NET平台，具有能与COM组件互操作、X-COPY部署等优点[1]。(2)同时支持“搭积木”和“接口”编程思想。(3)大粒度应用框架的复用，降低了软件复杂度，实现了软件敏捷开发。(4)即插即用的接口设计，大大提高了软件的可扩展性、可定制性、可维护性。

2 应用框架的设计

2.1 设计目标

本应用框架是定位于支持多层软件结构的桌面应用或智能客户端的可运行原型系统。其主要特点如下：(1)支持多层软件结构。具有支持用户界面层、业务逻辑层、数据访问层等的组件。(2)支持智能客户端。所谓智能客户端，是一个可扩展的能集成不同应用的桌面应用程序，它具有在线升级、离线运用、个性化用户界面等特征[3]。(3)不加载任何插件就可运行的原型系统。通过配置文件和插件可以敏捷定制一个应用软件。

2.2 体系结构

支持插件架构的应用框架体系结构，核心部分是由主应用程序组件、共享接口组件、插件和配置文件组成[4]，次要部分包括被多个插件引用的公共基础组件(如通用数据访问组件等)和一些辅助工具(如在线升级器、XML文件编辑器、程序集查看器等)，如图1所示。

2.3 动态运行机制

整个应用框架是个高内聚的系统，应用框架的运行由不同组件、模块分工协调完成。现对应用框架运行机制做总体设计如下：

(1)主应用程序MainApplication启动时读取系统配置文件App.config中的appSettings配置节，设置应用软件的标题。

(2)然后调用插件管理类PlugInController的LoadPlugIns () 方法。该方法利用.NET的反射特性[4]在主应用程序所在目录的plugins子目录下逐个搜索可用的插件(所有合法的插件类型前加有属性标志PlugIn)，并将插件的相关信息(在PlugInAttribute和PlugInInfo类中定义)收集到一个SortedList类型集合体当中。同时通过插件属性标志PlugInAttribute的初始化参数得到菜单文本信息，根据菜单文本在主窗体中添加对应菜单项并注册菜单点击事件。

(3)当点击某菜单项时发生菜单点击事件，该事件调用LaunchPlugIn () 方法来实例化类型。

(4) LaunchPlugIn () 方法先根据(2)中的集合体记录找到与所点击菜单项对应的程序集和类型信息;再进行两种判断：该类型是继承自Form类还是Iplug接口。如果是Form类就实例化一个窗体，并将其加入到MDI主窗体中，最后调用Show () 方法;如果是Iplug接口就调用run方法，该方法已在对应插件中实现。

2.4 接口设计

如图1所示，本应用框架与插件进行通信的接口被封装在SharedApi.dll里面。本应用框架提供两种类型的接口[5]：⑴框架与插件交互的对偶接口Iplug和Ihost：其中主应用程序必须实现Ihost，而插件必须实现Iplug。⑵具有元数据特征的属性标志类[1]PlugInAttribute(以后简称插件属性)：只要是给主应用程序定做的插件，其相应类型必须在前面添加插件属性，并且必须给出插件属性的两个位置参数。这两个参数分别对应的菜单项及其父菜单项的菜单文本。

2.4.1 框架与插件交互的接口

2.4.2 插件属性标志

2.5 配置文件

应用程序使用配置文件可以更好地适应需求的变化。本应用框架的配置文件为.NET框架所支持的标准XML文档。由于XML是Internet上数据交换的通用语言，所以在智能客户端应用中配置文件可以方便地从服务器传递到客户端[1]。本配置文件可以为主应用程序、插件、通用数据访问组件、在线更新组件所共用。以下给出配置文件App.config的示例代码：

2.6 对插件的即插即用

如图1所示，在主应用程序中包含一个插件管理类PlugInController，它提供两个重要方法，是实现机制的关键。

(1) LoadPlugIns () 方法：负责遍历plugins子目录的所有程序集，将合法插件的相关信息(菜单文本信息、程序集名称和程序集包含类型信息)记入在一个plugArray集合体中，以提供LaunchPlugIn () 方法中相关参数。同时，还调用GetMenus () 私有方法，根据菜单文本信息在主窗体中添加对应菜单项并注册菜单点击事件。

(2) LaunchPlugIn () 方法：负责响应菜单点击事件。判断两种不同的插件类型(Form类或Iplug类)，进行类型实例化，并调用相应类型的方法Show () 或Run () 。

需要注意的是，在主窗体加载事件调用LoadPlugIns () 之后，plugins子目录中的所有插件都将被锁定，如要进行删除或更新操作，就会出现“文件正被另一个人或程序使用”的错误信息，这样就阻碍了在线更新功能的实现。这里给出一个简单的解决办法：.NET框架有一个影像复制(Shadow Copy)特性，当在一个应用程序域(appdomain)中启用shadow Copy时，装载在该应用程序域的所有程序集将被复制到一个影像复制缓冲目录，并从缓冲目录中使用这些程序集，这样就解除了对原有文件的锁定，可以对原文件进行随意更改[6]。以下给出LoadPlugIns () 方法的核心代码：

2.7 用户界面设计

2.7.1 用户界面的结构

应用框架的用户界面设计为多文档界面[1](MDI)结构。如图1所示，在主应用程序中有一个MainForm类，该类定义了父窗体界面(主要由菜单栏、工作区、状态栏组成)，并提供退出系统、多窗体排列等基本功能。如图2所示。插件窗体为子窗体，其子窗体界面及功能由相应插件完成。

2.7.2 动态菜单的生成

图2所示菜单为不添加任何插件时父窗体的所有菜单项。当有插件添加时由LoadPlugIns () 方法调用GetMenus () 方法，动态添加其他菜单项。GetMenus () 方法首先根据插件信息中的父菜单文本 (pmenutext) 确定子菜单项的位置。如果父菜单已存在，则在该父菜单下添加子菜单项。如果父菜单不存在，则先创建父菜单项，再在该父菜单下添加子菜单项。同时对每个菜单项的点击事件进行注册。其核心代码如下：

2.8 在线更新组件设计

.NET框架所具有的X-COPY安装(不写注册表)的特性，再加上在线更新的功能，就可实现接近“零成本”的软件部署。在线更新组件可以普通插件或独立程序(如图1中UpDater.exe)的形式提供。如果采用普通插件的形式，有必要创建一个独立的线程完成文件下载任务，以免影响主应用程序的正常运行。

在线更新组件UpDater.exe设计的原理如下：UpDater.exe可在不启动主应用程序的情况下实现应用系统的自动更新。首先读取系统配置文件App.config中的Update配置节，获取更新资源的网络地址和已安装组件的当前版本。然后根据网络地址找到服务器上存放所有待更新资源的文件夹，该文件夹同时包含一个以修改日期命名清单文件，把该修改日期与当前版本相比较，如果前者大于后者，就将清单文件中列举的所有文件依次下载到本地目标位置。接着将Update配置节中的版本重写为修改日期。如果前者等于后者，则说明无需更新。最后，自动关闭更新程序。

以下是资源清单文件2006-12-01.xml的示例代码：

2.9 通用数据访问组件设计

在图1中，DataAccess.dll组件负责为数据库应用程序提供基础服务。其主要作用是采用简单工厂(Simple Factory)设计模式，对外屏蔽数据源类型的差异，实现对OLE DB、SQL Server等数据库的通用访问[7]。它提供读取配置文件信息(连接字符串、查询字符串)，返回数据库连接接口(IDbConnection)和数据适配器接口(IDbDataAdapter)等功能。本组件在实践中可以通过在线更新不断完善。

3 插件

以上已经初步建立起一个基于插件架构的应用框架。该应用框架本身就是一个可运行的系统。它是经过测试的大量相关代码的封装，也是一个面向特定问题域的完整的设计封装，非系统设计人员无须详细了解。但是对于为用户开发插件的程序员，必须明确插件编写的如下要求。

(1)一个有效的插件类型只能继承自Form基类或者Iplug接口。

(2)一个有效的插件类型必须在其类型前加上PlugIn属性标志。

(3)插件编写，不要在一个插件中捆绑3个以上类型[5]。否则会降低系统运行效率。

(4)插件加载时会在主窗体中自动添加一个菜单项，如需要实现多层菜单可在插件中以上下文菜单形式提供。

4 应用软件的定制

应用框架设计的目的是为了复用该框架，实现应用软件的敏捷定制。作为示例，假定要为某中学定制一个学生管理信息系统。要定制该应用软件，需要开展的主要工作是：调查分析用户需求，编写适应用户需求的插件，最后会通过网络部署插件。以下仅给出两个插件的编写范例。

4.1学籍信息编辑插件

4.2信息系统帮助插件

5 结语

综上所述，应用框架的设计并复用可以使应用软件的开发不必每次“从零”做起，大大降低了软件开发的复杂度，缩短了开发周期;插件的即插即用可以使应用软件随时更新、扩展所需的功能。因此，“应用框架+插件”的编程模型，实现了应用软件的敏捷定制，具有良好的应用前景。

参考文献

[1]Christian Nagel, Bill Evjen, Jay Glynn.C#高级编程[M].第4版, 北京:清华大学出版社, 2006.

[2]杨海澜.基于组件技术的学籍管理信息系统研究[J].武汉交通职业学院学报, 2006, 7 (1) :70-71.

[3]王介之, 陈志刚.利用WEB服务实现智能客户端应用[J].计算技术与自动化, 2005, 24 (1) :85-86.

[4]JasonClark.Let Users Add Functionality to Your.NET Applications with Macros and Plug-Ins[J/OL].MSDN Magazine, October2003.

[5]Joel Pobar.Dodge Common Performance Pitfalls to Craft Speedy Applications[J/OL].MSDN Magazine, July2005.

[6]Junfeng Zhang.AppDomain and Shadow Copy[EB/OL].http://blogs.msdn.com/junfeng/archive/2004/02/09/69919.aspx, Febru ary09, 2004.

敏捷软件开发实践总结 篇8

软件危机一方面是由软件生产本身存在着复杂性,另一方面却是与软件开发所使用的方法和技术有关。软件工程学正是为克服软件危机而形成的新的学科,但可惜的是时至今日人们并没有完全克服软件危机。

软件开发中当连续地犯错误时,我们会对错误进行诊断,并在过程中增加更多的约束和人为制品来防止以后重犯这样的错误。经过多次这样的增加之后,我们就会不堪巨大、笨重的过程的重负,极大地削弱我们完成工作的能力。一个大而笨重的过程会产生它本来企图去解决的问题。降低了团队的开发效率,使得进度延期,预算超支。它降低了团队的相应能力,使得团队经常创建错误的产品。遗憾的是,许多团队认为,这种结果是因为他们没有采用更多的过程方法引起的。因此,在这种失控的过程膨胀中,过程会变得越来越庞大。

2001年初,由于看到许多公司的软件团队陷入了不断增长的过程的泥潭,一批业界专家聚集在一起概括出了一些可以使软件开发团队具有快速工作、响应变化能力的价值观(value)原则。他们称自己为敏捷(Agile)联盟。在随后的几个月中,他们创建出了一份价值观声明。也就是敏捷联盟宣言(The Manifesto of the AgileAlliance)。

敏捷联盟宣言如下:

(1)个体和交互胜过过程和工具。

人是获得成功的最为重要的因素。如果团队中没有优秀的成员,那么就是使用好的过程也不能挽救失败的项目。但是,不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作,那么即使拥有一批优秀的成员项目也会失败。

一个由平均水平程序员组成的团队,如果具有良好的沟通能力,将要比那些虽然拥有一批高水平的程序员,但是成员之间却不能交流的团队更有可能获得成功。

团队的构建要比环境的构建重要得多。应该首先致力于构建团队,然后在让团队基于需要来配置环境。

根据调查总结:一般团队都具备创业型团队的特点:一个优秀的lead,带多名水平一般的员工;这样的团队存在两个问题:1)优秀员工的引入,受lead的水平限制;2)员工各自为政的开发模式,分享不够。

团队中的优秀人才并不是越多越好,优秀人才太多反而有更大的弊端。一是人力成本太高,他们可能消耗掉产品创造的大部分效益,那么就不划算了。二是团队分裂的风险太高,因为团队的空间有限,无法同时满足很多优秀人才事业发展的欲望;所以,团队的优秀人才恰好够用就行。

软件开发团队的lead应当具有四项素质,按级别从低到高排列;不错的技术才能(一段)较强的管理才能(二段)丰富的产品开发经验(三段)敏锐的商业头脑(四段)。目前大多数IT企业在物色团队的领导时,主要考察候选人的管理能力和技术能力。对于搞技术出身的人,如果他能当上小头目,一般地讲他的技术才能不会太差。然而即使技术水平是团队里最强的,如果他不具备带领团队所有成员正确干活的能力(即管理能力),那么他也就不不适合当lead。

(2)可以工作的软件胜过面面俱到的文档。

没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。然而,过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间,要使这些文档和代码保持同步,那么就要花费更多的时间。如果文档和代码之间失去同步,文档就会变成庞大的、复杂的谎言,会造成重大的误导。

( 3 ) 客户合作 胜过合同 谈判。

成功的项目需要有序、频繁的反馈。不是依赖于合同或者关于工作的陈述,而是让软件的客户和开发团队密切地在一起工作,并经常地提供反馈。项目成功的关键在于和客户之间真诚的协作。

( 4 ) 响应变化 胜过遵循 计划。

响应变化的能力常常决定着一个软件项目的成败。当我们构建计划时,应该确保计划是灵活的并且易于适应商务和技术方面的变化。

较好的做计划的策略是:为下两周做详细的计划,为下三个月做粗略的计划,再以后就做极为粗糙的计划。计划中这种逐渐降低的细致度,意味着我们仅仅对于迫切的任务才花费时间进行详细的计划。一旦制定了这个详细的计划,就很难进行改变,因为团队会根据这个计划启动工作并有了相应的投入。然而,由于计划仅仅支配了几周的时间,计划的其余部分仍然保持着灵活性。

综观上述四个过程,敏捷开发强调以人为中心,而不是以过程为中心,强调尽可能的沟通(与客户,与团队成员),尽可能地以最简单的设计解决问题(从而能够拥抱变化)。

敏捷开发不同于以往的瀑布式开发,非常适合需求变动的情况,敏捷开发的工作量是随着需求的变化而不断发生变化的,所以整个过程中浪费很少(如图1所示)。

与传统的软件开发方法惧怕需求变化相反,敏捷团队依靠变化来获取活力。团队几乎不进行预先设计,因此,不需要一个成熟的初始设计。他们更愿意保持系统设计尽可能的干净、简单,并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性,持续地改进设计,以便于每次迭代结束所生系统都具有最适合于迭代中需求的设计。

上面的描述非常美好,读者不禁会问:敏捷开发人员如何知道要做什么的呢?

答案是:

(1)他们遵循敏捷实践去发现问题;

(2)他们应用设计原则去诊断问题;

(3)他们应用适当的设计模式去解决问题。

软件开发的这三个方面的相互作用就是设计。

到目前为止,已经有许多的敏捷开发方法可供选择,包括Scrum、Crystal、FDD(Feature DrivenDevelopment)、ADP(AdaptiveSoftware Development)、XP(e Xtreme Programming)等。S c r u m是最常用 的方法之 一。Scrum本意是橄榄球运动中的争球。在一般人的印象中,橄榄球运动是非常野蛮的,球员目的非常明确——破门得分。你可以抱着球跑,可以传给队友……各种方式都可以,目的就是要快速得分。敏捷开发就需要这种精神。下面我们来看一下Scrum大概的流程(如图2所示)。

1、在一个Scrum项目中,产品负责人(Product Owner)建立待开发的产品条目(ProductBacklog),并确定其优先级。开发中需求的改变也要写进去,对于调研、查阅资料、配置环境等也应考虑进去,因为这些也很占用时间,敏捷开发中不提倡冲刺,不提倡加班,讲究发挥团队最大价值;

2、根据所 列P r o d u c tBacklog情况,确定产品一个迭代(Sprint)所要完成的东西,每一个Sprint大概是2-6周的时间;

3、Sprint开始前,需要开一个迭代计划会议(Sprint PlanningMeeting)会议。会上,产品负责人(Product Owner)讲解本次开发要开发的条目(Story),将确定的Story放入Sprint Backlog中来;

4、Sprint开发过程中,团队每天都要开一个站立会议(DailyStand-up Meeting),以便团队之间了解彼此的开发进度;

5、Sprint结束之后 , 需要开评审会(Review Meeting),Scrum团队会在评审会议上把这个迭代的开发成功展示给大家;

6、之后还 要开一个 反思会(Retrospective Meeting),S c r u m团队会回 顾过去这 个Sprint,从中总结经验教训。

传统的项目负责人也罢,敏捷的项目负责人也罢,都会制定计划,而且会为之投入相当的时间。但是他们对待计划的态度截然不同。在敏捷开发中,我们采用“调整性行为”来说明应该采纳的一些正确做法(其中之一便有可能是纠正计划本身)。

1、知晓变 化 ( 即不确定 因素)可能随时发生,面对突发的变化,要进行相应的调整,而不能继续按原计划执行。

实际工作中我们会遇到:客户提出新的要求,开发团队的经验不能马上告诉:这个技术需求能不能实现或需要多长时间实现。一般需要三天时间进行预研,这样才能知道是否能做,需要多少时间完成。然后修改部分计划。

2、必要时,对项目的过程和实施办法做出随机调整。

(1)调节项目中的已知和未知。

哈佛商学院教授罗布·奥斯丁(Rob Austin)和同事李德文(LeeDevin)共同执笔发表了《艺术性管理》(Artful Making)一书。书中提到一个价值1.25亿美元的IT项目最终失败的案例。失败的原因正是由于合作企业一味坚持原计划,亦步亦趋死板执行,拒绝用调整来应对突发的变化而造成的。书中写道:“‘为工作制定计划,然后按照计划做事’成了让他们盲从的真言,直接导致团队采取了毁灭性的做法,带来惨重的代价。……在商界,人人都以为这种问题很少发生,可实际上却非常普遍。”

现实中每一个项目都有其已知的条件和未知的因素,有其确定的一面以及不确定的一面,因此每一个项目都必须在计划和随机调整之间取得平衡。这种平衡是必须的,因为项目可以是生产性的,也可以是开发性的,还可以是介于两者之间的。生产性的项目不确定性很低,而开发性的项目却是高度不确定的。开发性项目强调预见性,项目执行的过程,就是朝着预见的方向探索前进的过程,而不是制定出严密周详的计划,然后严格实施的过程。也就是说,计划或调整,不能说孰对孰错,管理者应根据项目自身的具体情况、具体条件,作出最恰当的选择。

实际中经常遇到类似这样的情况:

Product owner(需求方,可以是产品经理,可以是甲方,可以是单位的主管)不可能一次想清楚所有需求时,产品上线前的灰度发布会有些修改,上线后还要根据用户的反馈,可能还会进行不止一次的修改。(例如,如何鼓励用户进行评价。开始是要求用户必须评价,后来用户评价的频度降低了,而且大多是“哈哈哈哈哈”等无效评价;又选择做趣味性界面,增加了动画,但时间长了,也就降低了趣味性。有效评价还会再次降低,再次面临新的修改。)

(2) 驾驭风险,抓住机遇

人们不想采取敏捷的做法时,往往会找各种借口、理由,甚至抱怨:“这样做太费时间了”,或者“这样做成本太高”等等。所以无论是短期试点,更新数据,随时整合,自动检测,还是其他的各种变通性做法,总是会遇到这样的托辞。

多数情况下,虽不尽然,找种种借口拒绝调整,往往会直接导致效率低下,因为它让企业失去了精简流程、提高随机应对的机会。培养团队的敏捷性,必须进行小型的试点;而小型试点的目的就是找到方法,让重复的工作环节能够低成本地快速完成。而快速且低成本的工作习惯,又能促使团队面对变化,另辟蹊径。快速低成本的解决办法,还能够鼓励团队勇于创新,从而锻炼团队的创新精神。而这种创新又会影响到企业的其他部门,产生涟漪效应。这样一来,降低成本应对变化,就会促使企业重新思考它的商业模式。

(3) 采取可靠的而不是可重复的步骤

必须指出“可重复的”并不意味着敏捷。虽然实施可重复的步骤,已经成为许多企业的管理目标,但在产品开发的过程中,追求可重复的目标却不仅是错误的,而且会极大的遏制产品的开发。可重复意味着用同样的方式,做同样的事情,产出同样的结果。而可靠性却指的是无论遇到什么困难障碍都要实现既定的目标——也就意味着不断的做出调整,应对各种变化,实现既定目标。

可重复的步骤,通过制定标准和对流程的不断改进,来减少产品的质量变化。这是一个源于制造业的词。因为在生产制造中,产出什么样的产品,是已经定义好的。那么可重复性就意味在生产过程中,只要连续输入,就可以产出预期的结果。可以重复意味着从输入到产出的转换过程是可以复制的,而无需任何变化。它还意味着生产的过程不会有任何新情况发生,因为所有信息都全部预先知道,来保证最终的精准产出。但是,可重复的步骤在产品开发中毫无用处,因为首先很难精准地判断出最终的结果;其次项目不同,项目的投入也大不相同;第三,开发不同产品,从输入到产出的转换过程本身更是大相径庭。

可靠的步骤过程关注的是产出,而不是投入。哪怕是投入完全不同,通过采取可靠的步骤,项目成员也能够想出各种办法,不断向既定的目标靠拢。也正因为投入的差异,他们决不会把一个项目所采用的步骤或做法,亦或是试点,复制到另一个项目中。

可靠性是受结果驱动的;而可复制性是受输入驱动的。如果把项目的步骤固定下来,那么项目本身就会因为投入和转化的巨大差异,而变得极其危险。即便是那些声称采用了固定步骤且获得成功的企业,他们的成功并非来自于固定的、可重复的过程本身,而是来自于企业员工在实施这些步骤时,进行的敏捷调整。

敏捷开发项目管理(APM)既是可靠的,又是可预测的:这样的项目过程,由于考虑到了各种不确定性因素,因而在规定的时限内开发出的产品,最能满足客户不断变化的各种需求。这一点是其他任何一种管理方式都无法比拟的。而之所以能够这样,不是因为项目经理制定出了极其周详的任务计划,也不是对这个计划实施了精微细致的管理,而是因为敏捷的项目管理者,营造了一个这样的工作环境和氛围:人人追求卓越,并愿意为实现目标而努力。

敏捷管理虽然是可靠的,但也并非是无往而不胜的,因为它并不能消除所有的不确定性,也无法避免全部的意外。但是,这样的管理方式能够设法转化意外和不确定性,使项目最终走向成功。

总结来说:敏捷设计是一个过程,不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净以及富有表现力。

卷烟敏捷物流运作模式构建 篇9

2013年4月在京召开的烟草行业经济运行工作会议上, 国家烟草专卖局原局长姜成康强调, 要努力打造中国烟草升级版, 全面实现“卷烟上水平”目标任务。卷烟上水平的评判标准主要表现为:品牌结构不断优化、产品档次持续提升, 价格保持稳定、销量稳步增长。具体要求卷烟结构上水平, 管理上水平, 技术创新上水平, 国有资产保值增值上水平[3]。要抓好推动烟草产业转型升级这一关键点, 在提升水平上下功夫, 坚持市场推动、创新驱动, 进一步推进资源配置方式改革。基于上述背景, 当前研究并实践烟草物流如何快速响应客户需求, 提升物流服务终端能力, 显得十分重要。

1“隔日送货”卷烟物流模式及存在问题

1.1 莆田烟草物流有限公司概况

莆田烟草物流有限公司 (以下简称物流公司) 作为莆田市烟草公司 (以下简称莆田烟草) 的全资子公司, 注册资本500万元, 具有独立法人资格, 公司下设行政部、财务部、仓储部、配货部和送货部, 占地18.6亩, 员工124名, 拥有送货车辆38部, 承担全市13 300多零售客户的卷烟配送工作。公司以打造敏捷物流体系为目标, 率先在福建省内开展当日订货当日送货, 当日送货户数达5 400多户, 其余客户为次日送货, 平均送货响应时间19.3小时, 在福建省九个地市公司中响应速度是最快的。仓储面积8 000多m2, 最多可存储卷烟50 000多件, 分拣车间配置两条半自动分拣线, 单条分拣线分拣效率每小时可达360件。在日常管理中, 注重成本控制, 单箱物流费用、单箱人工费用等指标水平位居全省前列。通过近几年建设, 形成效率高、成本低、服务优的现代卷烟配送体系。

1.2“隔日送货”卷烟物流模式简介

莆田烟草卷烟配送原来采用“隔日送货”模式, 公司在三日时间之内完成客户订单接收、货物分拣和配送等工作, 即客户第一天订货, 第三天才能收到卷烟。

在订单接收环节, 所有订单必须接收完毕才一次性提交到物流公司, 提交时间为下午2:30。订单提交结束, 开始后台扣款。扣款完毕, 仓库根据出库信息进行出库备货, 备货时间需要2至3个小时, 对于各品牌的出库尾数还需进行拆零处理, 一次性备好第二天需要分拣的卷烟。第二天, 配货部将分拣数据按线路导入分拣机台, 开始一天的分拣任务。分拣好的卷烟按线路进行归集, 整理存放于待发区。第三天各配送线路与配货部交接, 将配送卷烟装车进行配送。送货人员送货后返回公司做好资金结算、车辆入库等工作, 完成一天的配送任务。

1.3“隔日送货”卷烟物流模式存在问题

原先采用的“隔日送货”模式, 从客户订货到接收卷烟需要三天的时间, 交货周期较长, 导致客户的资金周转速度较慢, 影响服务水平和客户满意度的提升。从卷烟配送业务流程入手, 剖析该种模式, 发现存在以下3个主要问题:

1) 原有订货模式难以保证订单提交及时。原有的订货模式为客户呼入, 该模式对客户订货的配合度要求较高, 若部分客户不按时订货, 就难以在规定的时间内完成全部的订单提交。

2) 原有出库流程难以保证卷烟配送时效。按照原有出库流程, 仓储部根据订单提交后生成的领货单据进行卷烟备货、出库。卷烟出库包含卷烟拆零和件烟出库扫码等工作, 其中卷烟拆零占用较多的时间, 假设第一批出库卷烟为700件, 则完成出库时间至少需花费1.5小时, 即订单9:30提交后, 等到11:00才能开始分拣, 从而延误下午的卷烟配送。

3) 原有线路布局不支持实施当日配送。莆田原有的送货线路划分为5个片区, 30部送货车辆, 150条线路。每日集中一个片区, 客户订货, 物流公司送货, 一次送货量大, 但片区内在非订货日期间货源有时又供应不足, 片区间可能出现串货现象。

基于上述分析, 究其原因, 原“隔日送货”模式主要是采用串行的运作方式, 如:订单全部接收完, 才提交给物流公司;后台扣款完毕, 仓库才开始备货、出库等。也就是说, 每个业务环节将自身任务全部执行完毕, 才推到下一个环节, 导致下一个环节等待时间过长;在执行过程中各环节之间缺乏有效沟通, 衔接不够紧密, 延长整个订单履行的过程, 拉长订单执行周期。

2 构建“当日送货”卷烟敏捷物流运作模式

烟草生产和销售企业越来越重视通过烟草流通环节降低成本, 并力图通过提高物流运作效率、降低烟草流通成本, 提高客户服务水平[4]。对烟草这一特殊行业来讲, 建立科学的服务体系, 为客户提供优质的服务, 是行业稳定发展, 健康运行的关键之一[5]。当前, 全国烟草系统提出“以客户为中心”为企业战略的出发点, 优化物流作业流程, 提高对客户需求的响应速度, 提高服务质量, 已经成为烟草物流发展的趋势。因此, 公司针对上述问题, 顺应形势发展, 组建由公司和福州大学团队构成的课题组, 启动“基于烟草供应链协同的敏捷物流模式研究与实践”课题项目, 以“网上订货、批次提交、滚动分拣、及时配送”为指导思想, 开展订单系统升级改造、出库流程重组、分拣设备改造、线路规划优化等, 构建并实施“当日送货”卷烟敏捷物流运作模式, 即客户当天订货, 当天就能收到卷烟。公司在一天内完成客户订单接收、货物分拣和配送等工作。

2.1 优化订货系统, 转变卷烟订货模式

订单接收、提交作为卷烟配送的第一道环节, 其快慢直接影响到以后各个作业环节的完成时间。实施当日送货, 要求当日送货的第一批次订单要在8:30之前提交。而原有的订货模式为主动呼入模式, 该模式对客户配合度要求较高, 若部分客户不按时订货, 就难以在规定的时间内完成全部订单的提交。为解决这一难题, 莆田烟草将电话呼入模式改进为网上订货与自动呼出相结合的模式。第一, 将订单提交由原来的一次性提交改为分批次提交。第二, 为了减轻人工订货的压力, 大力推广网上订货和语音电话订货, 目前网上订货的客户比例已达到95%, 确保订单的准时提交。第三, 自动呼叫系统根据时段安排, 按送货线路进行排序, 对该线路内客户进行滚动呼出, 对每日安排订货的且未通过网上订货的零售户利用电话主动呼出订货。系统完成这些客户的呼出订货后, 订单部及时将各时段的订货数据传递至物流公司, 保证订单的按时提交, 为卷烟配送留出较为充足的时间。第四, 为了解决部分客户在三轮循环呼出后仍然没有订货的问题, 专门开设一条专线, 客户可以在阶段订单提交前, 通过咨询台电话进行补充订货。

2.2 优化储配流程, 转变卷烟出库模式

按照原有出库流程, 仓储部根据订单提交后生成的领货单据进行卷烟出库。卷烟出库包含了卷烟拆零和件烟出库扫码等工作, 其中卷烟拆零占用较多的时间。针对这一问题, 建立“预先出库, 及时补货”的出库模式。第一, 对原有储配流程进行重组, 订单提交完成后, 立即进行分拣, 而不是等到全部卷烟出库完成后再进行, 压缩卷烟出库时间, 为后续环节的分拣和送货工作留出更多的作业时间。第二, 在仓库库位设计上, 将卷烟仓库设置为正常库和2个分拣库, 其中分拣库位于每条分拣线的备货区。仓储部根据日均销量进行测算, 设定预出库量上下限, 在订单提交之前对每个分拣库进行提前备货, 等订单提交后, 再根据领货单据进行及时补货。第三, 卷烟以件烟方式出库, 减少卷烟拆零环节。分拣工作完成后, 实施分拣库卷烟盘点, 提高卷烟的出库效率。

2.3 优化分拣操作, 转变卷烟分拣模式

针对半自动化分拣线存在的某一品牌分拣量过大, 以及卧式机分拣时容易后溜这两个主要问题, 物流公司改进分拣机的任务分布, 采用双卧式机来分拣重点品牌, 缩小相对分拣等待时间;研制一种新型防后溜装置, 防止卧式分拣机上出现后溜现象。第一, 为了解决重点品牌, 如七匹狼 (白) 、七匹狼 (红) 分拣等待时间过长的问题, 建立数学模型进行分析判断。根据分析结果, 将同一台卧式机分拣的某一品牌转移至立式机分拣, 而让重点品牌卷烟使用双卧式机分拣, 减少分拣等待时间, 以实现效率的最大化提升。第二, 针对卧式分拣机容易后溜的问题, 研制、开发与卧式通道机兼容的护烟装置。护烟装置采用全自动化控制, 无需分拣员及技术员参与操作。通过技术创新, 减少卷烟破损, 有效缩短问题处理时间, 提高生产线分拣速度, 以适应“当日送货”模式对分拣速度的要求。

2.4 优化送货线路, 转变配送网络布局

为配合物流快速响应方案的实施, 需打破原有的线路分布, 对全区的送货线路进行整体规划与优化。第一, 在原有5个片区、150条线路基础上, 根据客户聚类分析, 重新将全区送货线路进行整体规划, 划分为3环、4个大片区、每个大片区又分为5个小片区。第二, 优化工作以“由里到外, 先急后缓”的原则, 在原有线路的基础上对原有相邻线路的客户进行整合。对于同片区的送货线路, 在优化过程中注意平衡线路间的送货户数和送货量, 使各条线路的工作量趋于平衡。将全市配送客户由内到外分为三环, 一环实施当日订货当日送货;二环实施当日订货次日上午送货, 由当日送货配送车辆进行配送;三环实施当日订货次日全天送货, 由其余车辆进行配送。全区送货车辆为30部, 一环送货车辆23部, 每条线路的送货户数为40户;二环送货车辆23部, 每条线路的送货户数为40户;三环送货车辆7部, 每条线路的送货户数为70户。综合平衡每条线路的送货量、客户数、送货里程、道路状况、送货服务时间, 使各条线路的综合工作量相对均衡;考虑同一送货线路不同客户经理的搭配, 使每位客户经理的订货日不是集中在一天, 而是分散在3至4天, 从而使客户经理每天的工作量也相对均衡。通过客户聚类分析, 重新优化送货线路, 有效解决工作量平衡的问题。

2.5 优化紧急订送货, 转变临时需求应对

为了满足部分客户在非订货日用烟的临时需求, 促进部分重点品牌卷烟销售, 物流公司向部分客户提供非订货期间的订送货服务, 不断提高客户满意度。在非订货日期间有婚丧喜事、风俗节庆、大型活动等应急需求的客户, 重点培育“通系列”等品牌卷烟需要紧急送货的客户, 因公司工作失误造成订单丢失需要补单的客户, 可以向莆田烟草申请紧急订货、送货服务。物流公司针对这些客户, 专门研究制定相关的紧急订送货方案, 并付诸实施, 提升物流服务水平。

3 制定“当日送货”的保障措施

3.1 统一思想认识, 解决部门协调问题

由于物流快速响应工作涉及物流、营销、信息等部门, 因此需要各部门的紧密配合, 才能保证项目顺利完成。在项目启动初期, 莆田烟草对相关部门进行动员, 强调快速响应项目的重要性, 统一各部门认识, 并成立四个工作小组, 明确各自工作职责, 其中:综合组负责课题前期调研、方案制定、组织实施及物流中心各部流程设计、进度协调等工作;出库分拣组负责出库、分拣流程改造、系统升级等工作;线路优化组负责全区线路的规划与优化工作;营销组负责组织实施客户订货时段的分配工作、客户订货时间调整宣传工作、语音订货及后台扣款推广工作;福州大学项目团队负责相关理论研究、数据分析、技术支持。在项目实施过程中, 建立定期沟通机制, 了解各自进度, 共同分析项目实施过程中出现的各类问题, 研究解决办法。

3.2 充分开展调研, 解决项目论证问题

此次项目涉及卷烟配送过程中的订单接收、卷烟出库、卷烟配送等环节, 涉及面广, 需对整个课题的可行性进行充分调研。因此, 在项目的实施前期, 莆田烟草组织物流、营销和信息等部门召开多次会议对当日送货的可行性进行了深入的调研。通过测算各环节的作业效率和所需时间, 论证项目实施的可行性;通过对送货里程、送货量和送货时间等的测算, 运用ABC分类、聚类分析、EIQ分析等方法, 为项目的决策制定提供了一系列支持依据。

3.3 加大客户宣传, 解决客户习惯问题

实施“当日送货”需要对零售户的订货方式、订货时间和接货时间进行调整, 部分零售户可能由于习惯问题而对新订货时间、方式有所不适应, 有时会忘记订货。因此, 在项目实施前期, 莆田烟草要求客户经理、送货员认真做好当日送货的宣传、解释工作, 提醒零售户在规定时间内完成订货, 提前做好足额存款工作, 避免无法按时订货。

3.4 规范资金存放, 保障货款回收安全

“当日送货”模式实施后, 伴随出现个别送货线路的部分现金货款来不及存入银行的问题。为了解决这一问题, 莆田烟草积极与农业银行协商, 在物流公司安装一台自动存款机, 更好地保障货款安全存放与售烟款的快速划转入市烟草公司的银行帐户。

3.5 制定应急预案, 保障旺季配送安全

销售旺季期间, 可能出现在当天下午无法完成配送任务, 需要进行夜间配送。针对这一问题, 物流公司制定相关安全应急预案, 成立安全机动小组, 实施内外围送货车辆相互协助的接力送货方式, 加强对送货过程跟踪监控, 做好旺季卷烟的安全配送工作。

3.6 购置备用设备, 保障设备运行正常

针对送货车辆和分拣设备可能在运行过程中出现故障, 导致当日送货工作无法在规定时间内完成。第一, 物流公司购置一定数量的备用车辆和分拣设备常用零件, 当送货车辆或分拣设备发生故障时, 通过启用备用车辆和使用备件, 可以在短时间内进行应急处理, 确保当日送货工作不受影响。第二, 物流公司与设备维护方协商, 建立紧密合作机制, 设备维护方在设备发生故障时能够以最快速度到达形成开展维修, 减少设备故障对卷烟配送工作造成的影响。

摘要：物流响应速度是衡量物流服务水平的重要指标, 是企业及时满足客户需求的重要表现。针对莆田烟草物流原有“隔日送货”模式存在的问题, 构建“当日送货”的敏捷物流运作模式, 通过统一认识、调研论证、客户宣传、规范资金存放、制定应急预案, 确保敏捷物流模式的实施。

关键词：卷烟物流,敏捷物流,快速响应

参考文献

[1]刘小群, 马士华.支持快速客户响应的敏捷物流运作技术与方法[J].科研管理, 2007, 28 (2) :151-159.

[2]王富忠.敏捷物流系统的建模、控制与运作研究[D].杭州:浙江大学, 2007.

[3]袁桂玲, 刘艳.烟草品牌结构优化途径选择与卷烟上水平[J].现代商业, 2013 (11) :141-142

[4]扈景科.烟草行业物流现状与改革措施[J].衡水学院学报, 2008, 10 (5) :22-23.