Pivotal Tracker as a tool in Waterfall development
There are not many companies in the Russian market for outsourcing that use flexible development methodologies ( Agile ). Everyone is accustomed to work on a cascade model ( Waterfall ). The same applies to the mobile development sector.
The customer almost always has a budget or expectations for the cost, as well as the final task - an application with a certain functionality. However, in mobile product development, the use of Agile is more justified.
')
We are engaged in the outsourcing development of mobile applications, although we use the Agile-tool - Pivotal Tracker (hereinafter - PT). It is about the experience of using it that I want to tell you in this article.
When a team is working on a development — a project manager, several developers and a tester — then one entity (entity is a task, task, user-story or other) may have several states, a responsible person and a performer. Therefore, many classic task managers are not suitable for accounting development tasks.
Ultimately, we came to the conclusion that the entity should have the following values:
Also, each entity should be able to add a comment (and lead a comfortable discussion) and different states (not started, started, finished, delivered, etc.).
There are many tools for teamwork on the market (both for the office team and remote employees). We consider only the tools for interaction manager, developer and tester. Communication between the manager and the customer, the manager with the designer, and other bundles do not require specially sharpened tools, but there are interesting practices here as well - in another article.
I’ll 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 on the SaaS model, but there are solutions that can be installed on your server.
This is probably the most famous system for tracking tasks, discussions, files and the like. Therefore, simple, reliable and convenient. Great for managerial tasks - simple checklists, discussions, joint editing of texts. But not at all suitable for development tasks.
The task may be in a certain list, it may have a performer, there may be a deadline. I know people who wrote the necessary version (“Voting for rating [3.4]) in the title of the task to assign the task to a specific version of the product (Version 1.0), and the lists were used to determine the status of the task (“ Planned ”,“ In progress "," Completed ").
Perhaps for simple projects - one manager and one developer - Basecamp may be suitable, but the system collapses when there are 2-3 developers in the project, a tester and a project manager.
A well-known platform that many developers love. It is installed on the server, it is easy to customize, it has many modules. For tasks, the development manager-tester seems cumbersome. The interface is austere, and in the presence of “Apple brain” the use of such a tool will be distressing =)
Monster from a company that ate all the animals in software development tools. Customized, scaled - sometimes confusing and expensive, but many really like it.
Many (including companies) store the code in Github repositories. Surprisingly, many do not know that their task tracker is there. However, it is also interesting because Issues can be tied up with commits - made push and task closed (if I indicated their ID in the comments, respectively).
I know that TFS is popular in some circles, but I'm sorry - I’m even afraid to look there)
The Thematic Media guys advised to take a look at Asana, but somehow they didn’t take it either.
PT is not a free product, it costs quite sane money and works on the model of SaaS.
For $ 100 a month, you get the opportunity to create an unlimited number of projects and 25 participants in them.
PT can integrate with Google Apps, then it becomes easier to invite employees to projects, and you can immediately attach documents from Google Drive to tasks (for example, with the described logic).
PT has a lot of 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. We have this task / task.
There are 4 types of tasks in PT - feature, bug, chore and release. We use these types like this:
Feature - the main tasks to change or improve functionality
Bug - the bug number in Crashlytics, or a brief description of the bug
Release - the name of the build version (alpha, beta and rc)
Chore - tasks for the manager directly related to the development or release
The purple label is an epic - we use as its version number, into which this functionality will go.
The green label is a tag - we use it to specify the sections to which this feature applies (for example, blog view).
In each task, you can have a discussion with mentioning other team members (they will be notified by notifay), you can add any files (most often these are screenshots, for example, to a UI-bug), you can conduct a subtask (conveniently with pixel-perfect updates).
All epics (epics) are initially stored in a separate tab. You can always open the epic with some old version of the application and see when a certain feature has been implemented, and also easily plan a roadmap for future versions. Each epic has its own unique number, as well as a task - you can always give a direct link to it.
The interface in PT is a panel: the main ones are backlog, icebox, current. We use only the icebox panel (for storing ideas and those tasks that are not included in any version yet) and backlog (tape of approved tasks), as well as panels that are called through epics - they display tasks only to the selected version. At first glance, to someone who does not use it, everything will seem very strange - but then you get so used to this system that you can never look at the other.
The manager has on hand TK and roadmap versions. The process of creating tasks begins. Each task is necessarily accompanied by an epic (if this is development from scratch, then the version is usually 1.0) and a label by section (we use the label as a screen, i.e. the command screen is “team”, the match screen is “match”). All Tasks go to Icebox.
Next, the task is moved to the Backlog. From this point on, they are approved and each task must have a performer installed. If there is one developer on the project, then this is not required. If there are several developers, the distribution of tasks is carried out by the project team.
Each task has a difficulty level - this is a kind of abstract value in points (it is used to calculate the velocity, but we do not use it). However, without setting this value, the puzzle will not start. After the developer starts the task, he presses Start. When the task is completed, the developer clicks Finish. The next possible state task is Delivered. This happens when the developer delivers the task to the assembly.
We do Friday assemblies, and just the completed tasks get into them. Making the assembly, the developer notes those tasks that will fall into the assembly and which can be taken by the project manager. A manager can accept a task if he thinks that the task is done as it should and is functioning, or he can do a rejection, indicating the reason. After the redesign, the task has the Rejected state (button - Restart) and you can proceed to it again.
Thus, at any time you can understand what a specific developer is doing, what tasks have already been implemented and will get into the assembly, what else in the icebox, etc. This is very convenient and intuitive, you can also easily change the order of tasks - for example, in one release, or transfer to the next release.
After reviewing Friday's build, the manager can also create bugs related to bugs. In releases with beta and rc status, a tester is connected, which can also create bug bugs. He is then responsible for accepting or re-issuing them after correction by the developer.
When the task is delivered and accepted, it becomes green and the task is closed.
Developers like to point in a commit in GitHub ID task, then when you push task, it automatically finishes.
In large projects, the number of tasks can go up to a thousand. You can develop your own principles of creating tasks and use them.
In the case of an automatic build server, the state task for Delivered needs to be changed when changes are logged into the repository, since assembly will occur 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 access to Pivotal 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 (albeit slowly jumping off of it, as they switch to full Scrum) and in the mobile development department. Bambk friends use Pivotal for server development. We are all very pleased that such a tool exists on the market and really provides the capabilities that we need. Pivotal Tracker can be implemented by a small start-up team, as well as by a serious team of a major product project or outsourcing.
In the comments, I propose to tell which task manager for development you chose and why.
Also ready to answer questions on our workflow in Pivotal Tracker in terms of development.
The customer almost always has a budget or expectations for the cost, as well as the final task - an application with a certain functionality. However, in mobile product development, the use of Agile is more justified.
')
We are engaged in the outsourcing development of mobile applications, although we use the Agile-tool - Pivotal Tracker (hereinafter - PT). It is about the experience of using it that I want to tell you in this article.
What did we need?
When a team is working on a development — a project manager, several developers and a tester — then one entity (entity is a task, task, user-story or other) may have several states, a responsible person and a performer. Therefore, many classic task managers are not suitable for accounting development tasks.
Ultimately, we came to the conclusion that the entity should have the following values:
- title
- executor
- owner (task director)
- tag (for categorization)
- label (in order to relate the entity to a specific version of the product)
- Sabtaski
Also, each entity should be able to add a comment (and lead a comfortable discussion) and different states (not started, started, finished, delivered, etc.).
What can I try?
There are many tools for teamwork on the market (both for the office team and remote employees). We consider only the tools for interaction manager, developer and tester. Communication between the manager and the customer, the manager with the designer, and other bundles do not require specially sharpened tools, but there are interesting practices here as well - in another article.
I’ll 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 on the SaaS model, but there are 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, simple, reliable and convenient. Great for managerial tasks - simple checklists, discussions, joint editing of texts. But not at all suitable for development tasks.
The task may be in a certain list, it may have a performer, there may be a deadline. I know people who wrote the necessary version (“Voting for rating [3.4]) in the title of the task to assign the task to a specific version of the product (Version 1.0), and the lists were used to determine the status of the task (“ Planned ”,“ In progress "," Completed ").
Perhaps for simple projects - one manager and one developer - Basecamp may be suitable, but the system collapses when there are 2-3 developers in the project, a tester and a project manager.
Redmine
A well-known platform that many developers love. It is installed on the server, it is easy to customize, it has many modules. For tasks, the development manager-tester seems cumbersome. The interface is austere, and in the presence of “Apple brain” the use of such a tool will be distressing =)
Jira
Monster from a company that ate all the animals in software development tools. Customized, scaled - sometimes confusing and expensive, but many really like it.
Github issues
Many (including companies) store the code in Github repositories. Surprisingly, many do not know that their task tracker is there. However, it is also interesting because Issues can be tied up with commits - made push and task closed (if I indicated their ID in the comments, respectively).
Other
I know that TFS is popular in some circles, but I'm sorry - I’m even afraid to look there)
The Thematic Media guys advised to take a look at Asana, but somehow they didn’t take it either.
Why Pivotal Tracker?
Pricing
PT is not a free product, it costs quite sane money and works on the model of SaaS.
For $ 100 a 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 it becomes easier to invite employees to projects, and you can immediately attach documents from Google Drive to tasks (for example, with the described logic).
PT has a lot of 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. We have this task / task.
There are 4 types of tasks in PT - feature, bug, chore and release. We use these types like this:
Feature - the main tasks to change or improve functionality
Bug - the bug number in Crashlytics, or a brief description of the bug
Release - the name of the build version (alpha, beta and rc)
Chore - tasks for the manager directly related to the development or release
The purple label is an epic - we use as its version number, into which this functionality will go.
The green label is a tag - we use it to specify the sections to which this feature applies (for example, blog view).
In each task, you can have a discussion with mentioning other team members (they will be notified by notifay), you can add any files (most often these are screenshots, for example, to a UI-bug), you can conduct a subtask (conveniently with pixel-perfect updates).
All epics (epics) are initially stored in a separate tab. You can always open the epic with some old version of the application and see when a certain feature has been implemented, and also easily plan a roadmap for future versions. Each epic has its own unique number, as well as a task - you can always give a direct link to it.
The interface in PT is a panel: the main ones are backlog, icebox, current. We use only the icebox panel (for storing ideas and those tasks that are not included in any version yet) and backlog (tape of approved tasks), as well as panels that are called through epics - they display tasks only to the selected version. At first glance, to someone who does not use it, everything will seem very strange - but then you get so used to this system that you can never look at the other.
Directly workflow
The manager has on hand TK and roadmap versions. The process of creating tasks begins. Each task is necessarily accompanied by an epic (if this is development from scratch, then the version is usually 1.0) and a label by section (we use the label as a screen, i.e. the command screen is “team”, the match screen is “match”). All Tasks go to Icebox.
Next, the task is moved to the Backlog. From this point on, they are approved and each task must have a performer installed. If there is one developer on the project, then this is not required. If there are several developers, the distribution of tasks is carried out by the project team.
Each task has a difficulty level - this is a kind of abstract value in points (it is used to calculate the velocity, but we do not use it). However, without setting this value, the puzzle will not start. After the developer starts the task, he presses Start. When the task is completed, the developer clicks Finish. The next possible state task is Delivered. This happens when the developer delivers the task to the assembly.
We do Friday assemblies, and just the completed tasks get into them. Making the assembly, the developer notes those tasks that will fall into the assembly and which can be taken by the project manager. A manager can accept a task if he thinks that the task is done as it should and is functioning, or he can do a rejection, indicating the reason. After the redesign, the task has the Rejected state (button - Restart) and you can proceed to it again.
Thus, at any time you can understand what a specific developer is doing, what tasks have already been implemented and will get into the assembly, what else in the icebox, etc. This is very convenient and intuitive, you can also easily change the order of tasks - for example, in one release, or transfer to the next release.
After reviewing Friday's build, the manager can also create bugs related to bugs. In releases with beta and rc status, a tester is connected, which can also create bug bugs. He is then responsible for accepting or re-issuing them after correction by the developer.
When the task is delivered and accepted, it becomes green and the task is closed.
Developers like to point in a commit in GitHub ID task, then when you push task, it automatically finishes.
Special features
In large projects, the number of tasks can go up to a thousand. You can develop your own principles of creating tasks and use them.
In the case of an automatic build server, the state task for Delivered needs to be changed when changes are logged into the repository, since assembly will occur 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 access to Pivotal 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 (albeit slowly jumping off of it, as they switch to full Scrum) and in the mobile development department. Bambk friends use Pivotal for server development. We are all very pleased that such a tool exists on the market and really provides the capabilities that we need. Pivotal Tracker can be implemented by a small start-up team, as well as by a serious team of a major product project or outsourcing.
In the comments, I propose to tell which task manager for development you chose and why.
Also ready to answer questions on our workflow in Pivotal Tracker in terms of development.
Source: https://habr.com/ru/post/198930/
All Articles