0x01 ：序言
I am a slow walker,
but I never walk backwards.
那些细碎而美好的存在不会消失，
记忆里自己还是温暖的模样；
向着阳光，踮起足弓，
跌跌撞撞的坚强，
磕磕绊绊的成长；
——致以BugPhobia团队的Alaph阶段软件开发
0x02 ：前端的开发历程纲要和敏捷思想
To the world,you maybe a person.
But to a person,you maybe the world.
在团队项目的整体架构中，在第一轮迭代的开发前的需求分析和调研阶段自己就反复思考自己的定位，试图在“Django后端结构-Semantic UI前端结构-系统环境”中定位中确定自己的分工，或许自己更倾向于团队本身的前端工作和设计工作，因此在敏捷开发的过程中自己完全经历从零基础的HTML入手到Semantic UI的前端实现；这里也简要分享自己的一些心得和感受，将敏捷开发过程中的前端学习部分简要概述出来。
ü HTML，本身作为超文本标记语言，其实和MarkDown这种轻量级的标记语言的入门过程非常相似，首先不得不承认自己对HTML和CSS的认识尚处于浑沦吞枣、邯郸学步的阶段，因此，在敏捷开发的初期阶段，必然会遭遇学习成本和工作进度相冲突的矛盾状况，这里首先要保证敏捷开发的交流高效性和高昂学习成本的消化。因此，在开发的矛盾冲突状况，应当善用浏览器的开发者模式，去阅读大量的源代码并复制粘贴到本地琢磨它的布局安排，同时强烈推荐Firefox浏览器的3D Inspector功能，能够清晰地观察到网页本身的“搭积木”式的设计方案，在实践的过程中也缩减了大量的时间。同时，HTML和CSS的学习需求可以暂时确定为能够充分理解源代码的具体含义，和html页面的基本的结构快，至少在敏捷开发的起始3天内达到这一程度是非常重要的，而这也使得后续自己实现前端时能够缩减大量时间
ü 在能够阅读清楚HTML和CSS的基础上，视敏捷开发的需求而定，开始逐步掌握javascript的嵌入方式和本身逻辑；因为笔者本身曾接触过，因此在javascript代码的阅读逻辑上节省了大量时间，而在第一轮迭代中采用的jQuery库在前端的实现过程中较少出现，主要集中在前后端链接时需要封装的特定事件处理、AJAX交互，因此在初始的开发中可以以简短的学习形式记录；但在第二轮迭代中，由于此次BugPhobia团队在第二轮迭代中将重点围绕前后端的对接进行开发，因此此jQuery库本身的一些特性还是需要理解，保证前后端对接时不会“找不到北”（捂脸逃跑）
ü Semantic UI框架，这里不得不承认它在敏捷开发中的便利性，高度语义化的框架，使得实现时能够充分用接近自然语言的语法去实现，缩减了大量的学习成本。这里借用《No Silver Bullet》中的经典论据，高级语言不必关心底层的实现而只需在抽象且更接近人类思维的层次去设计软件，而合理运用“处理常见功能的库、框架或者可重用的代码”是值得鼓励的行为。因为，框架本身所带来的不仅是精炼的成本，更重要的是新鲜的设计思想和动力。其实就像之前和GNU_Linuxer（http://www.cnblogs.com/fzyz999）“结对”编程时吐槽的一样，即便具备“优秀”的框架，前端实现的工作也不是单纯的复制和粘贴（否则，如果真的按照“代码行数”衡量工作量的话，我做的第一件事就是把编译后的“html”提交，目测行数可以爆表，捂脸），仅从个人的理解中，Semantic UI中有两点强调的设计思想，网格/模块化布局和响应式布局，两者在一定程度上是项目呼应的。在传统的设计中，由于设备多样从而必须本身搭建不同的“前端”以满足不同的需求，而在初期设计和实现时合理的排版将使得网页本身在其他平台也能展示得非常精彩。而第二轮迭代中，不同于第一轮迭代，前端的优化将重点集中于响应式布局的理念（http://semantic-ui.com/examples/responsive.html），因此需要重点把握此部分的学习过程
0x0304：前端工作的团队理解
其实经过前端开发的阶段，在前端实现和设计后期，陷入了短暂的低谷期，前端不是独立工作的部分，高昂的交流成本将大量缩减后期调试和修改的巨大损失，因此谨将此部分展示于同样采用Semantic UI框架做敏捷开发的前端少年。在敏捷开发中，前端工作不只是简单的复制粘贴，不只是照着原型图临摹的攻城狮。在敏捷开发（Agile methodologies）中，极限编程方法更强调面对面的沟通，前端和后端的充分交流，前端和设计的充分调整，前端和用户体验的充分交流都是必要的部分。因此，谨将此部分致以继承此项目的前端开发人员，愿困惑和纠结能不再缘起傲慢。
|
ü 敏捷开发是适应性比预见性更重要：这里从架构和前端的开发角度讨论这一点恰验证敏捷开发的重要思想。因为单纯从架构的角度选用复用度较高、稳定性较强的框架使得开发本身的适应性大幅增强，对于急剧的需求更改，后端本身能够通过Django架构本身的优势设置一定的STA，使得大量的代码工作精炼，而减轻一部分附加属性，从而保证高效的适应性 ü SCRUM方法论：实际上，团队本身的SCRUM进展较为顺利，因为在交流中和编程中都做出了一定“结对编程”的措施，使得团队本身能快速完成进度沟通，而小范围的频繁讨论也使得开发过程中各部分均能依据“交流-完成-复审-测试”的流程逐步进行 ü 敏捷开发是以人为本：因为敏捷开发过程每个人都能围绕各自的工作展开讨论和监督，同时也能依据需求的更变或其他对项目中的其他人进行进度预警等提醒工作，因此全员参与敏捷开发的管理工作在一定程度上也使得开发进度本身逐步趋向积极态 |
0x030404：前端和后端的充分交流
|
前端只需完成原型图的实现，而将样例的Demo直接交付后端人员去处理 |
|
这里必须充分强调前端和后端的对接的过程，在初期的前后端设计文档都间接忽视了最重要的“数据对接”过程，在团队项目的前期，由于后端架构和本地系统的配置学习成本极其高昂，因此前后端共同协议由前端和设计人员直接完成Demo的例图，只把“前端认为的”应该包含的数据设计出来即可，因此造成了“暴力丑学”的设计和后端数据完全无法在前端很好的展示出来。这里借用下图的图1和图2的对比来充分说明这一情况（这里实际情况并未同对比图展示的如此严重，但前后端因为类似的问题都进行了修改，进度整体拖延1-2天，因此为了更强烈展示此问题的严重性，笔者对原型图做出了一定的修改）。因此，在第二轮迭代中，首先要在一定程度上通过结对编程的方式加深前后端的耦合，虽说前后端的分离开发将大幅提高开发效率，但数据脱节这种严重问题，如果在初期能够有充分的设计，将大幅减少后期的调试工作。在第二轮迭代中，将首先由前后端同时发布类似E-R图的前端设计和后端数据结构，降低前后端对接的工作难度。 |
图1 暴力丑学的设计和后端数据无从利用的尴尬场景
图2 后端设计的数据结构能够充分通过前端展示出来
0x030408：前端和设计的充分交流
|
设计是设计，前端实现人员是我的“傀儡”，他必须按照我的设计方案去尽可能真实的还原 |
|
的确抱歉，在阐释问题时不应夹杂“傀儡”这类个人情绪的词汇，导致读到这里的你可能非常明显地观察到笔者本身的态度。这里首先简单展示正规公司中前端实现人员和设计人员的区别：前端实现人员强调逻辑、线性思考和层次，而可能最担心和害怕的是手腕关节综合症和EPS文件；设计人员强调直觉、创造力和想象，而可能最担心和害怕的是PERL语言和“客户”的修改意见（冷笑话捂脸）。 但请注意我这里的措辞，设计并非天马行空的涂鸦，是讲究一定规范的“创造”。优秀的设计将大幅降低前端实现人员的工作量，特别是响应式布局本身更对设计人员提出了严格的规范要求。这里的理解可能只是囫囵吞枣，但毕竟作为敏捷开发的团队，优秀的设计方案，前端实现人员和设计人员的充分沟通，将使得前端的布局压力大幅降低，而不必再耗费额外的时间进行方案的讨论。 |
0x03040c：前端和用户体验的充分交流
|
我要做的是让用户适应我的页面布局，而不是让我的页面去迎合用户的习惯 |
|
这里我只能阐释一点自己的理解，能强制用户去适应的页面布局，是因为它真正地更满足用户的使用习惯，因此不必迎合主流公司所制定的“习惯”（腾讯副总裁、微信创始人张小龙先生真的是一位能读懂用户的产品经理）。但仅从此处的敏捷开发过程，项目本身应尽可能满足用户的本身的操作习惯。在第一轮迭代中，此部分的数据还在进一步的收集中，因此在笔者写作时尚未感受到它本身的益处，但第二轮迭代在收集用户反馈的过程将尤其重要。比如菜单、标签栏通常布置于侧边，方便单手和双手操作的用户都能够尽快访问这一部分内容。在第二轮迭代中，也会将此部分的收获进一步补充~ |
0x03 ：“银弹”观点和团队项目的关联
To the world,you maybe a person.
But to a person,you maybe the world.
“软件工程中面临的固有的不可避免的问题，主要包含复杂性、隐匿性、配合性、易变性”是软件工程开发中不可避免的冲突和矛盾，而“除非附属性工作要耗费的心力超过全部工作的9/10，否则就算是将所有的附属性工作降至零，也无法将整个开发工作的轻松程度提升一个数量级”（Nevertheless, such advances can do no more than to remove all the accidental difficulties from the expression of the design. The complexity of the design itself is essential, and such attacks make no change whatever in that. An order-of-magnitude gain can be made by object-oriented programming only if the unnecessary type-specification underbrush still in our programming language is itself nine-tenths of the work involved in designing a program product.）。借用自己通俗的理解，由于软件本身大量的复杂性属性，并不存在任何一项技术或方式可以使得软件工程的生产力呈现数量级范围的提高（如至少10倍）。
单纯从此次的敏捷开发过程中，个人其实感受到的是“没有银弹理论”的合理性。从文中固有属性和外部事故的经典二分法来看待此问题，银弹本身强调的是软件工程开发方法的通用性，但无论敏捷开发或是能力成熟度（Capability Maturity Model for Software）模型开发，均具备一定的前置条件。敏捷开发强调对快速需求变化的适应能力，提前的编码也能暴露项目早期的很多技术风险。譬如，在此次团队开发中，在选用django框架进行搭建的过程中，测试人员（http://home.cnblogs.com/u/-OwO-/）在配置的过程中发现框架本身对强注入的防范度较低，因此在设计初期也进行了一部分架构，并预计在第二轮迭代时将此部分纳入信息安全的部分进行一定程度的封装。当然，回到“无银弹理论”，软件工程强调团队的整体协作，而各种模型的开发必然会受到主观协作、客观需求的内外交织的双重压力。仅针对此次的敏捷开发而言，从表格中可以简要概括内部主观协作的瓶颈：
|
产品经理/项目经理 |
由产品经理负责的协调工作、督查项目宏观方向、任务和进度跟踪是敏捷开发中不可或缺的部分：而失败的任务分配和监督将导致团队本身工作量失衡，而导致部分成员难以及时参与到讨论中并最终与团队“脱节”；失败的协调工作，则很容易激化本身的矛盾甚至出现“恶意罢工”的现象（比如前段和设计开始争吵谁的设计更理想，或者强势的开发人员不遵守进度要求）；而失败的项目宏观方向也将导致弱需求、不必要需求的出现 |
在初始的任务分工中，PM并未考虑到高昂的学习成本而制定工作计划，而导致初期时燃尽严重偏离预期，部分成员工作量失衡，耽搁了一定进度。 但中后期，PM基本梳理清团队各成员本身的开发进度和关系，能够有针对部分进度呈现充分条件的组合加快进度速度，燃尽的发展也逐步趋向于预期的走向。 |
|
设计/开发/测试人员 |
这里出于分类考虑，仅阐释部分的协作压力。对于前后端开发人员，必须要能够对数据结构、数据展示形式、数据逻辑流程有着很好的把握。而若两者消息链失衡，导致前后端的数据展示脱节，则很容易导致其中一部分返工从而造成进度拖延。而对于设计/开发/测试人员，都必须依赖于一套成型的规范去限制自己的设计或开发，从而保证代码的可读性和稳定性，而若其中一方依据自己的编码规则进行开发，将很可能导致后期维护过程浪费大量时间去弄清楚其本身的功能和逻辑 |
在初期的设计中，前后端协商分离式“高效率”开发，而不得不面对数据脱节的尴尬状况，最后在开发中后期进行了为期1-2天的代码复审工作去优化此部分工作量。 |
因此，“没有银弹理论”本身并不是在否定软件工程本身的开发理论，而是强调软件工程的复杂性是不可避免的，从这一立场出发，笔者本身是支持此理论论述的基本观点。
当然，“没有银弹理论”并不等价于软件工程不需要一定的方法去提高开发效率。毕竟，无论是结构化的方法和设计、或是面向对象的设计思想、程序的工程化自动化验证均能在一定程度上保证软件工程的高效开发，因此，银弹的研究也并未因为这样一篇理论而就此终止，逻辑上的反驳和论述也始终存在，期待软件工程本身的系统化方法能够再次迈上新台阶。
0x04 ：大泥球、大教堂、集市和BugPhobia
To the world,you maybe a person.
But to a person,you maybe the world.
仅从定义的角度阐释，大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑，往往会导致很多错误或者缺陷，其本身强调了碎片性代码和一次性代码的弊端。而大教堂和集市则着重区分了源代码的管理方式，而这里仅从大泥球的理论在阐释自己在团队开发时的感悟。其实，在项目初期，从主页面到搜索结果展示页面的实现过程中，基本未剥离出单独的模块结构来保证前端逻辑的正常执行，仅从代码行数看待这一问题，主页面的和搜索结果展示页面的代码重复率高达30%(header、footer、ui grid的架构方式，以及重复复用的head头部)；因此，为保证前后端对接能够减轻压力，团队本身的架构更改了前端本身的逻辑实现，通过base继承，include迭代的方式完成了大量重复代码片段的模块化，而在后续的开发中也尽可能通过segment的搭建工作保证“搭积木”效果的快捷完成。因此，大泥球不仅依赖于开发者本身对代码本身搭建框架熟练度，同时更注重开发者之间的“可读性维护”和“高效性耦合”。这也是文章中强调的重点“健壮的结构远比精巧的设计来得重要”。因此，在此段的第一轮迭代向第二轮迭代的过渡期，将全面完成代码复审工作，由前后端结对编程的方式充分沟通其中的冗杂代码块，共同完成对项目本身精简工作。特别说明，在BUG的调试阶段，大泥球现象愈加趋向于严重，可能出于快速敏捷解决BUG的想法，一般都采取添加冗杂代码块的方式去进行“填充”式的修改，并未注重前后端本身的模块化依赖关系，在11月14日的过渡会议上已经完成了此部分的提醒和监督工作，将对近期的服务器的代码进行整合和梳理工作。
关于大教堂和集市的思考，这里引用团队内架构师GNU_Linuxer的深刻论证，笔者对这一部分内容表示高度的赞同，因此强烈引用（http://www.cnblogs.com/fzyz999/p/4963681.html）：
“我们一直采用集市式的方式进行我们的团队项目，大多数任务几乎都是自己主动要来的。团队内部的大部分人都很积极，任务也大多数都有明确的人来真正去负责。所以大体上十分顺利。但是，集市式方式所面临的问题，我们自然也不可避免的遇到了。而且，我们甚至没能及时注意到这成为了一个问题。大教堂式的开发是设计好了一切，按部就班地完成开发。而集市式则更像一个闹哄哄的集市，每个人选择其自己感兴趣的任务去进行。我们顺利地采用集市式的模式完成了几份高质量的作品。一个人初稿、一个人复审迭代更新、一个人再度审核排版等等，每个人都出于个人的责任、荣誉以及兴趣等复杂情感，深入地参与到了整个过程中。虽然没有非常明确的安排，但是大家都主动承担了某一部分的任务。我们用集市搭建起了一座教堂。”
其实，从个人参与团队项目经历中，团队本身的管理呈现了“大教堂”嵌套“集市”的趋势，因为不可否认，集市作为一种局部管理是具备一定优势的，工作任务没有重叠或者即便重叠也是双方均知情的“集市”是敏捷开发中可以选用的任务分配、交流沟通方式，却并非理想的团队管理方式！而这也是此次团队本身管理所忽视的部分，片面夸大局部的工作效益而忽视了大局观的分配，恐怕的确是团队本身最深刻的反思和迫切需要进行调整的方面！团队管理方式可以依赖于集市模式的集合，但却必须给出非常严格监督条件，如：模块直接负责人（绩效管理的影响者，必须以个人为单位，这里插入读完感触颇深的链接http://www.ituring.com.cn/article/9363）、时间节点（Deadline）、依赖关系（和其他模块的时间、架构上的依赖关系），否则，此次Scrum Meeting失衡的错误必将无可避免的再次发生！愿这一次的反思真正能够使个人和团队都能涅槃重生，愿一切安好，愿不忘初心和规则！
0x05 ：瀑布模型、软件工程和第二轮迭代的初心
To the world,you maybe a person.
But to a person,you maybe the world.
回顾自己在翻阅《构建之法》后提出的问题（http://www.cnblogs.com/panacea/p/4832903.html），现在仔细想来，对于需求的变更所导致的影响，现在也在一定程度上有了属于自己的理解。从“瀑布模型”的概念出发，软件开发的阶段性开发周期可以具象为瀑布水流的逐级下落，而每一阶段的输出也会为下一阶段的输入提供一定的奠基。在瀑布模型的基础上，开发团队可以专注于开发固定节点的检测，即可通过前置节点的正确性循环证明软件后续节点的正确性。但因此，在需要需求的变化后，开发者必须要通过设计更改需求（Design Change Request）来确保不会出现弱需求，在保证需求的必要性后，再根据瀑布模型的流程逐层调整，从而继续保证软件开发过程的稳定性。而根据此前软件工程的论证中，软件工程必然具备其本身的复杂性，因此较需求的变更而言，瀑布模型难以承载急剧的需求变化。但瀑布模型本身的严谨性在团队管理和0x04中提及的教堂、集市管理可以相互借鉴。
最后，就用瀑布模型和软件工程本身的理解，去设计第二轮迭代的整体职能。从第一轮迭代的前端开发人员，到第二轮迭代的项目经理，希望自己能谨记自己今日的反思和所感，不忘初心，一切安好~
|
ü 保证开发、设计人员的学习成本，尽可能通过第一轮迭代的过渡期完成必要人员对自身框架的学习过程：此阶段强制纳入绩效管理，通过提问-回答的方式进行学习成本的检查和督促 ü 保证软件本身呈现大教堂式的规范开发过程：在第二轮迭代阶段，前后端人员必须合作完成一份数据连接报告，其中包含后端能获取的数据、前端期望后端获取的数据、前端的数据展示原型图；同时，后端部分必须完成后端逻辑的修改设计，对原有文档进行二次修订和维护 ü 保证职能责任化：充分保证各职能高度归一，模块开发过程中允许结对编程，但最终绩效评定依据单一的负责人进行评价，保证集市式开发过程的预警性和责任制 |
0x0a ：结对编程项目总结
To the world,you maybe a person.
But to a person,you maybe the world.
以你所在方位画下一个坐标，然后跌跌撞撞杀出一条血路。
第二轮迭代的项目经理，铭记反思，愿一切安好~
Hola~BugPhobia~