代码之家 › 专栏 › 技术社区 › 13ren

为您的项目创建支持/开发工具-您应该/应该在上面花费多少时间?

devtools project-management

0

13ren · 技术社区 · 17 年前

我关心的是这个第二个项目,试图让它变得完美,并扩展它。。。当主要项目陷入困境时(例如:Knuth花了数年时间撰写“计算机编程的艺术”来创建TeX以帮助他排版)。

我想的不是标准的支持/开发工具,比如构建工具、测试系统、bug追踪器和源代码控制,而是为特定项目创建的,用于支持您自己的开发的工具,只有开发人员才会使用(即,它不是项目的可交付成果)。

3 回复 | 直到 8 年前

1

3

MrTelly 17 年前

很容易被工具创建的乐趣所吸引。我们试图通过查看我们需要编写的工具来管理它,花一些适当的时间寻找我们可以使用的开源软件,或者按照我们的意愿去做,然后才求助于自己的滚动。我们还将此作为一个迭代零练习,使用sprint和scrum——如果一个工具需要一个以上的sprint(2周),那么它就太大了。

2

1

S.Lott 17 年前

这很容易。

编辑

请记住,支持和帮助台是一流的用户。支持用例必须与最终用户用例一起放在混合中。用例按需要进行优先级排序和构建。在某些情况下,可操作性考虑必须优先于用户功能。

编写新的基础架构(语言、编译器、调试器、操作系统、关系数据库管理系统、ESB等)几乎没有必要。

发明一种新的编程语言是让你的爱好接管你的工作的一个例子。如果你不能用世界上前50种语言中的任何一种来做这件事 TIOBE Index

3

1

Community Mohan Dere 9 年前

谢谢你的提问!回复时间长,时间晚,但希望值得一读。

习俗

正道

似乎可以通过一个简单的成本效益分析来决定是否投资脚手架(正如项目管理科学所说):估算开发成本,与预测效益进行比较,如果脚手架的价值大于成本,那么建造脚手架是有好处的:

COST               BENEFIT
Spec         Â£500  Time saved over 2 years Â£3000
Development Â£2000  Savings on training      Â£600
Total:      Â£2500                          Â£3600

       COSTS              BENEFIT
BUILD  Spec         Â£500  Time saved over 2 years Â£3000
       Development Â£2000  Savings on training      Â£600
       Total:      Â£2500                          Â£3600

BUY    License      Â£500  Time saved over 2 years Â£1000
       Setting up   Â£500  Savings on training      Â£300
       Total:      Â£1000                          Â£1300

显然,现成的工具更便宜;然而,它的投资回报率(ROI)只有30%,而自己动手解决方案只有44%。

好吧,如果事情就这么简单就好了,因为在现实生活中,实际成本和收益很难事先确定和量化。如何量化在脚手架上工作而不是在项目可交付成果上工作的开发人员的机会成本?或者在脚手架中加入一些生产知识的好处,这样新手就不必花时间学习手动构建或发布过程?或者,任何人都可以在不到半小时的时间内一步构建任何版本的软件,而不是让高级开发人员花费一天的大部分时间来完成任务,这会带来什么好处?

此外,预测数据和实际数据之间不可避免地会存在一些差异,预期差异越大(也称为风险),你就越不可能依赖这些数据来实现。风险为我们的分析提供了第三个维度,考虑到一些成本和收益是完全不确定的,所以整个成本收益问题实际上开始失控。

实用方法

自动化任务所需的时间是否比手动执行任务所需的时间要长?
在没有脚手架和对高度专业化人才或超人能力的任何要求的情况下,任务能否可靠地完成?
成本是否超过了近期可提取的收益?

一些注释

还有几件事需要记住:

Why I Hate Frameworks
脚手架应与应用程序分开;它并不是一个真正的可交付成果,在大多数情况下,它不应该取代用于维护和配置的部分应用程序。
- 加快发展。
- 避免重复工作。
- 减少人为错误。
- 提供结果的一致性。
- 有助于在团队中保存知识(它永不放弃,而且总是可以反向工程)。
- 提高士气,因为开发人员不必把时间花在平凡的任务上。
通过粗糙的非关键解决方案脚手架可以作为新的工具、技术、技术、想法的试验场,这些想法后来成为杀手级应用程序的基础。 FogBugz 是内部工具的一个很好的例子,最初开发该工具是为了测试FogCreek创始人关于处理软件问题的正确方法的假设,因为他们坚信必须以任何COTS工具都不支持的确切方式来完成。我们都知道,后来脚手架被利用,成为一个独立的旗舰产品)。通过搭建脚手架,你创造了知识产权。
Test Driven Development