Copyright @ Joel Jiang（江东敏） at 2017.06.14 08:00 a.m in
Shenzhen.China. LIST-TE-E22-01
如有需转载请注明文章与作者的来源。
关键字：Real Time &Instantiation Of Demand、Living documentation、
在企业中， 任何应用一项技术时，首要的法则是，在有效率的系统中导入自动化，将使效率倍增。第二条法则是，在缺乏效率系统中导入自动化，会使效率更地下。
- Bill Gates（比尔盖茨）
Software Manager是一个相当Abroad与Holy的行业术语。关于学术派就有对它不同的定义与理解，甚至升华以至哲学的某种思想（这里先谢谢先前某pre-南极圈某博士对本人一些指导与商讨，而这里不再讨论），也希望未来的某一天，自已能力能不断的提升，与大家共勉，写出一些这样的文章与大家一起分享。而关于software develop 以及 一些 Develop Sense，本人以前关注过像@michaelbolton（Twitter）等人的一些文章，关于他一些文章地址，我在文章的最后cite处会给出，帮助于大家一起互相学习。
文章内容：
Part 0.001: Cause.
在互联网时代，不管是从事于AI或其他软件专题的开发，工作重点放在于快速、正确地构建产品与构建正确的产品的兼顾是一种必须、高效的事。协同制定需求说明等虽经典但早同Code Freeze、 Project Standardization Management 等在很多项目中慢慢will to be past. 在互联网团队中，新型商业模式以及高效开发效率是抢占市场最为重要的事, 成功的产品需要快速迭代,与几年前不同, 曾经的软件产品经过了长达一年的设计,实施与测试周期而无需与用户发生联系,今天最好的产品建立在快速构建，了解用户反馈回路的基础之上，因此在学习与实践Real Time &Instantiation Of Demand(1) 中， 真的意识到Living documentation(2)能够更有效地实施变更，同时有效地分享知识而满足团队成员和项目的进展，并且在产品前期与收尾过程中，可更快地发现error 和减少 rebuild。
They ensure that all project participants speak the same language, and build a shared and consistent understanding of the domain. This leads to better specifications, flushes out incorrect assumptions and ensures that functional gaps are discovered before the The stability of development starts.
(句子引用于书：Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing )
Part 0.002:The demonstrate of this process (picture 01).
所有的演绎与流程，对Real Time &Instantiation Of Demand来说，功能需求、需求说明与验收，以及测试都是一回事，最终实现一个Living documentation，它更多的从业务层去解释系统可以做什么， 实现什么商业价值，以商业的角度去看待每一个需求点。并且与programming language 一样，可靠且容易理解。在整个"skeleton"中，一些经验与方法论将归入敏捷系列之（1） Real Time &Instantiation Of Demand - 实战经验篇，这里不再细谈。
Part 0.003: How to do it.
下面先以简单的一张图片表(picture 02)介绍基本的组织框架（只供参考）
0.003.01 :Basic preparation.
好的准备是为了好的high quanlity， 而运生出更多更好的迭代，对于新生的project，从member, tool（可参看后面写的）, time plan 等等，以及模块化的准备，实施良好的准备是成功项目的核心关键。
0.003.01.01 :Reform the develop process.
不管是在新的项目或原有的项目中，向敏捷过程的转变，首先同样面临着产品质量保证与提高的问题，这是一切转变的开始，也是提高软件质量而引进的方法论最有力的武器。
在应用到现有的项目中，大多数的都是从功能测试自动化开始reform的, 开始慢慢的从“开发 -> 测试” ，转变为以Real Time &Instantiation Of Demand 为indication的开发。在这个过程中，可以大量地让测试人员赶上开发的每一次迭代（即使已经出现测试落后于开发），也能渐渐的起到共同、同步的作用。而why can it can accomplish it highly？
/ 新的方法并不需要像老的方法一样需要大量的人工测试，人才资源的分配的减少大大的减少了成本，并于进度相吻合。与手动测试相比，自动化可以让团队在同样的时间内运行更多次的function testing , 有助于系统的稳定性测试与商业发布率（我觉得用上线次数更为精准）。
/ 对于TDD(3)大家相对比较熟悉的多，简单的截图（picture 03）与引用一下一段话如下：
对于经常应用TDD的人来说，他也许不会把Real Time &Instantiation Of Demand当成一个全新析replace或reform ，而是把新的方法与原来的TDD进行更好的结合，更软件更具有要可测试性与修改性，以及对业务功能的角度去看待新的方法论。
0.003.01.02 :Change the team culture.
文化很多时候可以对等于思想，更高层来说是灵魂，谁都不敢轻易去改变一个团队的文化，因为害怕失败，团队在诞生之时便赋予了文化与精神。在一些会使用敏捷的人群中，使用Real Time &Instantiation Of Demand也许能得达大数人的认同与接受。特别是得到管理者的支持，是成功的进行文化改变的一个有力的支撑点。在做文化层的改变时，我认为更多的是引进成功的案例，在有光明的道理上点燃未来，才是最有力的精神支柱。
/ 不要过分偏于tools化，script当然高效，可最张的目标是让大家便捷化。
最后切记，不要让测试自动化成为了最终目标 ，对产品开发者与商业参与者来说，我相信，看到业务层的可利成功的产品才是一切的王牌！
0.003.01.03 :Integration and collaboration .
这里refer一下，Real Time &Instantiation Of Demand更强调了：
/ 建立sharing permissions，此主要针对开发人员与测试人员；
/ 快速feedback and rework, 高效地完成软件的一小块（这是重点）。
/ 强调高效的conversation chatting, 而不是长篇大论documents.
0.003.01.04 :Deal with well sign-in and extensibility.
重要的一方法论（经验）： the same version ,the same code.
即把同级别同版本的代码放在同一个控制系统中，做适当tag and branch mark.
在签收的时候，通过导出活文档来签收（可为PDF等形式进行functional check），但注意签收的是范围与功能，而不是Living document. 适当时候可以引用于实例进行单元点说明。
0.003.02 : Get the domain of the business goals.
学习过产品用户需求定义的朋友都知道， 软件也如此， 构建软件系统最难的部分往往是如何精确地定义与构建，以及定与构建了什么？我们应该学会做到以下基本要点(picture 04)：
0.003.02.01 :Rebuild the right territory of demand.
通过上面一步，再一次rebuild一份简易、可理解的demand ，通过后期的不断改进，进行与业务层次的交付与更新需求，为后面的工作开展提供最可靠的需求说明。
0.003.02.02 :Collaborative determination range and prepare more with cooperation.
很多开发经理或开发人员非常意识到，协同的作用性，曾经的我也是做过一个人担任一个项目的开发工作，在工作中，非常体会到效率的不佳，与出现一系列问题没有办法在第一时间得到解决与沟通，甚至有些遗留到今天。当今很多创业公司用的就是“中小型工作坊”这种模式，当今最流行协同模型通过学习后总结了以下几个方式：
/ 大型团队意念：团体全面参加，建立共识，所有技术人员一起了解业务领域，比较参加项目立项会，与分析研讨会，部署大型的知识体系结构。
/ 小型团队意念：以核心人员主导，参加的人数以信任业务能力为一小单位，进行开展工作，XP意念可非常实用于此类型，高效。
/ 其他：让审核、测试、开发人员尽早的知道用户故事。
而成熟的产品可以较少的事先分析，考虑其他的，这块相关的经验见《经验篇》
0.003.02.03 :Get more information and redefine the demand by some ways
关于更多的有效的信息，是保证完成一个成功产品的关键部分，demand尽量去做到少歧义，少抽象的概念，并且要做到true，我个人的感觉与理解，应该少增加个人的观念与理解，以需求的实际来源有导向，并且get 到information 要尽量的易于他人去理解。
在理想的情况下，需求要以业务的角度去定义开发，而一开始不要太关注一些开发的细节，如果有可能，让开发人员去自由发挥寻找有效的实现方式，所以一份好的demand 更要多次的去redefine ，最终做到：实例要精确可靠，一开始不要太多流程化的东西（如果涉及到逻辑流的情况，方可使用hypothesis ->when/why ->then ->do的方式，具体这里不细写）， 特别是软件设计。特别是细节、技术难点的评估，长篇的解释目标 是很多引进敏捷时的通病。其实，需求化更重要的是说明要专注、减少依赖项。
0.003.03 :Automated verification.
不管UI或底层，在提炼好重要的需求点和目标以后，便有了Automated verification这个交付，它是一种长期维护的成本。
0.003.03.01 :Manager automatly.
在管理中，PM 最常见的方法轮就是用project tool 与document去做管理工作，纯文本或HTML格式去处理demand，而在Manager automatly中，采用了script 去做管理，可以适应与频繁的修改与迭代，以命令的方式去管理demand，比维护纯文本的方法更加高效。但有几个需求特别的注意：
原来系统过于固定，在遗留系统中，不适合做script管理 ，这会增加了系统的复杂难度。以及在复杂的集成environment中，要先多edge开始，慢慢切入。或采用一些新型的架构，比如https://github.com/brynary/webrat/wiki。
0.003.03.02 :Manager test data.
管理好测试数据，特别对以数据i驱动的系统更为重要，以下几个方法值得去思考：
对数据驱动型、不利用重新建立所有的数据的系统：尽量去准备与固定好那些没有变动的数据，并对它们进行第一时间的check 与尝试，可专门设置一组完全独立的测试来验证它们，快速验证他他们的可行性，进行快速反馈与改进系统的选型。
对非数据驱动的系统：在OO的设计原则上多次强调软件“低耦合”的重复性，在非数据驱动的模型中，重用了原来的数据去做设计，这虽在很大方面可以提高了设计的重构性，但会在系统后期的维护与更新带来了很多复杂的理解，特别是在引进了大规模的数据时，问题点会特别的多，关于这个，与重构思想的矛盾，本人能力有限，以后深入全面理解后，可再细研。
0.003.03.03 :To UI of user control automatly.
用户界面的自动化程序库使用的是屏幕语言，也是一种软件设计思想，但基于语言的设计对UI 用户UE 与cortrol 并不是最理想的做法。因此，基于更高层次的抽象思想来说明用户界面的功能能使系统更加的易理解（即抽象到工作流的高度）。工作流与系统的设计有关，所以实际上我们可以更进一步关注到用户想要完成的事情。
在原有业务层下，把需求分开谈，可以大大减少复杂性的发生。测试所展示或操作的是什么,user 怎么使用这些UI功能，每一个简单的步骤需要什么技术方案与过程，这是建立用户界面自动化很要注意的方面。
0.003.04 :Frequent testing.
Frequent testing可以做到与CI(4)一样，形成比较完善的document note practice ,这样可以通过比较快速的找到BUG，让软件系统跑在正解的道路上。在Frequent testing中 ，要做到有效的保证了系统的稳定性，找到boring question并快速的处理它，然后不断的retest。
0.003.04.01 :Get the newest and the quickly feedback.
有时，从众多的要不稳定系统中，做到精确的retest ,需要一些专用的方法（见经验篇章）。在这个过程中，具体的方法论为(picture 05)：
0.003.04.02 :Boost the stability of system.
最后的系统要求：Living document 前后要一致，只存在一种语言（此处已不像c++等语言了），建议用最简易的语言去定义。 组织上，可以按用户故事去组织当前的工作，但通常一个用户故事需要我们更改多处的功能区，故层次上来，各大模块的实现故事点都应有清晰的document ，最后组成完善的“用户故事书” ， 对于嵌入式系统方面等， function化明显，function bills 也是一种有效的方法。总一点，就是得清晰的层次化架构。
特殊情况：
针对P2P ： 对于业务架构非常层次架构分明系统，根据业务的guide去P2P。
针对ＵＩ软件层开发：同业务层一样，可以根据ＵＩ层去做出类盘通作用。
部分名词解析：
(1) Real Time &Instantiation Of Demand: 我想表达的意思为实时实例性需求，表示虽项目需求不断变化与自动化适应的需求。
(2) Living documentation：活文档（即随需求自动化变化的document）
(3) TDD: Test-driven development (TDD) (Beck 2003;Astels 2003), is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring. 更多的information 可以参考这本书：www.amazon.com/exec/obidos/ASIN/0321146530/ambysoftinc （此类书都差不多，这里不多谈）
(4) CI: Continuous integration 持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
一天中进行多次的集成，并做了相应的测试，这样有利于检查缺陷，了解软件的健康状况，减少假定。
最后送上@Sam Lessin（Facebook former product director ）两条重要的PM rule分享给大家：
/ Rule 1: Go read sci-fi books and make it happen.
/ Rule 2: When designing product, start by stripping out all technology, because there are a lot that’s changing, but the fundamentals of who humans are, and what we want to navigate are NOT changing.
Reference:
en.wikipedia.org/wiki/Agile_software_development
