软件项目定义
项目团队通过一定技能、方法及工具，在预期时间实现期望特性集合的产品或服务的交付。
团队成员、交付时间、地点、交付对象等都是独一无二的，连呼吸的空气都不一样，因此软件项目具有独特性，需要因人而异、因地制宜的管理，没有“银弹”，需要基于情景选择合适的开发管理策略，制定适用的开发体系。不可简单的移植一套高大上开发管理体系，当作圣经推广，这些技巧、方法、工具在一处实践成功，换一个土壤或许就不灵了，不是这套开发管理体系有问题，而是环境变了缺少支撑维持这套体系持续有效运行的必要营养供给，好比橘生南为橘，橘生北为枳，南橘北枳。因此软件项目开发体系需要根据企业所在环境、企业本身文化、项目团队素质、软件项目特性、客户方要求等因素或约束综合考量，评估选取一个和自身匹配的开发体系，不求最好，但求合适。在这个过程，我们可以吸取失败项目的教训，成功项目的经验。借助外界力量，站在巨人肩膀思考。开发模式的选取上，见下图不同模式的差异：
不同开发模式生命周期
成功交付一个软件项目需要怎么做？
一次软件项目交付，我们比喻一艏在海洋行驶至彼岸的船，在指定时间运载指定货物到达指定地点，船长掌舵，规划线路图，检查航向如有脱离正轨，需要及时纠正，船上水手各司其职向执行船长命令，反馈结果。航行过程，未知的暗礁，不确定的狂风暴雨随时来临，面对这些风险，需要在线路图中考虑应对措施。
成功软件项目需要一个坚实的基础设施奠定基础。软件最终交付最核心的是代码，如何保障代码生成、存储、使用、发布整个流程即高效又省时省力？代码编写选择什么工具，轻量级的还是重量级的，统一还是个性化自主选择，根据软件规模、企业文化、团队人员习惯视情况而定。代码的存储是分开还是统一，统一存储是一定必要的，分开存储非常不利于团队协作，今天小明代码覆盖小红代码，明天小红覆盖小明代码，恢复代码又要花费时间和精力，早已计划好的约会又要泡汤。发布使用冲突不断，就如步入雷区，一不小心雷声响起，下次在哪里踩雷还不知道，紧张无奈，日复一日，周而复始。如何避免这些雷区？项目之初就要构建这些基础实施，选择一款代码管理软件，支持协同编码，代码合并，差异分析等。在此基础上引入一款持续构建编译、测试、部署工具，实现代码自动构建，自动测试运行。引入问题跟踪管理工具，问题及特性登记到关闭有迹可循。谁在什么时候提出什么特性&问题，现在状态如何，是否接收、是否已处理，什么时候处理，在那个版本已发布等这些信息形成闭环管理。避免出现此类情况，一位很贴心的客户追问XX特性为什么实现还在还没有实现，好久前就提出了，你觉得无理取闹，在你的问题跟踪白板上都没有看到有这个需求，答应最近一个版本实现，最后各自带有怨气不欢而散。经过团队加班加点这个特性很快上线发布，但是经历这件事情，客户也没以往那么贴心了。因此把团队成员精力集中在软件实现上，尽量减少此类代码上沟通协作事宜，把它们交给工具去实现吧。磨刀不误砍柴工，君欲善其事必先利其器。
基础设施搭建好了，就需配备一个好船长掌舵，确保航向正确，不翻船，最终行至到目的地。软件项目就需配备一名技术经理，带领团队在承若时间交付承若产品。技术经理统筹规范定制开发流程、技术规范、项目制度，同时为团队成员保驾护航。技术经理确保团队成员理解并能贯彻执行这些条条框框的规定，需要在制定的时候让团队成员参与设计和讨论，形成大家都认可，或是保留意见的成文规定，而不是自上而下，一纸文件下来，要求团队遵守执行的命令。避免上有政策下有对策的局面，最后是各种理由借口，落不到实处，成为形式主义。
怎样的流程规范才是合适？
技术经理通过团队任务清单管理软件实现特性，任务清单是软性需要实现的特性集合，并且有严格的优先级划分，交付时间点，实现人员。优先级的划分来源依据和客户及上级经理商讨。任务清单是公开透明，团队成员随时可查看，避免是技术经理个人的时间安排游戏。个人任务清单来源于团队任务清单，优先级由技术经理定，始终和团队任务清单优先级保持一致。好比大家同在一条船上，船开向哪里由船长掌舵，听船长的，万众一心，目标一致，不要东西南北方向各自按自己想象去划。
如何确认大家处理正确的航行轨道，没有偏离轨道？
每日例会，每人简短发言，听取大家当前正在做什么，遇到什么困难?如有偏离，能及时发现并予纠正。对于团队新人通过这种方式加强和团队的沟通互动，可以针对性的提供帮助和指导，对于闲不住的好好先生，知道他动向，又做了哪些任务清单不相干的事情，给予制止，安排更多的任务。
代码审查，安排团队高级成员每日或周定期对少量代码审查，发现代码问题，防患于未然，对项目新人起指导作用，加快融入团队速度，对于好好先生也是一种监察，看是否又动了不该动的代码。所有代码修改都必须是跟任务清单相关的，如果一定要重构修改的代码，也要在任务清单安排，再分配到个人任务清单。
代码变更通知，每天自动发送代码变更内容到团队成员，大家对于变动内容了如指掌，那块内容谁又进行了修改，哪些代码实现特性，之前已有人实现，可以提醒拿来复用，谁好久没有提交代码了。起到警醒和督察作用。
软件落地如何推进？
曳光弹开发方法，以终为始，以目标为导向，做的事情是否直至目标，射出的子弹有迹可循，与目标是可视化关联。从业务端到端维度，带领团队成员基于系统伸缩性、扩展性、并发量等角度，规划系统对象。比如划分客户端、web服务器端、数据逻辑处理端、数据访问端、数据库；对系统对象进行定义，明确各个对象边界，编写各端对象接口模型；填充接口实现功能代码；接口通信互通。
项目开发过程尽量让客户参与，当作自家孩子一样培养。一起制定回顾项目任务清单内容及优先级，听取客户意见是否有新的特性加入，定期演示系统成果，让上级及客户放心，相信在项目在承若时间能交付承若产品。客户参与好处是尽早提出软件由价值特性，避免在项目后期或验收时提出，永远要相信唯一不变的就是变化，不要担心客户不断提出新的特性会增加项目负担，任务清单也是可以变化的，加一个优先级高的，可以适当降低一个任务优先级嘛。换个角度来讲客户什么都不提，说明没有期望，爹不疼娘不爱，蒙头拉车，到头来做出的东西被一竿子打死，更惨。
网友评论