Most organizations follow some type of methodology for their software development life cycle (SDLC). Waterfall, Agile, Scrum, Lean and XP are some of the principals many corporations are trying to utilize to effectively build software products. There are definitely no shortages of books on these methodologies, and the number of great blogs is countless. I certainly don’t want to try to publish one more blog on promoting a specific software development principal, or discuss the pros and cons. Instead, I feel I need to look at why an organization establishes SDLC to begin with, and what type of methodology we should try to use.
A small organization may not follow specific methodology in building software products. People tend to wear many hats, and almost operate like fire fighters. If new business requirements come up, people just try to implement them immediately without any kind of formal process. With organizational growth, the complexity and size of software projects tend to grow; thus, forcing us to consider some kind of formalized process. As a result, corporations may end up picking an established methodology and run with it. Over time, continuous business evolution may push us towards discovering the shortcomings of our methodology even after successfully utilizing it for many projects. Consequently, we may be inclined to pick a drastically different methodology hoping to improve the software development process.
I believe the reason we seek these changes boils down to maximizing return on investment. How can we maximize our return on investment? If we can quickly produce high quality software products in a cost effective manner we give ourselves an opportunity to do just that. One may say ‘we should always use XP, Lean or Agile for flexibility regardless of the project’. One may also feel that certain business model only calls for Waterfall methodology. When we consider business models, personnel as well as the nature of projects, one methodology may make better sense over another one; however, we should never limit ourselves to a specific model for every project. The key factor is to find appropriate balance between quality, cost effectiveness and quick delivery by employing a flexible SDLC. Sometimes, we may utilize a hybrid approach (e.g. mixture of Agile and Waterfall) for project implementation. Other times, we can pick one specific methodology and go all the way through. It’s all about moving away from rigidness and finding flexibility in software development life cycle.
I believe the reason we seek these changes boils down to maximizing return on investment. How can we maximize our return on investment? If we can quickly produce high quality software products in a cost effective manner we give ourselves an opportunity to do just that. One may say ‘we should always use XP, Lean or Agile for flexibility regardless of the project’. One may also feel that certain business model only calls for Waterfall methodology. When we consider business models, personnel as well as the nature of projects, one methodology may make better sense over another one; however, we should never limit ourselves to a specific model for every project. The key factor is to find appropriate balance between quality, cost effectiveness and quick delivery by employing a flexible SDLC. Sometimes, we may utilize a hybrid approach (e.g. mixture of Agile and Waterfall) for project implementation. Other times, we can pick one specific methodology and go all the way through. It’s all about moving away from rigidness and finding flexibility in software development life cycle.
No comments:
Post a Comment