最快的时间线和很少的需求的最佳编程方法?[关闭]

你要问的问题不止一个。

1. 快速开发,需求很少=>使用脚本语言进行黑客攻击,假设需求很少或很少,而目前还没有稳定或明确的需求,但将来会有很多需求。
2. 快速开发具有大量不稳定或隐含的需求=>scrum、xp等。专注于原型设计,以便尽快从客户那里获得关于他想要什么的反馈
3. 让管理层改变他们的做法=>让项目尽快崩溃;-)认真地说,这要求你对想要改变的内容更加具体。当然,你的里程数取决于迪尔伯特对你的环境有多喜欢,以及你对实现目标有多愤世嫉俗。
4. 让人们停止在一个文件中编写5千行程序=>向他们展示这对您来说是什么样的问题,如何编写更好的结构化程序同样容易,展示他们可能从中获得的好处,并尝试就更好的做法达成一致。

运行…像地狱一样

Scrum 很好地用于这些项目。它很好地提供了一种说服管理层您可以按时拥有项目,或者您可以拥有您想要的所有特性,但不能同时拥有这两者。

使用武力。

但说真的,这听起来像 Death March . 逃跑。

一般来说,项目有三个组成部分, 时间 , 质量 和 钱 .

看来你的客户/老板想控制时间…他应该再控制一个,另一个你要控制。

因此,如果他想控制时间和质量,他需要为你和/或你的团队支付更多的钱,让你投入更多的额外时间。如果他想控制时间和金钱,你就要控制质量,在这种情况下质量会很低。

我们总是告诉我们的客户,他们可以拥有它,或者他们现在可以拥有它,但是 他们现在不能吃 !

我认为方法论无关紧要…真正的问题是时机。

这里没什么新鲜事!

我发现一种叫做 Evolutionary Prototyping .

最好的方法是实现您对客户想要什么的想法,然后将其呈现给他,得到他的意见,并相应地调整您的实现。当客户最终满意时,您的实施就完成了。有趣的是:记录下来!

我不想冒失,但似乎大多数人都对你想要的答案感到困惑。大多数答案似乎都围绕着项目管理方法,而不是编程方法。

考虑到您的情况,我认为Scrum和敏捷类型的方法(比如开放式)从项目管理方法中可以很好地工作。事实上,我会坚持只使用scrum,因为它听起来不像在项目的结构方面有太多的障碍。它将使事情保持良好和精益,并应将注意力集中在手头的任务上。您只需要确保遵循Scrum的一些基本规则,这些规则可以识别您的任务、估计您的任务、描述您的任务、计划您的迭代,如果可能的话,还可以执行Sprint回顾。如果你真的很准时,那么我相信你可以把这个扔掉。

为了回答您的实际问题(我无论如何都看到了),我建议您采用一种使用CRC的域驱动方法( C 少女 R 额外负担 C 作为你的设计机制的卡片。我假设您的应用程序存在一些有限的域,如会计、库存管理等。尝试将您的域分解为域中存在的对象,即“库存项目”、“发票”、“交货”等真实世界对象。然后为每个这些对象创建一个CRC卡,在其中定义其名称、响应。与之合作履行职责的能力和其他类别。然后编写实际类来表示应用程序中的这些CRC卡。

避免创建任何带有管理器后缀或coordinator的类或这些行中的任何内容。您最终应该得到的是一组表示域的对象,您可以轻松地修改这些对象,而不需要进行大规模的重构来执行在该域中发生的任何类型的活动。您可以很容易地通过改变需求来适应这样一个构建的解决方案,因为域对象应该保持静态,除非您添加了更多的对象或者您的域变宽了。

希望这对你有用。

做任何类似于合理定制开发的事情的最快方法是与您和客户一起开发。反馈是即时的,他们可以准确地看到所涉及的内容。否则,你只是为了他们更方便的关注交易速度。而且,由于他们直接与你合作,他们可能会为你的管理层辩护。

但是,如果没有进一步的背景,我必须同意其他人的观点,并说这可能不是最有利于职业发展的情况。

如果“缺乏需求”确实是事实,那么您甚至不应该启动一个项目。我相信你的意思是“需求不清楚或不确定”。如果这是您的情况,那么敏捷过程就是您应该考虑的。XP、Scrum或Crystal。毫无疑问,Scrum是最轻量的敏捷过程。

管理层可能和工程师有不同的想法,但你不能说管理是错误的,他们的做法应该改变。只是多沟通,以提高理解和解决冲突。

为了防止人们写不可读的代码,最好的方法是训练人们以简洁的方式写代码。结对编程和连续的代码审查可能是一个很好的解决方案。

我想应该是Scrum,但请记住,Scrum需要非常有纪律的团队成员。养成记录你的需求的习惯,把它们放在一个地方,这样每个人,包括管理层,都可以访问它。最后,找到一种合理的方法来预测任务,并将其放在管理层面前,这样他们就能知道团队中每个人当前的优先级。去年我在一个非常相似的环境中,不幸的是我没有发现一颗魔法子弹。

写5000行程序完全是懒惰的表现。我们最近让一个家伙走了,因为他首先从5000行Java类开始,然后使用Test/catch语句来初始化构造函数中的变量(不要问)。找到一种方法,用一些建设性的批评来激励编写5000行程序的人。不过,这听起来像是一个核心管理问题。

scrum或xp在这种情况下工作得很好;如果您能够解决“基本”系统的一些最低要求集并在此基础上进行构建,那么您就可以对这样一个事实作出反应:即使提供了预先需求,它们几乎总是错的。

写5000行单文件程序的人是不守纪律和不好的程序员。因为xp和scrum都需要规程来建立一个可以维护和构建的系统,所以我不确定如果这是您必须要使用的,如何继续。我的 猜测 至少是试图让他们相信他们的方法是错误的。

好的,Scrum看起来很有趣……当办公室位于不同的位置时,它能被实现吗?