对应参赛华为云账号： jinxingfei一、参赛收获、思考首先，这是第二次使用APP Egnine平台开发作品并参与比赛了。相比较而言，这次的开发较为顺利，对于赛题的理解也较深入。个人总结原因还是在于熟能生巧，平时多点开APP Engine，有些好的想法可以动手实践一下，用的多了，渐渐的了解了怎么定义对象，编写脚本，为前端页面定义对象模型，页面组件有哪些事件。懂得了前端页面是如何通过传参并调用后台Script或Folw,对外开发RESTful接口。在开发时，也能够根据个人想法对作品做修改优化，新增业务处理和逻辑判断等。总之，一切从实践中来，多谢APP Engine这一开放平台，让有想法的人能够付之行动，反馈了问题后很快得到回应。其次，谈一谈在开发过程中，对于本赛题的一些思考。1、页面布局的优化。针对参考教程所提供的页面布局，进行修改。包括啤酒信息列表和订单列表。主要思路是借助栅格容器中 行布局（分割比例），字体高亮（基于此，浏览啤酒页面、查看订单页面和评价页面风格均保持一致）。首页中新增直达订单查询界面的按钮，无须点击购物车后，再跳转至查询订单页面。其中订单查询页面中的订单数据，除了在后端模型视图中添加 查询订单的服务模型，可以添加 查询啤酒信息的服务模型，根据订单中啤酒的ID去查询到啤酒的图片、单价和销量等数据，显得更加直观。效果如下图：参考界面：优化后：2、消费者购买啤酒之后，可以通过手机号查询订单，并分页展示。若该手机号对应订单较多，例如50个“已下单”订单和1个“派送中”订单，单独查找“派送中”订单就需要一页页查找。所以应该支持按照订单状态查询，消费者输入手机号和选择所查询状态，对订单进行一个初步过滤，更方便。主要思路是：在查询订单列表的脚本代码中，新增一个参数 status，在后台模型中自定义order_status字段，并与前端下拉框进行值绑定。页面初加载时，默认查询全部状态的订单，用户可以通过点击下拉框选择查询特定状态的订单。另，针对手机号为空，手机号不合法，手机号没有对应订单等情景进行校验和提示。3、新增评价和自取两个功能，如下图所示，不同状态的订单应该具有不同的操作，那么如何使得 已下单-->取消订单， 待自取-->自取， 已签收-->评价等状态一一对应呢，具体思路是在后台模型中字段buttonName，该字段与红色按钮的属性显示值绑定，在查询到一系列订单列表后，编写JS代码，根据当前状态对字段进行赋值，达到不同订单的按钮显示不一致的目的，然后再根据订单状态的不同去调用不同的后台脚本。例如 点击取消订单调用editMgtInfo, 点击自取调用editMgtInfo,点击评价调用appraiseOrder4、参考常用的APP，作品可以提供一个“评价”功能。当订单完成派送，显示“已签收”，此时消费者可以对订单进行评价，输入意见和评分。评价后商品销量+1，并生成综合评分。主要思路是当消费者点击“评价”按钮时，跳转至评价页面，输入评分和评价信息，点击确定。后台对应新增脚本appraiseOrder。该脚本需要的参数包括：啤酒ID（用于修改啤酒的销量和评分）、评分和订单ID（用于修改订单的状态）。具体的代码和修改订单信息、修改啤酒信息类似，在此不做赘述。5、赛题所提供的物流方“接单”和“关单”功能，有一些不恰当之处，首先物流方不能查询“已下单”、“已取消”、“待自取”等状态下的订单，这属于消费者的信息，只能供应方查看，不应该被物流方查看到，且和物流方没有业务关联。“待发货”状态订单被接单后，状态变为“派送中”，此时已经处于派送状态或者已完成投递，那么不应该允许物流方再次进行接单操作，接单功能应该禁用，否则整个流程不符合日常逻辑。“总之，物流方接单时，只能操作“待发货”状态的订单，而不能随意操作其他订单。同理，关单操作也是如此。具体思路是在操作按钮中输入表达式运算，根据订单状态来决定操作结果。除此以外，对于期望到货日期不在三天之后、输入非法字符、手机号不合法、查询订单结果为空，取消订单的状态不是“已下单”，物流方查询不属于其业务状态的订单等情况，都应通过消息框或错误框进行提示，以提高作品的易用性。以上所提及的建议和问题，本人在所提交作品中均有新增和优化，并针对页面布局优化。二、作品讲解视频作品讲解视频链接：https://v.qq.com/x/page/z3158b8fhy6.html

OA系统在工程建设行业：泛微OA系统工程管理方案，通过一套协同工作台为工程建设组织提供“工地施工管理平台”、“工程数据监管仓”、“工程合同电子签署平台”、“工程风险监测中心”以及“工程成本管控中心”等5大应用，全面协同工程管理资源，让组织全员在一个平台协作推进工程项目高效、安全验收。方案看点：全员协同、全过程工程管理平台一个大型工程实施过程常常需要项目部联合多个岗位、部门与外部供应商、分包商一起协作推进，单一的工程管理、采购管理、合同管理软件信息无法互通，在线协作难推进，工程建设组织需要借助OA系统消除各部门、各岗位、各套业务软件以及组织内外部之间的连接壁垒，内外协同提升工程管理效率。>>> 大型工程协同管理平台全面融合“BIM工程信息系统、ERP软件、报表分析系统、智能大屏、电子签章以及企业微信”等多套管理软件，帮助建设工程组织统一内部办公平台，以流程驱动工程全员、全过程、全数据、全程电子化、内外协同管理。（大型工程管理平台应用情况）>>> 满足各个岗位的工程协作需求：① 领导层：不怕项目多，随时能监管全国各地在建工程项目信息自动汇总、统计、分析，随时通过表单就能掌控所有项目进展。（领导监管看板）② 工程负责人：不怕工地远，远程也能管工地施工现场情况同步回传，每天都能及时了解现场施工进度、安全问题，及时调整工程计划。③ 工程施工员：不怕汇报难，手机端及时沟通工地施工情况、施工难题每天用手机应用就能及时上报负责人，在线协调设备进场时间，确保安全、按计划施工。④ 法务、财务：不怕数据多，自动就能传工程所需的合同、费用、采购信息自动共享、储存，无需人工核对录入、统计，全面降低跨部门协作成本。⑤ 采购人员：不怕工地催，供应商对接快通过企业微信连接微信，采购人员可以快速收集外部供应商信息和详细报价，供应商通过微信就能接单、签合同，不耽误工地设备、材料采购。“5”大工程应用 +“1个”移动管理助手，全面支撑工程全过程管理需求一、工地施工管理平台泛微通过对接BIM工程信息软件，借助电子流程快速落实工地施工管理制度，满足工地日常工作汇报、巡检需求，让施工透明化，化解传统工地管理中“距离远、看不见、不了解”难题，“零距离”监管工地。1、工程监管看板所有BIM、ERP软件中的项目数据，自动同步到OA系统，通过业务流程渠道自动分类、汇总，形成项目信息库，工程建设组织当前承包的工程项目统一汇总，施工状态、承建单位、负责人、工程进度、施工地点、成本预算信息一目了然。（工程地图）（工程信息台账）2、工程进度全程跟踪将各个工程按照实施流程一一细化成不同执行环节，借助OA系统任务管理功能，严格管控各环节任务执行效率，工程项目是否报备、合同签没签、启动了没有、准备如何了、有没有验收等等，全部视觉化呈现，高效跟踪进度。（工程进度看板）3、工程质量检验前期围绕工程技术质量要求，图纸会审、施工方案上报全面流程化，后期通过巡检应用，智能上报工程检验意见，推动巡检、整改、验收全程电子化。4、安全监督智能化打造“事故上报”、“施工现场巡检”以及“施工队伍监管”三大安全监管应用，不仅工地施工员可以及时上报现场事故，巡检人员也能定期走访工地，用手机上报巡检结果，帮助记录工地安全标准完成情况。1）工地安全事故一键上报各类可能出现的施工事故，比如机械故障、工人受伤等，施工人员随时可以用手机上报，帮助总部及时制定应对方案。2）施工现场安全标准实施巡检工地监管人员可以定期走访工地，用手机上报巡检结果，帮助记录工地安全标准完成情况。（工地安全巡检情况一键上报）3）施工队伍安全事故信息记录同时，通过OA系统记录各个工地、各个施工队伍施工期间的事故率、设备损坏率、不良事件、工程维修率，帮助建设工程组织及时监管、合理安排施工资源。二、内外协同的合同电子签章平台工程项目实施过程涉及合同、单据材料多且杂，各类工程项目合同、施工协议、分包合同、材料/设备采购合同等条款多、条件也越来越复杂，不仅内部法务审核、盖章工作量大，如何与外部分包商、供应商快速签约、回传也是难点。OA系统引入电子签章通过企业微信帮助工程建设组织打造内外协同全程电子化的合同管理平台，只需一条流程合同从“起草、审批、盖章、签约、收付款到履约、更新、开票”全程电子化管理。1、电子模板规范合同格式为了规范工程类文件版式，泛微电子模板库可以为各类工程合同、采购合同、验收单、联系单提供标准样式，一键套用，减少合同内容风险。2、用印、签署全程电子化引入电子签章应用，为工程管理过程提供电子印章、电子签名，工程文件流程审批后自动完成内部盖章，无需人工干预。3、流程外发高效推动签约OA系统通过企业微信和微信信息互通，各类工程合同、分包合同、工程发函、材料/设备采购合同的内部签约流程通过企业微信就能发送给客户、分包单位以及供应商微信。让工程建设组织的项目负责人、采购及施工人员与外部客户、分包商伙伴、供应商在一个平台就能极速对接合同信息，在线电子签章。签约后的文件信息自动通过流程回传OA系统，全程无需切换平台、无需下载打印，全面提升工程文件签约效率。（签约流程外发，在微信签电子合同）4、微信智能收取项目款通过企业微信和微信消息互通，不仅解决了工程项目合同的在线无障碍签约，还能通过流程外发，在验收阶段帮助项目负责人快速向客户收取工程款。只需将内部收款流程通过企业微信发送给客户微信，就能在线完成微信支付，信息全程记录，又快、又安全。（收款流程外发至客户微信，在线付款）5、合同信息自动关联汇总所有工程项目涉及的合作、采购、验收合同，都能通过OA系统电子表单自动汇总分类形成电子合同信息库，在流程驱动下让信息与执行情况自动相连，签约/回款情况、是否超期一目了然。三、工程成本预算管控中心做好工程项目成本管控，是工程管理的重要任务之一。泛微财务共享中心全面集成BIM系统、资金、影像以及税务系统，为工程实施工程中涉及的各项“采购、劳务”制定预算费用方案，借助电子流程全面监控业务用款情况。不仅帮助管理层、申请用款人员及时了解预算余额，还能让财务了解费用使用情况，及时把控超支风险。（全程电子化费控管理平台）1、超支自动提醒通过预算设置，各个项目分包付款、采购付款申请中一旦超支，智能提醒，严格执行费控。（费用预算超支提醒）2、预算执行智能考评预算方案执行情况可以通过智能报表定期分析汇总，各项工程不同时段的预算制定执行情况一目了然，及时调控。3、全生命周期调控助手从预算方式制定、报销、费用申请、预算变更全面流程化执行，减少人为干预，让工程项目预算制度真正落实。四、工程数据监管仓为了帮助工程建设组织更直观、便捷的掌控工程情况，OA系统集成BI报表及智能大屏软件，借助OA流程帮助组织全程跟踪、收集工程管理中的财务、项目、合同、人事等信息，通过BI报表智能呈现，满足领导层、管理层和项目执行人员的日常监管需求。可以以通过综合信息分析监控整体工程状况；可以了解不同阶段合同金额变化、回款效率以及各个子公司签约金额大小等等；可以智能汇总工程问题，帮助了解安全隐患及质量问题数量，剩余工期等，帮助把控风险；可以智能汇总各个工程的人工、设备资金投入情况，及时掌控成本，快速调控。（项目总体数据监控）（施工安全监控）五、工程风险监测中心OA系统风险管控中心，可以针对工程项目实施中的财务、合同、供应商、工程事故、不良事件、机械故障等各类风险事件建立集“上报、预警、处置、监控”于一体的工程风险监测中心。通过构建日常工程风险事件库，设置风险预警条件，帮助工程项目管理人员智能预警风险，及时做出风险调控，加快工程建设组织内部风险识别能力，缩短风险应对时间，提升工程施工安全性。（工程风险事件检测中心）六、移动工程管理助手大多工程施工地较远、处于户外工作，由于缺乏移动化管理工具，不仅施工数据和现场情况很难及时反馈，施工人员想查工程信息、实施计划也无从下手，现场灵活办公难度大。管理层出差在外，想第一时间了解项目进度以及施工人员工作情况都很难。泛微移动工程管理助手为管理层、现场施工员、安全员、技术员等提供移动办公助手，工地现场人员可以随时随地用手机反馈工程进度、查询联系人信息；管理层可以第一时间了解施工情况，审批业务；全面消除管理层与执行人之间的信息传输障碍，加快工程施工信息共享。（反馈施工情况）（施工进度可视化）总结OA系统大型工程管理平台已经服务了众多工程建设组织，帮助实现工程数据共享，让越来越多工程建设组织在资源、人员、信息全面协同的基础上，体验真正便捷、全程电子化的工程项目管理。

    通过华为云这一平台，做工业互联网-啤酒管理系统开发，对我专业上有所提升，在我遇到困难时有专业的军哥和赛道解答机器人给我耐心的指导，在此非常感谢。工业互联网是现在新旧动能转换最重要的一环，工业互联网解决了以前用人工来管理工厂、企业的数据既费时又费力，有了工业互联网可以可以解决这一问题，省去了许多人力、物力。一、通过平台上的控件进行拖拉拽形成一个前端页面，然后通过后端脚本代码进行与前端控件进行绑定，只需要操作页面就可以实现了控件的功能，这一平台和云计算的平台非常类似，都是通过操作界面进行管理。二、通过这一平台开发出来的啤酒管理系统非常直观明了，可以进行需求者浏览啤酒进行下单购买，然后物流方进行供应，购买者和物流方都可以进行很方便的管理订单状态，进行统计。三、通过认真学习并开发完啤酒管理系统后，我想可以把这个推广到微信小程序中，进行开发，通过json、js、wxss、wxml、等实现这一管理系统。非常方便用户可以随时随地进行下单购买。四、可以通过这一平台进行小商城o2o管理系统的开发。五、啤酒系统管理大屏幕非常人性化，通过配置控件、图表、绑定等等就可以实现界面的显示，相比用代码开发、调用接口API等等简单而又省时、省力非常简单易用。希望能够大力推广华为云、沃土数字平台的使用。

“文谷数字化工厂TSES有—套合理的产品标准和生产制造逻辑，所以对梳理整个公司的流程非常有帮助，通过数字化的上线，把整个公司的生产流程给梳理了—遍，剔除不好的，保留好的，数字化工厂有助于我们在产品管理上符合流程方面做得更好。”—— 天阁汽车零部件有限公司总经理随着经济的飞速发展，我国已经迅速成为世界制造业的中心。制造型企业纷纷选择信息化企业管理提高生产力，降低成本。宁波天阁汽车零部件有限公司是一家为BorgWarner、TRW、HONEYWELL、LEAR、WINWIN、VISTEON等国内外知名客户提供各类汽车零配件、紧固件、塑料焊接件、五金件及压铸件等优质产品的汽车零部件企业。为追求更高的产品质量、拓展更广阔的市场及更好地满足各类用户的不同需求，天阁坚持不懈地追求领先的生产技术，吸纳先进的管理经验和服务理念。在以信息化促进工业化、工业化带动信息化的潮流中，为了应对市场挑战并坚持与国际接轨，公司不仅安装了office、三维CAD软件等工具软件，也上马了ERP等管理软件，但随着企业规模的不断扩大，天阁在订单管理、生产管控以及部门协作等方面的问题日益凸显，主要存在以下难题：对生产、出入库、订单等关键环节管理上遭遇的痛点和难点，天阁迫切希望通过部署新的信息化系统，实现业务流程规范化，打通进销存、生产、财务等各个环节，“真实”呈现企业的运营状况。提升订单交付能力，完善质量监控体系，从而实现提升企业的综合竞争力的目标。 二、解决方案作为华为严选的生态合作伙伴，华为云宁波沃土工场能开放华为在云计算、大数据、物联网领域的软件核心底层技术，并由华为团队入驻与参与管理，引入华为在关键领域的专家和合作伙伴支持。为了改善生产质量，实现高效化生产，我们在华为云严选商城购买文谷数字化工厂TSES解决方案，开始与浙江文谷科技科技有限公司（以下简称“文谷”）的合作之旅。下图为文谷数字化工厂TSES架构图，该系统统一管理平台部署在华为云上，加速云服务器有效地改善企业用户访问办公系统的速度，云安全服务保障了数据的安全，进一步发挥系统效能与价值。1、将生产研发过程标准化文谷的TC研发管理系统将企业原来独立的材料清单BOM，工艺流程PFD，设备参数，质量要求等进行标准统一，并有效连接起来，使产品的各种数据标准化、结构化、参数化，从而让这些数据能够更加快速、直接地被生产者和设备识别。从而保证能快速、高效地部署产品信息应用软件，以支持企业业务过程的协同运作。2、做的生产过程信息的全面追溯文谷MC生产管理系统能通过实时的数据采集、高效的全员协同、全面的过程控制、精准的计划排程、透明的信息追溯，对生产过程进行全面管理，从而达到先期预防，高效响应，智能分析，精准决策的效果。3、全面提高企业质量保证能力文谷QC质量管理系统通过完善先期质量标准、监测过程质量数据、统计质量量化结果，并通过智能的数据分析自动的比对手段，减少人为因素影响，实时披露质量问题、避免问题持续发送，最终全面提高企业质量保证能力。4、将设备管理可视化文谷的EC设备管理系统将企业生产资源（设备、人员、刀模具、工器具等）纳入统一的管理，确保资源能够正常运转和被使用。通过实时的生产反馈数据及运行数据采集，EC能够对各种资源的利用情况进行实时统计、客观分析，为管理者提供多种企业生产效率方面的报表及视图（员工绩效分析、设备使用效率、OEE/TEEP分析，整体产能分析等），为管理者实时了解企业生产负荷，找出企业效率短板和瓶颈提供数据依据，确保企业生产过程顺畅有序。三、客户受益1.打通了多个各自独立的“信息孤岛”，形成了真正的工厂物联网，从而极大提高了生产管理的有效性和实时性、促进了企业的快速发展。2. 通过订单高级排产，产能可视，协同呼叫，计划、来料和生产消耗环节信息透明，提高了接单效率，缩短了供货周期。3. 实现了车间生产调度、产品跟踪、质量控制、设备故障分析、员工管理的统一，为生产管理人员进行过程监控与管理、保证生产正常运行、控制产品质量和生产成本提供有力的支持。 文中提到的商品：文谷数字化工厂TSES（点击可查看详情）上严选商城，挑选更多优质云上精品！【华为云云市场，助您上云无忧】

“如何进行车队的高效管理，为企业节省成本，成为智能交通的解决方案给出了完美答案。”—— 毕节烟草公司一、业务背景贵州毕节烟草公司拥有近300辆公务车，跨越毕节市的七星关区、赫章县、纳雍县、织金县等7个县区，车辆分布范围广，管理难度大。此前公司采用传统定位设备，由于功能单一，无法进行精准定位和轨迹查询，无法满足监管驾驶行为、高效调度车辆、提高车辆利用率等多元管理需求，且服务成本高。 二、业务痛点1. 车辆定位偏离严重，无法进行精准定位和轨迹查询；2. 公务车利用率低，存在难以调度及车辆闲置的情况；3. 车队安全无告警机制，无法对驾驶员进行驾驶行为监管；4. 缺少科学可行的公务车管理系统与有效全面的管理方式，管理人员在管理中缺少数据的支撑，难以规范用车各个环节。 三、解决方案为了能高效、便捷的进行公务车车辆管理，贵州省烟草公司毕节市公司成选择为智能交通，携手贵州鼎合黔立引进基于北斗定位监控管理系统的成翼行车队管理云服务，2018年8月初进行项目测试后，10月正式启动。成翼行车队管理云服务基于华为云，通过弹性云服务器、镜像服务、云数据库RDS等服务，帮助客户实现智能化车队管理转型。1.  采用GPS+北斗双模块，车辆定位精准无误。设备全新升级，采用GPS+北斗双模块定位技术，车辆定位更精准；行程轨迹偏移值减少，车辆行程监控一目了然，方便车队管理员进行后台车辆调度。2.  引入事件视频回放，实现车队可视化管理。 当发生不良驾驶行为事件时，车队管理员可在平台上进行不良驾驶行为事件的视频查看，有效规范驾驶员驾驶行为；当发生碰撞事件时，车载智能终端能够自动记录事故前后画面，强制保存关键记录，并上传至服务器。有效还原事故现场，轻松查清事故责任归属。3.  专业PMO团队，提供高性能的售后服务。项目过程中，成为智能交通组建专门的PMO团队，根据项目的要求和生命周期，为毕节烟草公司提供从计划、设计、实施到交付的整套服务，帮助其掌握和利用最新的技术，提高系统的整体运作性能。此外，还向毕节市烟草公司提供全方位的技术支持服务，其内容包括：电话技术支持服务、现场技术支持服务、系统故障报告和预防服务、定期巡检服务等服务内容。4.  为管理提供有力支撑，树立智能化车队管理样板点。通过成为智能交通车队管理服务系统及车载智能终端设备，贵州毕节烟草公司公务车的使用率显著提高，不但弥补了传统车辆管理系统对动态数据处理统计的局限性，还极大程度地提高了公务车辆管理系统的应用性和扩展性，促进贵州省其他子烟草公司的公务车管理数字化转型。四、改变与提升1. 车辆定位精准，行车轨迹完整，车队的精细化管理能力提升。方案试点1个月后，极大改善行程丢失情况，定位偏移情况从几十公里缩减至几百米2. 提高车辆使用率，促进资源合理配置。通过云平台完成了实时的公务车监控管理，根据平台数据筛选各部门车辆使用率，进行合理资源分配，提高管理效益。3. 可视化实时监控平台，提升车队安全系数。车队管理员可随时在平台监控驾驶员行为，消除行车安全风险，及时进行安全预警，减少事故发生概率。 文中提到的商品：成翼行车队管理服务（点击可查看详情）上严选商城，挑选更多优质云商品！【华为云云市场，助您上云无忧】

项目管理之敏捷开发之道（三）

项目管理之敏捷开发之道（二）

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 敏捷开发原则 敏捷建模（AM）定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP中借鉴而来，在Extreme Programming Explained中有它们的详细描述。而XP中的一些原则又是源于众所周知的软件工程学。复用的思想随处可见！基本上，本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作；这样，对于这些借鉴于XP的原则，我们可以从另一个角度来看待。核心原则 ◆主张简单当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案。不要过分构建（overbuild）你的软件。用AM的说法就是，如果你现在并不需要这项额外功能，那就不要在模型中增加它。要有这样的勇气：你现在不必要对这个系统进行过分的建模（over-model），只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统。尽可能的保持模型的简单。◆拥抱变化需求时刻在变，人们对于需求的理解也时刻在变。项目进行中，Project stakeholder可能变化，会有新人加入，也会有旧人离开。Project stakeholder的观点也可能变化，你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实。◆你的第二个目标是可持续性即便你的团队已经把一个能够运转的系统交付给用户，你的项目也还可能是失败的－－实现项目投资者的需求，其中就包括你的系统应该要有足够的鲁棒性（robust ），能够适应日后的扩展。就像Alistair Cockburn常说的，当你在进行软件开发的竞赛时，你的第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版，或是你正在构建的系统的运转和支持。要做到这一点，你不仅仅要构建高质量的软件，还要创建足够的文档和支持材料，保证下一场比赛能有效的进行。你要考虑很多的因素，包括你现有的团队是不是还能够参加下一场的比赛，下一场比赛的环境，下一场比赛对你的组织的重要程度。简单的说，你在开发的时候，你要能想象到未来。◆递增的变化和建模相关的一个重要概念是你不用在一开始就准备好一切。实际上，你就算想这么做也不太可能。而且，你不用在模型中包容所有的细节，你只要足够的细节就够了。没有必要试图在一开始就建立一个囊括一切的模型，你只要开发一个小的模型，或是概要模型，打下一个基础，然后慢慢的改进模型，或是在不在需要的时候丢弃这个模型。这就是递增的思想。◆令投资最大化你的项目投资者为了开发出满足自己需要的软件，需要投入时间、金钱、设备等各种资源。投资者应该可以选取最好的方式投资，也可以要求你的团队不浪费资源。并且，他们还有最后的发言权，决定要投入多少的资源。如果是这些资源是你自己的，你希望你的资源被误用吗。◆有目的的建模对于自己的产出，例如模型、源代码、文档，很多开发人员不是担心它们是否够详细，就是担心它们是否太过详细，或担心它们是否足够正确。你不应该毫无意义的建模，应该先问问，为什么要建立这个产出，为谁建立它。和建模有关，也许你应该更多的了解软件的某个方面，也许为了保证项目的顺利进行，你需要和高级经理交流你的方法，也许你需要创建描述系统的文档，使其他人能够操作、维护、改进系统。如果你连为什么建模，为谁建模都不清楚，你又何必继续烦恼下去呢？首先，你要确定建模的目的以及模型的受众，在此基础上，再保证模型足够正确和足够详细。一旦一个模型实现了目标，你就可以结束工作，把精力转移到其它的工作上去，例如编写代码以检验模型的运作。该项原则也可适用于改变现有模型：如果你要做一些改变，也许是一个熟知的模式，你应该有做出变化的正确理由（可能是为了支持一项新的需求，或是为了重构以保证简洁）。关于该项原则的一个重要暗示是你应该要了解你的受众，即便受众是你自己也一样。例如，如果你是为维护人员建立模型，他们到底需要些什么？是厚达500页的详细文档才够呢，还是10页的工作总览就够了？你不清楚？去和他们谈谈，找出你想要的。◆多种模型开发软件需要使用多种模型，因为每种模型只能描述软件的单个方面，“要开发现今的商业应用，我们该需要什么样的模型？”考虑到现今的软件的复杂性，你的建模工具箱应该要包容大量有用的技术（关于产出的清单，可以参阅AM的建模工件）。有一点很重要，你没有必要为一个系统开发所有的模型，而应该针对系统的具体情况，挑选一部分的模型。不同的系统使用不同部分的模型。比如，和家里的修理工作一样，每种工作不是要求你用遍工具箱里的每一个工具，而是一次使用某一件工具。又比如，你可能会比较喜欢某些工具，同样，你可会偏爱某一种模型。有多少的建模工件可供使用呢，如果你想要了解这方面的更多细节，我在Be Realistic About the UML中列出了UML的相关部分，如果你希望做进一步的了解，可以参阅白皮书The Object Primer -- An Introduction to Techniques for Agile Modeling。◆高质量的工作没有人喜欢烂糟糟的工作。做这项工作的人不喜欢，是因为没有成就感；日后负责重构这项工作（因为某些原因）的人不喜欢，是因为它难以理解，难以更新；最终用户不喜欢，是因为它太脆弱，容易出错，也不符合他们的期望。◆快速反馈从开始采取行动，到获得行动的反馈，二者之间的时间至关紧要。和其他人一共开发模型，你的想法可以立刻获得反馈，特别是你的工作采用了共享建模技术的时候，例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工作，去了解他们的的需求，去分析这些需求，或是去开发满足他们需求的用户界面，这样，你就提供了快速反馈的机会。◆软件是你的主要目标软件开发的主要目标是以有效的方式，制造出满足投资者需要的软件，而不是制造无关的文档，无关的用于管理的工件，甚至无关的模型。任何一项活动（activity ），如果不符合这项原则，不能有助于目标实现的，都应该受到审核，甚至取消。◆轻装前进你建立一个工件，然后决定要保留它，随着时间的流逝，这些工件都需要维护。如果你决定保留7个模型，不论何时，一旦有变化发生（新需求的提出，原需求的更新，团队接受了一种新方法，采纳了一项新技术...），你就需要考虑变化对这7个模型产生的影响并采取相应的措施。而如果你想要保留的仅是3个模型，很明显，你实现同样的改变要花费的功夫就少多了，你的灵活性就增强了，因为你是在轻装前进。类似的，你的模型越复杂，越详细，发生的改变极可能就越难实现（每个模型都更“沉重”了些，因此维护的负担也就大了）。每次你要决定保留一个模型时，你就要权衡模型载有的信息对团队有多大的好处（所以才需要加强团队之间，团队和项目投资者之间的沟通）。千万不要小看权衡的严重性。一个人要想过沙漠，他一定会携带地图，帽子，质地优良的鞋子，水壶。如果他带了几百加仑的水，能够想象的到的所有求生工具，一大堆有关沙漠的书籍，他还能过得去沙漠吗？同样的道理，一个开发团队决定要开发并维护一份详细的需求文档，一组详细的分析模型，再加上一组详细的架构模型，以及一组详细的设计模型，那他们很快就会发现，他们大部分的时间不是花在写源代码上，而是花在了更新文档上。宣言原则 最重要的是通过尽早和不断交付有价值的软件满足客户需要。我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。可以工作的软件是进度的主要度量标准。敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。对卓越技术与良好设计的不断追求将有助于提高敏捷性。简单——尽可能减少工作量的艺术至关重要。最好的架构、需求和设计都源自自我组织的团队。每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。敏捷成功之道 随机应变 要达到敏捷的成功—交付支撑业务的最佳软件—软件专家也可以引用这些规则。自主权 专注于工作，交付正确的软件，而不是被他人的愤怒情绪所影响。分享经验 构建完美软件开发流程，并没有统一的模式。但是在这个领域，敏捷技术，加上持续的应用和改进，都能够达到敏捷的成功。敏捷开发相关工具 Visual Studio Team Foundation ServerTFS，即团队基础服务器是微软应用程序生命周期管理服务器，用于帮助团队在Visual Studio的协作开发。最近，它进有了升级包括工作项目执行改进、富文本编辑器的改进，以及富文本编辑器中改善的超链接体验。 TFS中的Kanban面板也做了改善，提升了可以录入和跟踪的项目数量，该服务器现在有一个“利益相关者”许可，来规范服务器的访问权限。Atlassian JiraAtlassian的是一个很流行的工具，主要用于跟踪产品开发、帮助团队整理问题、安排工具，以及记录团队行为。它Jira Agile插件使开发人员更容易部署关键敏捷策略，这包括用户故事开发、冲刺模块构建，以及可视化的团队活动。AxosoftAxosoft以前被称为Axosoft OnTime Scrum，这一软件套件有四个功能模块：Scrum、Bug追踪器、帮助台和Wiki。它是基于HTML5构建的，帮助开发团队管理待办事项列表、发布和冲刺，带有燃尽图功能，有一个 管理仪表板用于跟踪编码和修改BUG的时间。LeanKit使用 LeanKit的团队可以看到工作负载的分布并导出历史数据。最近 LeanKit 进行了一次升级，包含单点登录功能 和附加报告功能，从而提供更细粒度的数据详细信息。PlanboxPlanbox 敏捷管理工具通过燃尽图跟踪进程，集成客户反馈，它的目标人群很广泛。最近它对应用的前端和后端都做的升级，添加了更强大的报告功能和新仪表盘，来提升项目速度。时间跟踪特性和工具允许用户得到所有他们在Planbox产生的数据。敏捷开发实践 敏捷建模（AM）在AM原则的基础上定义了一组核心实践（practice）和补充实践，其中的某些实践已经是极限编程（XP）中采用了的，并在 Extreme Programming Explained一书中有详细的论述，和AM的原则一样，我们在描述这组实践时，将会注重于建模的过程，这样你可以从另外一个角度来观察这些已或XP采用的素材。核心实践◆Stakeholder的积极参与 我们对XP的现场客户（On-Site Customer）的概念做了一个扩充：开发人员需要和用户保持现场的接触；现场的用户要有足够的权限和能力，提供建构中的系统相关的信息；及时、中肯的做出和需求相关的决策；并决定它们的优先级。AM把XP的“现场客户”实践扩展为“使project stakeholder积极参与项目”，这个project stakeholder的概念包括了直接用户、他们的经理、高级经理、操作人员、支持人员。这种参与包括：高级经理及时的资源安排决策，高级经理的对项目的公开和私下的支持，需求开发阶段操作人员和支持人员的积极参与，以及他们在各自领域的相关模型。◆正确使用artifact 每个artifact都有它们各自的适用之处。例如，一个UML的活动图（activity diagram）适合用于描述一个业务流程，反之，你数据库的静态结构，最好能够使用物理数据（physical data）或数据模型（persistence model）来表示。在很多时候，一张图表比源代码更能发挥作用，一图胜千言，同样，一个模型也比1K的源代码有用的多，前提是使用得当（这里借用了 Karl Wieger的Software Requirements中的词汇）。因为你在研究设计方案时，你可和同伴们和在白板上画一些图表来讨论，也可以自己坐下来开发一些代码样例，而前一种方法要有效的多。这意味着什么？你需要了解每一种artifact的长处和短处，当你有众多的模型可供选择的时候，要做到这一点可没有那么容易。◆集体所有制 只要有需要，所有人都可以使用、修改项目中的任何模型、任何artifact。◆测试性思维 当你在建立模型的时候，你就要不断的问自己，“我该如何测试它？”如果你没办法测试正在开发的软件，你根本就不应该开发它。在现代的各种软件过程中，测试和质保（quality assurance）活动都贯穿于整个项目生命周期，一些过程更是提出了“在编写软件之前先编写测试”的概念（这是XP的一项实践：“测试优先”）。◆并行创建模型 由于每种模型都有其长处和短处，没有一个模型能够完全满足建模的需要。例如你在收集需求时，你需要开发一些基本用例或用户素材，一个基本用户界面原型，和一些业务规则。再结合实践切换到另外的Artifact，，敏捷建模者会发现在任何时候，同时进行多个模型的开发工作，要比单纯集中于一个模型要有效率的多。◆创建简单的内容 你应该尽可能的使你的模型（需求、分析、架构、设计）保持简单，但前提是能够满足你的project stakeholder的需要。这就意味着，除非有充分的理由，你不应该随便在模型上画蛇添足－－如果你手头上没有系统认证的功能，你就不应该给你的模型增加这么一个功能。要有这样的勇气，一旦被要求添加这项功能，自己就能够马上做到。这和XP的实践“简单设计”的思想是一样的。◆简单地建模 当你考虑所有你能够使用的图表（UML图、用户界面图、数据模型等）时，你很快会发现，大部分时候你只需要这些图表符号的一部分。一个简单的模型能够展示你想要了解的主要功能，例如，一个类图，只要能够显示类的主要责任和类之间的关系就已经足够了。不错，编码的标准告诉你需要在模型中加入框架代码，比如所有的get和set操作，这没有错，但是这能提供多少价值呢？恐怕很少。◆公开展示模型 你应当公开的展示你的模型，模型的载体被称为“建模之墙”（modeling wall）或“奇迹之墙（wall of wonder）”。这种做法可以在你的团队之间、你和你的project stakeholder之间营造出开放诚实的沟通氛围，因为当前所有的模型对他们都是举手可得的，你没有向他们隐藏什么。你把你的模型贴到建模之墙上，所有的开发人员和project stakeholder都可以看建模之墙上的模型，建模之墙可能是客观存在的，也许是一块为你的架构图指定的白板，或是物理数据模型的一份打印输出，建模之墙也可能是虚拟的，例如一个存放扫描好的图片的internet网页。如果你想要多了解一些相关的资料，你可以看看Ellen Gottesdiener的Specifying Requirements With a Wall of Wonder。◆切换到另外的Artifact 当你在开发一个artifact（例如用例、CRC卡片、顺序图、甚至源码），你会发现你卡壳了，这时候你应当考虑暂时切换到另一个artifact。每一个artifact都有自己的长处和短处，每一个artifact都适合某一类型的工作。无论何时你发现你在某个artifact上卡壳了，没办法再继续了，这就表示你应该切换到另一个artifact上去。举个例子，如果你正在制作基本用例，但是在描述业务规则时遇到了困难，你就该试着把你的注意力转移到别的artifact上去，可能是基本用户界面原型、CRC模型，可能是业务规则、系统用例、或变化案例。切换到另一个artifact上去之后，你可能就立刻不再卡壳了，因为你能够在另一个artifact上继续工作。而且，通过改变你的视角，你往往会发现原先使你卡壳的原因。◆小增量建模 采用增量开发的方式，你可以把大的工作量分成能够发布的小块，每次的增量控制在几个星期或一两个月的时间内，促使你更快的把软件交付给你的用户，增加了你的敏捷性。◆和他人一起建模 当你有目的建模时你会发现，你建模可能是为了了解某事，可能是为了同他人交流你的想法，或是为了在你的项目中建立起共同的愿景。这是一个团体活动，一个需要大家有效的共同工作才能完成的活动。你发现你的开发团队必须共同协作，才能建立一组核心模型，这对你的项目是至关重要的。例如，为了建立系统的映像和架构，你需要和同组成员一起建立所有人都赞同的解决方案，同时还要尽可能的保持它的简单性。大多数时候，最好的方法是和另一些人讨论这个问题。◆用代码验证 模型是一种抽象，一种能够正确反映你正在构建的系统的某个方面的抽象。但它是否能运行呢？要知道结果，你就应该用代码来验证你的模型。你已经用一些HTML页面建立了接受付款地址信息的草图了吗？编码实现它，给你的用户展示最终的用户界面，并获取反馈。你已经做好了表示一个复杂业务规则逻辑的UML顺序图了吗？写出测试代码，业务代码，运行测试以保证你做的是对的。永远也别忘了用迭代的方法开发软件（这是大多数项目的标准做法），也别忘了建模只是众多任务中的一个。做一会儿建模、做一会儿编码、做一会儿测试（在其它的活动之中进行）。◆使用最简单的工具 大多数的模型都可以画在白板上，纸上，甚至纸巾的背面。如果你想要保存这些图标，你可以用数码相机把它们拍下来，或只是简单的把他们转录到纸上。这样做是因为大多数的图表都是可以扔掉的，它们只有在你画出模型并思考一个问题的时候才有价值，一旦这个问题被解决了它们就不再有意义了。这样，白板和标签往往成为你建模工具的最佳选择：使用画图工具来创建图表，给你重要的project stakeholder看。只有建模工具能够给我们的编程工作提供价值（例如代码自动生成）时才使用建模工具。你可以这样想：如果你正在创建简单的模型，这些模型都是可以抛弃的。你建模的目的就是为了理解，一旦你理解了问题，模型就没有存在的必要了，因此模型都是可以丢弃的，这样，你根本就不必要使用一个复杂的建模工具。补充实践◆使用建模标准 这项实践是从XP的编码标准改名而来，基本的概念是在一个软件项目中开发人员应该同意并遵守一套共同的建模标准。遵守共同的编码惯例能够产生价值：遵守你选择的编码指南能够写出干净的代码，易于理解，这要比不这么做产生出来的代码好得多。同样，遵守共同的建模标准也有类似的价值。可供选择的建模标准有很多，包括对象管理组织（OMG）制定的统一建模语言ML），它给通用的面向对象模型定义了符号和语义。UML开了一个好头，但并不充分－就像你在Be Realistic About The UML中看到的，UML并没有囊括所有可能的的建模artifact。而且，在关于建立清楚可看的图表方面，它没有提供任何建模风格指南。那么，风格指南和标准之间的差别在何处呢。对源代码来说，一项标准可能是规定属性名必须以attributeName的格式，而风格指南可能是说在一个单元中的一段控制结构（一个if语句，一段循环）的代码缩进。对模型来说，一项标准可能是使用一个长方形对类建模，一项风格指南可能是图中子类需要放在父类的下方。◆逐渐应用模式 高效的建模者会学习通用的架构模式、设计模式和分析模式，并适当的把它们应用在模型之中。然而，就像Martin Fowler在Is Design Dead中指出的那样，开发人员应当轻松的使用模式，逐渐的应用模式。这反映了简单的价值观。换言之，如果你猜测一个模式可能适用，你应当以这样的方式建模：先实现目前你需要的最小的范围，但你要为日后的重构留下伏笔。这样，你就以一种可能的最简单的方式实现了一个羽翼丰满的模式了。就是说，不要超出你的模型。举一个例子，在你的设计中，你发现有个地方适合使用GoF的Strategy模式，但这时候你只有两个算法要实现。最简单的方法莫过于把算法封装为单独的类，并建立操作，能够选择相应的算法，以及为算法传递相关的输入。这是Strategy模式的部分实现，但你埋下了伏笔，日后如有更多的算法要实现，你就可以重构你的设计。并没有必要因为Strategy模式需要，就建立所有的框架。这种方法使你能够轻松的使用模式。◆丢弃临时模型 你创建的大部分的模型都是临时使用的模型－－设计草图，低精度原型，索引卡片，可能架构/设计方案等等－－在它们完成了它们的目的之后就再不能提供更多的价值了。模型很快就变得无法和代码同步，这是正常的。你需要做出决定：如果“同步更新模型”的做法能够给你的项目增添价值的话，那就同步更新模型；或者，如果更新它们的投入将抵消它们能够提供的所有价值（即负收益），那就丢弃它们。◆合同模型要正式 在你的系统需要的信息资源为外部组织所控制的时候，例如数据库，旧有系统和信息服务，你就需要合同模型。一个合同模型需要双方都能同意，根据时间，根据需要相互改变。合同模型的例子有API的细节文档，存储形式描述，XML DTD或是描述共享数据库的物理数据模型。作为法律合同，合同模型通常都需要你投入重要资源来开发和维护，以确保它的正确、详细。你的目标是尽量使你系统的合同模型最少，这和XP的原则traveling light是一致的。注意你几乎总是需要电子工具来建立合同模型，因为这个模型是随时需要维护的。◆为交流建模 建模的次要原因是为了和团队之外的人交流或建立合同模型。因为有些模型是给团队之外的客户的，你需要投入时间，使用诸如文字处理器，画图工具包，甚至是那些“被广告吹得天花乱坠”的CASE工具来美化模型。◆为理解建模 建模的最重要的应用就是探索问题空间，以识别和分析系统的需求，或是比较和对照可能的设计选择方法，以识别可能满足需求的、最简单的解决方案。根据这项实践，你通产需要针对软件的某个方面建立小的、简单的图表，例如类的生命周期图，或屏幕顺序，这些图表通常在你完成目的（理解）之后就被丢弃。◆重用现有的资源 这是敏捷建模者能够利用的信息财富。例如，也许一些分析和设计模式适合应用到系统上去，也许你能够从现有的模型中获利，例如企业需求模型，业务过程模型，物理数据模型，甚至是描述你用户团体中的系统如何部署的模型。但是，尽管你常常搜索一些比较正确的模型，可事实是，在大多数组织中，这些模型要么就不存在，要么就已经过期了。◆非到万不得已不更新 你应当在你确实需要时才更新模型，就是说，当不更新模型造成的代价超出了更新模型所付出的代价的时候。使用这种方法，你会发现你更新模型的数量比以前少多了，因为事实就是，并不是那么完美的模型才能提供价值的。我家乡的街道图已经使用了5年了，5年我自己街道并没有改变位置，这张地图对我来说还是有用的。不错，我可以买一张新地图，地图是每年出一次的，但为什么要这么麻烦呢？缺少一些街道并没有让我痛苦到不得不投资买一份新地图。简单的说，当地图还管用的时候，每年花钱买新地图是没有任何意义的。为了保持模型、文档和源代码之间的同步，已经浪费了太多太多的时间和金钱了，而同步是不太可能做到的。时间和金钱投资到新的软件上不是更好吗？确实不错的主意以下的实践虽然没有包括在AM中，但是可以做为AM的一份补充：◆重构 这是一项编码实践。重构，就是通过小的变化，使你的代码支持新的功能，或使你的设计尽可能的简单。从AM的观点来看，这项实践可以保证你在编码时，你的设计干净、清楚。重构是XP的一个重要部分。◆测试优先设计 这是一项开发实践。在你开始编写你的业务代码之前，你要先考虑、编写你的测试案例。从AM的观点来看，这项实践强制要求你在写代码之前先通盘考虑你的设计，所以你不再需要细节设 计建模了。测试优先设计是XP的一个重要部分。敏捷开发名词详解 AM是一种态度，而不是一个说明性的过程。AM是敏捷建模者们坚持的价值观、敏捷建模者们相信的原则、敏捷建模者们应用的实践组成的集合。AM描述了一种建模的风格。当它应用于敏捷的环境中时，能够提高开发的质量和速度，同时能够避免过度简化和不切实际的期望。AM可不是开发的“食谱”，如果你寻觅的是一些细节的指导，如建立UML顺序图或是画出用户界面流图，你可以看看在建模Artifacts中列出的许多建模书籍，我特别推荐我的书The Object Primer 2/e(尽管这有失公允）。AM是对已有方法的补充，而不是一个完整的方法论。AM的主要焦点是在建模上，其次是文档。也就是说，AM技术在你的团队采用敏捷方法（例如eXtreme Programming，Dynamic Systems Development Method （DSDM），Crystal Clear）的基础上能够提高建模的效果。AM同样也可以用于那些传统过程（例如Unified Process），尽管这种过程较低的敏捷性会使得AM不会那么成功。AM是一种有效的共同工作的方法，能够满足Project Stakeholder的需要。敏捷开发者们和Project Stakeholder进行团队协作，他们轮流在系统开发中扮演着直接、主动的角色。在“敏捷”的字典中没有“我”这个单词。AM是有效的，而且也已开始有效。当你学习到更多的AM知识时，有件事对你来说可能不好接受，AM近乎无情的注重有效性。AM告诉你：要使你的 Project Stakeholder的投资最大化；当有清晰的目的以及需要了解受众的需要时要建立模型或文档；运用合适的工件来记录手头的情形；不论何时都尽可能创建简单的模型。AM不是灵丹妙药。敏捷建模是改进众多专家软件开发成果的有效技术，充其量也就是这样了。它并不是什么了不得的灵丹妙药，能够解决你开发中的所有问题。如果你努力的工作；如果你专注其上；如果打心眼儿里接受它的价值观、它的原则、它的实践；你就可以改进你做为一个开发人员的效果。AM是面向一般的开发人员的，但并不是要排斥有能力的人。AM的价值观、原则和实践都简单易懂，其中的很多内容，可能你都已经采用或期待多年了。应用AM技术并不是要你去练水上飘，但你需要有一些基本的软件开发技能。AM最难的就是它逼着你去学习更广泛的建模技术，这是个长期的、持续性的活动。学习建模在一开始可能很难，但你可以试着一次学习一样技术来完成你的学习。AM并不是要反对文档。文档的创建和维护都会增大项目涉众的投资。敏捷文档尽可能的简单，尽可能的小，目的只集中在和开发的系统有直接关系的事情上，充分了解受众的需要。AM也不是要反对CASE工具。敏捷建模者使用那些能够帮助开发人员提高效果，提升价值的工具。而且，他们还尽力使用那些能够胜任工作的最简单的工具。何时是敏捷的？要想了解AM，你需要了解模型和敏捷模型之间的区别。模型是一个抽象的概念，它描述了一个的问题的一个或多个方面，或是处理这个问题可能的解决方案。传统意义上，模型被认为是图表加上相应的文档。然而那不够直观的artifact，也可以被视为模型，例如CRC卡片集，单条或多条业务规则的文字描述，或是业务流程的一段结构化英文描述。一个敏捷模型就是一个刚刚足够好的模型。但是你怎么知道什么时候模型才是刚刚足够好呢？当敏捷模型显现出如下的特性时，它就是刚刚足够好的：敏捷模型实现了它们的目的。有时你为沟通而建模，或许你需要把你工作的范围告诉高级经理；有时你为理解而建模，或许你需要确定一个设计策略，实现一组Java类。一个敏捷模型是否足够好，要看它是不是满足了创建它时的初衷。敏捷模型是可理解的。敏捷模型要能为其预期听众所理解。使用用户能够理解的业务语言来描述需求模型，反之，技术架构模型则需要使用开发人员熟悉的技术术语。你所使用的建模符号会影响易懂性－－如果你的用户不了解UML用例图中的符号的含义，那用例图对用户就没有任何价值。这样的话，要么使用另一种方法，要么教授用户学习建模技术。风格问题同样也会影响易懂性，例如避免交叉线。杂乱的图表比清晰的图表难懂。模型的细节程度（见下文），也会影响易懂性，因为相较一个不那么详细的模型来说，一个过于详细的模型要难于理解。简单（见下文）同样是影响易懂性的一个因素。敏捷开发敏捷模型是足够正确的。模型通常都不需要100%正确，只要足够正确就行了。举个例子，如果一张街道地图漏画了一条街道，或是它标示某条街道是通行的，但你发现它已经关闭维修了，那你会不会扔掉你的地图开始在城里飙车犯罪呢？不太可能。你会考虑更新你的地图，你可能会拿出笔来自己做修改或是去当地的商店买一张最新版的地图（你原来的那张过期了）。也许你还是会接受那张虽不完美但仍可使用的地图，因为它对你来说已经足够好了。你还是可以用这张地图四处转转，因为它还是个正确的模型，标记出了大部分街道的位置。你在发现这张地图不正确的时候，你没有立刻扔掉它，原因是你根本不在乎它是否完美。类似的，当你在需求模型、数据模型中发现错误的时候，你也会选择更新或是接受－－虽不完美但已经足够好了。有些项目成员能够容忍这种不正确而有些则不能：这取决于项目的特性，每个团队成员的特性，组织的特性。充分正确性既和模型的听众有关，也和你要处理的问题有关。敏捷模型是足够一致的。一个敏捷模型并不需要和自己（或其它有用的artifact）保持完全的一致。如果一个用例在它的一个步骤中显式的调用了另一个用例，那么相应的用例图需要用UML的 <> 版型来标记这两个用例之间的关系。然而，你看了看图表，发现它们并没有这样做，天哪！用例和图之间不一致！危险！太危险了！红色警报！快逃命呀！等一下，你的用例模型是有不一致的地方，但也没到世界末日啊。是的，理想情况下，你的所有artifact最好是能够完全一致，但这通常是不可能的。当我开发一个简单的商用系统时，我通常都可以容忍部分的不一致。但有时我是不能容忍这种不一致的。最有力的佐证就是1999年 NASA发射火星太空探测器时采用了精密的测量系统。要树立一个观点，敏捷模型只要足够一致就行了，你通常不需要使用那么完美的模型。关于正确性和一致性，很明显要考虑权衡问题。如果你要维护一个artifact（我们称之为“保管”），随着时间的流逝，你需要投入资源来更新它。否则它很快会就会过期，对你就没用了。例如，我可以容忍一张地图标错了一两条街道，但是我绝对无法容忍一张地图中四分之三的街道都标错了。这就需要权衡了，进行足够的努力，保证artifact足够正确。过多不必要的努力反而会减缓项目的进度，而投入不足就没有办法保证artifact的有效性。敏捷模型有足够的细节。一张路线图并不需要标记出每条街道上的每栋房子。那会有太多的细节，使得地图难以使用。然而，在修路的时候，我想施工人员一定会有这条街道的详细地图，包括每幢建筑、下水道、电线盒等足够的细节，这样的地图才是有用的。但是这张地图并不用标记出每个院子和通向它们的路线。因为这样又太繁琐了。足够的细节和听众有关，也和他们使用模型的目的有关－－司机需要的是显示道路的地图，施工人员需要的是显示土木工程细节的地图。考虑一个架构模型，可能一组画在白板上的图表就足够了－－项目的进行中再对它们更新，也许你需要用CASE 工具来生成一些图表，也许这些图表还需要有详细的文档，这依赖于环境。不同的项目有不同的需要。在每一个例子中，实际上你都是在开发、维护一个有足够的细节的架构模型，只是这个“足够的细节”的概念和环境有关。敏捷模型能提供正面价值。对项目中的任一artifact，一个基本的要求是它们能够提供正面价值。一个架构模型给你的项目带来的价值是不是能够超过开发它、维护它（可选）的总成本？一个架构模型能够坚定你们团队为之努力的愿景，所以它当然是有价值的。但是，如果它的成本超过了这个价值，那就是说，它无法提供正面价值。投入100,000美元去开发一个详细的、重量级的文档化架构模型，而它的效用，只需一些画在白板上的图表就能够达到，这些图只需要花你 5,000美元，看看，这是多么轻率的做法。敏捷模型要尽可能的简单。只要能够达到目的，你应当努力让你的模型尽可能保持简单。模型的详细程度会影响简单性，而所使用的符号范围也会影响简单性。例如，UML的类图就包括了无数的符号，包括对象约束语言 (Object Constraint Language OCL) ，但大多数的图使用符号的一部分就能够完成。所以你常常不需要使用所有的符号，你可以限制自己使用符号的一个子集，当然，这个子集是足够让你完成工作的。因此呢，一个敏捷模型的定义就是一个实现它的目的，没有画蛇添足的模型；为你的预期听众所理解的模型；简单的模型；足够正确、足够一致、足够详细的模型；创建和维护它的投资能够给项目提供正面价值的模型。一个普遍的哲学问题是源代码是不是一个模型，更重要的，它是不是一个敏捷模型。如果你是在我们这篇文章之外问我这个问题，我会回答说，是，源代码是一个模型，虽然是一个高度细节化的模型，因为它是软件的一个抽象。同时我还认为，优秀的代码是一个敏捷模型。但在这里，我还需要把两者区分开来，源代码和敏捷模型还是有区别的——敏捷模型帮助你得到源代码。敏捷开发建模者 敏捷建模者的个性Alistair Cockburn指出：很多的方法学都定义了软件开发项目中开发人员所担任的角色，同时还定义各个角色执行的任务，尽管入席，这些方法并没有定义这些角色最适合的人选。一个人要想成功的担任某个角色，他应当很好的适应它－－虽然这并不需要人们掌握所有的技能，但人们必须要慢慢的熟悉这些技术。我的经验告诉我，要成为一个成功的敏捷建模者，下面的列出的个性是必要的：团队竞赛 第一点，也是最重要的一点，敏捷建模者总是积极的寻求协作，因为他们意识到他们不是万事通，他们需要不同的观点，这样才能做到最好。软件开发可不是游泳，单干是非常危险的。在敏捷的字典中没有“我”这个词。畅所欲言 敏捷建模者都有良好的沟通技巧－－他们能够表达出他们想法，能够倾听，能够主动获取反馈，并且能够把需要的写出来。脚踏实地 敏捷建模者应当脚踏实地 他们的精力都集中在满足用户的需求上，他们不会在模型上画蛇添足，即便那双足是多么的好看。他们满足于提供可能的方案中最简单的一种，当然，前提是要能够完成工作。好奇 敏捷建模者乐衷于研究问题，解决问题。凡是都问个为什么敏捷建模者看问题从不会至于表面，而是会打破沙锅问到底。他们从不会就想当然的认为一个产品或一项技术和它们的广告上说的那样，他们会自己试一试。实事求是敏捷建模者都非常的谦逊，他们从不认为自己是个万事通，所以他们会在建立好模型之后，用代码来小心的证明模型的正确。根据实验敏捷建模者应当愿意尝试新的方法，例如一项新的（或是已有的）建模技术。一般而言，他们也会接受敏捷建模开发技术，必要时，为了验证想法，他们愿意同传统的思想做斗争，例如在一个项目中减少文档数量。有纪律要坚持不懈的遵循敏捷建模的实践。对你来说，你可能会在不经意间说，“加上这个功能吧！无伤大雅。”或是，“我比project stakeholder更了解。”在AM的道路上要想不偏离方向，是需要一定的纪律性的。

咨询行业作为智力密集型的知识服务型产业，以专门的知识、信息、经验资源，针对不同的用户需求，提供解决某一问题的方案或决策建议，业务范围广，内容丰富。在管理上也有其独特的行业特点：业务过程中以项目为中心展开；知识密集，企业内部文件量大；合伙管理，结算管理方式不同；项目绩效、结算有各自的体系。……因此，咨询行业企业信息化管理，需要以“项目”为业务核心，以“人员”为管理基础。泛微OA系统以协同办公、移动办公为基础，为咨询行业搭建了满足项目管理、知识管理、合伙管理与结算、绩效提成核算以及报表分析等需求的综合办公平台。（咨询行业协同办公平台架构）>>一站式办公入口：通过建立统一门户，随时推送公司信息、通知通告以及个人待办相关，帮助快速进入工作状态。通过公司门户、个人门户、报表门户、项目门户等多样化门户，帮助咨询机构按照各员工职能权限和岗位需求快速聚合办公信息。并且在门户中建立统一项目管理模块，能够快速查询个人项目信息；通过报表门户，实时查看重要统计信息图表和自定义建模形成报表。（一站式特色门户）以项目为核心，全面覆盖咨询行业日常业务一、投标管理（投标管理流程架构）投标申请审批：当有投标商机时，可发起内部投标申请流程，经部门及公司领导审批是否投标。当投标申请流程归档后，投标项目信息自动归集到投标项目台账。投标项目台账展示所有投标项目，并且可快速查看、筛选、统计不同状态的投标项目。每个项目形成电子投标项目卡片，详细地展示了当前项目的投标保证金、履约保证金、投标费用信息。投标保证金：为了确保投标保证金支付规范和安全，需要通过流程进行申请审批和支付。投标保证金支付时通过关联投标项目，自动带出相关项目信息，不需要二次输入。流程申请通过之后，形成投标保证金支付申请台账记录。并可按照预计退回时间到期对经办人员和其领导进行提醒。中标项目移交申请：投标项目中标后通过中标项目移交流程，表单中关联了投标项目和基本的项目信息、投标保证金和履约保证金信息。流程归档后更新投标项目台账是否中标为已中标，此流程归档时自动将数据写入项目台账中。投标终止申请：当有其他原因需要终止投标时，可以通过投标终止申请流程处理；流程归档时自动将该投标项目是否中标状态更新为“终止”。二、项目全过程管理咨询公司项目管理过程包括项目立项、任务下达、任务执行反馈、报告编制阶段、成果审核用印、竣工验收、项目结算等内容。项目立项：投标项目通过中标移交流程完成项目的移交立项、非投标项目需要通过项目立项流程完成项目立项。开工申请：项目开工时通过项目开工申请表确认项目负责人，分配项目任务、确认任务内容、任务责任人、任务开始日期、完成日期，分配专家；流程审批后抄送到相应的项目负责人、任务负责人以及专家。验收申请：项目成果交付之后项目负责人可申请内部进行验收申请；验收申请时需要将相关的项目资料上传归档；流程审批完成后将自动更新项目状态为竣工验收阶段。项目结算：项目结算审批主要是处理公司和项目的结算，不同类型的项目可能结算比例有差异，项目结算类型有阶段结算和最终结算。当结算类型为最终结算时，流程归档自动变更该项目的状态为终止。奖金分配：通过最终结算的项目负责人可通过奖金分配流程申请项目提成结算，如果该项目涉及多个人的可对奖金进行分配。项目开票：经办人员可通过项目开票申请开具发票，流程归档后形成当前项目的开票记录。开票流程归档后自动更新项目台账中的已开票金额。项目回款：由财务每天将项目回款记录登记到系统中、回款记录会更新项目的已回款金额和项目余款金额。三、财务管理财务统计数据：自动展示每个项目的立项日期、合同金额、开票金额、回款金额、结算金额、项目余款等。通过数据汇集，可按照不同的检索组合条件查看汇总公司项目的合同总金额、开票总金额、回款总金额、结算总金额以及项目总余额。项目成本管理：由日常费用报销、差旅费报销流程归档自动将项目类成本费用转到项目成本管理台账。将成本管理设置到项目卡片页面拓展中，通过项目卡片点击即可看到当前项目的成本费用合计及明细信息。项目卡片基本信息页面展示项目信息：合同信息、开票信息、收款信息、成本管理、发票登记、成果管理、项目结算、内部结算记录四、评审专家库实现项目评审专家库电子化管理，每位专家的个人信息，如姓名、联系方式、单位、专业方向、职称等信息一一记录，从登记到备案形成专家库，随时方便调用。五、知识管理统一存储：整个办公平台使用一套数据库，文档统一存放、多级管理，分权查询，数据综合管理，快速复用。统一知识库：文档管理按类分管，系统自动收集。既可以手动创建知识、上传文档，系统会自动收集各应用中的文件、表单、数据，按体系存入知识库。知识报表：通过强大的报表引擎，图文并茂地展现了著者文档数量、部门文档数量、分部文档数量、文档目录报表、阅读日志报表。（知识报表）六、证照管理公司荣誉证书、财税证件、完税明细、审计报告等公司日常需要使用的证照文件统一管理，通过流程进行查阅、借用，根据流程流转自动在台账中更新证照状态，有留痕，效率高且安全。同时实现了相关证照电子化，员工可随时按照需求下载使用权限内的证照。咨询行业专业人员多、人员证件多，泛微OA系统将人员证件形成台账管理，方便查询及调取。（人员证件信息卡片）OA系统咨询行业特色功能应用价值泛微OA系统通过建立一整套涵盖业务开拓与办理，投标管理、项目管理、合同管理、专家库管理、成本费用管理、项目结算管理、奖金分配管理等业务场景与应用的协同办公管控平台，全方位提升内部管理水平。

什么是敏捷？（Agile）从本质上讲，敏捷（Agile）并不是开发方法，而是一种理念。对于项目管理而言，敏捷是一个全新的术语，敏捷强调在软件研发过程中持续性的根据用户反馈和需求优先级来发布新版本，不断进行迭代，让产品逐渐完善。在数十年前，瀑布式项目管理是软件研发的主流方法，在研发过程中，团队成员将会花大把的时间和精力在项目前期去收集资源和信息，然后基于这些去做产品设想和研发规划。到了70年代，有先觉的研发人员发现瀑布式研发不仅在执行中各处受限，研发速度还很慢，显然Out了。尤其到了90年代末期，开始出现黑客来捣乱，这就意味着前功尽弃、全部推倒重来，这简直是研发的噩梦。相比瀑布基于线性、可预测性地去开发产品，研发人员更想要能够灵活管理用户反馈、Bug和需求的方法。这也就是敏捷方法出来以后受欢迎的原因。另外，你也可以通过这个视频学习什么是敏捷（Agile）在2001年，17位研发人员共同探讨出了《敏捷宣言》这份文档，阐述了他们对于软件研发的看法。文中他们定义了敏捷开发需要遵守的四项价值观我将之总结为：以人为本：重视个体间的合作互动目标导向：我们最终交付的是“可使用的软件”，而不是一堆繁重的文档客户为先：理解客户需求，与客户合作拥抱改变：客户会在不断变化需求的过程中明晰真正需要的，因此敏捷需要拥抱变化尽管如此，这四项价值观并不意味着我们就该放弃工具、文档和计划。因为它们对研发结果依然有非常重要的价值，只是相比之下，我们应该关注更核心的事物：人、产品模型、协作和迭代。为了让这四项原则变得简单易懂好执行，他们又将写了敏捷开发12项原则作为指导：我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。业务人员和开发人员必须相互合作，项目中的每一天都不例外。激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。可工作的软件是进度的首要度量标准。敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。以简洁为本，它是极力减少不必要工作量的艺术。最好的架构、需求和设计出自自组织团队。团队定期地反思如何能提高成效，并依此调整自身的举止表现。如果我们把这些原则和遇到的问题对号入座，很快我们就会发现，这12项原则正是对应了客户期望。比如，客户不会关心开发文档写的怎么样，他们更感兴趣交付的成品能干什么；他们不在意你的开发计划，他们希望你能立马交付；昨天他们想要修个BUG，而不是等到下次版本更新。我们总会遇到需求多样化的客户，而这时，敏捷能够确保你在研发过程中始终将用户需求作为核心。怎么知道敏捷（Agile）和团队成员是否三观相合敏捷虽然听起来光鲜亮丽，但不是所有项目都能用敏捷来做。敏捷在公司里投入使用后可能与预想的结果背道而驰。敏捷意味着快速推进项目，也就是说并不是所有事情都是按部就班。因此，我们得知道在这种快速变化的环境下，团队是否能够适应变化。所以在我们部署使用敏捷前，先来点前戏试试看。在使用前，我们可以先问自己5个问题：1.你是否会愿意接手目标不明确的项目？敏捷项目管理中有句话叫做：快速失败。比如我们接手了一个连最终产出都不明确的项目，首先我们会先交付最小模型产品，这时我们得做好被质疑的准备。毕竟没人知道要做出怎么样的产品，所以我们的最小模型的产品很可能是个怪胎。在与客户反复测试后，我们会才会逐步了解他们的真实需求，这时候我们离成功又近了一步。2.你会如何规避项目风险？就像我们前面提到的，敏捷提倡不断从犯错中积累学习并持续迭代。如果我们走老路，用传统项目管理的方法来推进的话，我们会要承担更大的风险。当然就算我们开始敏捷之后，也要准备好随时响应未知问题。3.你的团队能有多灵活？作为项目经理，我们的责任是和客户一起把产品做的更好。这么做很可能和设计、研发、其他成员的想法背道而驰。这时我们需要找主心骨聊一聊，是否愿意放下老套路，根据用户需求来调整想法、重新规划方向。4.公司阶层制度严格吗？敏捷的其中一项原则不仅是和用户一起工作，研发成员的身份也会发生变化。你们公司的文化开放吗？是否能接受扁平和开放的管理方法？5.你怎么衡量进度？怎么定义成功？用敏捷来管理项目能够帮我们逐渐进步的同时也督促我们将产品做得更好。如果因为突发灵感而放弃正在执行的任务，那么敏捷将毫无意义。我们先花些时间来看看团队是怎么看待进步和成功。然后再来看我们是不是离最终目标一步步的更近了？研发团队如何使用敏捷读到这儿，我想你已经跃跃欲试，准备踏上敏捷之路了。敏捷非常注重节奏，当你有多个任务要交付，团队更需要注重节奏的把握。而身为项目经理，我们的职责是让整个团队通过协作最终交付产品。敏捷是不断规划、执行、学习和迭代的过程，敏捷项目通常可以分解为一下7步：第1步：通过战略会议定义你的愿景每当开始新项目时，第一件要做的事情是定义产品的业务需求，或者说想要达到的愿景。事实上，我们只需要回答一个问题：你为什么想要做这个产品。这是我们心中的蓝图，时时提醒我们不要跑偏。作为一家产品公司，定义愿景的最佳方法之一是电梯演讲：用于：（哪部分目标客户）需求：（用户的需求）类别：（我的产品是哪种类型）功能：（产品的价值、客户为什么选我们）竞品：（主要的竞争对手有哪些）差异化：（和竞品的差异化描述）即使我们做的不是软件产品，我们也可以根据项目的目标来调整上述内容。战略会议的参与角色都有谁？此时我们要让更多人认同这个项目，所以很多关键的利益相关者自然不能缺席，包括相关主管、经理、主任和产品经理。战略会议该什么时候召开？项目开始前我们就该来开战略会，或者至少每年一次的定期会议来保证愿景依然不过时战略会议要召开多久？这个就由你主观来决定了，一般来讲，花4-16小时来探讨战略已经足够了。第2步：绘制产品路线图当我们开完战略会后，就该轮到产品经理把愿景变成产品路线图。产品路线图能帮助我们纵观全局、理清思路，让我们有宽松的时间来开发每个产品需求。“宽松”并不是说我们可以花数天或是数周的时间来推进每步计划，而是轻量级的去定义产品、理清需求优先级和粗略估算产品每个需求的时间。项目管理专家Roman Pichler认为：目标导向的产品线路图能够聚焦于目标和产出结果（比如：获客、增加活跃度、满足客户需求）。而产品特性来自于这些目标，所以我们在制定目标时应谨慎，每个目标对应3-5个产品特征。而每个目标，我们需要包含5个关键信息：时间、名称、目标、产品特征和衡量标准，有了这些，我们就能清楚知道哪些该做、什么时候算做成功了以及我们如何取得了成功。产品线路图谁来画？当然是产品经理，但我们也该听听其他利益相关者的想法，比如：客户、市场、销售、支持和研发团队的代表。产品路线图什么时候来画？路线图自然是要在开始实施迭代之前，当然最好是能在战略会后就着手开始。绘制产品路线图要多久？尽早实施，不是在前期纠结。虽然线路图看起来有点纸上谈兵，但当你的路线图能涵盖所有的目标时，我们也会更有信心去做好。第3步：制定发布计划当我们有了战略和计划，下一步我们就可以暂定几个时间节点。这个阶段产品经理要严格按照计划发布新版本。我们也不用担心功能不齐全的问题，敏捷项目都会有多次发布的过程，所以我们只要优先发布核心功能的版本即可。举例来说，你的项目要在11月交付，而你可能在2月初就已经做好了最小模型，打算在5月左右发布完整版。这些时间节点的安排都将由你的项目难度和每次迭代时长（或者说每次达成目标需要的工作时长）决定。通常每次发布新版本都需要经历3-5次迭代。谁来制定发布计划？产品经理、项目经理和所有团队成员都该来参与其中。当然，邀请少数利益相关者来加入其中也是对其他成员的鼓励，让团队能够尽早开始。发布计划什么时候来做？越早越好，你的发布计划应该在确认新产品后的第一天开始制定。在随后的每个季度中至少记录一次。制定发布计划要多久？一般来说会需要4-8小时，实际时长由具体情况决定，但不能因为它拖进度。第4步：制定迭代（Sprint）计划迭代（Sprints），我将其理解为通过短期研发完成具体任务来达到目标的一个过程，也是帮助产品经理和研发团队逐渐切入项目细节的方法。通常情况下，每次迭代大约要花费1-4周。具体的时长我们需要根据团队过往的表现情况来制定，同时尽量保持每次迭代的时长相同。哪些角色参与制定迭代计划？迭代是整个团队的活，因此，产品经理、项目经理以及其他所有成员都该积极参与其中，表达自己的声音和想法。迭代计划什么时候来制定？在每次迭代周期开始前，我们就需要做好迭代计划。比如说，你的计划是每周迭代，那么就你就需要在每周一（或者你选好的某一天）告诉其他人迭代计划。制定迭代计划要多久？迭代计划是迭代周期的基石，虽然如此，我们也不要在这上面浪费过多的时间，通常2-4小时足够了。写好了迭代计划也就意味着我们已经踏上了正轨。第5步：每日站会在每次迭代过程中我们需要有时间来确认项目组没有遇到阻碍，同时保证能准时完成既定目标。这时候我们就需要使用每日站会。每日站会，如同字面意思一样通俗易懂，每天花15分钟左右的时间来讨论下面3件事：昨天我完成了哪些事情今天我打算做哪些事情我有遇到哪些问题，如何解决或许讨论这3件事，可能让团队的一部分人的脸挂不住。但这对推动敏捷项目管理的沟通有积极意义。敏捷之所以能够跨团队协作，主要依靠的就是团队快速响应和有让成员发声表达的空间。第6步：迭代（Sprint）结束了？那就进入评审阶段吧如果迭代中一切顺利，那么迭代周期结束后，我们需要来检测下软件的功能。我们可以借评审的机会来向团队成员和利益相关者展示成果。作为产品经理，你对产品功能有选择的权利。如果有哪步错误，尝试多问几个为什么？下次迭代时我该怎么调整才能让团队达成目标？敏捷是不断学习和迭代的过程，你的流程管控和最终产出也是同一道理。哪些角色参与评审？团队全员和利益相关者都应该参加迭代评审会来确认项目进度和表达他们的观点。什么时候执行评审？每次迭代结束后就可以开始。评审阶段要多长久？无需特意去准备PPT、功能说明，审查会最多1-2小时就够了。第7步：下一步？迭代（Sprint）回顾总结为了让敏捷项目管理能顺利运作，我们在每个阶段结束后需要知道下一步要做什么。这是我们在迭代回顾阶段要做的事。当迭代和审查结束后，接下来该去决定下次要做哪些工作。我们需要回顾下，在迭代中是否发生了些事情改变了你的既定时间，甚至是项目愿景。谁来参加回顾总结会议？回顾总结是审查的延伸，这时利益相关者离开也没有关系，而其他团队成员则加入其中，给出自己的意见。什么时候来做？当然最好是在审查阶段结束后，立刻开始迭代回顾总结。这会花多长时间来做？概括下来大概几个词：简短明了、甜蜜温馨，最多花1-2小时来总结和大致规划下次计划。整个过程都结束了，接下来干啥？这时候我们可以选择发布新版本、获取用户反馈、规划新功能或者修复bug。持续性的发布、学习、再建，这一系列过程让敏捷在管理方法中异军突起。比起单纯的靠产品需求清单来执行项目，在敏捷指导下，我们可以通过不断发布新版本来看看客户的反馈。相比花一年时间来开发和发布，然后发现缺失核心功能的传统方法，敏捷能在每次迭代后迅速发现问题，并在下次迭代中及时调整。如何实施敏捷方法：Scrum和看板我想此时你已经跃跃欲试想把敏捷带给团队。但还有重要的一步，正如我们前面所说的，敏捷是项目管理的全新理念。为了能更好的执行，有些人研究出了一些敏捷方法。这些方法相似度很高，但从实施的角度来看，两者各有不同：ScrumScrum应该是最广为人知的敏捷方法，与看板并驾齐驱。其受欢迎的原因归功于操作简单、高效以及极高的可复制性。你可以观看这个7分钟视频，学习如何使用Scrum。我们来看下Scrum的工作原理：在Scrum中，产品经理和项目团队紧密协作，一起定义目标、梳理产品需求清单。清单中通常会包含产品特性、修复bug、非必要功能需求以及其他要在交付时完成的工作。有了产品清单，产品经理就会开始确定需求优先级，研发团队通常会在接下来30天左右的迭代中产出“潜在可交付版本”。当研发团队制定了迭代清单后，除了团队成员外，任何人都不能再加入需求。当一轮迭代完成后，全员再次分析需求清单、划分需求优先级，然后进入下一轮迭代。看板（Kanban）看板作为敏捷方法的一种，提倡化繁为简，不让研发团队超负荷工作。因此它和Scrum有一定相似，都强调持续性交付，这个视频解释了看板管理项目的原理。当然看板也会有自己的三原则：1.工作流可视化当项目逐渐复杂的时候，看板工具用“白板”帮我们理清所有项目的进度和归属：代办、进行中、已完成，洞悉项目的关联信息，让事情逐步变得简单清晰。2.WIP原则WIP类似于Scrum的迭代清单，一旦制定后就不再加入新的需求（研发团队除外），团队需要依靠看板来了解他们在每次迭代具体的任务量。3.明确规划下一步为了更好的实施看板，我们需要知道下一个任务是什么。这也就意味着我们需要实时更新产品需求，重新确定需求优先级。实施敏捷管理最后的建议恭喜！你现在应该已经学会了敏捷的概念，和如何实施敏捷开发的方法，现在可以再自己的团队内推广了。但是值得提醒的是，由于敏捷开发中涉及到大量的计划、开发任务管理、时间进度和负责人，你需要使用一个项目管理工具，让整个管理过程更可控。一个项目管理工具可以这样帮助你做好敏捷开发：1.进度报告：你可以看到还有多人任务等待完成、有多少延期任务2.沟通：让每个人反馈任务中遇到的问题和进展3.分配：项目下的任务应该支持分配到具体的负责人转载自：明道云

引言：在“DevOps能力之屋（Capabilities House of DevOps）”中，华为云DevCloud提出（工程方法+最佳实践+生态）×工具平台=DevOps能力。华为云DevCloud将推出“DevOps on DevCloud”系列，针对DevOps领域场景，阐述该场景在华为云DevCloud上的实施方法与实践。本文阐述了企业A在实施DevOps过程中，如何一步步采用华为云DevOps平台。此客户成功故事，希望为采用DevOps平台的企业提供借鉴。为行文阅读，本文中企业A将以第一人称（“我”或者“我们”）来进行阐述。目前，在产品团队的不断努力下，从第一次接触华为云DevCloud开始，现在我们终于拥有了优雅、全面的一站式DevOps解决方案，团队成员不必再费心劳力地使用和维护多种工具及版本。然而回首过去，我们的DevOps持续交付流水线，就像大多数公司和开源项目一样，有很多混杂的产品、服务和脚本，都松松散散勉强一起使用。同时来自不同公司的不同DevOps工具并不总是能够很好地兼容，情况越发复杂。简而言之，我们有很多工作要做，但最终，我们决定要统一工具的行为和目标。采用华为云DevCloud，我们经历了6个关键阶段。我们希望这会给通往DevOps涅槃路上的企业提供帮助。第一步：找到你的痛点也许，对于大多数的企业，包括我们自己，DevOps转型的最大动力往往来自于“火烧屁股”，主动转型多数时候是奢谈。正如微软Donovan Brown在谈论到DevOps时经常说：“找到最伤人的东西，围绕它去做很多很多的事儿，使它越来越好，直到它不再伤人。”这也成为我们的座右铭。如果你打算采用DevOps，并且正在考虑使用DevCloud，那么首先审视一下自己：在我们的DevOps流水线中，最痛苦的事情是什么？没有足够的单元测试？部署新版本太多手工操作导致容易出错？即使你已经到达了DevOps的顶峰，即使你的发布是可以一键部署，你仍然可能在生产中中断某件事情。然而，你会发现你没有合适的工具来告诉你错在哪里；也许是某些事情遇到了瓶颈，或者只是没有按预期的方式工作。因此，让我们找出这些痛点并从那里开始。    第二步：源代码版本控制 “代码”作为软件研发的核心产物，因而源代码版本控制是DevOps的基石。在DevOps异地协同上，集中式的SVN远不如分布式Git，因此，很多公司（包括我们自己）将代码从SVN迁移到Git上。这样，你可以使用华为云DevCloud的代码托管服务。华为云DevCloud也提供了迁移指南通过工具或者脚本来帮助企业进行迁移，大大简化了相关工作。当然，如果你采用Git，应该充分意识：No Pains，No Gains。对于新手来讲，Git需要一个巨大的学习曲线，合并、推送、拉取，变基等很多操作有一点儿复杂。这儿有一个很好的建议，当你开始使用Git时，可以像对待以前的版本管理系统一样对待它，如果你把你所知道的相关知识转义一下应用到Git上，你就可以摆脱初始学习的困境了。对于其他复杂的操作，随着时间的推移，你将开始适应它，水到渠成地学会使用那些强大的功能。现在整个行业最近都在迅速采用Git，但愿你不会迟到。Git有一个真正具有变革意义的杀手级功能——轻量级分支。Git创建分支的本质只是只是创建一个指针。当然选用哪种分支模型（GitFlow、Gitlab Flow、GitHub Flow或者自定义flow），产品团队需要考虑团队生产力和个人生产力之间的平衡。建议从成熟的flow模型开始。第三步：任务管理任务管理是产品团队除了源代码版本控制外必须做好另一个基础工作。我们一直在使用业界某主流敏捷项目管理工具T。我们非常喜欢它的简单，在看板的工作跟踪时，只有“未完成”、“进行中”、“已完成”等3个状态。但是随着研发需求的增加，简单的状态跟踪无法满足我的需求。此外，我在拿到客户需求的初期，希望对产品做一个需求规划，让团队可以按照发布或迭代进行需求拆解。DevCloud的项目管理服务解决了这些痛点，例如思维导图可视化按层级进行需求规划、标准的Scrum方法、可以自定义工作项状态。当然这意味着你失去了简单明了的方式。                                             图1 在Scrum板视图中查看工作项状态    归根结底，你可以选择你钟爱的工具，例如至为简洁的敏捷项目管理工具T，它可以工作得很好，但是你将丢失可追溯性。而华为云DevCloud可以帮你在DevOps方面做得更多，例如需求工作项与代码提交的关联，需求工作项与测试用例和缺陷的关联等。第四步：拥抱CI/CD在使用华为云DevCloud前，我们使用的是某主流工具C。它实际上是一个非常好的持续集成产品，它提供On Premises与SaaS版本。使用DevCloud编译构建服务的一个好处是构建启动的速度变得飞快。对于工具C，每当我们需要一个新的构建时，就会提供一个VM，这可能需要5到10分钟。这个前置时间太久，变得很烦人。而华为云DevCloud拥有了一个热的、随时可以在云中构建的机器池，所以只要有人提交一个新的提交，构建就会立即发生。    以前，我们的部署过程是手动的，我们需要运行一堆批处理脚本。而使用DevCloud流水线是一种乐趣，它不仅仅可以支持一键全自动部署，将变更投入生产，而且提供了完美的可视化编排，可以将构建、部署、自动化测试等纳管起来，并根据实际需要定制多级流水线，加入质量门禁、人工审核等控制。第五步：Bug跟踪在此之前，我们使用Excel对Bug进行跟踪，随着团队人数的增加，分清Excel版本已经足够让我们头疼了。使用了DevCloud之后，简直给我们的工作带来了不可思议的改变。首先，Bug跟踪在早例会的直观展示。当我们开早会时，将Scrum缺陷跟踪板投屏，可以通过过滤筛选每个成员手中的Bug状态和等级，便于识别风险。其次，Bug跟踪与需求、测试的关联。DevCloud中基于需求创建测试用例，测试用例失败生产Bug，实现了需求-测试用例-缺陷双向关联。最后，多维度的Bug统计。在DevCloud统计报表中，预置了多种Bug统计报表，用户也可以根据自己的需要自定义统计报表。                 图2 在DevCloud预置的缺陷统计模板第六步：定制DevCloud适应项目需求不要陷入DevCloud希望你工作的方式中。如果有众多不同的状态，比如批准、已提交、已解决、已验证，请不要盲目屈从于产品对敏捷或Scrum的定义或者那些对你不起作用的东西。先问问自己什么是可能起作用的最简单的事情，然后在DevCloud上开展工作。最为重要的是，不要因为DevCloud产品经理想的太多而强迫自己过度思考，无所适从。自定义相对比较简单，因为DevCloud提供了工作项字段、模板、状态流转等的可定制性。你可以用它来增加东西，但你也可以用它来减轻东西。所以，把对你没有意义的东西拿走，只保持最低限度。你只需把它作为一个工具来了解你的团队在做什么，并传达优先事项，保持它的简洁与实用。采用华为云DevCloud最重要的是，它作为一个全面的解决方案所带来的聚集效应。你可以选择只使用其中的部分服务，然而如果你选择使用尽可能多的服务，你将发现令人震惊的积极变化。当然，这并非没有困难，一蹴而就。DevOps转型面临不同层面的变革，从改变企业文化，到整个组织的新的工具平台的投资，到团队成员的知识与技能水平。但请相信，这确实是一个短期痛苦、长期收益的改变！全面的解决方案无疑会是一个赢家。一旦我们采用了一体化工具平台，向我们的客户交付软件就变得更容易、更自动化，甚至是一个很好的体验。无论如何，采用华为云DevCloud会失去什么呢？我相信无论只使用部分服务，还是全部服务，它只会给你带来更多的业务效益，以及高效的交付体验。作者：伦语春秋  莫妮卡

#include <stdio.h>int main() {    int flag;    char input[15];    flag = 1;    scanf("%s", input);    int len = strlen(input);    if (len == 1) {        if (input[0] == '9') printf("11\n");        else printf("%d\n", input[0] - 48 + 1);    } else {        for (int i = 0; i < len; i++)            if (input[i] != '9') {                flag = 0;                break;            }        if (flag) {            for (int i = 0; i < len + 1; i++)                if (i == 0 || i == len)                    printf("1");                else                    printf("0");            printf("\n");        } else {            if (len % 2) {                int mid = len / 2;                input[mid] += 1;                if (input[mid] == 58) {                    input[mid] = '0';                    input[mid - 1] += 1;                    input[mid + 1] += 1;                    for (int i = mid + 1; i <= len - 1; i++) {                        if (input[i] == 58) {                            input[i] = '0';                            input[i + 1] += 1;                        }                        if (input[len - 1 - i] == 58) {                            input[len - i - 1] = '0';                            input[len - i - 2] += 1;                        }                    }                }            } else {                int mid = len / 2;                input[mid] += 1;                input[mid - 1] += 1;                for (int i = mid; i <= len - 1; i++) {                    if (input[i] == 58) {                        input[i + 1] += 1;                        input[i] = '0';                    }                    if (input[len - 1 - i] == 58) {                        input[len - 2 - i] += 1;                        input[len - i - 1] = '0';                    }                }            }            printf("%s\n", input);        }    }    return 0;}知乎@C语言编程俱乐部这个，困扰了我一整个学期的魔鬼，分享给大家!

引言：在“DevOps能力之屋（CapabilitiesHouse of DevOps）”中，华为云DevCloud提出（工程方法+最佳实践+生态）×工具平台=DevOps能力。华为云DevCloud将推出“DevOps on DevCloud”系列，针对DevOps领域场景，阐述该场景在华为云DevCloud上的实施方法与实践。在敏捷项目中，用户故事（User Story）是产品团队用来描述用户需求的主要方式。每个用户故事是小的、独立的行为，最好可以在一个迭代中增量式实现，并为最终用户提供价值。Bill Wake提出的INVEST模型，描述了良好的用户故事应该具备的特征，是用户故事应该遵循的原则：•     Independent：独立性•     Negotiable：可协商性•     Valuable：有价值•     Estimable：可估算性•     Small：短小•     Testable：可测试性将业务特性分解成为符合INVEST模型的用户故事，成为每一个敏捷团队的必备技能。LeffingWell在《Agile SoftwareRequirements 》一书中提出了分解故事的10种方法：•     Workflow steps•     Business rulevariations•     Major effort•     Simple/complex•     Variations in data•     Data entry methods•     Deferred systemqualities•     Operations •     Use-case scenarios•     Break-out spike不少人经常会说分解用户故事在增量式开发中既是艺术性又是科学性工作。敏捷产品团队可以参照10种方法进行故事分解，并使之尽量符合INVEST原则。然而敏捷产品团队如何在软件交付中记录故事分解方法，以更好地分享方法或者事后回顾改进或者统计分析呢？当然比较好的方式是采用敏捷项目管理工具，例如华为云DevCloud的项目管理（ProjectMan）。在华为云DevCloud的项目管理中Story并没有缺省字段来记录分解方法，因此需要通过“Story设置”特性来自定义此字段。用户可以在项目中通过“设置”-“项目设置”-“Story设置”-“字段与模板”进入工作项模板页面，如图所示：在工作项模板页面，点击“编辑模板”，并在字段配置处点击“+新建字段”，在下图中输入字段名称、字段类型以及字段选项等。将工作项模板编辑后进行保存。新建字段“故事分解方法”这样，在新建Story或者编辑Story的时候，团队成员可以记录故事分解方法。如下图所示在Story中记录故事分解方法随着敏捷项目的迭代进行，产品团队将不断积累此项目的故事分解方法，团队成员可以基于此数据进行分享与学习，将局部的、隐性的分解方法变为了全局的、显性的分解方法。这也正是DevOps三步法（Three Ways）在持续学习与实验中提倡的实践之一“将局部知识转化为全局知识”。一旦在项目迭代开发过程中，团队积累了故事分解方法的过程数据，那么团队可以在适当的实际进行相应的统计分析。对于故事分解方法的统计分析，目前华为云DevCloud的项目管理的自定义报表特性尚未提供基于自定义字段的维度分析，产品团队可以使用工作项导出特性，将Story导出到Excel进行统计分析，发现分解方法的一些规律，可以指导产品团队更好地有重点地提升分解能力。

【参赛须知】使用华为云App Cube新型开发平台，0代码基础的小白也能无压力体验一个全能APP的诞生！（本次赛题提供手把手操作指南，提供样例代码）【赛事背景】       山东省是全国啤酒产量最大的省份，天气逐渐热起来，啤酒的需求量在持续增加，各烧烤店、酒吧、大排档等店铺啤酒是不可缺少的饮品；啤酒的及时供给，有助于提升食品领域的消费能力，为促进经济的恢复贡献一份力；特别是新鲜可口的生啤，需要尽快配送到店铺里面；华为云DevCloud聚焦啤酒预约、配送管理系统的开发与配送需求，邀请开发者为提高啤酒配送效率贡献一份力量，给逐渐炎热的天气送去一份清凉。 【赛道二报名】本次大赛2个赛道分开报名，可以同时参加竞赛，2倍获奖机会！1、赛道二报名地址：https://competition.huaweicloud.com/information/1000041230/introduction（一定要报名才行！）2、报名时间：6月1日9:00~9月30日23:593、提交作品时间：9月10日 00:00 ~9:月30日 23:59前重要！参与前，请确保已报名加入活动群（大赛qq群：见下方）活动小助手微信号：HorizonDPService）【赛题详情】本赛道包含主赛题与附加题两个环节，主赛题+附加题1+附加题2=总分，排名按照总分高低排序。请见报名地址 赛题详情部分：https://competition.huaweicloud.com/information/1000041230/circumstance。【应用效果体验】1. 啤酒需求方体验下单购买的二维码：                                                                                2. 啤酒供应方与啤酒物流方体验说明表1 啤酒供应方体验通道说明用户名/密码体验url备注supplierUser/Xiao_1204supplierUser1/Xiao_1204https://cas.e.huawei.com/cas/login?service=https%3a%2f%2fstudio.e.huawei.com%2fbaas%2fauth%2fv1.0%2fsso%3fredirect_url%3dhttps%253a%252f%252fstudio.e.huawei.com%252fapp%252fportal.html啤酒供应方只能看见啤酒供应方的菜单表2 啤酒物流方体验通道说明用户名/密码体验url备注deliverUser/Xiao_1204deliverUser1/Xiao_1204https://cas.e.huawei.com/cas/login?service=https%3a%2f%2fstudio.e.huawei.com%2fbaas%2fauth%2fv1.0%2fsso%3fredirect_url%3dhttps%253a%252f%252fstudio.e.huawei.com%252fapp%252fportal.html啤酒物流方只能看见啤酒物流方的菜单登录时，遇到此图请忽略。3. 啤酒供应方将生成一个啤酒供需数字化管理监控大屏：表3 啤酒供需数字化管理监控大屏---体验url备注https://studio.e.huawei.com/magno/render/DVBeerMgtDMAX172550dd7e2_0000000000Wgees5R7LN直接单击URL就可以查看    【评分说明】主赛题+附加题1+附加题2 = 总分请见 报名地址 链接中的 赛题详情部分：https://competition.huaweicloud.com/information/1000041230/circumstance【提交说明】请见 报名地址 链接中的 赛题详情部分：https://competition.huaweicloud.com/information/1000041230/circumstance【奖项说明】【交流互动】大赛官方交流请在本论坛发帖或QQ**群或微信咨询。~~~~~~~还有什么不清楚的快来咨询我们的小助手哟，加小助手微信 ~~~         

如何结合企业业务实际去提升项目管理效率，有没有详细案例？