When planning, you need to distribute all the work in several stages. Each stage ends with a milestone. A milestone is a certain point in time when the results of the work done are evaluated.
When planning the milestones, two tasks need to be solved. First, you need to distribute user requirements across the milestones. Secondly, it is necessary to estimate the duration of each milestone. At the same time, it is important to ensure that the duration of the milestones is approximately the same.
We use several criteria to distribute the work by milestones:
Each milestone should be dedicated to a specific topic. This allows the team to concentrate on something specific and avoid scattering and throwing.
Examples of topics: data model, toolbars, graph editing window, etc.
It is necessary to take into account the dependencies between the works. It is necessary to distribute the work in such a way that the dependent works would be located later than those works on the results of which they depend.
It is necessary to withstand approximately the same duration of all milestones. We are trying to ensure that the duration of each milestone is 5-6 weeks.
Step 2.3. Make a communication plan
In order for the work on the project to progress successfully, it is necessary to think about how communication will be built within the team between individual developers, as well as between the team and Customers.
We use several practices in our company, which turned out to be — in our case! — very successful.
Project space in the “cloud”
When starting a new project, we create a project space in the “cloud”. We use Google Drive as a cloud storage. But you can also use other services: Yandex. Disk, Mail.Ru , One Drive from Microsoft and others.
If privacy requirements or just personal preferences do not allow using a cloud service, then you can install Sharepoint on a local server, or use a version control system such as svn, git or perforce, or create a project folder on a regular file server. There are a lot of options — from simple to exotic.
A single project space allows you to concentrate all documents related to the project in one place. And using the “cloud” allows you to open access to them to all team members: everyone — from their workplace.
What is the project space? This is a regular folder in the cloud storage to which access rights are configured. Inside it contains other folders, each of which concentrates documents related to a particular discipline.
For example, in our case, the project folder usually contains 4 such subfolders:
Contains documents describing customer requirements and the design of the application being developed.
This folder contains documents describing the technical design of the program, class diagrams, existing technical limitations, etc.
This folder contains everything related to project management issues: project evaluation, team composition, project schedule, vacation schedule, etc.
It contains descriptions of test cases, reports on the results of the milestone, rules for the design of bugs, a list of problem areas in the program, methods for finding bugs.
The contact list is a document that contains the names of all people who are somehow connected with the project, as well as ways to contact them: phone numbers, email addresses, Skype accounts, etc.
The contact list allows you to quickly find the right person. Managers who neglect to compile such a list then waste their time and their nerves in vain to find their lead programmer, designer or quality engineer in some emergency.
The contact list is best designed in the form of something like this table:
Full name Position Mobile Phone Email Skype
Ivanov P.I. Lead Programmer +7 (XXX) XXX-XX-XX firstname.lastname@example.org pivanov
Petrov I.S. Programmer +7 (XXX) YYY-YY-YY email@example.com ipetrov
Daily meetings (stand-ups)
Every day our small team (4 programmers and 1 QA engineer) gathers for a short meeting to discuss the current progress of work on the project. Usually such a meeting takes 10 — 15 minutes and allows all team members to keep up to date.
The format of the meeting has remained unchanged for a long time and consists of three parts:
Report of each team member
Discussion of problems and suggestions
In the first part, the project manager (or the lead programmer performing managerial functions) informs the team about some news related to the project. These may be some management decisions of the project curators, requests from internal customers, positive or negative feedback on the application being developed or on the work of the team.
Then comes the turn of reports. At this stage, each team member reports on their work by answering the following three questions:
What did I do yesterday?
What am I going to do today?
Do I have any obstacles that prevent me from performing current tasks?
This report format allows the project manager (or the lead engineer performing part of the managerial functions) to be aware of how the project is moving and what progress the team has made. And since each team member must tell about the task he is working on at the moment and name the existing problems, this helps other team members to find out in time about the dependencies between their task and the task of their colleague and, if necessary, resolve these dependencies by adjusting their actions.