Being in the need of finding a methodology to develop software, either because you or your your job place lacks one or to replace the current one, is a nice and complicated task. I believe there are three main concerns you should identify a priory and make a plan to successfully tackle them: the time you’ve got to accomplish the task, the way you’re going to find the right one for you and the political issues this change will bring into otherwise messy but calmed waters.
The first is a constraint you find in every project and is the one that takes you out of the ideal scenario where you build the same project with all the candidate methodologies and then compare metrics. This concern is why you need to put some trust in other people’s success stories. The second concern, the matter of this post, tries to identify what are you going to compare so you know the methodology suits better for your needs. Finally, you have to realize that not because you and your closest teammates believe it’s time for a change everybody else does, some other people may just love the way it is now.
Where not to begin.
Usually the non expert software engineer, like myself, will google for software methodologies and depending of how you look at yourself, someone in a poncho or a business suit, you will rule out a big set of methodologies. Then, the hype will reduce the candidates two or three, and, finally an opinion from someone you look up to will settle the competition. If you include some heavy reading in this process, this will be the one at-least thing you will be able to rescue. Make sure you drink a lot of water during these long readings so your brain rehydrates and you get the most out of it.
Where to begin.
First, remember maybe it’s not you the one who’s going to use the methodology but business analyst, designers and programmers who might have a different level of know-how on the business your solving problems for. This evaluation on the expertise of the staff helps you choose the general way you will looking at the problems, as a big problem that you need to break in several small ones or a small solution which needs to grow up into a bigger enough one to solve the problem. You should follow the bottom-up path when the staff is experienced on the business field and will be able to join together the small solutions to deliver the big complete one. The top-down path is said to be safer because you first get an overview and the solve little pieces at the time but having already decided where they fit. Where I work the business is too broad and many people is less than a year on their current positions so I chose the top-down approach, The one we’ll develop on this post.
How small will problems be.
Now, you need to decide how small these problems are. This will depend on how often you want to release a testable preview of the software. If you need to release often for test you could try a feature-driven approach, understanding a feature as something the system needs to do like automatically upgrade when a new version is available. Here you test every time a new feature has been coded, but tests will not be necessarily easy since is very little what you are testing and sometimes the scaffolding needed to make the test is bigger than the feature itself. A nice and common developing unit is the use case. A use case- driven approach leads you to more comprehensive tests but not that often releases because it’s going to be a bigger piece of code the one you are testing. If you don’t like to/can’t see your testing buddies too often, you have even bigger pieces of code, you should follow an actor-oriented oriented approach where you wont test before all functionality an actor needs is concluded.
Take your time.
Take your time constraint and evaluate how much documentation your projects will be able to produce. Making as much useful documentation as possible is very good practice but not always plausible, so the UML diagrams you will use to traduce business into code might need to be reduced to the minimum necessary. Truth to your top-down promise, first you will need where to model the overview of the problem: use case diagram. How you want to specify every use case is matter of taste, so you might use text or activity diagrams, or both. The domain model of course will be laid as a simple class diagram. Here so far for the analysis. At design time, you might translate little problems into little components on another view of the system. You might also ease the change from activities to classes with a robustness diagram. Then, refining the domain model would lead to more class diagrams. And you might go on depending what are outstanding views you need from the system, where and what kind of tests you want to run, etc.
Choose a methodology.
Finally you have an idea of what the methodology should cover so it’s going to be of any help for you and your work. Just by this point you know what you are looking for and will be good to go in this dangerous quest of seeking a methodology. And, if you think it through you kind of built a methodology from a 10 Km high view, which means you understand what you are looking for and will have a stronger criteria when this hero of your makes a recommendation, and, won’t need to read every methodology in the way, but some few overviews till you find two or three which are close to your approaches.