How do we do trello
After a couple of years of searching, we finally found a tool for painless task management at Alconost: Trello . The tool is simple and not overloaded with unnecessary functionality; in fact, these are boards with ticket stickers moving from the “Idea” or “Suggestion” column to the “Made” column.
We began to use Trello to solve small current tasks (update the description of services on the site, find a South Korean translator, etc.) and very quickly saw that we could lead global long-term projects. Now we have completely transferred to Trerello the management of the process of creating videos , large localization projects, and even projects to develop our own products.
How the guys from Fog Creek Software managed to make such an amazingly simple and at the same time functional product - in the post by Bobby Grace (Bobby Grace) “How We Make Trello”
')
Transferred to Alconost .
Look around: is there something screwed to the floor nearby? Thanks, now take hold of this tighter. I'm going to reveal the maps: you will find out how Trello was actually created. What you learn may shock you, make you take a sedative and reconsider your view of things. In general, unpredictable consequences are possible. Well, if you are firmly entrenched in space - let's begin.
To understand how Trello is done, let's look at how it works. When you go to trello.com in a browser, you are actually running a client application that accesses the Trello API. An API is a thing that takes your request to the database and returns with the boards and cards you requested. You say the API: “Hi, I'm Bobby. If you don’t feel sorry, let me see my boards when it’s convenient. ” And in a matter of milliseconds, the API responds with the line: {user: bobbygrace, boards: ['44321234432', '44321234433']]. The client application takes this line and turns it into beautifully organized readable information, which you can see on the screen.
Perhaps you downloaded our applications for iOS , Android , Kindle , Windows 8 and thought: “These are well-made programs with high ratings in app stores, are they just customers who access the API?”. Yes. These are just customers. Customers everywhere. Actually, the Trello API is open, and if you know how to communicate with it, you can also make your client .
The Trello API is well written, error free and generally very reliable. At least, changes are made to it not very often. This means that we can always make new customers without needing to update the API. That is, at any given time many different versions of the site can work.
“This is all wonderful and clearly somehow linked with the stated theme further along the article, but you actually promised to tell you how Trello was done.” OK OK. We will come back to this later, and now I will describe our workflow.
Not surprisingly, we use Trello to work on Trello. We have a board "Service Trello", where everything that we are working on is now based on the API and the site. Our lists look like this: “In work”, “Waiting for testing / checking”, “Ready for merging”, a pack of lists for recent releases, “Incoming errors”.
Suppose a developer wants to correct an error. Everything happens as follows:
Now another developer can pull out changes from the official Build repository and merge them with his working branch. And then his changes will pass the described process like clockwork. So we make changes many times a day.
I am sure that everything said up to this point sounds reasonable, but the correction of errors is still flowers. What about the big new features that I would like to test first, something like a new card turnover ?
Remember that in the Build repository is a stable, approved version of Trello? In fact, there are many stable, approved versions, and you can work with any of them. What you see is not necessarily what others see. Sorry if your picture of the world began to crumble. But why do we do this to you?
Let's say we are going to solve a big problem in Trello. Conducted research, carefully designed and developed a completely new version of Trello, fully tested and tested - all this long and thorough process went through, which I squeezed into one sentence. This version is probably still a confusing, annoying mess with a lot of mistakes. Why? Because design is only a reasonable assumption, not an obvious solution. We do not know exactly how this works in the real world (a concept, the fundamentals of which I shook for you). Instead of giving away the unfinished product to everyone, we give this version to the team in order to understand what needs to be corrected. So we send this version to the Alpha channel.
“Channel CHEGOOO?”
Trello has three channels: Stable, Beta, and Alpha. When you visit trello.com, the server determines which channel you are on and which version to show you. Most - on the "Stable" channel. About 20 more people have access to Beta, and the Trello team and Fog Creek employees have access to Alpha. If the user has access to multiple channels, the switch is shown.
Thus, while minor edits go to the “Stable” channel, big changes, for example, a new card turnover or a new page of the boards , are sent to the alpha channel and are used with the real data by the team. When the version gets into the alpha channel, we raise the visor. Hot disputes begin. Boils up anger. Triumph. Joy. Disappointment. Hope. And - repeat the cycle. A lot of repetition. As soon as you notice something wrong in the alpha channel - we screwed up, shoot.
And by the way: if you need changes in the API for a new client, they are placed separately before the new client enters the alpha channel.
The version is being finalized in the alpha channel until it is ready for display in Beta. The beta version has a noticeable button "Feedback" and a note that this is an early test version of Trello, with a request to "pay attention to new features." Then we get feedback, we go through cycles, we finalize ... When we are almost satisfied with the result, we begin to spread this version little by little for a small percentage of random users of a stable channel. Usually we start from 1% and reach 15% in a few days. So we get a lot of feedback. We draw attention to the serious errors that are often encountered, and again we go through cycle after cycle.
Now everything is fine - and the new client is available to all users of the stable version. We are preparing a blog post about the biggest and coolest new features, announce it and - Bach! Salute, champagne, clinking glasses. We are constantly opening up champagne, although personally it seems to me that it is time to tie, because it is expensive and I have a terrible hangover from champagne.
I would like to linger for a moment on the previously mentioned design and research stage. We use the product planning board, where we store issue cards. We call the cards like this: "I can not find this function" or "I want to do this, but I can not." There are several sources of such problems:
We use all this feedback as research material. We conduct many internal surveys and usability tests. We also look at anonymous data about site usage in Google Analytics, in order to understand what features people really use. In the end, we hope to understand: how people are using Trello now, how they want something to work, what they don’t use and what they have the most serious problems with.
This information and several possible solutions are counted on the back of each card. When we take on a specific problem, I take her card, make several paper sketches based on the proposed solutions, then a couple of rough layouts and schemes in Sketch (note: Sketch is not made by us, but it’s still worth buying). In the course of the work, I constantly publish charts and screenshots on the corresponding card in Trello and in this way I receive constant feedback from the team. Knowing that the interface can change dramatically as a result, I don’t spend much time on detailing layouts. In any case, we can quickly change everything in the code. Here is an example of a new card turnover layout. Comments point to important innovations. This layout is more detailed than others because it describes important elements of graphic design.
The next step before developing a prototype is to give the project a code name. This is very important and often very fun. The new page of the boards was codenamed "Outskirts" because it applied to everything outside the main board. The project to create a new turnover of the card was called “Donut with jam”, because inside (the card) it was even tastier than the outside. When we added the ability to use multiple clients, it was called "Hydra" - in honor of the mythical many-headed monster. We are currently working on a search. This is called “Skating on the hay” and, in my opinion, refers to the search for a needle in a haystack. The iOS team also has project code names. When they worked on scrolling quality, the project was called “The Hobbit” - in honor of a large-scale film with a detailed, almost vivid, high-resolution picture. Code names are important as pivot points. We also call our branches: bobby / borderlands looks much better than bobby / new-boards-page-starred-boards-other-stuff-too.
Now that everything is named and prototyped, we launch the development into the Alpha channel and begin the cycle. Implementation. Run Champagne. Touche.
Our workflow has come a long way, thanks in large part to Doug’s efforts and the ability to use several working clients at the same time. Maybe Doug would write something more technical about it. I must say that the workflows for iOS and Android teams are different; they are no less interesting, but not described here. Ian says that the build process for iOS is “cmd + B”, but yes, you understand that this is not exactly what I mean.
That's all. I hope it turned out quite informative. You can criticize me on Twitter .
About the translator
The article is translated in Alconost.
Alconost is engaged in the localization of applications, games and websites in 60 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.
We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.
Read more: https://alconost.com
We began to use Trello to solve small current tasks (update the description of services on the site, find a South Korean translator, etc.) and very quickly saw that we could lead global long-term projects. Now we have completely transferred to Trerello the management of the process of creating videos , large localization projects, and even projects to develop our own products.
How the guys from Fog Creek Software managed to make such an amazingly simple and at the same time functional product - in the post by Bobby Grace (Bobby Grace) “How We Make Trello”
')
Transferred to Alconost .
Look around: is there something screwed to the floor nearby? Thanks, now take hold of this tighter. I'm going to reveal the maps: you will find out how Trello was actually created. What you learn may shock you, make you take a sedative and reconsider your view of things. In general, unpredictable consequences are possible. Well, if you are firmly entrenched in space - let's begin.
To understand how Trello is done, let's look at how it works. When you go to trello.com in a browser, you are actually running a client application that accesses the Trello API. An API is a thing that takes your request to the database and returns with the boards and cards you requested. You say the API: “Hi, I'm Bobby. If you don’t feel sorry, let me see my boards when it’s convenient. ” And in a matter of milliseconds, the API responds with the line: {user: bobbygrace, boards: ['44321234432', '44321234433']]. The client application takes this line and turns it into beautifully organized readable information, which you can see on the screen.
Perhaps you downloaded our applications for iOS , Android , Kindle , Windows 8 and thought: “These are well-made programs with high ratings in app stores, are they just customers who access the API?”. Yes. These are just customers. Customers everywhere. Actually, the Trello API is open, and if you know how to communicate with it, you can also make your client .
The Trello API is well written, error free and generally very reliable. At least, changes are made to it not very often. This means that we can always make new customers without needing to update the API. That is, at any given time many different versions of the site can work.
“This is all wonderful and clearly somehow linked with the stated theme further along the article, but you actually promised to tell you how Trello was done.” OK OK. We will come back to this later, and now I will describe our workflow.
Using Trello for Trello
Not surprisingly, we use Trello to work on Trello. We have a board "Service Trello", where everything that we are working on is now based on the API and the site. Our lists look like this: “In work”, “Waiting for testing / checking”, “Ready for merging”, a pack of lists for recent releases, “Incoming errors”.
Suppose a developer wants to correct an error. Everything happens as follows:
- He takes a card from the “Incoming errors” list, assigns himself to the performer and transfers it to the “In Work” list.
- He knocks on the keyboard like a mad monkey until he corrects the mistake (well, or it’s just me who does it).
- It creates a new branch in its repository (for example: bobby / oops-no-crash) and sends it to Kiln, a first-class distributed version control system and code checks (by the way, we also make Kiln). I will not delve too deeply into the work of the version control system, but, in simple terms, a branch is a new version based on a stable main version on a production server. Everyone who knows how version control systems work is now twisted and flipped.
- The developer adds the name of the branch to the card description (for example: “fixed in bobby / oops-no-crash”) and transfers it to the “Waiting for testing / validation” list.
- At the same time, it sends the changes for verification to another developer in Kiln (which you should have purchased) and notifies our brave tester, Ali T., who checks this thread to make sure that the error is indeed corrected.
- When all possible checks have been successfully completed, the card is sent to the “Ready for Merge” list.
- Our release manager Doug Patty combines these changes with the official Build repository, turns the version with the changes into a new and stable version, prepares the release and releases it to the world. We often joke that using Kinect would make this move more exciting. Doug could just wave his arms and shout, “Depla! Depla! Deploy! ” To our shame, this is not a priority now.
- Corrections published. Champagne, clinking glasses.
Now another developer can pull out changes from the official Build repository and merge them with his working branch. And then his changes will pass the described process like clockwork. So we make changes many times a day.
I am sure that everything said up to this point sounds reasonable, but the correction of errors is still flowers. What about the big new features that I would like to test first, something like a new card turnover ?
How we make and test great innovations
Remember that in the Build repository is a stable, approved version of Trello? In fact, there are many stable, approved versions, and you can work with any of them. What you see is not necessarily what others see. Sorry if your picture of the world began to crumble. But why do we do this to you?
Let's say we are going to solve a big problem in Trello. Conducted research, carefully designed and developed a completely new version of Trello, fully tested and tested - all this long and thorough process went through, which I squeezed into one sentence. This version is probably still a confusing, annoying mess with a lot of mistakes. Why? Because design is only a reasonable assumption, not an obvious solution. We do not know exactly how this works in the real world (a concept, the fundamentals of which I shook for you). Instead of giving away the unfinished product to everyone, we give this version to the team in order to understand what needs to be corrected. So we send this version to the Alpha channel.
“Channel CHEGOOO?”
Trello has three channels: Stable, Beta, and Alpha. When you visit trello.com, the server determines which channel you are on and which version to show you. Most - on the "Stable" channel. About 20 more people have access to Beta, and the Trello team and Fog Creek employees have access to Alpha. If the user has access to multiple channels, the switch is shown.
Thus, while minor edits go to the “Stable” channel, big changes, for example, a new card turnover or a new page of the boards , are sent to the alpha channel and are used with the real data by the team. When the version gets into the alpha channel, we raise the visor. Hot disputes begin. Boils up anger. Triumph. Joy. Disappointment. Hope. And - repeat the cycle. A lot of repetition. As soon as you notice something wrong in the alpha channel - we screwed up, shoot.
And by the way: if you need changes in the API for a new client, they are placed separately before the new client enters the alpha channel.
The version is being finalized in the alpha channel until it is ready for display in Beta. The beta version has a noticeable button "Feedback" and a note that this is an early test version of Trello, with a request to "pay attention to new features." Then we get feedback, we go through cycles, we finalize ... When we are almost satisfied with the result, we begin to spread this version little by little for a small percentage of random users of a stable channel. Usually we start from 1% and reach 15% in a few days. So we get a lot of feedback. We draw attention to the serious errors that are often encountered, and again we go through cycle after cycle.
Now everything is fine - and the new client is available to all users of the stable version. We are preparing a blog post about the biggest and coolest new features, announce it and - Bach! Salute, champagne, clinking glasses. We are constantly opening up champagne, although personally it seems to me that it is time to tie, because it is expensive and I have a terrible hangover from champagne.
Design and research
I would like to linger for a moment on the previously mentioned design and research stage. We use the product planning board, where we store issue cards. We call the cards like this: "I can not find this function" or "I want to do this, but I can not." There are several sources of such problems:
- error information from users that we receive through FogBuzz — a world-class error handling system (note: we also do FogBuzz, and yes, you should buy it);
- dissatisfaction with the development team;
- personal conversations with Trello users, conducted by our client happiness specialist Ben . I do not know how exactly his position is called.
We use all this feedback as research material. We conduct many internal surveys and usability tests. We also look at anonymous data about site usage in Google Analytics, in order to understand what features people really use. In the end, we hope to understand: how people are using Trello now, how they want something to work, what they don’t use and what they have the most serious problems with.
This information and several possible solutions are counted on the back of each card. When we take on a specific problem, I take her card, make several paper sketches based on the proposed solutions, then a couple of rough layouts and schemes in Sketch (note: Sketch is not made by us, but it’s still worth buying). In the course of the work, I constantly publish charts and screenshots on the corresponding card in Trello and in this way I receive constant feedback from the team. Knowing that the interface can change dramatically as a result, I don’t spend much time on detailing layouts. In any case, we can quickly change everything in the code. Here is an example of a new card turnover layout. Comments point to important innovations. This layout is more detailed than others because it describes important elements of graphic design.
The next step before developing a prototype is to give the project a code name. This is very important and often very fun. The new page of the boards was codenamed "Outskirts" because it applied to everything outside the main board. The project to create a new turnover of the card was called “Donut with jam”, because inside (the card) it was even tastier than the outside. When we added the ability to use multiple clients, it was called "Hydra" - in honor of the mythical many-headed monster. We are currently working on a search. This is called “Skating on the hay” and, in my opinion, refers to the search for a needle in a haystack. The iOS team also has project code names. When they worked on scrolling quality, the project was called “The Hobbit” - in honor of a large-scale film with a detailed, almost vivid, high-resolution picture. Code names are important as pivot points. We also call our branches: bobby / borderlands looks much better than bobby / new-boards-page-starred-boards-other-stuff-too.
Now that everything is named and prototyped, we launch the development into the Alpha channel and begin the cycle. Implementation. Run Champagne. Touche.
Our workflow has come a long way, thanks in large part to Doug’s efforts and the ability to use several working clients at the same time. Maybe Doug would write something more technical about it. I must say that the workflows for iOS and Android teams are different; they are no less interesting, but not described here. Ian says that the build process for iOS is “cmd + B”, but yes, you understand that this is not exactly what I mean.
That's all. I hope it turned out quite informative. You can criticize me on Twitter .
About the translator
The article is translated in Alconost.
Alconost is engaged in the localization of applications, games and websites in 60 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.
We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.
Read more: https://alconost.com
Source: https://habr.com/ru/post/218245/
All Articles