Breaking down the project into small tasks

Question

Hello,

Am wondering, when a new project arrives, say building a social networking website, how do I go about breaking the project into small tasks. There are usually 2-4 programmers per project and usually no testers as such. Should I be breaking the whole site into 4 hour tasks from the beginning itself. Should we be doing it in phases? What about testing, is it okay to have the programmers test the code?

Thank you for your time.

Answer 1

You need to pick up a basic book about project management, read it and practice what you learn from it. Check out the Wikipedia article about project management is is a good starting point: http://en.wikipedia.org/wiki/Project%5Fmanagement

A way to break down projects is to set milestones and do rough estimation to reach those milestones. Don't over complicate things. Usually project planning and estimates are unreliable in the beginning of a project. But as you go along estimation and plans improve as you get to know what your are building.

You could break you project down into 4-hour tasks but that would be micromanaging (unless you really can fit a unit of work into 4-hrs :)) I'd recommend against it, specially in the beginning of a project.

Regarding programmers testing their code:

It is pretty common today to have programmers test their code, testing is a huge domain like project management. For instance you do different kind of testing in the different stages of the system development life cycle:

1. During development you could do test driven development->make your developers write the test first and when their code is verified against the test it is ready to be committed to whatever source code repository you use.

2. Once all your code is submitted and you have a early version of your software you could do internal testing, like system testing where you have testers or programmers to test the application.

3. When you're happy with the systems testing you could do user acceptance testing before deploying it anywhere. User acceptance testing should be performed by whoever is your target users.

I wish you good luck with your project :)

Answer 2

That's a big question for a forum so I'll start with recommending a book:

Agile Estimating Planning by Mike Cohn

As you can tell from the title it is presenting an agile approach.

Until you have bought and read the book, this extremely short version might be of some use:

• Do a coarse grain planning first. Something like: We'll plan to deploy the first version after two months, containing the very basic features to make it really usable. After that we will have a new version about every month. Make sure you don't get into to much detail. Since reality will kill all the detailed plans anyway. You can think of the steps in this plan as phases, but note that they don't match the classical phases analysis, design, implementation, test, deployment

• For the first phase plan in more detail what you are going to do. Use vertical slices for planning, i.e. Do not plan: First we'll make the GUI then the model, then the database, but use complete features, often modeled as User Stories. e.g. "As a user I want to enter orders into the system" This would be one user story. The implementation of that user story would imply doing all the stuff from Userinterface to persistence, also including testing. (Google 'user stories' and 'iteration planning' for more information about this.)

For your testing question: Developers testing their code is better then no test at all. But there are better ways to ensure high quality of code. I'd recommend the following approach:

• Do test driven development, i.e. write tests first, then the implementation. This kind of forces you and your team to make the code well structured, it supports rapid change of the code, since the tests will inform you about stuff getting broken.

• Do pair programming at least part of the time (the more the better). This makes sure at least two persons understand each line of code. It also is works as implicit training and finally works as a code review, which is a good thing, since code reviews are known to be more effective in finding bugs than tests.

• You will still need manual tests of the complete application.

More stuff to read and google: agile, scrum, xp, TDD, BDD, Planning Poker,

Answer 3

Another book you might find useful is

Software Estimation: Demystifying the Black Art

by Steve McConnell

Other than I can only repeat what the others have said: which is basically "Divide and Conquer".

Answer 4

We use a fairly simple system.

• First we split the project into user stories or "verticals". For example "Update Customer".
• Make a list of all the verticals in the first column of your streadsheet.
• Then along the top you place the layers or activities. For example Data Layer, UI, Logging.
• For each of the elements in the matrix you cam allocate an estimate and decide who should develop it.
• Breaking it down into 4 hour elements is good, because then each developer can then say: "I am going to do these two tasks today" in the scrum.

We normally do this for each sprint for the activities that are to be completed within the sprint.

On testing programmers should test code by writing unit tests, but testers should perform the system test.

Answer 5

What about testing, is it okay to have the programmers test the code?

If you don't have any QA, programmers must test their code!

I recommend also the programmers doing code reviews (reviewing each others code). As team leader I used to review everything from new hires, before they checked in:

• Quality Control (ensure they aren't checking-in bugs)
• Also, training (see whether there's something they don't know and should know, that I can tell them)

I'd stop reviewing a person's code when my reviews stopped finding bugs, which would happen when they learned to test their own code.