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.
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
-
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.
Some pointers that will most definatelly save you time in that particular enviroment. 1. Coding methodology, prefixes, function usage & variable/pointer passing and all those things that will make a coder ask "Why did you make it like this?" or "How does this work?". Make the team write code as a single individual rather than 10 different people. 2. Never assign 2 people in the very same module or closelly related modules. 3. Never assign 2 people in "distand" modules hence leaving them to cover a lot of space between them. 4. Always assign jobs that will sightelly overlap each other thus covering the very critical and small gap between interconnection of 2 modules made by 2 individuals. Believe me, that's a critical point where all hell can break loose. 5. If you don't have a project manager but rather work as a collective, make sure that you've established and assigned the 'Masters vote' priviledge to one of the team members. It's going to come in handy when no decision can be reached after endless hours of meetings and planning. This person should be either the most acceptable or the more experienced in the type of project you want to develop. 6. Everyone backs up his code. In addition, a collective of the total code is stored in mediums. 7. This applies to all team members --- 'LEARN TO FOLLOW ORDERS'. Any team member that can't visualize and share the way you choose to work, no matter how good, he'll cause slowdowns, backsteps and a bunch of other issues simlpy because he wants to be the leader. Remember that you're striving for a leaderless/collective way of working. This means that all decisions about 'who is who' and 'who does what' are based on knowledge, speed, efficiency and not personal goal seek or development. 8. Avoid assign the 'Masters vote' for a project to a person that already has that priviledge for another (unfinished) project. Although we've done it many times, it's still a bad practice. 9. Depending on the difficulty and time schedule of a project, create a 'Comment template' for each function/sub/class/property, .. etc and MAKE SURE that everyone fills that with meaningfull information. As a sidenote, stuff other than "Purpose, Method of working, Prequisits, Creator, Project" like "Date started, Date ended, ... etc" are not of much use. 10. Respect the work of your team members. This means, when they've made an error or didn't actually get what they had to do thus creating something else, or created buggy or badly structured code, DON'T edit their code. Tell th
-
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.
agile methodology will be best for this kind of organization. Eleminate the document preparation process at the starting the project. Since you have a small team and developers are few, you should ask the developer to estimate a module or a project.so the presure will be on the developer to complete the task what they estimated. after all it is on the management and leadership how to get work dome form the developers. no need for the testers if u have a small project to work. Ask developer to ensure for the quality what they are delivering. see there is not any limitation of money in s/w industry so don't get worried about the money that you are paying for the resources but take care that your resources give u the best work. Thanks
-
agile methodology will be best for this kind of organization. Eleminate the document preparation process at the starting the project. Since you have a small team and developers are few, you should ask the developer to estimate a module or a project.so the presure will be on the developer to complete the task what they estimated. after all it is on the management and leadership how to get work dome form the developers. no need for the testers if u have a small project to work. Ask developer to ensure for the quality what they are delivering. see there is not any limitation of money in s/w industry so don't get worried about the money that you are paying for the resources but take care that your resources give u the best work. Thanks
qqqzzz wrote:
Since you have a small team and developers are few, you should ask the developer to estimate a module or a project.so the presure will be on the developer to complete the task what they estimated. after all it is on the management and leadership how to get work dome form the developers. no need for the testers if u have a small project to work. Ask developer to ensure for the quality what they are delivering.
Oh yeah! That is the process we use (three developers), and it works like a charm...like one of those charms you buy at a gas station in North Dakota. That is the kind of process you get when you have a non-manager, so-so-programmer leading a development team. - Brian
-
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.