青岛软件开发流程总结
青岛软件开发流程总结
一、序言：心得体会
“软件即服务”，第一次看到这句话是来自Pual Graham，这也是我对软件行业最基本的认知。在经历了一些项目的沉沉浮浮之后，在反思和自省中度过了一段艰难的时光，反反复复地，我在思考一个问题：我们应该遵循什么样的软件开发流程。从甲方到乙方，从外企到民企，从大到小，从国内到国外，经历了各式各样的项目之后，我试图写下这篇外包软件开发流程的总结，以便今后再遇到相关业务时，可以有一些参考。
二、从计划开始
“计划总是会失效，但还是要做计划。”巴顿将军关于计划的断论是我对计划在项目开发中的基本理解，在一个项目从启动开始，一定要有计划。
谁谁谁，什么时间做什么事情，运用什么方法完成，这些问题的答案的详细程度基本上将会决定这个项目今后是否会失控，或者有多少程度的失控。详细的计划还有一个非常重要的作用，就是要求我们自己去做足够深入的调研。在过去的很多时间里，我受到一种思想的影响很深，就是“先做起来，然后再解决问题。”对，就是这样想法让我舍弃了很多前期的调研和计划安排。不是说这个想法不对，而是这个想法有它适应的范围。当我们开发一个周期可能长达数月的项目的时候，这个想法可不管用；而且更糟的是：在一条错误的路上走的越远，就会离目标更远。
所以，一定要做足够的前期调研然后拿出计划来。详细的计划是衡量项目调研是否充足的指标。
计划，在出发之前。
三、设计先行
现代的软件开发，尤其是像我们可能接触到的项目，基本上都是工程师完成，包括前端、后端的实现。所以这里的设计不仅仅是界面、logo、配色的设计，而且包括了流程、事件行为、数据存储的设计，是整个产品的设计。
在实际项目经验中，我们遇到的最大的问题无疑是飘渺不定的需求。的确，有些时候，有些需求只有到做好了才会发现那不是我们想要的，这种现象我们承认，也乐意接受。但反过来，明确的设计方案，尤其是和客户协商敲定后的设计方案，可以规避掉绝大部分的需求问题，可以节省后期90%以上的开发成本，也让工程师的心情愉悦很多啊！
软件开发，设计先行。
四、测试覆盖
我从没有见过一个程序员可以在没有测试覆盖的时候，面对需要不段更新的产品写出完美的代码。因为程序员也只不过是凡人。现在的产品一定是会不断变化的，尤其我们也不愿意去做一杆子的买卖，我们希望产品可以复制，可以伸展，然后转卖给更多的用户。所以，需求的变化是必然的，很多时候我们为了赶时间，忽略了测试用例的开发，其实是很危险的。至少基本功本的测试用例还是必要的，慢下来，把测试写一写，实际上可能会更快。
一个拥有操作界面前端的产品，需要必要的功能测试覆盖；后端的代码应该也有必要的功能覆盖以及单元测试覆盖；有测试环境的测试，也有实际环境的测试；有重要功能的测试，也有细节的测试——而测试用例，也许就是那个让程序员改完代码依然很有安全感的护身符吧。
测试用例，慢就是快。
五、客户适当参与
“闭门造车”这个词语用在我们过去的经验上是合适的，但这是不对的。因为归根到底，客户才是那个最后使用软件。很多时候，我们开发、开发，最后项目失控了，很大程度是因为在前期调研以及设计的时候出现了偏差，但这中间不乏原因，其中最可能的就是“客户完全不知道自己想要什么”。很多客户并不具备相关的经验或者知识，他就是想要那个东西，当我们的设计被认可的时候，我们也许以为这事儿敲定了，但实际上不是，太多客户喜欢拍着脑袋说要这个要那个。真是令人头疼。
的确，客户会提出一些很无理的、很幼稚的想法，但这其实是我们应该解决的问题：如何让客户明白软件开发。客户经理应该做的事情就是一方面及时地将开发进度展现给客户，另一方面要做到如何简约自己的开发资源。
让客户适当，这个“适当”是一门艺术吧，原则上我们希望对客户坦诚，但另一方面我们又必须保障自己的合理利益。乙方的产品经理必须兼顾双方的利益。“修改设计、锁定设计、重新开发，再次交付”这样的流程是比较合适的，同时，作为软件开发者，应该教育客户软件开发的成本是昂贵的，以此来约束客户无理的要求。
客户应该“适当”参与。
六、结束语
青岛软件开发流程，是复杂的，虽然没有万能的银弹，但至少良好的流程会有很大的帮助，值得我们不断总结提高。计划、设计、定稿、开发、测试、修改、交付，这样的软件开发流程就是我目前认为比较合适我们的方案，我们尽量按照这样的流程走，可以提高我们的效率还有心情。
一、序言：心得体会
“软件即服务”，第一次看到这句话是来自Pual Graham，这也是我对软件行业最基本的认知。在经历了一些项目的沉沉浮浮之后，在反思和自省中度过了一段艰难的时光，反反复复地，我在思考一个问题：我们应该遵循什么样的软件开发流程。从甲方到乙方，从外企到民企，从大到小，从国内到国外，经历了各式各样的项目之后，我试图写下这篇外包软件开发流程的总结，以便今后再遇到相关业务时，可以有一些参考。
二、从计划开始
“计划总是会失效，但还是要做计划。”巴顿将军关于计划的断论是我对计划在项目开发中的基本理解，在一个项目从启动开始，一定要有计划。
谁谁谁，什么时间做什么事情，运用什么方法完成，这些问题的答案的详细程度基本上将会决定这个项目今后是否会失控，或者有多少程度的失控。详细的计划还有一个非常重要的作用，就是要求我们自己去做足够深入的调研。在过去的很多时间里，我受到一种思想的影响很深，就是“先做起来，然后再解决问题。”对，就是这样想法让我舍弃了很多前期的调研和计划安排。不是说这个想法不对，而是这个想法有它适应的范围。当我们开发一个周期可能长达数月的项目的时候，这个想法可不管用；而且更糟的是：在一条错误的路上走的越远，就会离目标更远。
所以，一定要做足够的前期调研然后拿出计划来。详细的计划是衡量项目调研是否充足的指标。
计划，在出发之前。
三、设计先行
现代的软件开发，尤其是像我们可能接触到的项目，基本上都是工程师完成，包括前端、后端的实现。所以这里的设计不仅仅是界面、logo、配色的设计，而且包括了流程、事件行为、数据存储的设计，是整个产品的设计。
在实际项目经验中，我们遇到的最大的问题无疑是飘渺不定的需求。的确，有些时候，有些需求只有到做好了才会发现那不是我们想要的，这种现象我们承认，也乐意接受。但反过来，明确的设计方案，尤其是和客户协商敲定后的设计方案，可以规避掉绝大部分的需求问题，可以节省后期90%以上的开发成本，也让工程师的心情愉悦很多啊！
软件开发，设计先行。
四、测试覆盖
我从没有见过一个程序员可以在没有测试覆盖的时候，面对需要不段更新的产品写出完美的代码。因为程序员也只不过是凡人。现在的产品一定是会不断变化的，尤其我们也不愿意去做一杆子的买卖，我们希望产品可以复制，可以伸展，然后转卖给更多的用户。所以，需求的变化是必然的，很多时候我们为了赶时间，忽略了测试用例的开发，其实是很危险的。至少基本功本的测试用例还是必要的，慢下来，把测试写一写，实际上可能会更快。
一个拥有操作界面前端的产品，需要必要的功能测试覆盖；后端的代码应该也有必要的功能覆盖以及单元测试覆盖；有测试环境的测试，也有实际环境的测试；有重要功能的测试，也有细节的测试——而测试用例，也许就是那个让程序员改完代码依然很有安全感的护身符吧。
测试用例，慢就是快。
五、客户适当参与
“闭门造车”这个词语用在我们过去的经验上是合适的，但这是不对的。因为归根到底，客户才是那个最后使用软件。很多时候，我们开发、开发，最后项目失控了，很大程度是因为在前期调研以及设计的时候出现了偏差，但这中间不乏原因，其中最可能的就是“客户完全不知道自己想要什么”。很多客户并不具备相关的经验或者知识，他就是想要那个东西，当我们的设计被认可的时候，我们也许以为这事儿敲定了，但实际上不是，太多客户喜欢拍着脑袋说要这个要那个。真是令人头疼。
的确，客户会提出一些很无理的、很幼稚的想法，但这其实是我们应该解决的问题：如何让客户明白软件开发。客户经理应该做的事情就是一方面及时地将开发进度展现给客户，另一方面要做到如何简约自己的开发资源。
让客户适当，这个“适当”是一门艺术吧，原则上我们希望对客户坦诚，但另一方面我们又必须保障自己的合理利益。乙方的产品经理必须兼顾双方的利益。“修改设计、锁定设计、重新开发，再次交付”这样的流程是比较合适的，同时，作为软件开发者，应该教育客户软件开发的成本是昂贵的，以此来约束客户无理的要求。
客户应该“适当”参与。
六、结束语
青岛软件开发流程，是复杂的，虽然没有万能的银弹，但至少良好的流程会有很大的帮助，值得我们不断总结提高。计划、设计、定稿、开发、测试、修改、交付，这样的软件开发流程就是我目前认为比较合适我们的方案，我们尽量按照这样的流程走，可以提高我们的效率还有心情。
想要了解更多详情欢迎来电咨询18678812288，或登陆网址www.zzydkj.net。联系人：王经理。
