software development methodology for the small team
-
Does anyone have a suggestion as to what the best software development process/methodology works well for a small team (3-5) of developers? Most of the projects we do are low level, long, drawn out and complex, but there are some more simple projects tossed in the mix too. Right now there really is no well defined process for our development. Things happen according to which way the wind is blowing. It's tough for developers to work in that environment! :) Any suggestions would be greatly appreciated!
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
-
Does anyone have a suggestion as to what the best software development process/methodology works well for a small team (3-5) of developers? Most of the projects we do are low level, long, drawn out and complex, but there are some more simple projects tossed in the mix too. Right now there really is no well defined process for our development. Things happen according to which way the wind is blowing. It's tough for developers to work in that environment! :) Any suggestions would be greatly appreciated!
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
In my previous company, we were about that size in our development team. We found that the best thing for us to do is work in pairs on different parts or modules of the project. This way, no one person becomes an expert on it and holds up others when they go on vacation or quit. So 3 to 5 developers would mean 3 to 10 different pairs of developers to chose from. Assuming of course everybody gets along well with everybody else. :)
"This perpetual motion machine she made is a joke. It just keeps going faster and faster. Lisa, get in here! In this house, we obey the laws of thermodynamics!" - Homer Simpson Web - Blog - RSS - Math - LinkedIn - BM
-
In my previous company, we were about that size in our development team. We found that the best thing for us to do is work in pairs on different parts or modules of the project. This way, no one person becomes an expert on it and holds up others when they go on vacation or quit. So 3 to 5 developers would mean 3 to 10 different pairs of developers to chose from. Assuming of course everybody gets along well with everybody else. :)
"This perpetual motion machine she made is a joke. It just keeps going faster and faster. Lisa, get in here! In this house, we obey the laws of thermodynamics!" - Homer Simpson Web - Blog - RSS - Math - LinkedIn - BM
Yeah, the "all your eggs in one basket" approach isn't good..which is what we've been using! What about the whole cycle of development. Did you have some sort of system in place to manage your projects? How did that work? Was there a certain set of steps you went through for each project? Right now, for us, every project is different. It's almost like starting a new job every couple of weeks - each project there are different people doing different things, even though we are all in the same company.
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
-
Does anyone have a suggestion as to what the best software development process/methodology works well for a small team (3-5) of developers? Most of the projects we do are low level, long, drawn out and complex, but there are some more simple projects tossed in the mix too. Right now there really is no well defined process for our development. Things happen according to which way the wind is blowing. It's tough for developers to work in that environment! :) Any suggestions would be greatly appreciated!
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
I would suggest an Agile approch like XP or Scrum.
-
Does anyone have a suggestion as to what the best software development process/methodology works well for a small team (3-5) of developers? Most of the projects we do are low level, long, drawn out and complex, but there are some more simple projects tossed in the mix too. Right now there really is no well defined process for our development. Things happen according to which way the wind is blowing. It's tough for developers to work in that environment! :) Any suggestions would be greatly appreciated!
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
We're in a small team (three devs) in exactly that kind of environment. Essentially, we don't do anything without a written requirement that's signed off by the customer. They tell us what they want done, we tell them how we're going to do it, and once everyone agrees that everything matches up, we put it in the dev queue. The first person available does the work. This approach requires a team of "agile" and competent programmers. People that need hand-holding don't mix well in our environment.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Does anyone have a suggestion as to what the best software development process/methodology works well for a small team (3-5) of developers? Most of the projects we do are low level, long, drawn out and complex, but there are some more simple projects tossed in the mix too. Right now there really is no well defined process for our development. Things happen according to which way the wind is blowing. It's tough for developers to work in that environment! :) Any suggestions would be greatly appreciated!
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
get a project manager, then ask them
Todd Smith
-
Yeah, the "all your eggs in one basket" approach isn't good..which is what we've been using! What about the whole cycle of development. Did you have some sort of system in place to manage your projects? How did that work? Was there a certain set of steps you went through for each project? Right now, for us, every project is different. It's almost like starting a new job every couple of weeks - each project there are different people doing different things, even though we are all in the same company.
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
It depends on how many projects you have, their size and deadlines. For the most part, we had short daily meetings to give a 5 minute summary of where we are and a weekly meeting to discuss problems. Each developer was experienced enough to be left alone to tackle whatever problem was laid out in front of them. We had version control to make sure things could be undone. In one project, I had to visit the client in another state, and I stayed up 'til 3:00 AM rewriting one part of the code because I knew the client would like it and eventually ask for it. I had to get up at 5:00 AM to go to the airport. Sure enough, the client not only said they were going to ask us to implement it, they wanted me to do some other fixes live while it was being tested. Change, build, test, repeat. This lasted for three days before I headed back home. It was a good learning experience and one of my more interesting projects. In cases when you have small teams, I feel that pair programming combined with extreme programming can be the best choice especially if every member of the team is capable of doing their part. As the project evolves, the limitations in place will become apparent and your methodology will grow out of it. I've worked on projects were everything needs approval from the system architect and I found those to be more troubling than they're worth. Of course, you will need the project manager's approval before you can agree on anything.
"This perpetual motion machine she made is a joke. It just keeps going faster and faster. Lisa, get in here! In this house, we obey the laws of thermodynamics!" - Homer Simpson Web - Blog - RSS - Math - LinkedIn - BM
-
Does anyone have a suggestion as to what the best software development process/methodology works well for a small team (3-5) of developers? Most of the projects we do are low level, long, drawn out and complex, but there are some more simple projects tossed in the mix too. Right now there really is no well defined process for our development. Things happen according to which way the wind is blowing. It's tough for developers to work in that environment! :) Any suggestions would be greatly appreciated!
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
-
Does anyone have a suggestion as to what the best software development process/methodology works well for a small team (3-5) of developers? Most of the projects we do are low level, long, drawn out and complex, but there are some more simple projects tossed in the mix too. Right now there really is no well defined process for our development. Things happen according to which way the wind is blowing. It's tough for developers to work in that environment! :) Any suggestions would be greatly appreciated!
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
-
Does anyone have a suggestion as to what the best software development process/methodology works well for a small team (3-5) of developers? Most of the projects we do are low level, long, drawn out and complex, but there are some more simple projects tossed in the mix too. Right now there really is no well defined process for our development. Things happen according to which way the wind is blowing. It's tough for developers to work in that environment! :) Any suggestions would be greatly appreciated!
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
Were you all listening in on the meeting I was just in? Some of your comments are exactly what we discussed and are headed towards - at this point anyway! The wind is coming out of the west....
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
-
Were you all listening in on the meeting I was just in? Some of your comments are exactly what we discussed and are headed towards - at this point anyway! The wind is coming out of the west....
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
Brent Lamborn wrote:
Were you all listening in on the meeting I was just in?
Yes, although you made good points, you really should have spoken up more, taken charge, led the team. By the way, your coffee was a bit acidic, I almost had to put sugar in it :omg: and you really need to work on security. ;) Anyone could just walk in there...
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Does anyone have a suggestion as to what the best software development process/methodology works well for a small team (3-5) of developers? Most of the projects we do are low level, long, drawn out and complex, but there are some more simple projects tossed in the mix too. Right now there really is no well defined process for our development. Things happen according to which way the wind is blowing. It's tough for developers to work in that environment! :) Any suggestions would be greatly appreciated!
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
First things first, a good score on the Joel Test[^] will help you more thanm picking any kind of process. Second, Does Process Matter?[^] a decent meta-look at different processes. Third, my three cents. Don't subscribe to a single methodology. If you can, shop around and try individual ideas - but as said above, these elements must support each other. Which parts of agile, scrum, waterfall work for you strongly depends on the type of project and your client interaction. (The latter ranges from "how often the client will (or should or wants) to see something new" over "how much your specs are frozen", to "how often money comes in".) I wouldn't recommend anything specific without knowing more, esp. what are your specific problems? Shifting priorities? To many bugs? Skill levels differ to much? To many dependencies? Steve smells of garlic? ;) Only a few "always right" recommendations: Work with only two priorities: 1=now, 2=later. Know your tools - what they can and what they can't. Any task that is estimated at more than 4 hours needs to be broken down in sub tasks, because it's not clearly defined (in your particular case, it might be 4=sqrt(2), try to find your limit) A Programmers "gut feeling" includes only the time you need to crank out the code, but not starting up Visual studio, merging code, asking Steve how this weird gonkulator interface works etc. A way to account for that is assigning less than 8 coding hours to a day. (The value is individual but mostly stable. I am lucky when I get 4)
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
Does anyone have a suggestion as to what the best software development process/methodology works well for a small team (3-5) of developers? Most of the projects we do are low level, long, drawn out and complex, but there are some more simple projects tossed in the mix too. Right now there really is no well defined process for our development. Things happen according to which way the wind is blowing. It's tough for developers to work in that environment! :) Any suggestions would be greatly appreciated!
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
-
First things first, a good score on the Joel Test[^] will help you more thanm picking any kind of process. Second, Does Process Matter?[^] a decent meta-look at different processes. Third, my three cents. Don't subscribe to a single methodology. If you can, shop around and try individual ideas - but as said above, these elements must support each other. Which parts of agile, scrum, waterfall work for you strongly depends on the type of project and your client interaction. (The latter ranges from "how often the client will (or should or wants) to see something new" over "how much your specs are frozen", to "how often money comes in".) I wouldn't recommend anything specific without knowing more, esp. what are your specific problems? Shifting priorities? To many bugs? Skill levels differ to much? To many dependencies? Steve smells of garlic? ;) Only a few "always right" recommendations: Work with only two priorities: 1=now, 2=later. Know your tools - what they can and what they can't. Any task that is estimated at more than 4 hours needs to be broken down in sub tasks, because it's not clearly defined (in your particular case, it might be 4=sqrt(2), try to find your limit) A Programmers "gut feeling" includes only the time you need to crank out the code, but not starting up Visual studio, merging code, asking Steve how this weird gonkulator interface works etc. A way to account for that is assigning less than 8 coding hours to a day. (The value is individual but mostly stable. I am lucky when I get 4)
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us!peterchen wrote:
A Programmers "gut feeling" includes only the time you need to crank out the code, but not starting up Visual studio, merging code, asking Steve how this weird gonkulator interface works etc. A way to account for that is assigning less than 8 coding hours to a day.
Very good point. I scored us a 4 on the Joel test. X| I like the approach that the specific process you follow is not as important as whether it plays well with the others; the last sentence in the "Does Process Matter".
peterchen wrote:
Work with only two priorities: 1=now, 2=later.
How do you know which "later" is to be the next "now" if the later's aren't prioritzed as well?
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
-
We're in a small team (three devs) in exactly that kind of environment. Essentially, we don't do anything without a written requirement that's signed off by the customer. They tell us what they want done, we tell them how we're going to do it, and once everyone agrees that everything matches up, we put it in the dev queue. The first person available does the work. This approach requires a team of "agile" and competent programmers. People that need hand-holding don't mix well in our environment.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
People that need hand-holding don't mix well in our environment
That is good because those kind of people can really bog down a team.
-
peterchen wrote:
A Programmers "gut feeling" includes only the time you need to crank out the code, but not starting up Visual studio, merging code, asking Steve how this weird gonkulator interface works etc. A way to account for that is assigning less than 8 coding hours to a day.
Very good point. I scored us a 4 on the Joel test. X| I like the approach that the specific process you follow is not as important as whether it plays well with the others; the last sentence in the "Does Process Matter".
peterchen wrote:
Work with only two priorities: 1=now, 2=later.
How do you know which "later" is to be the next "now" if the later's aren't prioritzed as well?
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
Brent Lamborn wrote:
I scored us a 4 on the Joel test.
Work on that! Seriously. It doesn't work magic, but it helps.
Brent Lamborn wrote:
How do you know which "later" is to be the next "now" if the later's aren't prioritzed as well?
You end up with a sequential list and never think about priorities again :) Priorities are to fuzzy, you end up with three "top priority" items, and two other "just now, quickly", and when you get it wrong, it's all your fault. With a sequential list, you see what projects you penalize by making something "high priority", and changing the "now" item twice in a week or so should raise a red flag.
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
Does anyone have a suggestion as to what the best software development process/methodology works well for a small team (3-5) of developers? Most of the projects we do are low level, long, drawn out and complex, but there are some more simple projects tossed in the mix too. Right now there really is no well defined process for our development. Things happen according to which way the wind is blowing. It's tough for developers to work in that environment! :) Any suggestions would be greatly appreciated!
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
-
SCRUM
ed ~"Watch your thoughts; they become your words. Watch your words they become your actions. Watch your actions; they become your habits. Watch your habits; they become your character. Watch your character; it becomes your destiny." -Frank Outlaw.
But don't take tips from South Africa or England.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
I don't see it happening, at least not until it becomes pointless.
-
Does anyone have a suggestion as to what the best software development process/methodology works well for a small team (3-5) of developers? Most of the projects we do are low level, long, drawn out and complex, but there are some more simple projects tossed in the mix too. Right now there really is no well defined process for our development. Things happen according to which way the wind is blowing. It's tough for developers to work in that environment! :) Any suggestions would be greatly appreciated!
"Half this game is ninety percent mental." - Yogi Berra If you can read thank a teacher, if you can read in English, thank a Marine.
Brent Lamborn wrote:
low level, long, drawn out and complex
Sounds like winging (aka agile) won't work for you. I'm assuming you have exacting specs from the start.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
I don't see it happening, at least not until it becomes pointless.
-
In my previous company, we were about that size in our development team. We found that the best thing for us to do is work in pairs on different parts or modules of the project. This way, no one person becomes an expert on it and holds up others when they go on vacation or quit. So 3 to 5 developers would mean 3 to 10 different pairs of developers to chose from. Assuming of course everybody gets along well with everybody else. :)
"This perpetual motion machine she made is a joke. It just keeps going faster and faster. Lisa, get in here! In this house, we obey the laws of thermodynamics!" - Homer Simpson Web - Blog - RSS - Math - LinkedIn - BM