我的最后一篇文章
在医院建设示例中成功设计IP（信息系统）的
秘密有时引起评论中的激烈讨论。 因此，在此讨论的基础上，我决定陈述一些观点。
设计不适合程序员
很多时候，在讨论设计和实施信息系统项目的方法时，您会听到开发人员（程序员）对这些方法的批评。
有时，开发人员根本看不到，除了编写代码外，项目还具有重要的组织组成部分，即确定，制定和同意需求-最困难的任务是教育用户并重建所有流程-不仅仅是一天。
亲爱的程序员，为了弄清楚系统应该做什么，您完全不需要知道C＃或JAVA，而是要拥有一个主题领域。 要设计物流系统，您必须是后勤人员：具有该领域或几个相关的类似领域的经验。 因此，有些业务分析师的任务是确定系统的功能外观。
充其量，客户会给出30-50％的必要信息，其余信息应独立考虑。 而思考是至关重要的。 首先，客户不知道他想要什么！ 通常，进行业务模型的联合开发，然后才编译功能列表。
这需要了解主题领域。 我们需要简短地了解客户：他仍然在讲这个主意，您已经知道他为什么需要它，最重要的是，它是如何组织的，这种业务应该如何运作，而不仅仅是软件。
敏捷笔记
敏捷是新宗教吗？
讨论主题敏捷与 设计技术（瀑布，瀑布，瀑布）更像是宗教狂热者之间的争论！ 这篇文章根本不是关于敏捷的，但是所有评论都是关于“灵活”的。 伙计们！ 好吧，真的不可能更宽泛地看到两种方法都在阳光下吗？
我认为，敏捷的强烈拒绝是对这项技术极具侵略性推动的一种反应。 听着灵活技术的“传播者”的声音，似乎在敏捷世界不存在之前，就没有多年的软件开发经验，总的来说，在我们之前工作的每个人都是傻瓜和可怕的罪人，因为敏捷得不到启发。 天真！ 这样的世界观对青少年来说很典型，但是我们...
让我们降低程度，尝试清醒地评估每个项目的不同方法。
就像设计技术一样，敏捷并不适合所有地方
正如一位评论者所言：
“敏捷不适合IT，也不适合IT。 敏捷的业务和专业的业务 。
” 确实，有时您需要获得非常快速的结果，至少要投入一些东西才能进入市场并寻找投资者。 还是有新技术的发展，对这些新技术的要求很难满足。 这绝对是一个敏捷的利基市场。
另一方面，您在哪里找到愿意使用灵活技术的足够客户？ 市场上70-80％的订单是使用标准设计技术的政府机构。 此外，根据GOST34。他们为此付出了高昂的代价。
此外，可以将这些方法组合在一个开发中：使用设计技术创建核心，并通过反复试验（敏捷）创建某些部分。 好吧，并非所有事情都可以事先考虑。 另外，设计技术具有灵活性：存在诸如试运行的过程，在此过程中可能会发生很大变化。
敏捷是开发人员的想法
我不能为所有人保证，但是似乎程序员认为“灵活”，敏捷符合他们的思维结构！ 毕竟，编程是对最佳解决方案的不懈追求。 您坐下来完成任务，仍然不知道应该如何解决。 您既无法预先预测结果，也无法预测截止日期（是的，将开发人员的截止日期乘以6到10倍，这是获得真实情况的唯一方法，因为他们忘记了测试和改进）。 这是许多程序员的想法，因为他们是有创造力的人。 因此，您无需强迫有创造力的人参与项目的无聊工作。 为此，有分析师，项目经理。
我们意识到敏捷是思考开发人员的精髓。 但客户却认为不对！ 客户希望在开发开始之前就了解自己所支付的费用，“触摸”未来的结果。 然后，事实证明游戏具有一个目标：对开发人员来说很方便，并且客户晚上不睡觉，思考它是否会奏效，如果能奏效，那么奏效会发生什么，以及花费多少。 但是对Laf程序员来说，我会冷静地工作，我会做的，然后在完成后再做，然后我会按要求完成尽可能多的事情，他们会付出很多。 是不是
但是有时候客户应该这样说：我们在做新的事情，因此我们不准备预测时间，成本或结果。 你同意吗 然后我们做。 这至少是诚实的。
永远打开你的头
软件开发与其他领域的不同之处在于，您始终都在学习一些东西。 每个项目都像一个新世界。 每个项目都有自己的要求。 因此，磁头应始终保持打开状态。 不要只迷上一种技术，一种方法。 我几乎必须总是即兴创作。
要批评某件事，您需要研究它。
当批评设计技术或敏捷时，批评者很少知道他们的愤怒主题。 真正研究过（包括标准：GOST，ISO，IEEE）并试图认真应用设计技术的人很少。 但是她的批评者就足够了。 很少有真正成功的团队（以便使客户满意！）申请敏捷，但有足够的“支持者”。
再说一次，不要混淆敏捷和混乱。 如果您不知道如何设计并因此选择灵活的方法，那么您将一团糟。
成功的敏捷应用程序可能比设计技术需要更多的精力。 团队具有更高的连贯性，成员的资格以及与客户找到共同语言的能力。
阅读作者的其他文章：