Questions tagged «development-process»

已关闭。这个问题需要更加集中。它当前不接受答案。 4年前关闭。 已锁定。该问题及其答案被锁定，因为该问题是题外话，但具有历史意义。它目前不接受新的答案或互动。 我是清单的忠实粉丝。有旅行清单，移动清单甚至是Scrum清单。 上下文：您已被一家大公司雇用，并承担了建立整个软件开发环境，流程，团队等的任务。您将负责创建软件的工作增量。项目规模：2000人/天。 您将哪些项目添加到以下清单（故意是小的和不完整的）清单中： 安装持续集成服务器 编写国防部 撰写一页编码指南 创建产品积压 安装错误跟踪系统 安排定期面对面时间

14 project-management  development-process 

一个经过良好测试的代码库有很多好处，但是测试系统的某些方面会导致代码库可以抵抗某些类型的更改。 一个示例是测试特定的输出-例如文本或HTML。通常（天真吗？）编写测试以期望将特定文本块作为某些输入参数的输出，或者在块中搜索特定部分。 更改代码的行为以满足新的要求，或者由于可用性测试导致了界面的更改，因此也需要更改测试，甚至可能不是针对更改代码的特定单元测试的测试。 您如何管理查找和重写这些测试的工作？如果您不能只是“全部运行并让框架将它们整理出来”怎么办？ 还有哪些其他类型的被测代码会导致习惯性的易碎测试？

14 development-process  tdd 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 在我目前的工作中，感觉我们有很多需求变更。我们是一家“敏捷”商店，所以我认为我们应该进行调整，而不能进行调整，但是有时候变化很大，没有什么微不足道的。 我的问题是，您如何有效地传达变更成本？由于敏捷，如果更改足够大，将会从当前的sprint中删除某些内容，但是通常只会在下一次添加。由于我们的模型是SaaS，因此最终客户实际上是企业本身，他们知道n周后将获得削减功能。 我想我要了解的是删除某项功能实际上并没有什么用，因为它仅延迟了n周。您还需要通过什么其他方式来使企业了解变更成本？

14 development-process  agile 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 2年前关闭。 形式化方法可用于指定，证明和生成应用程序的代码。这不太容易出错-因此通常用于安全/关键程序中。 为什么我们不经常在日常编程或Web应用程序等中使用它？ 参考文献： 形式方法 B法 霍尔逻辑

14 development-process  code-quality  formal-methods 

我正在阅读《极限编程说明》第二版，在第11章“约束理论”中，作者讨论了过时和过时的“推”开发模型以及XP方式（“拉”开发模型）。它看起来像一个非常重要的概念，但是只用了一个很小的段落和两个图像，它们只是“瀑布”和迭代过程的说明，除了图像标题外，这些模型没有其他具体说明。我进行了搜索，在本书的其余部分中对此没有任何进一步的说明。我也无法在Internet上找到任何进一步的解释或讨论。 如果关于它们的唯一区别是一个是“瀑布”而另一个是迭代的，那么它们为什么推，为什么拉？ 有人知道这两者之间的真正区别是什么，并举一些很好的例子吗？

14 agile  development-process  extreme-programming 

我是软件开发团队的一名软件工程师。最近三年，我们为内部客户开发了新产品。现在该产品完成了，我们将为现有产品开发主要的新功能。对于特定功能，产品管理人员猜测开发需要150个小时。我们与项目经理一起制定了非常详细的计划，我们花了300个小时努力。昨天我们讨论了这个问题，他们认为我们已经严重高估了事情。 在我们的计划中，我们估算了编写单元测试的时间，其目的是丢弃它们以节省时间。尚未做出决定，如有需要，我将捍卫这一计划和单元测试。但是我在这里真正不喜欢的是管理正在干扰我们的开发过程。如何使它们脱离我们的开发流程？我可以使用哪些参数来保持单元测试到位（除了质量和长期节省时间之外）？ 附带说明一下，我们公司有3个工程团队，我所在的团队按时交付了他们的软件（给予或获得10％的利润）。而其他团队总是迟交，这主要是由于对计划的低估。他们只计划编码，而不计划编码的管理，测试和处理。

14 development-process  management 

我正在完成我最早的C ++项目之一（根据框架），该项目应该是跨平台的。我完全在Windows和Visual Studio中开发了该项目，以为既然这些库都是跨平台的，那么“以后”进行OSX构建将是微不足道的。事实并非如此，而是“ Windows代码”无法正常运行，并且需要解决一些编译错误。 预先存在哪些技术可以确保代码与所有平台兼容？同时开发所有平台，从而在添加新功能时针对每个平台同时测试代码，而不是一个接一个地开发不同的平台版本？（*） 从外观上来看，特别建议不要依赖于工具，而可以使用“开发过程”来帮助跨平台兼容性，无论使用什么工具。就像上面的一个（*）。 具体来说，我正在使用WDL-OL（https://github.com/olilarkin/wdl-ol）和一些跨平台DSP库开发VST插件。WDL-OL项目同时设置了VS和Xcode项目，但我想问题出在库中，然后是编译器之间的差异。

13 c++  development-process  cross-platform 

是否有人有使用bugzilla / mantis或JIRA之类的bug跟踪/问题跟踪软件的经验，不仅可以解决bug或任务，而且可以发起并维护最终导致决策的讨论？ 例如，开发人员认为应废除所有受保护的字段，并使用访问它们的受保护方法更改为私有字段。这不是他的电话，他想讨论。通常，他在下一次开发人员会议上提出要点，然后在会议上做出决定。相反，我的想法是让他提出某种“决定”类型的问题并描述他的意图，就像通常描述一个错误或任务一样。 其他开发人员可以根据自己的意愿发表评论，最后，该问题以“已接受”或“被拒绝”结束。 我从中看到的优势： 异步通信：当他们还没有时间监督上述决定的所有后果时，没有人会被迫在会议上发表自己的意见。 导致决定的考虑因素的书面记录。如果后来有人再次提出这个问题，可以向他提出。 可以建立与其他问题的关系，例如可以将一项任务跟踪到一个决策。 与版本控制软件（例如提交）的集成可以追溯到决策。 缺点： 金锤味浓：通常使用问题跟踪软件来跟踪可操作的项目 组织的开销可能不成比例：与人之间无需进行简短的非正式演讲，就必须以书面形式交流自己的想法

13 development-process  tools  issue-tracking 

详细地说，我很想知道人们在一个人的项目中需要采取什么措施（团队源代码控制，文档，构建等），以及直到第二个人来时才需要做的事情进入项目。 任何有过这种情况经验的人，他们的见解将不胜感激。

13 project-management  version-control  development-process  documentation  builds 

我想知道人们在开始实际编写代码之前通常对软件产品的定义有多好，以及它对他们的效果如何？我指的是定义用例，分析风险，绘制类图等。 我知道，对最终产品将在将来能够避免的风险有足够的了解是一个好主意，但是，也不能将产品定义得太好以致于难以适应，这一点也很重要。更改。 其他更具体的问题可能是： 通常在开发之前的计划阶段花费项目时间的百分之几？ 在开始编写代码之前，您是否想满足某些可衡量的标准？或者仅仅是胆量？ 您是在开始编写代码之前就绘制了所有类的图，还是主要是希望从一开始就创建一个动态设计，以期望事情会发生变化？ 您愿意分享的任何经验都将非常棒！

13 project-management  development-process  product-design  product-development 

我的情况简介 我在一家小型Web开发公司工作。我们有一个由四个ASP.NET开发人员组成的团队，其中包括我。我们几乎所有项目（> 98％）都是一个人的项目，大约需要1-4周才能完成。我们不使用源代码或版本控制。我们唯一拥有的是本地服务器上的共享文件夹，其中包含所有项目的最新源（==实时应用程序的源）。 在极少数情况下，我们确实需要与一个以上的人一起从事同一个项目，我们使用...超越比较。开发人员每天一两次询问彼此是否有可编译的版本，然后使用Beyond Compare同步其代码。当只有两个人在一个项目上工作时，这“相当好”，但是一旦第三个开发人员进入流程，它就变成了难以处理的垃圾。尤其是当每个人都开始对数据库进行更改时。 我（和我的一两个开发人员）已经多次告诉我的老板，我们应该开始使用某种形式的源代码和版本控制，例如Git，Mercurial或TFS（我们的老板非常注重Microsoft）。不幸的是，我的老板没有看到切换到源代码和版本控制系统的优势，因为在他看来，现在一切都很好，并且他不想花费时间和金钱来建立新系统并确保每个人都知道如何使用它。即使在我向他解释了优点（例如简化的协作，应用程序的不同版本，更安全的代码更改方式……）之后，他仍然不认为这是我们所需要的。 在这四个开发人员中，只有两个（包括我在内）具有源代码控制（Git）的经验。而且这种经验非常有限。我知道如何将Github存储库克隆到我的计算机上，进行一些更改，提交它们并将其推回到Github。而已。 我的问题/担忧的解释 几周后，我们将开始为我们的标准开展一个相当大的项目。可能需要2-3个开发人员几个月才能完成。我将担任项目负责人（项目经理和首席开发人员），我将负责所有工作。我在使用“超越比较”方法时遇到了很多问题，并且我不想走这个大项目，这是我的责任。 由于我怀疑我们是否能够 设置我们自己的Git服务器， 教大家与Git合作 在这个大项目中成功雇用了Git， 我很感兴趣，如果你们中有人知道一些允许多人在不使用源代码或版本控制的情况下就同一项目进行协作的好方法。 更新资料 我要感谢大家的回答和评论。这是计划： 与开发人员举行会议，以确保所有技术人员对实现源代码控制的感觉相同。当所有人都支持时，我们会提出一个更强的观点。 向老板介绍这个想法，并告诉他我们确实需要源代码控制。 尽快实施。

13 development-process  version-control  teamwork 

似乎很少见，但经常遇到的经验是，有时您正在从事一个项目，突然间突然出现一些意外情况，在工作中投入了大量的扳手，并极大地提高了复杂性。 例如，我正在开发一个与其他各种机器上的SOAP服务通信的应用程序。我提出了一个效果很好的原型，然后继续开发常规前端，并以一种不错，相当简单且易于遵循的方式来启动和运行所有东西。直到我们开始在更广泛的网络上进行测试，突然页面开始超时，因为连接的延迟和在远程计算机上执行计算所需的时间导致对Soap服务的请求超时后，它才开始工作。事实证明，我们需要更改架构以将请求转出到自己的线程上并缓存返回的数据，以便可以在后台逐步更新它，而不是根据请求逐个执行计算。 这种情况的细节不是太重要-确实不是一个很好的例子，因为它是可以预见的，并且为这种环境编写过很多此类应用的人可能已经预料到了-除了它说明了一种方式可以从简单的前提和模型开始，然后突然将复杂性升级到项目的开发中。 您有什么策略来应对这些类型的功能更改，这些功能更改的出现通常是环境因素而不是规格更改的结果，而在开发过程的后期或测试的结果是？在避免过早优化/ YAGNI /过度设计设计解决方案的风险之间，如何设计解决方案来缓解可能（但不一定是）可能的问题，而不是开发一个可能更有效但又没有针对此问题准备更简单的解决方案，这两者之间如何平衡？一切可能的事情？ 编辑：疯狂的埃迪的答案包括“您吸纳它并找到实现新复杂性的最便宜的方法。” 这让我想到了问题中隐含的东西，但我没有具体提出。 一旦遇到困难，就可以进行必要的更改。您是否执行了使项目尽可能接近进度但可能会影响可维护性的事情，还是回到了体系结构并在更详细的级别上对其进行了重新设计，该级别可能更易于维护，但会在开发过程中推迟一切？

13 development-process  complexity  change 

正如我在其他问题中所写的那样，我正在从事的项目现在没有软件过程。这意味着没有文档（包括硬拷贝要求或规范），没有源代码控制，没有错误数据库，（已修复）错误（希望）并且同时添加了新代码，也没有正式的测试人员-我们将在Joel测试中失败太糟糕了，甚至都不好笑。 昨天，我的经理要我写一份有关如何解决这些缺陷的文档。请注意，我只是一个实习生，在这里工作了6个月。我将在十一月感恩节左右回到学校。但是，我认为我也许可以使这个项目朝着正确的方向发展，但是我不确定从哪里开始。我目前正在使用CiteSeer和Wikipedia来查找一些描述软件过程并实现它们的论文，但是任何建议，个人经验或指向博客，论文，Wiki文章或其他任何内容的链接都将不胜感激。

13 development-process  specifications 

在阅读有关语法，词法分析器和语法分析器的澄清问题的答案时，答案指出： BNF语法包含词法分析和解析所需的所有规则。 这对我来说有点奇怪，因为直到现在，我一直认为词法分析器根本不基于语法，而解析器则很大程度上基于语法。在阅读了许多有关编写词法分析器的博客文章之后，我得出了这个结论，而从来没有人使用1 EBNF / BNF作为设计基础。 如果词法分析器以及解析器都基于EBNF / BNF语法，那么如何使用该方法创建词法分析器呢？也就是说，如何使用给定的EBNF / BNF语法构造词法分析器？ 我见过很多，很多的职位，应对写的用EBNF / BNF作为指导或蓝图解析器，但我已经遇到没有到目前为止，显示与词法分析器的设计相当。 例如，采用以下语法： input = digit| string ; digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ; string = '"', { all characters - '"' …

13 design  design-patterns  development-process  grammar  lexer 

我最近看到很多帖子说，使用敏捷的主要原因之一是因为客户经常更改需求。 但是，假设客户不会经常更改需求。实际上，客户的要求虽然严格，但可能有些含糊（但没有任何不合理的含糊），但无论如何，我还是使用敏捷。 我之所以选择敏捷，是因为该软件足够复杂，以至于存在一些细节和问题，直到我真正面对这些问题时我才意识到。我可以像瀑布一样进行全面的繁重计划，但是要花上几个月才能完成所有高级设计和低级代码签名。但是，系统有一个非常具体的固定体系结构设计。 我的问题是：这会被认为是不好的，牛仔编码，反模式等吗？在需求稳定时开始编码之前，我们是否必须采用瀑布式计划并尽可能详细地计划，而不是敏捷中的这种“让我们去做”的心态？ 编辑：这里的主要观点是：我们不能责怪客户改变需求。假设客户向我们指出了一个非常具体的问题，给我们一个非常合理的细节的愿望清单，然后让我们独自一人（即客户有自己的生产性工作要做，别再烦他们了。只向他们演示当您有最低限度的工作原型时结束）。在这种情况下使用敏捷会错吗？

12 agile  development-process