Questions tagged «development-methodologies»

16
一个人的最佳开发方法？
我在很多项目上花费了大量时间，在这些项目中，我是唯一的开发人员，项目经理，设计师，QT人员（是的，我知道...很糟糕！），有时甚至是客户。 我已经尝试了几乎所有用于计划项目和管理自己的事情，从坐下来自由工作直到项目完成（无论花费多长时间），再到单人版的Scrum，我在其中与自己举行了一次进度会议。每天早上烧毁图表（不是在开玩笑）。 对于那些花费大量时间独自工作的人，什么是组织自己，管理大型（一个人）项目并保持尽可能高的生产率的最佳方法？
10
为什么敏捷只涉及测试驱动开发（TDD）而不是开发驱动测试（DDT）？
因此，我是敏捷的新手，但不是测试驱动的开发。我在大学里的教授都是关于测试的思想，然后是代码然后是测试。我不确定我理解为什么。从我的角度来看，随着代码的发展，很可能会改变很多前期成本。 这就是我对TDD的想象以及为什么让我感到困惑。如果我要作为TDD承包商来盖房子。 给我您所有的规格（故事）。 获得有关规格的批准。 将所有规格分解为我认为需要的检查（展望未来）。 打电话给检查员看一下这些要点，然后告诉我，我现在检查不及格（谢谢）。 开始盖房子。 每天召回检查员（通过2/100）。 抱歉，我的理解存在问题，现在我需要再添加9个检查并更改其中的27个。 呼叫检查员通过1/109。 该死的。检查员为什么不喜欢这个...哦，我更新了该方法名称... 建立更多。 UGGGGHHHH更多更改让我更新了该死的检查器。哦，我没有失败。 我做完了吗 好的，那可能有些古怪，但是直到我的代码在那里，我才看不到如何知道所有方法以及事情将如何工作。99％的时间我必须返回并以任何方式更新单元测试，并在添加时添加更多内容。似乎倒退了。 似乎更合适的是DDT或开发驱动的测试，这似乎是社区几乎忘却的事情。 据我了解，房屋的滴滴涕看起来像： 给我您所有的规格（故事）。 获得有关规格的批准并将其发布。 启动一个单元（基础）。 记下一些棘手的逻辑（注释）。 在开始下一个单元的最后，进行检查（创建测试）。 解决发现的所有问题，然后再次检查。 批准将本单元移至下一个。 如果我们都说实话，这听起来不是更人性化，而是集中在开发人员和业务上吗？似乎可以更快地进行更改，而且似乎不会产生开销的TDD。
25
坦白说，您喜欢牛仔编码吗？[关闭]
大多数程序员捍卫政治上正确的方法论，例如敏捷，瀑布式，RUP等。其中一些遵循方法论，但并非全部遵循。坦白说，如果您可以选择方法论，那么您肯定会采用主流的“正确”方法论，或者您更喜欢像牛仔编程这样的“简便”方法论？为什么？ 我知道这取决于。请说明何时使用一种或另一种。请说出您在Cowboy编码方面看到的优势。 在Wikipedia上了解有关Cowboy编码的信息
10
毕业生期望与现实[关闭]
当选择我们想要学习的东西，以及我们的职业和生活时，我们都对它会是什么样子抱有一些期望。现在我从事该行业已经有近十年了，我一直在反思自己的想法（当时我在学习计算机科学时），编程的工作生活将是什么样子，以及它实际上如何变成是。 到目前为止，我的两个最大的震惊（或者应该说是打破期望）是软件涉及的大量维护工作以及总体上缺乏专业精神： 维护：在uni，我们都被告知大多数软件工作是对现有系统的维护。因此，我知道可以抽象地期望这一点。但是我从未想过这到底会是多么令人难以置信。也许这是我精神上的困惑，并希望我能从头开始构建更多新颖的东西。但是，实际上大多数工作都是以维护，错误修复和支持为导向的。 缺乏专业素养：在uni，我始终给人以商业软件工作非常注重流程和严格设计的印象。我有ISO流程的图像，大量技术文档，严格记录了每个功能和错误以及普遍专业的环境。震惊的是，意识到大多数软件公司的运作方式与一个为期一个学期的大型项目的学生团队没有什么不同。我曾经在小型敏捷黑客商店和中型企业中工作过。虽然我不会说它一直都是完全“不专业”的，但绝对可以感觉到软件行业（总体上）与我期望的强大工程学相去甚远。 其他人有类似的经历吗？您对我们职业的期望与现实有何不同？
9
敏捷开发方法是否有可行的替代方案？
两种主要的软件开发方法是瀑布式和敏捷式。在讨论这两者时，通常会着重于将它们区分开的特定实践（结对编程，TDD等与功能规范，大型前期设计等）。 但是真正的差异要深得多，因为这些实践来自一种哲学。 Waterfall说： 更改成本很高，因此应将其最小化。 敏捷说： 改变是不可避免的，所以要使改变便宜。 我的问题是，不管您如何看待TDD或功能规格，瀑布式开发方法真的可行吗？ 真的有人认为对于希望交付有价值的软件的人来说，最小化软件更改是一个可行的选择吗？还是真正的问题是，哪种方式在我们的情况下最能应对不可避免的变化？
7
如何衡量重构的潜在价值
在具有技术债务的旧的大型项目中，如何可靠地估算或衡量重构代码的收益？ 例如，假设您在软件堆栈解决方案中有一些组件是用较旧的语言编写的，而某些较后的组件是用较新的语言编写的。开发团队将不断向该解决方案添加新功能和错误修复。 开发人员建议用新版本替换现有的旧语言组件将是“一件好事”。但是，这项工作不会增加任何额外的功能，这将花费x开发日。 销售人员建议添加“一项很棒的新功能”。公司通过使用公式来衡量他的建议的价值。即。它将在t年内以x开发日的工作成本为公司赚取F百万英镑。 公司如何以有意义的方式增加重构建议的成本？在什么情况下，这可能是公司最赚钱的选择？
17
每日站立-是或否？[关闭]
您认为每日站立会议有多有价值（或没有）？ 如果您不熟悉它，则指的是Scrum拥护者（以及其他一些敏捷方法论）中的日常会议。这个想法是，您每天召开一次会议，时间限制为15分钟，每个人都必须参加会议（以鼓励人们直截了当）。 在会议上，您到处走走，每个人都说：-昨天您做了什么-您今天打算做什么-任何阻碍或阻碍您前进的障碍。 您认为这种做法有价值吗？有没有人在一个做过的地方工作，您觉得呢？
9
如何在团队中应对不同的开发风格（自上而下与自下而上）？
假设您刚开始在一个非常小的团队中从事{目前相对较小，但希望以后会更大}的项目。请注意，这是一个旨在供现实世界中的其他开发人员使用的实际项目，而不是一些打算在学期末取消的学术项目。 但是，该代码尚未发布给其他人，因此尚未确定任何决定。 方法论 你们中的一个喜欢在开始编写代码并使各部分组合在一起之前，必须对所有组件的交互方式（自下而上的设计）有个清晰的认识。你们中的另一个人喜欢先进行整个设计，然后在编码解决方案之前确定所有组件和通信的细节。 假设您正在开发一个新系统，而不是模仿现有系统，因此，正确的最终设计应该是什么样子并不总是显而易见的。因此，在您的团队中，不同的团队成员有时甚至对最终产品所需的要求有不同的想法，更不用说如何进行设计了。 当自下而上的开发人员编写一些代码时，尽管该代码可能会解决手头的问题，但自上而下的开发人员还是会因为设计中可能会遇到的未来问题而拒绝该代码，并认为正确设计更重要在尝试编写解决方案的代码之前。 当自上而下的开发人员在开始编写代码之前尝试设计出完整的设计和设想的问题时，自下而上的开发人员会拒绝它，因为自下而上的开发人员并不认为实际上会出现某些问题，并认为，当要求和约束变得更加清晰时，将来可能需要更改设计。 问题 这导致的问题是自下而上的开发人员最终浪费了时间，因为自上而下的开发人员经常由于设计缺陷而决定废弃自下而上的开发人员编写的解决方案，从而需要重新设计。 -编写代码。 自上而下的开发人员最终浪费了时间，因为自上而下的开发人员现在经常坐下来与自下而上的开发人员一起制定正确的设计，将两者序列化到甚至更快的程度比2人多做1人。 两位开发人员都希望继续合作，但似乎合并实际上并没有帮助他们中的任何一个。 目标 显然，共同的目标是最大程度地提高编码效率（即，将时间浪费最小化）并编写有用的软件。 问题 简而言之，您如何解决这个问题并应对这种情况？ 我能想到的唯一有效的解决方案不会浪费时间，就是让每个开发人员都遵循自己的设计风格。但是，这比您进行代码审查并实际上需要批准彼此的更改以及尝试设计一个供他人使用的一致框架时听起来的困难。 有没有更好的办法？
8
测试驱动开发（通常是敏捷）的这种局限性在实际上是否相关？
在测试驱动开发（TDD）中，您从次优解决方案开始，然后通过添加测试用例和重构来迭代地产生更好的解决方案。该步骤应该很小，这意味着每个新解决方案都将以某种方式位于前一个解决方案的附近。 这类似于数学上的局部优化方法，例如梯度下降或局部搜索。这种方法的一个众所周知的局限性是它们不能保证找到全局最优值，甚至不能保证找到可接受的局部最优值。如果您的起点与所有可接受的解决方案之间有很大范围的不良解决方案，则无法到达此目标，该方法将失败。 更具体地说：我正在考虑一个场景，在该场景中，您已经实现了多个测试用例，然后发现下一个测试用例将需要一种完全不同的方法。您将不得不放弃以前的工作，然后重新开始。 这种想法实际上可以应用于所有以小步骤进行的敏捷方法，而不仅仅是TDD。TDD与局部优化之间的拟议类比是否存在严重缺陷？
5
一个团队进行设计，另一个团队进行编码
我将参与一个项目，该项目的所有软件设计均由本地团队进行，然后将这些设计发送给离岸团队进行编码。 这是我第一次面对具有这种特征的项目，这对我来说有点奇怪：经理们希望我们制定非常详细的设计文件，因此离岸团队没有错误的余地。从我的角度来看，它们使我们可以在纸上进行编码，而我们可以在IDE中进行编码。 所以，我的问题是这种方法是好的还是正确的？我们的软件流程要在项目中取得成功，必须考虑哪些主要考虑因素？
9
我对软件工程有错误的想法吗？[关闭]
按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 我最近的工作（而不是实习生）提出了一个问题。 只是为了说明背景-我21岁，我已经完成了第二年的大学学习，在此之前，我拥有大约2年的从事系统管理员/质量检查工作的经验，基本上我可以说我已经看到了与众不同IT部门运作。回顾现在，这是我在英国一家主要研究机构之一从事实习工作。 我要做的是使用多种技术（主要是AWS / Java / Bash）创建一些内部工具，您就会明白。一切都很好，我正在做我的工作，但我不高兴。为什么会这样-因为希望我可以临时工作。那就是快速创建事物，而无需花费时间进行设计。我的经理明确表示，希望从出现的问题中“匆忙”解决，而本质上是我们。结果，结果是必须重新做事和重新设计，它们仍然不是完美的。就测试而言-将其保持在最低水平，只要看起来可行，就可以了。 我是否有责任不同意这种工作方式？想对整个系统进行思考，然后关注不同的组件并了解它们如何互操作，将不同的“关键点”归零，这在将来会带来问题，这是错误的吗？做好工作而不是“快速工作”是犯罪吗？想要研究适用于问题的数据结构，以便您可以根据特定问题集选择最佳方案，这是错误还是错误的态度？据我所知，“软件工程”中的“工程”部分与此完全相关-研究您的问题领域并提出一个明智的解决方案，然后根据需要进行改进？ 我去过英国某军械库办公室的一次采访，他们给我看了他们的SCRUM室，看起来他们对如何管理他们的项目有很好的主意-他们积压，他们有关于每个人待多长时间的指标这个问题可能需要解决-SCRUM的常规操作-与“在这里”运行的方式完全不同 我对软件行业总体上是否建立了错误的观念？我想听听您的意见。我的意思是说我“进入”软件开发纯粹是因为我想创建简单而简单的东西，但我想创建高质量的东西。我想查看我的软件在各种情况下使用的情况，我想查看它的防弹功能-这不是所有软件工程师的动力吗？我认为每个人都可以通过学习语法来成为一名程序员/编码器，但对我而言，真正的乐趣始于当您实际上不得不提出一种在现实世界中可行的设计时。 我过去只是看大学就直接做编码，然后很容易就获得了75％以上的分数，而且从来没有真正欣赏过“软件开发生命周期”模块。但是现在，当我看到在现实世界中，没有任何正式流程就工作有多么糟糕，以及在明天不知道需求是否会改变的情况下固有的沮丧感（哦，我是否说我们不没有明确定义的需求分析？） 我真的很想相信我刚刚担任的职位，有些人只需要一个代码猴子来完成他们的肮脏工作，而软件世界的运作情况却并非如此。
1
什么是开发人员无政府状态？
我一直在阅读有关开发人员（或程序员）无政府状态的信息，该技术似乎被认为是后敏捷开发方法。我发现它（一些资源1，2），但它似乎并没有很多在那里。 我想知道是否有人有什么好的资源可以在其中找到更多信息-如何实现，优缺点，与其他方法的比较等。
11
是否可以编写不需要不断修改的软件？
我已经用许多不同的语言编写了许多软件，并且还“编写”了与使用Verilog和VHDL的FPGA一起使用的硬件。 我倾向于更喜欢编写硬件而不是编写软件，我认为主要原因之一是可以编写“完成”并且不需要修改的硬件：定义接口和功能，编写测试平台，实施硬件模块，然后使用模拟器测试其功能。然后，您可以依靠该硬件模块作为构建块来创建更大更好的产品：如果需要向该模块添加功能，则可以创建第二个模块并在其中添加功能。您永远不会丢掉原始模块，因为它可以正常工作并且仍然有用。 我对软件的主要不满之一是它永远不会“完成”。总有另一个功能要添加。通常，添加功能时会在以前正常工作的其他地方引入错误。只要不违反接口，在硬件中就不会发生这种情况。 明确地说，我并不是在建议使用某些功能列表来构建某个版本，而仅此而已：永远是这样：我赞成随着时间的推移进行迭代和发行多个版本以添加新功能。我只是不想在左侧戳代码而在右侧找到错误，而这似乎是在添加新功能之后发生的。 是否可以通过类似于“编写”硬件的方式来编写软件？有没有一种好的软件开发方法，可以始终取得向前的进展，并允许添加新功能而无需重写现有代码和引入新的错误？
7
您在敏捷的前几个迭代中提供了什么？
据我了解，敏捷方法论的思想是，您交付的是功能性的东西，并且您经常交付。递增后，应用程序进入其最终形状递增。 但是在早期的迭代中，您可能会构建应用程序所依赖的框架或基础，因此它很重要，但对用户不可见。 在这些最初的迭代中，什么交付给客户？在构建脚手架代码时，如何显示正确方向的进度？
7
Scrum冲刺是否意味着以最快的速度工作？
想要改善这篇文章吗？提供此问题的详细答案，包括引文和答案正确的解释。答案不够详细的答案可能会被编辑或删除。 我最近采访了一些从事敏捷，Scrum的公司，以进行更精确的介绍，有些事情在我看来并不像敏捷。现在，我将考虑一个特别令我感兴趣的案例，即Scrum冲刺。 我与一位特定的项目经理交谈（是的，我说项目经理）自豪地说，她的团队中的人们理解（“被告知”这是我从上下文中挑选的），当工作时间结束时，您不回家，无论完成多少工作，您都会在工作完成后回家。我在这两行之间读到的是，我们将尽可能多的功能组合到sprint中，并加班以实现它。 现在，我还没有做敏捷（与大多数仍然喜欢瀑布的金融和政府机构合作），但是我的理解是： Scrum中的sprint是敏捷中通用迭代的名称； 团队应该以可持续的速度工作，并尽量避免长期加班，因为这只会在短时间内产生影响，并且这种影响因长期存在的问题而相形见war。 我的陈述正确吗？而且，我是否应该将经理的介绍作为危险信号？
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.