I'm not sure which forum this should be in, so I stuck it in here. Does anyone have a good guide as to the steps you should follow when developing new applications?
I know first is to gather requirements, but now that we've done so we aren't exactly sure what is next. Previously I've built out prototypes at this stage to kind of verify requirements and based on these built my database and then my presentation layer followed by any methods called from my presentation layer to access the database.
Anyone else have any good material or suggestions for how to progress after you've gathered requirements?
I think you have illustrated the steps in brief. I dont have any boklet on this. But few tips...
Think you should have identified the technology u want to go with. Now concentrate on developing a POC (proof of concept) to ensure that U can develope the application based on the given requirements using the technlogy chosen. Simultaneously start working on database stuffs. This will be a critical stuff and will require good brain stroming sessions with co-workers. Finalise the database. Start the design. Prepare a generic framework. Mostly common dynamic stuffs and common operations will be captured in framework. A good Design will take care of most things or rather hide most things from developer and expose only needed classes/objects. Hide and provide interfaces whereever possible. Start working on the objects that you will use for each module.
There are many schools of thought on this. There are many prominent supporters of agile methods -- those development methods that emphasize iterative development, constant customer feedback, lots of developer testing, and deemphasize the notion of a "phase" and the notion of "Big Design Up Front" (BDUF). I'm an agilist myself, as are many of the Ranch's staff.
But as I said, there are many different schools of thought. I'm going to move this thread to our Process forum, where this question will be right at home.
When following XP, you would next create a rough release plan, guided by perhaps some architectural prototyping to get better estimates for the risky parts. That probably shouldn't take longer than a few days.
Then you would start your development iterations. In my experience, the best iteration length is one week. In every iteration, you implement a handful of the highest priorities features for the system (for that you need to break down the features into rather small chunks, which is a Good Thing TM), end to end. You only build the parts of the architecture (framewors etc.) that are necessary to support those features.
The goal should be to have at the end of every iteration a running system that you can demonstrate to the Customer and shows him that the most important things (to him!) are working. If the Customer likes, he should be able to get a new system into production every couple of iterations.
How does that sound to you?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Every single person says that the first time they hear it. Many are convinced otherwise in short order. The trick is to give yourself small tasks (stories) that can be built and tested. The "item" might not be complete in one iteration (and that may make you ask next about our definition of "iteration") but the part that is built and tested is positive progress.
If you try this style start with a longer iteration if you must, but look back after a few and see what's stopping you from going shorter. [ April 24, 2006: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jul 11, 2001
Originally posted by kri shan: Hi Ilja, one week iteration length is too short for highest priority items(it may be complicated task).
If your highest priority items cannot be implemented in less than a week, I would strongly advise to break them down into smaller parts. There are at least two reasons to do this:
- big features are much harder (if not impossible) to estimate. If you don't break them down into smaller chunks to estimate, you can be quite sure that your estimate is *way* off.
- a big feature invariably consists of parts that are more important, and other parts that are less important. Breaking it down into small chunks allows you to schedule those parts seperately, and thereby providing more value to your customer earlier.
It takes some practice, but we've found that it's almost always possible. We are six developers working on a one million lines of code system now for years, and we find that any Story (how features are called in XP) larger than 16 person hours constitutes an increased risk.
Originally posted by kri shan: one week iteration length is too short for highest priority items (it may be complicated task).
You do work 8 hours a day, don't you? And you do have lunch some time during the day, don't you? And you still get small things done every day, right?
The trick is, as Ilja and Stan mentioned already, to simply make sure that those tasks that you do complete within a one-week iteration are of production quality and, as far as possible, a cohesive piece of functionality that can be built upon or even used by the end users as it is (even if it's only a subset of the full feature).