About agile-methodology. Subjectively
The topic that I will talk about is extremely ambiguous. I foresee a sickly holivar about this, if, of course, the article will interest someone. Before proceeding directly to reading, take another look at the title and its last word. And do not say that I'm wrong. I myself know that many will disagree with me. Yes, and I have no such goal. So…
During my short career, if you can call it that, a developer, you managed to work in different (not only in names) organizations. We all change jobs from time to time, someone more often, someone less often. Naturally, we compare them with each other according to some criteria, expose subjective or not so assessments. For myself. For your future. Draw conclusions. Frustrated or rejoice. A few months after the change of work, we again begin to compare our current place with the previous one. Sometimes thoughts penetrate into the head, they say, it was in vain. The old job was still great, although they paid less. But I already knew everyone, I could go to the center of the office and say something like, "Yes, it all went to hell with deadlines, I had your job." Go for a break dash to drink tea, sit down at the computer again, play around so well and successfully finish your piece.
We all know that often tasks are put like this:
')
I am very glad that I saw this bayan-babayan just recently. This means that it was I who faced such academic idiocy rather late in my life and is completely grateful to her for that. This is what prompted me to write an article. We can laugh at the video, talk for three minutes, as it is vital and fun and, if not for such moments, our work would be boring and dull, pass by and generally say that there is nothing perfect, everyone is wrong, customers are not obliged to understand in the intricacies of our work and so on.
I learned about agile a little over a year ago. Before that, the work was also built on similar methods, but I did not know what it was called. Yes, and it was not necessary. There were tasks, lax estimeyty, deadlines, Redmine and SVN. At another place of work there were scrum, sprints, plenings (or their interpretation by managers), JIRA and BitBucket were used, which is basically the same, only better. I will not talk much about tools, as it is subjective, there are a lot of them, both paid and free, and this is important only in the second place. No, not even the best tool will help if the organization of labor is at a low level.
I call a poor organization of labor the transfer of people from a project to a project in a chaotic manner, when the most important thing is the number of established and completed tasks, when an emergency is an everyday development process, when the urgent and immediate redmine from tasks do not know where to blush (Redmail developers should think about adding status to the box with blinking and accompanying with a sound signal, like an ambulance, and certainly an uppercase), this is estimeytov display without the participation of developers. This is often outsourced, when you or your manager communicate directly with English-speaking colleagues who are in different time zones. Performing these tasks becomes your goal. Over time, you begin to believe that efficiency is measured by the number of tickets made yesterday, today, and scheduled for tomorrow. This is becoming the norm. It changes a person. Even the look changes. Man turns into an upturned deer. Seriously, I'm not joking. A good check of the team on the uproariness is an informal atmosphere. Corporate or some holiday.
I want the reader to understand that I blame not the methodology, but their improper use from the point of view of the performer. Representing yourself in the place of a leader, it seems that I would hardly be interested in how the task will be solved, because the main result is the final result. How do you do that, well let's be honest - more often than not, it doesn't matter.
I don’t know about you, but I need concentration of attention in order to do my job well. If a person participates in two or more projects, each of which has a rally every day, if you need to constantly switch from one task to another, you can hardly concentrate and do a good job for a long time. However, I understand that the future, like the present, is not without it. And, apparently, will have to get used to, as this may be one of the key skills.
For me, a good option is a stand-up of 5-20 minutes, in which we briefly find out who does what and, if necessary, after it ends, we communicate already in the process of working with each other. A good option is capturing once a week or two (sometimes a month) with the obligatory presence of everyone who will participate in the subsequent sprint. All this eliminates the need for every day for an hour and a half (God forbid, on Skype) to engage in chatter. Well, it is not necessary for everyone every day to know in detail what everyone else is doing! You need a designer - approached him, found out the necessary information, - went on working.
Any extreme is bad. I had the experience of everyday hour and a half chatting on Skype. This is extreme. Do not use tools that speed up workflows in good hands - extreme. Each team must find for itself the golden mean in which it will be comfortable for them to work, and not fit everyone in a row to certain standards. Moreover, they are not. It is possible to develop their own methods based on popular, effective practices. And it is not easy. On the search and sample can take precious time and money of investors. But you can not just take andsubmit an application for 250 thousand horses to start using agile.
Agile! == "run with bulging eyes and try to do everything, whatever the cost," although the sprint often means exactly that. For me, agile is just a set of methodologies that should help everyone - from a manager to an office manager.
Why does agile help me work?
It's simple. Without the organization of work, everything will be bad. The developer takes more responsibility for his work, organizes himself, gets used to a certain mode. The leader can follow the process, identify weaknesses. It is inappropriate to speak here about the scientific and practical justification - a separate topic for conversation.
Why does agile keep me from working?
When misunderstood, its use leads to such troubles as a poor microclimate within the team, overdue deadlines, layoffs, general dissatisfaction with the process and the result of development.
There are many people among us (I would also rank myself among them) who incorrectly interpret some of the concepts associated with modern approaches to managing development. I would like the leaders to understand them as best they can, listen not only to themselves and, most importantly, try to apply them as flexibly as possible in each particular case. It is not always the development process - the pipeline.
In conclusion - several associative links (they have only a tangent relation to the topic):
During my short career, if you can call it that, a developer, you managed to work in different (not only in names) organizations. We all change jobs from time to time, someone more often, someone less often. Naturally, we compare them with each other according to some criteria, expose subjective or not so assessments. For myself. For your future. Draw conclusions. Frustrated or rejoice. A few months after the change of work, we again begin to compare our current place with the previous one. Sometimes thoughts penetrate into the head, they say, it was in vain. The old job was still great, although they paid less. But I already knew everyone, I could go to the center of the office and say something like, "Yes, it all went to hell with deadlines, I had your job." Go for a break dash to drink tea, sit down at the computer again, play around so well and successfully finish your piece.
We all know that often tasks are put like this:
')
I am very glad that I saw this bayan-babayan just recently. This means that it was I who faced such academic idiocy rather late in my life and is completely grateful to her for that. This is what prompted me to write an article. We can laugh at the video, talk for three minutes, as it is vital and fun and, if not for such moments, our work would be boring and dull, pass by and generally say that there is nothing perfect, everyone is wrong, customers are not obliged to understand in the intricacies of our work and so on.
I learned about agile a little over a year ago. Before that, the work was also built on similar methods, but I did not know what it was called. Yes, and it was not necessary. There were tasks, lax estimeyty, deadlines, Redmine and SVN. At another place of work there were scrum, sprints, plenings (or their interpretation by managers), JIRA and BitBucket were used, which is basically the same, only better. I will not talk much about tools, as it is subjective, there are a lot of them, both paid and free, and this is important only in the second place. No, not even the best tool will help if the organization of labor is at a low level.
I call a poor organization of labor the transfer of people from a project to a project in a chaotic manner, when the most important thing is the number of established and completed tasks, when an emergency is an everyday development process, when the urgent and immediate redmine from tasks do not know where to blush (Redmail developers should think about adding status to the box with blinking and accompanying with a sound signal, like an ambulance, and certainly an uppercase), this is estimeytov display without the participation of developers. This is often outsourced, when you or your manager communicate directly with English-speaking colleagues who are in different time zones. Performing these tasks becomes your goal. Over time, you begin to believe that efficiency is measured by the number of tickets made yesterday, today, and scheduled for tomorrow. This is becoming the norm. It changes a person. Even the look changes. Man turns into an upturned deer. Seriously, I'm not joking. A good check of the team on the uproariness is an informal atmosphere. Corporate or some holiday.
I want the reader to understand that I blame not the methodology, but their improper use from the point of view of the performer. Representing yourself in the place of a leader, it seems that I would hardly be interested in how the task will be solved, because the main result is the final result. How do you do that, well let's be honest - more often than not, it doesn't matter.
I don’t know about you, but I need concentration of attention in order to do my job well. If a person participates in two or more projects, each of which has a rally every day, if you need to constantly switch from one task to another, you can hardly concentrate and do a good job for a long time. However, I understand that the future, like the present, is not without it. And, apparently, will have to get used to, as this may be one of the key skills.
For me, a good option is a stand-up of 5-20 minutes, in which we briefly find out who does what and, if necessary, after it ends, we communicate already in the process of working with each other. A good option is capturing once a week or two (sometimes a month) with the obligatory presence of everyone who will participate in the subsequent sprint. All this eliminates the need for every day for an hour and a half (God forbid, on Skype) to engage in chatter. Well, it is not necessary for everyone every day to know in detail what everyone else is doing! You need a designer - approached him, found out the necessary information, - went on working.
Any extreme is bad. I had the experience of everyday hour and a half chatting on Skype. This is extreme. Do not use tools that speed up workflows in good hands - extreme. Each team must find for itself the golden mean in which it will be comfortable for them to work, and not fit everyone in a row to certain standards. Moreover, they are not. It is possible to develop their own methods based on popular, effective practices. And it is not easy. On the search and sample can take precious time and money of investors. But you can not just take and
Agile! == "run with bulging eyes and try to do everything, whatever the cost," although the sprint often means exactly that. For me, agile is just a set of methodologies that should help everyone - from a manager to an office manager.
Why does agile help me work?
It's simple. Without the organization of work, everything will be bad. The developer takes more responsibility for his work, organizes himself, gets used to a certain mode. The leader can follow the process, identify weaknesses. It is inappropriate to speak here about the scientific and practical justification - a separate topic for conversation.
Why does agile keep me from working?
When misunderstood, its use leads to such troubles as a poor microclimate within the team, overdue deadlines, layoffs, general dissatisfaction with the process and the result of development.
There are many people among us (I would also rank myself among them) who incorrectly interpret some of the concepts associated with modern approaches to managing development. I would like the leaders to understand them as best they can, listen not only to themselves and, most importantly, try to apply them as flexibly as possible in each particular case. It is not always the development process - the pipeline.
In conclusion - several associative links (they have only a tangent relation to the topic):
- Article Stop Trying to Incentivize Your Employees More Like You
- The film “Office Space”
- Marina Mironovich: How to live further if you nevertheless decided to write your MVC framework
- Translation of a good article
Source: https://habr.com/ru/post/243675/
All Articles