开发...就像药物一样-他们编写系统是因为它很着急。 然后，突然发现-需要支付“抚养费”。 系统中的任何更改都会导致大量错误。 但是即使在上世纪初，伟大的
库尔特·哥德尔（KurtGödel）也预见到这一点，并
严格证明 ，即使在算术运算中，我们也没有足够的智能来表达其所有定律而没有矛盾。 在编程方面，甚至更多—我们将开始站起来并感到困惑。 通常会发生这种情况：要么笔记本电脑打开电源，然后在晚上重新启动，然后移动应用程序出现错误，以至于它们开始从口袋里掉下来并散落开来，在地板上骂人并吱吱作响。
您如何看待现在所有事物的时尚beta版本？ 看来，飞机很快就会开始出现在alpha-beta版本中。
但是您可以无错误地编程，以使灵魂欢欣，与客户一起喝啤酒不仅令人愉快，而且也很安全！
在有关软件开发各个方面的系列出版物中，我将尝试创建一组简约的价值观和规则，首先将价值观和规则置于普通人的头上，其次，它们通常允许...以最少的费用和时间赢得胜利。 今天，让我们坦率地谈谈收集软件系统的需求。
剧院，到处都是剧院。 但是，如果过程中的所有参与者都说实话，那么软件开发行业无疑会从中受益，其次，第二，没有人会支持克苏鲁周围的非系统性情绪和事奉。
您无需走太远的例子-开放的开发模型及其成功（不一定非营利）令人信服地显示：
- 清晰，开放，勇气
- 与社区和客户的讨论
- 快速识别和解决问题
以及基于相互信任和相互尊重的最公平的交流-引导成功的软件解决方案（例如网站）。
世界正在积极改变。 水平通信以光速发生，如果我们不学习如何使用这种新武器，我们肯定会失败。 但首先，环顾四周。
编程中的“圣战”来自哪里？
一切都很简单。 回顾几何学课程就足够了。 对我们所生活的世界的科学理解基于……相信“不变的真理” =公理，例如，“平行线不相交”或
一定范围内的质数（虽然这是一个定理，但它狗工作，但没人知道为什么）。
证明公理是不可能的，只是相信它总是有效。 但是我们无法飞往黑洞事件视界并进行检查。 并解释为什么光子之间的相互作用也比光速快得多。
许多科学理论都使用公理来得出定理的逻辑结论，等等，因此诞生了具有一定保修期限的厚实书籍。 结果，这不再是一件有趣的事了，
在90年代
证明了费马大定理，使得只有少数具有特殊教育水平的人才能理解该证明，并且能够在显微镜下用公式将数十页精美的文字铲除:-)这就是为什么他们继续寻找“真实的”，简单而优美的证据。
甚至在看似更简单，算术上的尝试中，也曾多次尝试使公理有序-但是事情仍然存在...
同样，我们用来创建网站，移动应用程序和信息系统的编程语言和技术实际上也代表了一组公理或参考点，您首先还需要“相信”这些公理或参考点，并以此为基础建立技术，但是无法证明它们是正确的（尽管有时还是有可能的：尝试使用C ++编写网站，看看您损失了多少时间和金钱）。
例如，在Java / C＃和其他具有静态类型的权威，信誉良好，现代的严格类型化语言的世界中，您只需要并且“相信”这个世界是由精神病患者组成的，容易遭受暴力和自我认同的破坏，因此就形成了“公理集”尽一切努力保护开发人员不仅受到同事的保护，还保护他自己（当然，我在开玩笑）。
结果是由铁和混凝土长时间创建的软件系统，然后进行了数百次自动测试，结果可能证明，到施工结束时，业务需求已经过时了，禁止了核武器，并且将拆除100米长的地堡立即去博物馆。 但是通常对世界的这种看法很有效，例如，在开发狭义的专业系统或错误成本很高（银行等）的情况下。
在具有严格/非严格键入（PHP，JavaScript，Python，Ruby）的动态语言世界中，公理集是完美的，从“完全”一词到另一个：
- 我们周围都是聪明的人，他们马上就写正确而整洁
- 迫害狂潮（更改列表下方的变量的类型，意图“恶意”的开发人员访问隐藏的类成员，预先需要进行深层代码重构等）-一种需要快速恢复的疾病
- 硬件变得越来越便宜，因此您只需要分段编译程序，然后在必要时进行编译
- 代码越多，错误就越多，因此代码应立即阅读清楚，简洁，性感
在功能语言（例如Haskell / OCaml）的世界中，您需要相信：
- 任何任务都可以用功能来表达
- 变量，周期和可变性-导致错误（实际上是这样）
- 编程-选择和倾向于分析思维
结果，真正的科学工作不再是简单的“制作，检查，决定和遗忘”的拐杖脚本，而是从工作场所开始的，而寻找“上帝的功能”对于用一个没有变量的功能集的网站表示非常有趣，哇！
我当然夸大了，但是没有火就没有烟。 尽管在某些任务中这种方法
很好用，但是 没有人提出一种更好的方法。
软件项目管理中的“十字军东征”
在项目管理领域，这种情况更加被伪科学的阴暗笼罩。 原因是众所周知的：表面上有一个明显而简单的简洁解决方案：
实际上，由于某种原因，它不起作用:-)
项目团队中经验丰富的参与者都清楚，老顾客经常不知道自己想要什么，因为他不知所措，并在学校复制了数学问题，最终导致部分“大脑部分萎缩”，从而导致了他逻辑上一致的表达的想法。 有诗意的口号，口红的绘画和吉他和弦的音符，而不是网站的技术要求，专家们哭泣以免因阳laugh而大笑，将工作量的估计数提高一个数量级，对不适当的物品征税，等等。
在缺乏严格逻辑和欲望的情况下，我很遗憾将头用于预期的目的，好像飞速发展一样，在占星术/命理学/ pranyozhenie风格和咖啡渣中出现了可怕的不科学虐待。
滥用通常会被非常有信心的人积极利用，他们能够说服他们，他们从来没有掌握过“代码”（是的，我说的是错误的敏捷）。
他们说，在冲刺之前的某些团队中，即使是最热情的粉丝也迫使我们的工程师进行尿液治疗：-)但是，这些“做法”本身通常
是由经验丰富的开发人员
创建的，他们像其他人一样，可以正确使用它们。
在这里，我真的很喜欢双节棍的类比-好像是一种简单的武器，但只有少数可以正确使用，大多数人受伤了，对不起，您知道自己的事。
另一个神话是互换性
有时他们试图说服我们
工程师的
互换性 。 众所周知，为了对软件技术有深入的了解，您需要重新阅读许多书籍，
听几十门课程 ，解决数百个问题并参加五个软件项目，其中至少一个已经完成。 接下来-实验开始，至少经过5年，才制造出编码器-专家。
通常，开发人员经常在项目上工作，会说一两种编程语言和相关技术。 工程师的成功和专业成长恰恰在于他狭窄的专业领域，因为 除了语言本身之外，还必须深入研究系统库，这些系统库通常很多，并且它们的文档也很丰富。
问题在于，由于某种原因，现在不阅读书籍而是在谷歌上将其写下来（不包括大脑），同时在社交网络和智能手机通知中进行心理自慰，这很流行。
寻找一个真正的专家，从头开始，从下而上地，肯定地，系统地学习，以缩小自己的知识鸿沟-变得越来越困难。 不幸的是，市场上充斥着……“被宠坏的手”。
怎么办 建议生存值
首先，没有必要感到绝望，重要的是不要沉迷于情感。 有必要清楚地了解到，发展首先是严格的数学（通常是在学校一级）和具有度量标准的逻辑，其中需要运用直觉和直觉来应对优先风险和婴儿期“湿”老板。
我们以前曾经玩过在线游戏，而且效果很好-因此，继续吧，只有软件而不是老板，您将拥有软件项目，而不是错误-虫族！
总是有可能并且有必要清醒地管理风险，并且根据经验，如果“系统地，科学地”完成一个软件项目，那么该软件项目要么按时起飞，要么很快就会弄清楚为什么导弹无法启动以及什么/由谁着手，特别是问题所在。
鉴于上述情况，建议您开始遵循以下科学实践经验方法的值，这些值与众所周知的常识赞美诗“
python Zen ”和“
敏捷宣言 ”紧密相交：
- 搜索最简单，最清晰的解决方案
- 越清晰越正确
- 变得困难了-这意味着在某个地方出现了障碍，您需要继续进行进一步搜索
- 傲慢-来自不安全感或童年艰难
- 人脑的能力有限，尤其是在激素的影响下，甚至在某些时期
- 酗酒和吸烟-我们正在沉闷
- 我们往往会很快忘记甚至是我们熟悉的知识，甚至是最近
- 力求最大程度的透明度和开放性
- 互相尊重
- 鼓励在尽可能广泛的范围内尽可能快地进行上升和讨论问题-立刻成为理想选择
- 得出结论，不要连续踩耙3.14次：-)
需求收集
在了解了软件开发趋势的一些秘密和特征之后，我们将充满信心地继续前进-我们将学习如何正确组装系统需求。
客户原则上可以思考吗？
没什么好笑的-这仍然是正常情况。 在这种情况下，客户是一个集体概念。 首先，尝试评估逻辑思维的水平和集中客户代表的能力。 您将与谁一起工作，谁会帮助您？ 可能的选择：
- 政党。 例如，有必要在某个日期之前完成一个Web项目，因为有人想要/答应了某件事...要求含糊不清，没人知道细节，谁知道-不久就会退出。 该项目是由一个离开的团队看到的，几乎不可能理解他们所看到的。 在墙上-可能是一位著名程序员自杀导致的干脑。 该代码不好，易碎，有异味，因此会伤害您的眼睛。 通常，在这种情况下，他们试图找到“对不起的牺牲”，请在接下来的六个月里指责它，然后……开始寻找新的牺牲。 嘴唇上沾满鲜血，使人感到恐惧，沮丧和压抑过程的开放性。 按时制作软件解决方案的可能性虽然很小，但仍然存在-如果您在具有现成文档的现成框架中再次进行，则仍然存在。 通常是唯一的方法，而没有其他方法。
- 您与客户代表进行沟通，并了解到人们很难始终如一地/正式地表达自己的想法，这些想法在第三句话之后被混淆并反复出现。 对话15分钟后，开始出现头痛的抱怨。 听到了笑声，聚会的气氛，自拍照，生活很成功……但是，总的来说，这些愿望是可以理解的和真诚的-您只需要稍微帮助他们就能明确。 在这里起飞的可能性通常高于第1段，但同样，使用现成的，装箱的解决方案以及现成的文档和典型场景通常会有所帮助。
- 客户很好地理解了自己想要的东西，并试图在逻辑上和始终如一地表达自己的想法和愿望。 在这个过程中，他得到了一位分析师的帮助，这位分析师毫不困惑，提出了管理思想并将其作为自己的思想加以传播。 客户团队在其主题领域也至少有一位专家（很有趣，但这仍然是非常罕见的情况）。 在这种情况下，以编程方式帮助解决问题的可能性非常高。 在这里，您可以参与设计，词汇表，对象模型，数据模型，数据流，负载测试方案的联合讨论。 您很可能可以在合理的时间内收集需求。
这里的另一个重要点是与客户建立尽可能信任的关系，显示您的开放态度和渴望帮助客户清楚表达自己的想法。 通常，某些培训会有所帮助，在该培训中，向客户代表说明了如何使用以下需求收集工具：
- 一般词汇
- 逻辑数据模型，其中在词汇表元素之间（一对一，一对多，多对多）引入了严格的多重关系
- 显示谁在使用系统以及如何使用的角色和使用链
警报将指示收集需求中即将出现的问题：
- 客户代表会相互翻译“箭头”，而无法将两个词联系起来，这会引起很多情绪困扰-建议尽快将问题升级并提升到更高的水平-否则，作为“神圣的牺牲”，您会被惹上一团糟退休/产假。 在这样的条件下进行敏捷操作非常危险，最好写出严格的技术要求并分步骤进行
- 客户代表的回应方式是：哦，你的头很痛，但是你很聪明，是一个“程序员”，所以要正确地做。 在这里，您需要要求找到主题领域的专家，他会尽快代表客户负责答案。 或参见上面的段落。
- 他们宁愿不谈论问题（代码不可读，缺少主要业务流程的文档），因为 花费了金钱，获得了职位，发表了奖金并大胆讲出风险可能导致对员工的密集清洁（尽管每个人都“了解”，并且这里工程师忙得不可开交）–很难提供建议，根据实际天气采取行动
同样，在上述临床案例中，开发具有现成文档的现成盒子/云解决方案很有帮助。 这种方法可以将航向突然变化的风险降低180个数量级。 但是担保已经很少了。
如果客户采取适当的方法，渴望学习和理解您，渴望按时启动项目并进一步发展的真诚愿望，那么同时使用多种技术平台会大有帮助。 设计不再是可怕的-您感到客户与您100％共同负责收集需求，您可以尝试做得很好。 您-确保彼此，并一起努力应对复杂性：
- 带有框架的PHP网站，盒装解决方案
- Python中的预测分析
- 一个移动应用程序，该应用程序可以在可在任何地方使用的单个平台上，或者我们为每个设备编写
不要浪费时间！
如果在2-3个星期（极端情况下，一个半月）中，您感觉不到参加比赛“以聪明的神情聊天并抽出时间把所有东西放在别人身上”的感觉，拉起起吊起重机，放火烧火车，然后大声喊叫。大喊：“回家，孩子们！ 演出结束了。”
认真地安排与客户管理层的会议，并坚持在项目团队中聘请足够的员工，他们会详细了解业务的运作方式并能够回答工程师提出的严格问题。 还是辞职-有时这是正确的步骤：保存您的面貌并成长为专家。
检查清单
因此，我们可以认为需求收集过程是成功的，并且如果您能够与客户一起在几周内准备以下工件，那么继续进行有意义的工作：
- 词汇表列出了50-150个域名术语
- 具有词汇表术语关系的逻辑数据模型
- 用语术语用例
- 对于复杂的算法-UML的流程图或活动图
- 在逻辑上不与上述项目相抵触的软件系统接口
- 您已经决定了一组公理，这些公理描述了您对世界的态度=选择的软件技术。 在这里，由于对创造力的热爱，许多人被萨多受虐狂和重塑车轮的欲望所吸引-抵制这种欲望。 决定：要么整个世界到处都是肮脏的把戏和精神变态，并制造出可以抵御UFO攻击的掩体，要么开发人员真诚地希望为您提供帮助。 最好的技术和一套公理：已开发的框架或现成的解决方案-不起飞的风险将降低几个数量级（根据经验，95％及以上的项目将起飞）
- 您错过了通过客户，您自己，您的大脑而错过的软件系统，而且在任何地方都没有任何泥泞的斑点或情绪激动。 如果存在此类潜在变坏的地方（通常总是发生这种情况）-将它们包括在风险管理计划中，并在每次项目会议上发表意见。 并期望您会被陷害，并一定要问您如何错过它
如果无法在指定时期内收集上述文物，并且只有覆盖第五点的论文，例如模糊的TK“口红”，分析人员就不会互相合作，客户领域的专家也不会期待，问题就会悄悄消失，窗饰的气氛将盛行。 “只有好消息”-收拾行装：很可能它们不会让您飞翔，对月球的探索被无限期推迟，并且您正在剧院里表演 不会分散。”
为了取得真正的成功，真正热爱软件系统，投身于最大程度地收集需求和设计，祝火箭早日起步，与客户喝啤酒，彼此信任并不断自我重复
Edsger Dijkstra的话是非常非常重要的：“简单是关键可靠性”！
伴随着所有人的到来，并衷心希望您在实施软件项目时万事如意。