Overcoming a project for small tasks

Question

It is interesting when a new project comes, say, creating a social network site, how can I break a project into small tasks. Usually for each project there are usually 2-4 programmers, and usually there are no testers. Should I split the whole site into 4 hours from the start. Should we do it in stages? How about testing, is it okay for programmers to check the code?

Thank you for your time.

Answer 1

We use a fairly simple system.

• First, we break the project into user stories or verticals. For example, "Update Client."
• Make a list of all the verticals in the first column of the table.
• Then at the top you place the layers or actions. For example, Data Layer, UI, Logging.
• For each of the elements in the matrix, you select an estimate and decide who should develop it.
• Splitting it into 4 hours is good, because then every developer can say: “I am going to complete these two tasks today” in the fray.

Usually we do this for each sprint for actions that must be performed in the sprint.

When testing, programmers must verify the code by writing unit tests, but testers must perform a system test.

Answer 2

This is a big question for the forum, so I'll start by recommending the book:

Agile Planning Assessment by Mike Cohn

As you can tell from the title, it offers a flexible approach.

Until you bought and read a book, this extremely short version may be useful:

• Plan coarse grains first. Something like: we plan to deploy the first version in two months, containing the most basic functions to make it really useful. After that, we will have a new version about every month. Make sure you do not go into details. Since reality will kill all the detailed plans anyway. You may think of the steps in this plan as phases, but note that they do not correspond to the classical phase analysis, design, implementation, testing, 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 will create a GUI, then a model, then a database, but we will use the full functions, often modeled as user stories. for example, "As a user, I want to enter orders into the system." This will be one user story. The implementation of this user story involves the implementation of all material with Userinterface persistence, including testing. ("User stories" and "iteration planning" for more information on this.)

For your test question: developers testing their code are better than not testing at all. But there are better ways to ensure high quality code. I would recommend the following approach:

• Conduct testing based on testing, i.e. write tests first, then implement. This type of force allows you and your team to make the code well-structured, it supports quick code changes, as the tests will inform you that the material will break.

• Perform pair programming at least for a portion of the time (the more, the better). This ensures that at least two people understand each line of code. It also works as implicit learning, and finally works as a code review, which is good because it is known that code reviews are more effective at finding bugs than tests.

• You still need manual tests for the full application.

More info for reading and google: agile, scrum, xp, TDD, BDD, Poker Scheduling,

Answer 3

You need to pick up a basic book on project management, read it, and practice what you learn from it. Check out Wikipedia's article on project management - this is a good starting point: http://en.wikipedia.org/wiki/Project_management

A way to break down projects is to set milestones and make a rough estimate to achieve these steps. Do not overdo it. Typically, project planning and evaluations are unreliable at the start of a project. But as you go about evaluating, and plans improve when you find out what you are building.

You can break the project down into 4-hour tasks, but it will be micromanagement (unless you really get to the unit of work at 4 o’clock :)) I would recommend against this, especially at the beginning of the project.

As for the programmers checking their code:

Today, it often happens that programmers check their code, testing is a huge domain, for example, project management. For example, you conduct various types of testing at different stages of the system development life cycle:

• During development, you can perform test development → first ask developers to write a test, and when their code is tested against the test, it will be ready to use any source code repository.

• Once all your code has been submitted and you have an early version of your software, you can perform internal testing, for example, testing a system where you have testers or programmers to test the application.

• When you are satisfied with system testing, you can test user acceptance testing before deploying it anywhere. User acceptance testing should be performed by anyone your target user.

I wish you good luck in your project :)

Answer 4

Another useful book is

Software Evaluation: Demystification of Black Art

Steve McConnell

In addition, I can only repeat what others said: it is basically “Divide and Conquer”.

Answer 5

How about testing, is it okay for programmers to check the code?

If you do not have a QA, programmers should check their code!

I also recommend that programmers do code reviews (reviewing each other's code). As a team leader, I looked at everything from new employees to before they registered:

• Quality control (make sure they do not check for errors)
• In addition, training (see if there is something that they do not know and should not know what I can tell them)

I would stop looking at a person’s code when my reviews stopped finding errors that would happen when they learned to test their own code.