Deciding Development life cycle.

Question

How to decide software development process for developing a software, what are the key factors to be considered while deciding which development process to follow(e.g Agile,WaterFall,Spiral...).

Answer 1

There are lots of factors influencing this decision, including "technical" ones:

• what kind of project is it (e.g. in house, open source, shrink wrap, enterprise, device driver, ...)
• predicted size of project (e.g. person years) and team
• predicted lifetime of project (ranging from throwaway prototype to mission critical enterprise app expected to run for the next 100 years)
• how often you can / are expected to deliver new releases

and social ones:

• are the users willing to cooperate with the team in agile style
• what is the culture, the "normal way of doing things" within the organization
• how open is management (and developers) to new ideas, can they be convinced of new approaches (with good arguments and evidence)
• is the team colocated or physically separated

Note that the latter are at least as much, if not more, important factors than the former!

Technical factors

The nature and size of your project strongly constrain how often you can publish new releases, which in turn has an effect on how agile you can be. E.g. some open source projects can be released as often as you wish, while according to Joel, shrink wrap software should not be upgraded more often than every 1,5 years.

As the size of the team grows, the communication tends to become more formal, and the team becomes less agile. Also the more critical the project, the more rigorous and formal the process tends to become.

Social factors

If your users are not willing, or can't coopoerate directly with your team, agility is limited. If management is stuck with conventional thinking and methods, again agility is limited. Same for a physically separated team.

---

The bottom line is: you don't need to choose a process once and for all. Also, names and fashionable acronyms are not as important as what your team is really doing day by day. You can do Waterfall or RUP in agile style, just as well as you can effectively turn XP or SCRUM into a rigid, formal process. In a good project, the process is constantly reviewed, fine-tuned and improved as the situation and the team's needs require. Start with something which seems good enough (and as simple as can be), then do regular retrospective meetings to gather feedback about what is going well, what went wrong, and what could be improved.

Answer 2

Personally, I would look at the overall size of the project (expected development in days/weeks vs years), the complexity, the development team size (and co-location or distribution across multiple locations)... ..but most importantly, look at the stakeholders, and consider the degree of ceremony they expect from the project.

All these factors tend to gravitate together in rough opposite poles.

The small, quick project tend to have a smaller development team, lower ceremony requirements and may fit a more 'Agile' approach. Bigger, multi-year projects tend to have huge teams, high ceremony, and may fit a more 'waterfall-ish approach. Keep in mind, waterfall without iteration will hardly ever succeed anyway - but that's outside the scope of your question.

Answer 3

There are a number of methods to choose from but there is not one definitive method (although it would be nice). In our environment we use agile. This makes sense for us due to a number factors:

• Typical time contraints (although every project is not the same, the way the time constraints are determined is pretty consistent)
• Development resources
• What type of client interaction are you able to have (are they responsive or un-responsive)
• Organization guidelines (e.g. do they expect a certain document artifact before the project begins and do they have requirements for what is in that artifact)
• Budget (again not always the same, but consistent in method for determining the budget)

I would also recommend looking at other companies in your industry and seeing how they handle things.

The single biggest thing I would recommend, don't get to hung up on the process, just build some great stuff and let the process start to refine from that. Although we use agile methods, it is kind of our own blend which works for us.

Hope that helps, I am sure there will be way better answers than mine :-)