中国式软件开发思路是什么样的呢？

菏泽炫佑科技

中国式软件开发思路是什么样的呢？

在软件工程领域，出现了多种软件开发模型，如瀑布模型、快速原型模型、增量模型、螺旋模型、演化模型、喷泉模型、RAD模型、敏捷软件开发模型、XP极限模型等。 这些模型都有各自的应用场景和适用范围，但我认为*实用的开发模型是敏捷软件开发。

什么是中国式的软件开发？ 从我接触过的大部分软件项目来看，它们基本上都有一个共同的特点——一定要快。 客户不耐烦，想今天开始项目，明天叫你拿出产品。

面对企业和客户如此快节奏的需求，我们有什么解决方案吗？ 人们从生产和生活中总结出一套高效、高质量的开发模式——敏捷软件开发。

1.什么是敏捷软件开发？

敏捷开发以用户需求的演化为核心，采用迭代、分步的方式进行软件开发。 在敏捷开发中，软件项目在建设初期被划分为多个子项目，每个子项目的结果经过测试并具有可视化、可集成、可运行的特点。 也就是说，将一个大项目分成多个相互关联、可以独立运行的小项目，分别完成，实现快速开发。

2. 敏捷开发是如何实施的？ 1. 将大系统拆分为子项目

过去我们接受的观念是，立项之后，首先要进行需求调研和分析。 研究结束后，我们会出具各种研究报告和需求说明书。 需求确定后，我们将进行概要设计（UE设计、UI设计、交互设计、数据库设计、框架设计）。 ），轮廓设计完成后再进行详细设计……这样的周期太长了。 当进度进入下一阶段时，当上一阶段出现问题时，将会影响到整个项目流程的各个阶段。

敏捷方法将一个大系统拆分为一个子项目，然后将子系统拆分为子模块，*大限度地减少模块之间的耦合，增加模块之间的内聚性。 这样，我们就可以将团队分成多个组，每个组可以同时工作。 另外，当某个模块的需求发生变化时，对其他模块的影响不会太大，从而降低开发难度。

在前面提到的房地产信息网络平台建设中，我们将系统拆分为自交易、经纪交易、用户权限管理、建委等对外接口、大宗资产、交易管理、平台后台管理等模块，和网站前端。 需求讨论。 需求讨论后，每个模块被拆分为对象。 信息仅通过公共变量在对象之间传输，以尽量减少与外部对象的关系。

简介： 将他们打成碎片，然后一一击败。

2. 团队与客户同在

为了降低沟通成本，我们团队所有成员直接前往客户现场，随时与客户沟通。 通过面对面的沟通，可以减少误会。

在项目的各个阶段，我们始终与客户保持密切联系，随时沟通。 通过这种方法可以立即获取需求，立即解决问题，减少出错的可能性，提高开发效率，保证开发质量。

而且这样会更容易获得客户的信任，客户可以随时了解项目的工作状态和进展情况。 当彼此之间建立了信任关系时软件开发，剩下的工作就会变得更容易、更愉快。

在房地产项目中，我们在客户现场工作并定期举行会议来讨论需求和设计。 当出现一些小的不确定性时，团队成员会直接去找客户的相关人员确认。 在整个项目周期中，需求没有发生重大变化。

总结：与客户面对面沟通，降低沟通成本，促进相互信任。

3. 使用建模进行沟通

使用模型与客户沟通，使用模型获取用户需求，而不是通过大量文档。 写文档费时费力，而且效果也不好。 其实我们大多数人都不喜欢花大量的时间看各种文字和参数，模型会更加直观和立体。 我这里所说的模型不仅仅指我们平时设计的原型。 它包括用例图、类图、部署图、状态图、活动图、包图、对象图、原型图、渲染图、ER图等，用不同的图形表达产品的不同维度，使产品丰富和三维的。

在房地产项目中，我们用原型与客户讨论需求，用ER图沟通数据库设计，用类图表达产品对象，用部署图确定硬件部署环境和网络结构，用活动图说明信息交互过程，并使用序列图来表达沿着时间轴的对象之间的交互。 通过各种图表来表达产品更加直观，发现错误时也易于修改。 与使用文档不同，修改不方便，维护困难，不利于阅读和理解。

总结：使用模型代替文档进行交流。

4. 敢于迎接变化

市场环境是产品的风向标，我们必须时刻关注市场。 为了迎合市场，产品也必须随时变化。

需求变化、设计变化……各种各样的变化让我们焦虑，但作为产品人，我们也应该接受变化。 只有产品快速变革，才能很好地迎来未来。

我们欢迎变化，只要是合理的，即使在开发阶段，需求也可能发生变化。

敏捷开发允许变化，并通过变化为客户带来更大的竞争力。 敏捷开发使用图表来记录需求，所有代码都采用模块化设计中国式软件开发思路是什么样的呢？，尽可能分离不同的功能，减少相关性。 这就是为什么它能够并且敢于拥抱变革。

提到敏捷的一个很重要的思想就是“勇于拥抱变化”。

有人说，你一定没有技术背景。 那些从事技术工作的人讨论变革。 *后允许的是修改某些要求。 产品经理在与技术人员沟通的时候，谈到一个复杂的操作时，经常会说：“你确定不修改吗？如果你确定需求不变，我就去做！”，你就得同意，然后再找另一个人进行技术改造时，就等于堵住了自己的退路。

事实上，怎么可能不需要修改呢？ 我们做产品不总是要接受市场的考验吗？

在海上航行时，当风向发生变化时，我们的大船必须时刻做好调头、调整的准备。 改变本身就是为了适应。 没有改变就意味着没有进步。

但作为产品经理，我们能做的就是用自己的智慧和敏锐的市场洞察力，尽力感知风向，尽可能地掌控需求，在需求发现的前期进行充分的研究。

害怕改变并不是解决问题的办法。 我们必须在项目前期制定灵活、可调整的计划。 如果需求真的改变了怎么办？ 这就是敏捷思维。 谁能阻止需求的变化？

5. 尽早并持续交付运营阶段性结果

我之前说过，一个项目的失败一般不是因为技术原因，而大多是因为客户对我们失去了信任。 我们需要持续不断地给予客户信任感。 一是我们在客户现场不断沟通，让客户感受到我们的热情。 同样，我们需要尽早、持续地为客户提供相应的结果（可运营的产品），让客户看到我们的能力。

当然，这样做的另一个好处是可以及早暴露问题。 别像个小女人一样害羞不敢见人。 只有提前暴露，才能早点解决。 问题越晚暴露，就越难解决。

在房地产项目中，当日完成的内容编译成功后，修改后的功能将部署到平台服务器上，以便客户随时看到变化，了解项目进度。 如果有什么问题，可以**时间暴露出来。

总结：为了降低项目风险，尽早交付可运行的程序

6. 面对面沟通

*快的沟通方式是面对面的沟通。 在敏捷开发中，*推荐的方式是减少冗余、低效的通信方式，采用*快的方式直接通信。 让技术人员、设计师、客户等所有团队成员共同努力，减少信息交流的中断，让沟通更加顺畅。

在房地产项目中，当你有不明白的问题需要沟通时，你总是直接来找我。 如果我有什么不懂的，我就直接去找客户。 当我不在的时候，同事也会直接和客户沟通，任何人都可以直接得到需求。

总结：直接沟通，减少中间环节

7. 可用的软件是首要标准

无论产生多少文档或中间产品，结果都不会清晰。 客户*关注的不是中间产品，而是产品。 对于敏捷软件开发来说，可工作的软件是评价开发进度的*重要标准。 唱得再好，也不如唱得好。 做事一定要踏实。 脚踏实地、脚踏实地，是敏捷开发的核心。 别耍花招。

总结：制作可交付的软件是项目的核心

8、保持恒定的发展速度

项目开发是一个长跑。 短期内快速加速并不是长跑的方法。 我们要持续不断、匀速奔跑，保证队员能够坚持到*后。 敏捷开发提供了可持续的开发速度，不仅可以防止团队成员疲劳，还有助于制定项目开发进度、控制开发周期。

总结：项目开发过程是一场长跑，不要从头开始冲刺

9、定期团队优化

每隔一段时间进行团队建设，进行批评与自我批评，找出工作中存在的问题和影响个人和团队发展的瓶颈。 我们通过沟通和交流发现团队和成员之间的问题，然后进行自我调整。 通过对自身团队的不断优化和升级，打造一支能战斗的团队。

总结：

如果项目经理能够善用敏捷开发思想，就相当于在游戏世界中拥有了法宝，在美食世界中掌握了烹饪方法。

敏捷开发还有很多其他的想法，但其中一些我不太同意。 例如，使用“测试驱动开发”在中国和国外是不同的。 国外有CMMI，测试要求非常高。 测试实际上就是质量。 检验部门和品管部门权威较高，对测试人员有更多的尊重和认可。

在中国，企业重开发，轻测试。 你可以从你公司的测试人员和开发人员的工资中看出谁更受重视。 让测试人员驱动开发在目前的现状下有些难以实现。

有时候我想，前人总结了那么多好的想法，我们确实应该多学、多看、多用。 然而，我们使用的想法并不一定适用。 每个想法都有自己的成长土壤。 不仅仅是多施肥多浇水就能长出好庄稼。 有时候，我们也需要看看植物的习性是否更适合我们的环境。

本文*初由@飞鹰长空 发表，人人都是产品经理。 未经许可禁止转载。

题图来自，基于CC0协议

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等