How do you begin breaking your project up into smaller pieces?

Question

I have seen this thread:

http://stackoverflow.com/questions/1448321/breaking-down-the-project-into-small-tasks

and it is helpful. I'm just not sure where to begin. Do I just read a book on agile and use that methodology as the project manager? Is agile a complete system from the absolute beginning to the end? Any software for a suggestion is also welcome, any platform.

It is a facebook app of moderation complexity, if that matters. I'm trying to "do it right" instead of by the seat of my pants. I know everyone's "do it right" may be different but I need some systemization techniques.

I don't expect perfect project management just the right general direction. I know I'll never deliver unless I break this down and maintain enthusiasm. It will get overwhelming very quickly - just the thought of it is.

Thank you.

Answer 1

You could read a book on Agile development but that won't write the code for you. I would sit down away from a computer and write out a list of about 5-10 small tasks in your project. They should be small enough you should be able to finish them all in a day or two of work. Next, write a time estimate for them. Then do as many of those as you can. As you go back over your time estimates you can reflect on your time management.

As you go, try and focus on isolating key functionality and abstractions that are present in your project. If you have a customer besides yourself, talk with them at each iteration and see how they think the project is going.

As you do this you could also be reading up on agile development. Agile development attempts to solve a lot of problems encountered when working on a team. If you can then I would get a friend to work on this too and you might find you learn more that way.

Answer 2

My approach is to work forward on any project such that I have plenty of milestones where something works and is finished to some defined point.

I may implement the nuts and bolts of my app in a simple command line app just to see it talking to the file system or the network; I may have it read input from a file rather than the keyboard, so I can quickly put it through its paces on repeatable data without having to do the repetition by hand.

I can work on the GUI separately. I can fiddle the HTML and CSS until I have a breathtakingly beautiful GUI, without worrying about the functionality of it all.

Then I'll build a project where I marry the previous two subprojects. I take two working subprojects, then, and create a single, working, bigger project. If that needs more stuff bolted on to it, I can do that.

The advantage is that I have working code more quickly, and I can identify risks earlier. The smaller chunks of the project are easier to test, and I can develop them separately. That also buys me shorter compilation times.

Answer 3

Here are some suggested steps based on Scrum.

1. Create a list of features (‘Product Backlog’) your application will perform. Ideally this should be done with the customer.

2. Assign gross estimates to those features with the developers doing the work (Maybe that’s just you).

3. Prioritize those features. Again with the customer (if available).

4. Allocate those features into 30 day buckets (Sprints).

5. Using the feature(s) allocated to the Sprint, create a list of tasks (Sprint backlog) that can be completed in 8-16 hour increments.
   
   Here are some examples:
   
   

   • Create data tables for feature X.
   • Create UI layout for screen 1.
   • Create event(s) for controls on screen 1
   
   You also don’t have to limit yourself to programming tasks. Tasks can also include things like research, as long as an end result is achieved. Ex. Research Facebook’s API and determine an interface approach.

6. At the conclusion of the Sprint, do an evaluation based on how quickly you/your team is getting things done (your velocity). This might require adjustments to estimates in both the Product and/or Sprint Backlog.

Answer 4

The way I work it out is first I sit with the non-technical guys and we create a list of the features in the product. The feature list is prioritised with the features that are most desirable on top. Once we have ths list then we have a meeting with the technical guys. Here for each feature that we have we break it into smaller tasks and the developers would provide estimates on how long each task would take to complete. We calculate the total amount of time estimated and select the tasks for the first iteration. Our first iteration is usually between 14 to 21 days and we divide the work equally between the developers. This process also helps us to find dependencies and we usualy have 3 team :

1. core team - working on api;
2. gui team working on the graphic part
3. testing team - working on creatin unit test for each of the tasks.

We also have daily standup meeting just to know the progress on each of the tasks. Usually by the end of the iteration we have a working and tested version of the product.
At the end of the iteration we have a meeting to see what were the problems the developers encountered. Hope this small view of how we use agile is helpful.