October 29, 2013 at 12:42Pivotal Tracker as a tool in Waterfall development
In the Russian market development outsourcing are not many companies that use agile development methodologies ( the Agile ). Everyone is accustomed to working on the cascade model ( Waterfall ). The same applies to the mobile development sector.
The customer almost always has a budget or cost expectations, as well as the ultimate goal - an application with certain functionality. However, in mobile product development, Agile is more justified.
We are outsourcing the development of mobile applications, although we use the Agile tool Pivotal Tracker (hereinafter referred to as PT). It is about the experience of its use that I want to tell you in this article.
When a team — a project manager, several developers and a tester — is working on development, then one entity (an entity is a task, task, user story or another) may have several states, a responsible person and an executor. Therefore, many classic task managers are not suitable for accounting for development tasks.
Ultimately, we came to the conclusion that the entity should have the following meanings:
And also, for each entity, it should be possible to add a comment (and conduct a comfortable discussion) and different states (not started, started, finished, delivered, etc.).
Many tools for team work are presented on the market (both for the office team and remote employees). We will consider only tools for the interaction of the manager, developer and tester. The communication of the manager with the customer, the manager with the designer and other bundles do not require specially sharpened tools, but there are also interesting practices here - more on that in another article.
I must say right away that there is no place for paper in our workflow, all the tools are only on the computer. Basically, now more services are provided according to the SaaS model, but there are also solutions that can be installed on your server.
This is probably the most famous system for tracking tasks, discussions, files and the like. Therefore, it is simple, reliable and convenient. Great for managerial tasks - simple checklists, discussions, joint text editing. But not at all suitable for development tasks.
A task may be on a specific list, it may have an executor, and there may be a deadline. I know people who, in order to assign task to a specific version of the product (Version 1.0), wrote the necessary version in the task name (“Vote for Rating [3.4]), and the lists were used to determine task statuses (“ Scheduled ”,“ In the process ”,“ Completed ”).
Perhaps for simple projects - one manager and one developer - Basecamp may work, but the system crashes when there are 2-3 developers, a tester and a project manager in a project.
A well-known platform that many developers love. It is installed on the server, it is easily customizable, it has many modules. For tasks, the manager-developer-tester seems cumbersome. The interface is ascetic, and in the presence of an “Apple brain” the use of such a tool will upset =)
A monster from a company that ate all animals in software development tools. Customized, scaled - sometimes confusing and expensive, but many really like it.
Many (including companies) store code in Github repositories. Surprisingly, many do not know that they have their own task tracker. However, it is also interesting in that Issues can be tied to commits - made a push and the tasks closed (if their ID was indicated in the comment, respectively).
I know that TFS is popular in some circles, but I'm sorry - I’m even afraid to look there) The
guys from Thematic Media advised me to look at Asana, but somehow it didn’t take root.
PT is not a free product, it costs quite sane money and works on the SaaS model.
For $ 100 per month, you get the opportunity to create an unlimited number of projects and 25 participants in them.
PT can integrate with Google Apps, then inviting employees to projects becomes easier, and you can immediately attach documents from Google Drive to tasks (for example, with the described logic).
PT has many interesting and hidden features, almost everything is described in a long help - www.pivotaltracker.com/help .
We do not use the concept of user-story as it really is. With us it's just a task / task.
There are 4 types of tasks in PT - feature, bug, chore and release. We use these types as follows:
Feature - the main tasks for changing or improving the functionality of
Bug - the bug number in Crashlytics, or a brief description of the
Release bug - the name of the build version (alpha, beta and rc)
Chore - tasks for the manager directly related to development or release
Purple The label is an epic - we use it as its version number, which go to this functionality.
The green label is a tag - we use it to indicate the sections to which this feature applies (for example, blog view).
In each task, you can conduct a discussion with the mention of other team members (a note will come to them), you can add any files (most often these are screenshots, for example to a UI bug), you can conduct subtask (convenient with pixel-perfect improvements).
All epics are initially stored in a separate tab. You can always open an epic with some old version of the application and see when a certain feature was implemented, and it is also easy to plan a roadmap for future versions. Each epic has its own unique number, like task - you can always give a direct link to it.
The interface in PT is a panel: the main - backlog, icebox, current. We use only the icebox panel (for storing ideas and those tasks that are not included in any version yet) and the backlog (the ribbon of approved tasks), as well as panels that are called via epics - they display tasks only for the selected version. At first glance, to someone who does not use this, everything will seem very strange - but then you get so used to this system that you simply can never look at another.
The manager has on hand TK and roadmap by version. The process of creating tasks begins. Each task is necessarily accompanied by an epic (if it is development from scratch, then the version is usually 1.0) and a section label (we use the label as a screen, ie the team screen is “team”, the match screen is “match”). All tasks fall into the Icebox.
Next, the tasks are moved to the Backlog. From this moment they are approved and each contractor must have an executor installed. If the project has one developer, then this is not required. If there are several developers, task allocation is carried out by the team lead.
Each task has a level of complexity - this is some abstract value in points (it is used to calculate velocity, but we do not use it). However, without setting this value, the task does not start. After the developer starts the task, he clicks Start. At the end of the task, the developer clicks Finish. The next possible task state is Delivered. This happens when the developer delivers the task to the assembly.
We do Friday assemblies, already completed tasks fall into them. When making an assembly, the developer notes those tasks that fall into the assembly and which can be accepted by the project manager. The manager can accept the task if he believes that the task is done as it should and functions, and can make a redirect indicating the reason. After the edit, the task has a Rejected state (the button is Restart) and you can start it again.
Thus, you can at any time understand what a particular developer is doing, what tasks are already implemented and will fall into the assembly, which ones are in the icebox, etc. This is very convenient and visual, and the order of tasks can be easily changed - for example, within the framework of one release, or transfer to the next release.
After a review of the Friday build, the manager can also create bugs related to bugs. In releases with beta and rc statuses, a tester is connected, which can also create task bugs. He is then responsible for accepting them or redirecting them after correction by the developer.
When the task is delivered and accepted, it turns green and the task is closed.
Developers like to specify a task in the GitHub commit when the task automatically finishes when it is pushed.
In large projects, the number of tasks can reach up to a thousand. You can develop your own principles for creating tasks and use them.
In the case of an automatic build server, the task state must be changed to Delivered when the changes are committed to the repository, because assembly will happen automatically. Well, here each team has its own characteristics.
Pivotal Tracker has excellent iPhone / iPad applications (for now, though without adaptation to iOS7), there are also third-party Android clients. There is integration with all external services - GitHub, Campfire, FlowDock, HipChat, Zendesk, etc.
We do not provide Pivotal access to the customer, but in case of such a requirement, the tracker has the opportunity to invite an “observer” with “read only” rights.
Our friends from Aviasales also use this tool both in server development (though they slowly jump from it, because they switch to full Scrum) and in the mobile development department. Friends from Bambk use Pivotal for server development. We are all very pleased that such a tool exists in the market and really provides the opportunities that we require. Pivotal Tracker can be implemented using either a small startup team or a serious team of a large product project or outsourcing development.
In the comments, I suggest telling which task manager for development you chose and why.
I’m also ready to answer questions about our workflow in the Pivotal Tracker in terms of development.
The customer almost always has a budget or cost expectations, as well as the ultimate goal - an application with certain functionality. However, in mobile product development, Agile is more justified.
We are outsourcing the development of mobile applications, although we use the Agile tool Pivotal Tracker (hereinafter referred to as PT). It is about the experience of its use that I want to tell you in this article.
What did we need?
When a team — a project manager, several developers and a tester — is working on development, then one entity (an entity is a task, task, user story or another) may have several states, a responsible person and an executor. Therefore, many classic task managers are not suitable for accounting for development tasks.
Ultimately, we came to the conclusion that the entity should have the following meanings:
- title
- executor
- owner (task manager)
- tag (for categorization)
- label (in order to attribute an entity to a specific version of a product)
- sabtaski
And also, for each entity, it should be possible to add a comment (and conduct a comfortable discussion) and different states (not started, started, finished, delivered, etc.).
What can I try?
Many tools for team work are presented on the market (both for the office team and remote employees). We will consider only tools for the interaction of the manager, developer and tester. The communication of the manager with the customer, the manager with the designer and other bundles do not require specially sharpened tools, but there are also interesting practices here - more on that in another article.
I must say right away that there is no place for paper in our workflow, all the tools are only on the computer. Basically, now more services are provided according to the SaaS model, but there are also solutions that can be installed on your server.
Basecamp
This is probably the most famous system for tracking tasks, discussions, files and the like. Therefore, it is simple, reliable and convenient. Great for managerial tasks - simple checklists, discussions, joint text editing. But not at all suitable for development tasks.
A task may be on a specific list, it may have an executor, and there may be a deadline. I know people who, in order to assign task to a specific version of the product (Version 1.0), wrote the necessary version in the task name (“Vote for Rating [3.4]), and the lists were used to determine task statuses (“ Scheduled ”,“ In the process ”,“ Completed ”).
Perhaps for simple projects - one manager and one developer - Basecamp may work, but the system crashes when there are 2-3 developers, a tester and a project manager in a project.
Redmine
A well-known platform that many developers love. It is installed on the server, it is easily customizable, it has many modules. For tasks, the manager-developer-tester seems cumbersome. The interface is ascetic, and in the presence of an “Apple brain” the use of such a tool will upset =)
Jira
A monster from a company that ate all animals in software development tools. Customized, scaled - sometimes confusing and expensive, but many really like it.
Github issues
Many (including companies) store code in Github repositories. Surprisingly, many do not know that they have their own task tracker. However, it is also interesting in that Issues can be tied to commits - made a push and the tasks closed (if their ID was indicated in the comment, respectively).
Other
I know that TFS is popular in some circles, but I'm sorry - I’m even afraid to look there) The
guys from Thematic Media advised me to look at Asana, but somehow it didn’t take root.
Why Pivotal Tracker?
Pricing
PT is not a free product, it costs quite sane money and works on the SaaS model.
For $ 100 per month, you get the opportunity to create an unlimited number of projects and 25 participants in them.
Main
PT can integrate with Google Apps, then inviting employees to projects becomes easier, and you can immediately attach documents from Google Drive to tasks (for example, with the described logic).
PT has many interesting and hidden features, almost everything is described in a long help - www.pivotaltracker.com/help .
General rules
We do not use the concept of user-story as it really is. With us it's just a task / task.
There are 4 types of tasks in PT - feature, bug, chore and release. We use these types as follows:
Feature - the main tasks for changing or improving the functionality of
Bug - the bug number in Crashlytics, or a brief description of the
Release bug - the name of the build version (alpha, beta and rc)
Chore - tasks for the manager directly related to development or release
Purple The label is an epic - we use it as its version number, which go to this functionality.
The green label is a tag - we use it to indicate the sections to which this feature applies (for example, blog view).
In each task, you can conduct a discussion with the mention of other team members (a note will come to them), you can add any files (most often these are screenshots, for example to a UI bug), you can conduct subtask (convenient with pixel-perfect improvements).
All epics are initially stored in a separate tab. You can always open an epic with some old version of the application and see when a certain feature was implemented, and it is also easy to plan a roadmap for future versions. Each epic has its own unique number, like task - you can always give a direct link to it.
The interface in PT is a panel: the main - backlog, icebox, current. We use only the icebox panel (for storing ideas and those tasks that are not included in any version yet) and the backlog (the ribbon of approved tasks), as well as panels that are called via epics - they display tasks only for the selected version. At first glance, to someone who does not use this, everything will seem very strange - but then you get so used to this system that you simply can never look at another.
Directly workflow
The manager has on hand TK and roadmap by version. The process of creating tasks begins. Each task is necessarily accompanied by an epic (if it is development from scratch, then the version is usually 1.0) and a section label (we use the label as a screen, ie the team screen is “team”, the match screen is “match”). All tasks fall into the Icebox.
Next, the tasks are moved to the Backlog. From this moment they are approved and each contractor must have an executor installed. If the project has one developer, then this is not required. If there are several developers, task allocation is carried out by the team lead.
Each task has a level of complexity - this is some abstract value in points (it is used to calculate velocity, but we do not use it). However, without setting this value, the task does not start. After the developer starts the task, he clicks Start. At the end of the task, the developer clicks Finish. The next possible task state is Delivered. This happens when the developer delivers the task to the assembly.
We do Friday assemblies, already completed tasks fall into them. When making an assembly, the developer notes those tasks that fall into the assembly and which can be accepted by the project manager. The manager can accept the task if he believes that the task is done as it should and functions, and can make a redirect indicating the reason. After the edit, the task has a Rejected state (the button is Restart) and you can start it again.
Thus, you can at any time understand what a particular developer is doing, what tasks are already implemented and will fall into the assembly, which ones are in the icebox, etc. This is very convenient and visual, and the order of tasks can be easily changed - for example, within the framework of one release, or transfer to the next release.
After a review of the Friday build, the manager can also create bugs related to bugs. In releases with beta and rc statuses, a tester is connected, which can also create task bugs. He is then responsible for accepting them or redirecting them after correction by the developer.
When the task is delivered and accepted, it turns green and the task is closed.
Developers like to specify a task in the GitHub commit when the task automatically finishes when it is pushed.
Features
In large projects, the number of tasks can reach up to a thousand. You can develop your own principles for creating tasks and use them.
In the case of an automatic build server, the task state must be changed to Delivered when the changes are committed to the repository, because assembly will happen automatically. Well, here each team has its own characteristics.
Pivotal Tracker has excellent iPhone / iPad applications (for now, though without adaptation to iOS7), there are also third-party Android clients. There is integration with all external services - GitHub, Campfire, FlowDock, HipChat, Zendesk, etc.
We do not provide Pivotal access to the customer, but in case of such a requirement, the tracker has the opportunity to invite an “observer” with “read only” rights.
Conclusion
Our friends from Aviasales also use this tool both in server development (though they slowly jump from it, because they switch to full Scrum) and in the mobile development department. Friends from Bambk use Pivotal for server development. We are all very pleased that such a tool exists in the market and really provides the opportunities that we require. Pivotal Tracker can be implemented using either a small startup team or a serious team of a large product project or outsourcing development.
In the comments, I suggest telling which task manager for development you chose and why.
I’m also ready to answer questions about our workflow in the Pivotal Tracker in terms of development.