My advice is not to be extreme. From my experience, pure agile or pure traditional will not work. Before you use any process, know what it mean to solve.
I personally use a variation of Agile RUP. I do some upfront effort such as investigate the actual needs, do high-level design with possible extension. And ask customer to sign-off some major high-level requirements.
If you work in small group, detail design or specification may not worth. Of course, if there is some libraries that are shared by many, it will be worth the trouble.
Deciding what to invest in up-front depending on its risk (likelihood and effect).
Moreover, many SW best practice is really 'best' like version control, automatic testing (to me I only used it way to early detect regression as I do not believe in TDD as driven force of the development). I suggest you read 'Pragmatic Programmer' it presents many of those techines.
As to answer you questions:
(1). Is it possible to have a development process in a place like this?
Yes, but as I say, trailer it to fit your organization.
(2). Would it help to have some sort of management? What kind of?
Management helps but no control freak. Plan what to do when: integrate, resolve conflict, dead line of some mile stone. And roughly keep them on schedule (I particularly like Scrum's sprint).
(3). Is it possible to make quality products with small resources?
Definitely as soon as the size of the work, the time to develop and the size of the team is balance. If you definition of Quality is the same with me. To me, Quality means: solve the problem it set out to in an efficient and reliable fashion.
(4). How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?
Point out the problems. If there are none, why change? If you want to change, you should be able to identify the problem OR potential problems. Point out the problem.
Some big one are:
Without any process, it is harder for new recruited to blend in as they must learn from observing other how to deal with things.
Without process, it is harder to work in stress.
Without schedule, it is hard to determine the progress.
Without automatic testing, it will takes more time to identify problems and regression.
Without version control, it will be harder to roll-back mistake and separation of work to each team members will be mess.
You need to work with the owner and setup short medium and long term goals. You will want to let them know progress even if only through email.
You will need to enforce some order on your workday or you will never get anything done (those long term goals).
Divide your day up into chunks when you can code, when you are working on hacks to keep it togther, when answering emails etc.
Definitely setup a bug tracker. This can help keep your email clean. You can even setup an email address to forward bugs to be categorized later. This is good because the bug reporters will eventually tire of the bug tracker and want to just email you the bugs anyway.
edit
And as lod3n said, source control, but you are using that already right???!!?!
The book Planning Extreme Programming helped a lot. I used 3x5 cards stuck on a wall. This kept my boss informed of my progress, helped with estimates and planning, and kept me on track. The Planning Game gives good ammo if your boss's expectations are unrealistic.
Unit testing, as others have stated, helps even if you're a sole developer. I find the TDD style valuable.
lod3n is absolutely right about Source Control.
I've gone with XP-style iterations before; you may want to establish a backlog of items (even something simple like a spreadsheet or 3x5 cards) as well.
Avoid deathmarches. Stick to 40 hours in the sense of not working overtime 2 weeks in a row. Spend extra time outside of work learning new skills - not just technologies, but principles and best practices.
as crazy as this sounds I use scrum just because I like the concepts of sprints, and backlogs. It makes it easier to set realistic goals. Of course the idea of scrum master and team is all you but if you are working on outside projects where it is possible that you may pick up an extra team member with your backlogs it will be easy to distribute work. Maybe I just like backlogs. With scrum you will need to get someone to be the product manager to talk about the features of the product. Version control is a must at probably should be implemented b4 even worrying about a software development process. I have worked in a company that started from 2 developers and went to 12 in a year. We started with no version control and low coding standards. The changes you will need to make will be gradual so don't worry about rushing to do a 180. Set a goal to change one thing a month and find supporters of your changes to make things go smooth.
As well as the recommedations of others I'd say that if you are tight on resources but have more say over how things get done you should make good use of off the shelf and open source products and libraries. This leverages the efforts of others, saving you time, ensures your code base doesn't become too esoteric and adds to your skillset so you don't end up being an expert in something that's useless everywhere else.
First, lets make a distinction between a development process and best practices. Best practices like source control, defect tracking, unit testing, etc. are an given.
Then there is the actual development processes. I would always recommend having a process, no matter small or large the team is. The trick is finding the right process. You have a process now - it is just an ad-hoc process that doesn't seem to be working out too well for for you. Rarely can you take a textbook development process and directly apply it. What you need to do is tailor the process to your companies needs and culture. Look at as many development paradigms as you can and try to find something that is a good fit and them start molding it to your needs. You may have to try and fail with a number of different processes. Perhaps the Personal Software Process will be a good starting process, maybe an agile process, a variant of RUP? You have a lot of options, start trying them out.
You are also going to have to work with the rest of your organization - they need to be a part of the process. You may be the lone developer, but a development process involves more than the developer, it involves ever person that has a say or impact in the product.
This may not be a specific answer, but my point is that you will need some kind of process. So start researching them and trying them out and molding them to your needs until you have something that works.
发布评论
评论（9）
我的建议是不要走极端。根据我的经验，纯粹的敏捷或纯粹的传统都是行不通的。在使用任何过程之前，请先了解解决问题的含义。
我个人使用
Agile RUP的变体。我做了一些前期工作，例如调查实际需求，进行可能扩展的高层设计。并要求客户签署一些主要的高级要求。如果您在小组中工作，详细设计或规范可能不值得。当然，如果有一些库是多人共享的，那就值得了。
根据风险（可能性和效果）决定预先投资什么。
此外，许多软件最佳实践确实是“最佳”，例如版本控制、自动测试（对我来说，我只使用它来早期检测回归，因为我不相信 TDD 作为开发的驱动力）。我建议您阅读“实用程序员”，它介绍了许多这样的技术。
至于回答你的问题：
（1）。在这样的地方可以有开发流程吗？
是的，但正如我所说，拖放它以适合您的组织。
（2）。进行某种管理会有帮助吗？什么样的？
管理有帮助，但没有控制狂。计划何时做什么：整合、解决冲突、某个里程碑的最后期限。并大致让它们按计划进行（我特别喜欢 Scrum 的冲刺）。
（3）。是否可以用少量的资源生产出优质的产品？
当然，只要工作规模、开发时间和团队规模达到平衡。如果你对质量的定义和我一样。对我来说，质量意味着：以高效、可靠的方式解决它提出的问题。
（4）。我如何说服自己和其他人，这家已经成功运营了几十年的公司需要改变？什么是必不可少的？
指出问题所在。如果没有，为什么要改变？如果你想改变，你应该能够识别问题或潜在的问题。指出问题所在。
一些重要的问题是：
如果没有任何流程，新员工就更难融入，因为他们必须通过观察他人来学习如何处理事情。
没有流程，就更难在压力下工作。
没有时间表，就很难确定进度。
如果没有自动测试，将需要更多时间来识别问题和回归。
如果没有版本控制，就很难回滚错误，每个团队成员的工作分离也会很混乱。
如果没有版本控制，就很难回滚错误，每个团队成员的工作分离也会很混乱
只是我的想法。
My advice is not to be extreme. From my experience, pure agile or pure traditional will not work. Before you use any process, know what it mean to solve.
I personally use a variation of
Agile RUP. I do some upfront effort such as investigate the actual needs, do high-level design with possible extension. And ask customer to sign-off some major high-level requirements.If you work in small group, detail design or specification may not worth. Of course, if there is some libraries that are shared by many, it will be worth the trouble.
Deciding what to invest in up-front depending on its risk (likelihood and effect).
Moreover, many SW best practice is really 'best' like version control, automatic testing (to me I only used it way to early detect regression as I do not believe in TDD as driven force of the development). I suggest you read 'Pragmatic Programmer' it presents many of those techines.
As to answer you questions:
(1). Is it possible to have a development process in a place like this?
Yes, but as I say, trailer it to fit your organization.
(2). Would it help to have some sort of management? What kind of?
Management helps but no control freak. Plan what to do when: integrate, resolve conflict, dead line of some mile stone. And roughly keep them on schedule (I particularly like Scrum's sprint).
(3). Is it possible to make quality products with small resources?
Definitely as soon as the size of the work, the time to develop and the size of the team is balance. If you definition of Quality is the same with me. To me, Quality means: solve the problem it set out to in an efficient and reliable fashion.
(4). How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?
Point out the problems. If there are none, why change? If you want to change, you should be able to identify the problem OR potential problems. Point out the problem.
Some big one are:
Without any process, it is harder for new recruited to blend in as they must learn from observing other how to deal with things.
Without process, it is harder to work in stress.
Without schedule, it is hard to determine the progress.
Without automatic testing, it will takes more time to identify problems and regression.
Without version control, it will be harder to roll-back mistake and separation of work to each team members will be mess.
Just my though.
您需要与业主合作并设定短期、中期和长期目标。即使仅通过电子邮件，您也会想让他们知道进展情况。
您需要在工作日执行某些命令，否则您将永远无法完成任何事情（那些长期目标）。
将你的一天分成几部分，当你可以编码时，当你在进行黑客工作时，当你回复电子邮件时等。
一定要设置一个错误跟踪器。这可以帮助保持您的电子邮件干净。您甚至可以设置一个电子邮件地址来转发错误以便稍后进行分类。这很好，因为错误报告者最终会厌倦错误跟踪器，并且只想通过电子邮件向您发送错误。
编辑
正如lod3n所说，源代码控制，但你已经在使用它了？？？！！！？！
You need to work with the owner and setup short medium and long term goals. You will want to let them know progress even if only through email.
You will need to enforce some order on your workday or you will never get anything done (those long term goals).
Divide your day up into chunks when you can code, when you are working on hacks to keep it togther, when answering emails etc.
Definitely setup a bug tracker. This can help keep your email clean. You can even setup an email address to forward bugs to be categorized later. This is good because the bug reporters will eventually tire of the bug tracker and want to just email you the bugs anyway.
edit
And as lod3n said, source control, but you are using that already right???!!?!
去过那里，做过那件事。
规划极限编程这本书有很大帮助。我使用了贴在墙上的 3x5 卡片。这让我的老板了解我的进展，帮助进行估算和规划，并使我保持在正轨上。如果你老板的期望不切实际，规划游戏可以提供很好的弹药。
正如其他人所说，即使您是唯一的开发人员，单元测试也会有所帮助。我发现 TDD 风格很有价值。
lod3n 关于源代码控制的说法绝对正确。
我以前也尝试过 XP 风格的迭代；您可能还想建立积压的项目（甚至是电子表格或 3x5 卡片等简单的项目）。
避免死亡行军。坚持40小时，即连续两周不加班。在工作之外花额外的时间学习新技能——不仅仅是技术，还有原则和最佳实践。
Been there, done that.
The book Planning Extreme Programming helped a lot. I used 3x5 cards stuck on a wall. This kept my boss informed of my progress, helped with estimates and planning, and kept me on track. The Planning Game gives good ammo if your boss's expectations are unrealistic.
Unit testing, as others have stated, helps even if you're a sole developer. I find the TDD style valuable.
lod3n is absolutely right about Source Control.
I've gone with XP-style iterations before; you may want to establish a backlog of items (even something simple like a spreadsheet or 3x5 cards) as well.
Avoid deathmarches. Stick to 40 hours in the sense of not working overtime 2 weeks in a row. Spend extra time outside of work learning new skills - not just technologies, but principles and best practices.
拥有一个错误跟踪系统，包括缺陷和新功能。不要依赖你的记忆。
持续集成和自动化构建甚至可以帮助单个开发人员。
对于源代码控制的建议怎么强调都不为过。
Have a bug tracking system, both for defects and new features. Don't rely on your memory.
Continuous integration and an automated build can help even a single developer.
Can't emphasize the recommendation for source control enough.
我决定不需要单元测试，因为我可以进行自动化功能/集成测试：因为增量开发没有集成前需要测试。
I've decided I don't need unit tests because I can have automated functional/integration tests instead: because with incremental development there's no need to test before integration.
尽管这听起来很疯狂，但我使用 Scrum 只是因为我喜欢冲刺和积压的概念。它使设定现实的目标变得更加容易。当然，Scrum Master 和团队的想法是你的全部，但如果你正在从事外部项目，你可能会根据积压工作挑选一名额外的团队成员，这将很容易分配工作。也许我只是喜欢积压。使用 Scrum，您需要找人担任产品经理来谈论产品的功能。版本控制是必须的，即使担心软件开发过程，也可能应该实施版本控制。我曾在一家公司工作过，该公司最初只有 2 名开发人员，一年内增加到 12 名。我们一开始就没有版本控制和低编码标准。你需要做出的改变是渐进的，所以不要担心急于做 180 度转变。设定一个目标，每月改变一件事，并找到你的改变的支持者，以使事情顺利进行。
as crazy as this sounds I use scrum just because I like the concepts of sprints, and backlogs. It makes it easier to set realistic goals. Of course the idea of scrum master and team is all you but if you are working on outside projects where it is possible that you may pick up an extra team member with your backlogs it will be easy to distribute work. Maybe I just like backlogs. With scrum you will need to get someone to be the product manager to talk about the features of the product. Version control is a must at probably should be implemented b4 even worrying about a software development process. I have worked in a company that started from 2 developers and went to 12 in a year. We started with no version control and low coding standards. The changes you will need to make will be gradual so don't worry about rushing to do a 180. Set a goal to change one thing a month and find supporters of your changes to make things go smooth.
除了其他人的建议之外，我想说的是，如果您资源紧张，但对如何完成工作有更多发言权，您应该充分利用现成的开源产品和库。这会利用其他人的努力，节省您的时间，确保您的代码库不会变得太深奥，并增加您的技能，这样您最终就不会成为在其他地方无用的东西的专家。
As well as the recommedations of others I'd say that if you are tight on resources but have more say over how things get done you should make good use of off the shelf and open source products and libraries. This leverages the efforts of others, saving you time, ensures your code base doesn't become too esoteric and adds to your skillset so you don't end up being an expert in something that's useless everywhere else.
首先，让我们区分开发过程和最佳实践。源代码控制、缺陷跟踪、单元测试等最佳实践都是给定的。
然后是实际的开发过程。我总是建议建立一个流程，无论团队规模是小还是大。诀窍是找到正确的流程。您现在有了一个流程 - 这只是一个临时流程，似乎不太适合您。您很少能采用教科书的开发过程并直接应用它。您需要做的是根据您公司的需求和文化定制流程。尽可能多地查看开发范例，并尝试找到最适合的开发范例，然后他们就会开始根据您的需求进行塑造。您可能必须尝试许多不同的过程，但都失败了。也许个人软件流程将是一个很好的起始流程，也许是一个敏捷流程，RUP 的一个变体？你有很多选择，开始尝试吧。
您还必须与组织的其他部门合作 - 他们需要成为流程的一部分。您可能是孤独的开发人员，但开发过程涉及的不仅仅是开发人员，它还涉及对产品有发言权或影响力的每个人。
这可能不是一个具体的答案，但我的观点是你需要某种过程。因此，开始研究它们并尝试它们，并根据您的需求进行塑造，直到您找到可行的东西为止。
First, lets make a distinction between a development process and best practices. Best practices like source control, defect tracking, unit testing, etc. are an given.
Then there is the actual development processes. I would always recommend having a process, no matter small or large the team is. The trick is finding the right process. You have a process now - it is just an ad-hoc process that doesn't seem to be working out too well for for you. Rarely can you take a textbook development process and directly apply it. What you need to do is tailor the process to your companies needs and culture. Look at as many development paradigms as you can and try to find something that is a good fit and them start molding it to your needs. You may have to try and fail with a number of different processes. Perhaps the Personal Software Process will be a good starting process, maybe an agile process, a variant of RUP? You have a lot of options, start trying them out.
You are also going to have to work with the rest of your organization - they need to be a part of the process. You may be the lone developer, but a development process involves more than the developer, it involves ever person that has a say or impact in the product.
This may not be a specific answer, but my point is that you will need some kind of process. So start researching them and trying them out and molding them to your needs until you have something that works.