我希望我能够通过这样一个挑衅性的标题（当然，是夸张的）吸引您的注意力。 好啊 现在，让我以一种更优雅，更不
引人注目的方式重新制定它：
原则上，软件可以按时编写，也可以按时编写，但不能同时编写**除了在现有的高性能团队中的少数情况下几个月以来，我一直在思考为什么创建高质量的软件与总体上估计的日期和计划不太吻合。 在我的职业生涯中，我看到了基于各种模型（层叠，
真正灵活，灵活层叠）的项目，它们都有一个共同点：无论我们正在从事的项目是“
在科学上”完成的 （就是说，我们不允许自己做一些恶作剧，因此以后我们会做恶梦），那么我们总是会违反最后期限。
另一方面，每当项目“准时”交付时，这意味着在其实施过程中不可避免地必须减少其数量，或者削减很多角落，以至于在实施过程中积累了大量技术债务，实际上保证了该项目将在不久之后重写。发射。 因此，我开始怀疑：我们是否真的可以假设该项目是“按时”交付的，如果结果是我们比原来的样子丑陋，不便支持，塞满了错误以及坦率地说，代码版本
更丑陋 ，试图做？
翻译成Alconost我有机会在没有严格期限的情况下从事项目。 是的，正式存在“最后期限”，但距离钢筋混凝土还差得远。 每个人都知道我们的截止日期是灵活的，质量比及时交付产品更为重要。 正是在这些项目上，我们获得了最好的软件，最满意的开发人员，并且总的来说，这些项目是我必须完成的所有项目中最成功的项目。 但是我们都知道这样的项目非常罕见，否则我不会写所有这些。
那么，为什么在计划截止日期并设定好最终期限的情况下计划工作并发布好的软件如此困难？ 我认为这主要是由于
创造力 ，
技巧和
不可预测性 。
编程的创意一面
我认为
软件开发从定义上讲是一种创造性的活动 。 当然，有些开发人员执行相同的琐碎任务，但是只有在有人弄清楚如何使他们的工作自动化之后，他们才能工作。 您不会羡慕它们，并且本文的主题完全不同。
对我来说，
创造新事物和寻找原始解决方案以应对挑战有一些特别之处； 这就是为什么我被要求从事软件开发，而我不认为我是唯一的一个。 实际上，我认为创造力是开发人员享受工作的主要原因。 我的经验表明，每当我在严格而不变的“一套实践”（无论是技术堆栈，流程，法规等）的条件下工作时，创造力的空间就会减少我曾经-对这样的工作着迷的程度越小。 “最后，如果他们已经为自己决定了一切，那么为什么他们需要我？” -我想。 另一方面，受到这样的工作（我也是最有生产力的）的启发，我感到很满足，因为上面的指令相对较少，有创造力的余地，而且我自己也可以做出技术决定。
重要的是要注意，额外的创作自由会导致这样一个事实，即在寻求解决方案的过程中不可避免地会经历更多的反复试验-这是正常的。 在某些人看来，您无需事先编写任何代码即可简单地（事先）简单地了解完美的解决方案。 相反，我坚持认为，在创造性过程中，发现任务解决方案的途径（不仅适用于软件）需要进行
修补 ：无法肯定地事先知道一切； 相反，您会在实践中学习，逐步挑选出新的方案并坚持可行的方案，细化您的决定（如果您按照“灵活”的方法进行工作，可能会逐步将其移交给客户），直到您对此感到满意为止。
试想一下，在纸上精心设计一个组件要花多少时间-直到那时，要完全重做设计，才值得开始实施。 在这项业务中总会有
未知的未知数，您可以识别它们并仅对它们进行
后验处理（实际上），对您的决定进行编程，而无需花费大量时间进行理论化并且不假装我们可以事先拥有完善的信息。 这样的即兴表现与估计日期不太吻合。
此外，与其他创意活动一样，在编程时练习
战略拖延也很有用-这个术语最初是亚当·格兰特（Adam Grant）提出的，他声称他经常无法
按需创造
，但相反，创造力来自于“推式通知
” 。在脑海中运行的进程：
定期拖延的员工通常将更多的时间用于发散思想，策展人通常认为他们比同事更有创造力。 拖延并不总是能激发创造力：如果员工没有信心去解决一个重大问题，那么由于滑倒，它就会滞后。 但是，如果一个人对商业有足够的热情并提出新的想法，然后推迟任务，他就会寻求更具创造性的解决方案 。“
-格兰特，亚当。 “原著：不循规蹈矩的人如何移动世界”
再次，这将不吸引寻求预见和衡量软件开发项目中每一分钟的
中央计划倡导者。
银河系，火星和流星编程技巧
我知道最好的开发商是熟练的工匠。 精通是优质软件的一项特色功能：
您可以创建可行的东西，并以最佳方式创建它 -创建有效的东西相对容易，但是很难做到既有用又经受时间的考验。
既然您是一位大师，您的工作质量就可以证明您 。 对您来说，质量比数量更重要，因为您不希望被公认是govnokod的作者，即使您可以使产品经理满意，为您的程序赋予外部光泽，并在内部充斥许多邪恶的惊喜-我称这种方式为
Kinder Surprise Development 。 您知道花足够的时间处理一个案例并编写一个好的程序是正确的，因此要抵制“更快地执行”的压力，因为您知道现在设置的拐杖越多，代码将越短，并且随之而来的问题也就越多。业务。
眼睛流血工艺与
关怀息息相关：我们关心的是做一个出色的工作，关心那些必须在我们之后维护我们的代码的人，关心应该很容易使用我们程序的客户，以及队友等。 您之所以这样做，是因为您不是混蛋，并且知道如果您关心项目的成功，那么应该这样做。
简而言之，一个好的工程师要完成一项艰巨的任务：在一个决定快速完成一切的世界中，从长远来看，要保证质量（长期来看）。
实际上，这用类似的方式表示：
- 找到封装，可扩展性，可伸缩性等之间的正确组合。 -再一次，将需要反复尝试的迭代方法，因为没有人会在第一次尝试中成功构建最佳解决方案。
- 如果遇到一段可耻的糟糕代码，请花一些时间进行重构。
- 编写良好，完整的测试-甚至可以进行TDD
- 与同事串联程序
不用说，不可能预先计划所有这些，因此类似的方法仍然无法帮助您按时完成任务。
你的预测是错误的
“即使有明确的要求-而且似乎从未发生过，但由于我们以前从未解决过这个问题，因此几乎不可能计算出完成一项特定工作所需要的时间。 如果您决定，那么只需给您结果。”
-罗恩·杰弗里斯（ No Restimates Movement）
软件项目是
复杂的系统 ：它们是由人创建的，因此通常具有人际关系，动机，沟通问题和人类心理的烙印-如果您对我的观点感兴趣，那么在表格中很难建模和量化所有这些内容。 因此，软件项目很难建模（因此无法预测）。 纳西姆·塔勒布（Nassim Taleb）在他的《
反脆弱》一书中对此做了最好的解释：
复杂的系统是高度相互依赖的（很难识别）和非线性反应。 “非线性”是指，例如，当您将药品剂量或工厂工人人数增加一倍时，回报将不是两倍，而是更多或更少。 这并不是说在费城的两个周末比一个愉快的两倍-我可以凭自己的经验说……”
-Nassim Nicholas Taleb，抗脆弱
更糟糕的是，鉴于时间不能为负值，任何未计划的“意外”都可能会延迟项目的完成，而不是拉近项目的完成时间，因为结果
不对称 ：
“时间不是负值，这意味着不能在零或负时间段内实施为期三个月的项目。 因此，在从左到右移动的时间轴上，误差在右侧而不是左侧累积。 如果不确定性是线性的，那么我们会看到一些项目大大提前完成了（因为有时我们到达某个地点的时间要早得多，有时又要晚得多）。 但实际上并非如此。”
-Nassim Nicholas Taleb，抗脆弱
这是个坏消息，因为
可以确保不确定性 ，并且即使评估单个任务的微小错误也会在整个项目范围内成倍地累积。 此外，在这里我们考虑最好的情况，即由开发商自己在仔细评估时间之后确定截止日期。 但是，现实要荒谬得多：在大多数情况下，“业务”会按他的喜好设置截止日期，然后工程师才开始工作，计划如何满足此任意指定时期的所有要求； 这个案例就像从屋顶而不是从地基开始建造房屋，或者在马匹前面放手推车一样令人震惊。
好问题以下是一些示例，这些示例演示了软件开发的非线性和由此产生的反馈循环：
- 您曾经建议要绑定的API接受
accountId ，但实际上它仅接受memberId 。 估计需要4天的时间，您需要重构API代码-之后，您将需要进行单独的审核，为此我们将再增加2天。
- 我们希望在2天之内解决的任务将持续一周，因为在审核过程中，一位同事强迫您（并且做对了）重构和优化长期等待中的令人讨厌的代码。
- 请记住，当您只需要实施一个新机会时，这是一项一次性任务。 但是事实证明，为此，您需要更新依赖项，该过程耗时4天，并且此操作在组装过程中引起了对其他依赖项和一大堆依赖项的更新的连锁反应。
我们搞砸了吗？
我们只是靠惯性继续通过评估和计划来玩这个游戏，只是为了保证自己：我们应该控制局势。 但是实际上，我们什么也没控制。 经验表明，软件项目是不可预测的。 因此，我认为将重点放在
业务上而不是计划上更好-
#NoEstimates ，谁和我在一起？ 但是，当然，这在许多组织中都行不通：“您不能只接受它，而让工程师来控制球，从而没人控制他们。 必须有责任感！” 知道了
你不是这样说吗那该怎么办？ 我认为这可以归结为缩小表的世界和IDE的世界之间的差距，以便为工程师提供最大的创造力，灵活性和自由来表现出精通的技巧，但是与此同时，负责任地遵守诺言并满足项目利益相关者的期望。 技术经理（工程经理）-建造此类桥梁的最佳专家，它也可以吸收两个世界之间的差距。 这项工作并不容易，但有必要。 这是亚伦·朗威尔（Aaron Longwell）在她的文章中对她的评价：
“由于技术经理生活在企业和技术人员之间的边界上，因此，他们必须解决期望与现实之间的矛盾。 它们就像杠杆悬架，向不同的方向拉动：它可以在两侧卡扣。 如果企业获胜，那么开发商将被逼死。 如果工程方面的考虑超过业务方面的考虑，那么就告别预算和截止日期了。 无论如何都是失败。 成功的软件项目经理会找到灵活采取行动的方法； 屈服，不断裂，逐步解决摩擦。 领导即服务方法可以帮助您变得更加灵活。”
-Aaron Longwell， 为什么软件开发需要仆人领导
在生产和工程师之间建立牢固的信任关系也很重要。 如果有信任，那么您可以诚实尽责地谈判最后期限。 如果您已经证明您的团队制造出了很好的软件，那么您应该拥有相当不错的声誉，并且利益相关者应该信任您，并了解到，如果您的进度超出预期，则出于充分的理由和共同的利益。
我个人用作经理的另一个“技巧”并不是要指定特定的日期，因为它们不可避免地会变成艰难的截止日期。 最好给出模糊的日期，例如“三到五个星期”。 在这种情况下，当接近这样一个不稳定的截止日期时，您可以添加：“ 4月或5月”，它很容易解释为4月初的“ 4月15日至5月3日之间”，大约4月10日可以变成“到20岁四月”等 在这种情况下，您无需分散精力，与同事沟通，团队将为解决不可避免的不可预见的问题提供所需的灵活性。
最后，请记住，由开发人员负责发布产品的技术质量，而不是其他有关方面。 组织之间自然会有摩擦，乍一看，这些摩擦是由不同的激励机制引导的。 在这种情况下，最重要的是要注意到你们所有人（大概）是一个共同的目标团结在一起的：在最短的时间内为客户提供高质量的软件。 显然，只有优秀的开发人员才能本着这种精神思考并理解，避免欺骗性的“一次，两次-完成！”方法是很重要的，从长远来看，这是最慢的方法。
总而言之，我将说这是一个可解决的复杂问题。 我想说的是，如果您认为您的经理或您的组织不愿意编写优质的软件，那么您需要谈论一下并尝试对其进行更改； 如果失败，则另谋高就。
关于翻译这篇文章由Alconost翻译。
Alconost以70种语言
本地化游戏 ，
应用程序和网站 。 母语翻译，语言测试，带有API的云平台，持续本地化，24/7项目经理，任何格式的字符串资源。
我们还制作
广告和培训视频 -适用于销售，图像，广告，培训，预告片，专家，Google Play和App Store的预告片的网站。
更多细节