工作一年了，我一直希望让自己每年对开发的理解更深入一层。谈轮了自己对各种开发技术的理解，这一年来，虽然对那些理概念的有所加强，但还不够深刻。希望能够多多学习《敏捷开发》的流程。
如果想让开发在公司的项目中发挥出它最大的价值，并不是招两个开发技术高手，或引入几个前端技术，而是使用开发前端技术对项目流程的渗透，以及开发与测试流程的改进与完善。虽然，当然前端行业前景乐观，许多中小企业也都在引入前端，但一百个公司就有一百种前端的想法，每个公司对前端的看法不同，公司对前端的定位也不完全一样。如移动前端，web前端，小程序前端。
这几天整理思路，回顾了前端工作的流程与架构。
简陋的前端流程
专职前端人员，相信一两个前端的公司还是不少的，入职后各种项目都在进行当中，而通过指派任务的方式。
下面是简陋的流程图：
需求分析与架构设计：
我们做的是某一移动公司内部使用的项目，需求分析与架构全部由项目经理完成，之后由项目经理给具体某个开发人员分配任务，具体对某个功能模块的实现。这个对项目经理的经验与技术要求很高，他既然担任了需求分析师，又担任架构师的角色。
程序员编码：
因为我们开发语言用的是JAVA 和vue框架语言，IDE用myeclipse和vscode 中自带的CVS版本管理工具，开发人员完成代码后，提交到版本库中。
前端写法：
笔者入职后的第一个任务是将页面全部画出来，然后跟各个开发确认好字段，并且在swageer上写好备注，jira上写清楚每个字段的意思接口地址等。后来正明效果并不好，因为对于一个六七人的开发团队项目，开发人员更喜欢人员能当面反馈，这样更能提高效率。对一个小bug 通过当面交流的方式就可以将问题修复。
对于当时的环境，并没有测试线。开发人员在本机上将项目进行部署运行。直接通过局域网访问开发人员的机子进行访问。这也是一个致命的缺点。因为开发人员使用的电脑存在太多不稳定性，一会儿就改内容改字段。
上线：
经过测试人员测试通过后，开发人员部署上线。
流程分析：
这个流程唯一的优点，就是能快速的发现并修复问题。
缺点就非常多了，相信许多小软件公司也有类似的流程。
这个流程中，项目经理是核心，项目经理也确实是有多年开发与项目经验的牛人，他喜欢不定期分享上些前沿的技术。我很崇拜他。
对于前端来说，需求很不明确，文档也是可有可无的产物，没有需求文档，或非常简陋，根据需求文档根本无法编写页面。笔者只能收集一些常见的页面样式，如登录、文件上传下载、列表翻页、日期选择、输入框验证、搜索等有一些“通用型”样式，以便在开发过程中做参考。
规范的开发测试流程
想了解真正的开发和测试在公作中如何进行的，开发和测试就应有自己的团队，专业的流程。
现在的逐步完善开发测试流程：
需求分析：
需求分析由产品人员制定，他们要做的不是一份简单的文档，而是细化每一个功能的细节，每一个按钮的位置，对于稍大或复杂一点的需求都进行建模。
需求评审：
这里会叫上所有参与项目人员进行，开发人员、测试人员。全员提出需求，开发人员考虑功能实现的方案与可行性。
开发人员编写排期：
开发人员需求根据需求功能点进行排期。然后将开计划转交给测试人员。
提交基线：
开发人员完成所有功能后，会对自己的功能进行一个自测。自测完成后提交测试人员进行基线。
具体测试流程：
开发人员对于基到测试线的功能进行测式，发现的问题通过缺陷管理工具进行反馈，开发人员对问题进行修复，然后，准备第二轮基。
测试通过：
经过两到三轮或四轮的测试后，直到没发现新的问题，或暂时无法解决，或不紧急的问题。通过上级确认，可以通过。编写测试报告与验收方案。
流程分析：
对于刚接触这个流程的我来说，这个流程是规范的，真正融入了整个流程，而且还担任了很重的角色，从而也有效的保证了软件产品的整体质量。
敏捷开发流程
下面来看敏捷开发，对敏捷要多花时间学习与研究。希望能够多多研究。
前面讲的第一种流程，还是第二种流程都是瀑布式的，严格来说第一种简陋的都不能称为瀑布式，对于一个三个月的项目说，产品把需求分析完了给开发，然后产品就没事儿了；开发开发完成之后给测试，然后开发人员也不忙了。测试完成之后上线。那么在产品分析的阶段，开发和测试都是没事干的（这里只对单一项目）。开发阶段，产品和测试也基本没事儿。同样在测试阶段，产品与开发也是没什么事儿的。
敏捷开发的一个核心是迭代，在每个时间点上，所有项目人员都是有事可做的。
1、下面是我理解中的敏捷开发流程图：
第一阶段：
通过上面的流程图，对于一个月的需求分析，在敏捷中，可能三五天就确定下来。这个需求定得会很模糊，但整体框架确定。产品对其中某一模块功能确认，开发人员开始对确认的功能编码，开发人员编码的过程中，测试进行功能分解，因为根据模糊的需求很难写出具体的用例，所以，只能尽量对功能进行分析得细些，标注需要验证的内容。
第二阶段：
开发完成后交给测试人员进行测试，开发人员继续开发新的功能。但开发进度并没有因为测试而停止。
流程分析：
在这个流程中弱化了文档，强调了各个人员的沟通，通过这种迭代的方式，三个月的项目，可以能两个月和两个半月就会完成。
但这种流程并非完美，加入一个功能在需求分析阶段就是错误的，因为它是一个迭代渐进的过程。也只能一路错下去。
2、对测试出现bug问题的处理-jira
第一块面板中是开发人员未实现的功能，第二块面板中是开发完成功能，测试人员对其进行测试，发现不通过的就放回未开发的面板中，测试通过的将放到第三块面板中。
需要说明的是，敏捷测试在国外很流程，在内容，雷声大雨点小，推行的人很多，真正有公司引入的不多。我们所在公司千差万别，开发流程也可能有很大的不同。对于已经工作两年一个前端技术来说，从来没关注过开发与测试流程结构应该是个悲剧。我希望不被思想局限，所以，努力冲破一个又一个的局限。