Posted: 8-Apr-09 |
Filed under: Methodology
Requirements are just a starting point?or at least they should be. I?ve had many customers who feel that once they?ve documented their requirements their job is nearly over. Many seem to feel that requirements get dumped into Visual Studio and out comes an entire system. I am exaggerating, of course. However, I am routinely asked to give a fixed price bid, for instance, to a set of requirements. This is absurd and dangerous at best. On larger projects it is negligent, in my opinion. There is just too much risk involved. I explain it to customers like this: ?I can estimate how long it takes a developer, given a particular architecture, to code a screen, a business object, a database table, a stored procedure, a service, and so on. However, I can?t tell you how long it takes (or how much it costs) to satisfy a requirement.?
What is required, of course, is decomposition of those requirements. This means analysis, the creations of use cases, a functional specification, a solution architecture, possibly a prototype, logical models, and physical models. This is hard work. However, it serves to validate and refine the requirements as well as eliminate a lot of risk. These deliverables also lead to artifacts (forms, classes, tables, and so on) that can be estimated based on complexity factors. The result is less risk to the project team (and stakeholders) and higher confidence that what is being built is what is actually required.
Posted: 23-Dec-08 |
Filed under: Methodology
When it comes to teamwork and mission execution, the United States Marine Corps (USMC) epitomized this concept. The USMC is the most elite fighting force in the world—and with good reason. Teamwork is the key ingredient to accomplishing any mission, and it's something Marines do very well. After all they've been doing it for over 230 years. Though this, a long tradition has formed a set guiding principles that make the USMC more successful than any other fighting force in the world.
I served for four years and learned that these Corps Principles (pun intended) are a part of me. I have found that I can apply them to my day to day work as a software developer. Doing so has made me and the teams I have worked with more efficient.
I will start to blog about these Corps Principles and how they can be applied to the software development process. Some of what I write will seem like common sense (an uncommon thing in some organizations). There may be a good chance that you will already be practicing them, and are more effective because of it. However, it has been my experience that following these principles will not guarantee success, but not following them will guarantee failure.