Lecture
Most people believe that only programmers are needed to develop a program, because they are the ones who write the code and make the customer’s dream come true. But between what the customer says and what the programmer eventually does is a whole gulf. Not because they are bad people or do not want to communicate and understand each other, but because the customer thinks at the scale of the goal, thinks what the program should do, why he wants to use it. And the programmer is obliged to think about how the program should work, where to get the data, how to name the new column in the data table, etc., to put it simply, think about the implementation details.
Since both programmers and customers are busy people, clarification of details takes place in the form of question-answer rounds, without fixing anywhere, when and why such a decision was made or how it changed over time. But the main disadvantage of such communication is that the developer asks “how?”, And the customer can only answer “why?”, And the rest is of little interest to him. Moreover, usually, responding to “how?”, The customer leads himself to a dead end, because he cannot and is not obliged to know how many options exist to fulfill his need and what is optimal. The programmer is only doing what he was told. As a result, a situation arises when a puzzled client asks why the application does not fit into his picture of the world, and the puzzled programmer answers that they asked to do so.
Even from the name of the analyst profession, it is clear that his duties include not only collecting requirements, but also analyzing them, namely choosing the optimal way to accomplish the goal. That is, the analyst must know, and why the client has this or that functionality, and how it is made by competitors in order to analyze possible ways of implementation, choose the best one and describe to programmers in detail.
Today, flexible software development methodologies are gaining popularity in Russia and the CIS countries. When considering the possibility of transition to them (and even in the process of transition or initial use), a number of questions almost inevitably arise. One of them is the need for the business analyst to participate in the development process.
The usual set of analytic functions - gathering requirements and writing detailed specifications of how the system should work. Even before the launch of the project requirements must be collected, the specification is written, the designs are drawn, and only then programmers begin to write code. This beautiful story of writing a program rarely corresponds to reality even in projects according to the methodology of waterfall, not to mention Scrum.
Project documentation has a tendency to get out of date very quickly — especially in combination with Agile, where change is the norm, not force majeure.
In this regard, in Agile-methodologies it is strongly advised to minimize documentation:
But this does not mean that everything must be minimized to zero. In the absence of documentation, most likely, the following problems will arise:
Link between developers and customers
In contrast to the classical interpretation of analytics functions, in Agile it is precisely the provision of effective communication between customers (users) and the development team that plays, in fact, a key role.
That is, the analyst is a person who is trusted by both users and developers:
In most cases, this “someone” is an analyst who is assisted by managers when administrative resources are required, and key project experts or even companies when generation of non-standard solutions is required.
Quality control
Traditionally it is believed that quality is controlled by special people who perform acceptance tests according to the described methods and programs. However, who will check that they have done what they need from a business point of view, and what is convenient to use?
Users and customers for the demonstrations are, of course, an option, but, firstly, it’s not a fact that people interested in this functionality will be among them; secondly, it’s possible to lose face (the demonstration will turn into a testing and debugging session); thirdly, a certain amount of resources and time will already be spent on debugging a possibly wrong business solution.
It is quite obvious that instead of (or together with) the owner of the product, this honorable duty may be placed on the analyst.
Analyst interaction patterns - team
In Agile much attention is paid to teamwork, self-organization. How to organize the interaction of the analyst with the team, taking into account the functions assigned to it? There are different options, and depending on the circumstances, these or those turn out to be effective.
Product Owner - Analyst
This is the simplest and most obvious case. The product owner is responsible for the product, for the collection and prioritization of requirements, is a kind of representative of the customer, but on the side of the contractor, he is responsible or helps to answer clarifying questions. All this is closely intertwined with the analyst functions discussed above.
T. h. You can decide: the functions of the analyst performs the owner of the product. Or, if you like, on the contrary - the analyst plays the role of the owner of the product.
Among the advantages of such a scheme: simplicity, minimalism, relative convenience for the customer, and for developers - and those and others always know who exactly needs to be addressed with their questions.
Disadvantages:
Analyst - assistant product owner
Most of the shortcomings of the previous scheme can be overcome by dividing the responsibilities of the product owner and analyst between two people — a fairly common practice. As a rule, the “main” decides what to do in which queue, and additionally performs managerial functions. And the assistant concentrates more on the content and details of the work, that is, plays the role of an analyst.
However, this scheme also has disadvantages:
Analyst inside the team
You can go even further and put the analyst inside the team. What does it mean:
Sounds great. And it works great! However, there are circumstances in which the scheme does not fit:
Conclusion
So is there a difference between an analyst in Agile and a non-Agile (for example, in a waterfall or other heavyweight methodology)? The unequivocal answer is!
In heavyweight methodologies, the analyst looks like a low-permeable wall between the development team and the customer / business representatives. To make a good product, you have to spend a lot of energy on “picking holes” in this wall. In addition, the risks associated with analyst errors are terribly high. The development team is given a supporting role.
In Agile, the analyst plays the role of a link between developers and customers - a kind of magnet that prevents them from running into different corners and quietly do something there without their knowledge. In this case, the development team has a very significant role. This reduces the risks associated with analyst errors: if anything, the team will clarify / correct (and if not correct, the customers will correct for the demonstration).
Analyst in Agile - the golden mean between extremes:
| One extreme | Golden mean | Other extreme |
| The team is not allowed to analytical work. | Agile | Developers themselves have to fully clarify what is needed. |
| The analyst communicates little with the customer. | Agile | The analyst spends all the time at the customer. |
| Detailed specifications before the start of the iteration. | Agile | The absence of any study of the requirements before putting them in the iteration. |
| The aspirated command refers to the analyst's settings. | Agile | The team does not trust the results of the analyst’s work (does not use them). |
| The analyst is not involved in testing (QA). | Agile | The analyst is forced to constantly "pierce" a lot of old interfaces. |
| The team perceives the analyst as a leader. | Agile | Analyst for the team - a boy / girl "running errands." |
| The analyst interacts with the team exclusively with the help of documentation and bug tracker. | Agile | The analyst interacts with the team exclusively through verbal communications. |
| Only the analyst communicates with the customer and users. | Agile | All team members are forced to communicate tightly with customers and users. |
If earlier it was fashionable to equip offices “according to Feng Shui”, now it is exclusively “according to ejail”. Agile is not only colored stickers, on which it is convenient to mark the progress of work (stickers, rather, should be attributed specifically to the kanban approach). But there is also a scrum - is it to do with it?
Especially for those who are confused in terms, we briefly reviewed these concepts and asked the experts why companies should switch to a new system.
The Innovations in Corporations heading is being released with the support of Spinon.
Agile (agile software development, from the English. Agile - agile) is a family of “flexible” approaches to software development. Such approaches are also sometimes called frameworks or agile methodologies.
Agile originated in the IT environment, but then spread to other areas - from industrial engineering to artificial intelligence.
The meaning of Agile is formulated in the Agile-manifest of software development: “People and interaction are more important than processes and tools. A working product is more important than comprehensive documentation. Cooperation with the customer is more important than agreeing the terms of the contract. Readiness for change is more important than following the original plan. ”
Agile-manifest - the main document of all the "flexible" approaches to development. It was created in 2001 by a group of enthusiastic programmers who wanted to understand what exactly was at the basis of developing a sought-after and useful IT product.
Agile assumes that the project does not need to rely only on previously created detailed plans. It is important to focus on the constantly changing conditions of the external and internal environment and to take into account feedback from customers and users. This encourages developers and engineers to experiment and look for new solutions, not limiting themselves to rigid frameworks and standards.
Individual agile approaches include scrum and kanban.
Scrum is a “structured approach.” A universal team of specialists is working on each project, which is joined by two more people: the owner of the product and the scrum-master. The first connects the team with the customer and monitors the development of the project; this is not a formal team leader, but rather a curator. The second helps the first to organize a business process: conducts general meetings, solves domestic problems, motivates the team and monitors compliance with the scrum approach.
The scrum approach divides the work process into equal sprints - usually these are periods from a week to a month, depending on the project and team. Before the sprint, tasks for this sprint are formulated, at the end - the results are discussed, and the team starts a new sprint. Sprints are very convenient to compare with each other, which allows you to manage work efficiency.
Kanban is a “balance approach”. His task is to balance different specialists within the team and avoid a situation where designers work for days and developers complain about the lack of new tasks.
The whole team is one - in kanban there are no roles for the product owner and the scrum master. The business process is not divided into universal sprints, but at the stage of accomplishing specific tasks: “Planned”, “Developed”, “Tested”, “Completed”, etc.
The main indicator of efficiency in kanban is the average time to complete a task on a board. The task passed quickly - the team worked productively and harmoniously. The task was delayed - it is necessary to think at what stage and why the delays occurred and whose work should be optimized.
To visualize agile approaches, boards are used: physical and electronic. They allow you to make the workflow open and understandable for all specialists, which is important when the team does not have one formal leader.
One of the principles of Agile is on the personal responsibility of a person, and not on adjusting internal processes.
(From an article on VC.ru)
When working with professional teams we use Scrum, most often we choose a cycle of 2-3 weeks long with retrospective meetings that allow us to keep everything under control.
(From an interview with Vedomosti with Frank Sosier, coach of Freestanding Agility)
The main idea of Kanban is visualization of the workflow. It consists in creating a physical panel on which you can visually mark progress.
(From Forbes column translation to Rusbase)
If we talk about what agile is, I would confine myself to such a phrase - this is a set of values, within which we build our work with products, with processes within the organization.
(Managing partner of ScrumTrek Alexey Pimenov in the article on Rusbase)
,:
Depending on the tasks, we use different methods within the framework of philosophy - agile, scrum, kanban.
Scrum allows you to develop the necessary qualities in employees - proactivity, autonomy, organization, sociability and foresight. The main purpose of the method is to perform tasks in self-organizing teams, where everyone has their own role and everyone is responsible for their part of the work. Using scrum, we conduct staff surveys, draw up schedules of the expected speed of task execution.
Agile we use in internal communications. Recently held a regular sprint to eliminate staff delays. All the heads and specialists involved in the project spent a whole day at a meeting discussing achievements, problems and upcoming tasks in a new sprint.
Now we are actively implementing the kanban method in the company. The goal of kanban is to increase production flexibility, better adapt to changing market demands. In practice, the method has helped us achieve consistency between stocks and actual products used in production.
Important point: agile-methodology is a general direction, and kanban and scrum are already its varieties.
We use a bundle of scrum + waterfall, and also refined the agile board itself during the year. Main reason for use: transparency and simplicity. In fact, this turns out to be the same Henry Ford pipeline: the transition of a task from status to status with a change of performer, so the main principle to the agile board itself is already simplicity.
We use agile as a direct part of our workflow, so all projects, from branding and website development to our AI and native advertising startup NativeOS, are carried out in Chernika bureau exactly according to this workflow.
A working product is more important than detailed documentation. This does not mean that we do not maintain any documentation, no. Rather, it is a glance towards efficiency with a blow to unnecessary bureaucracy.
Scrum brought rhythm and understanding to our team - whether we are on time or not on time. We see the speed of the team's work, there is no feeling of constant fucking. Previously, there were situations that before hard releases scrum disappeared somewhere and everyone just started to figure it out - now we have lost it, there is a constant feeling that we are on time. If risks arise, we discuss them with PD early on, adjust the plan, or reduce the scope of tasks in some way.
The work became more transparent, the working day began to fit into the 8-hour norm, and it felt like we began to do more. We understand that when you have a feeling that you are not doing enough, you feel that you need to work harder - this has a very bad effect on productivity, you need to get rid of it.
For clarity and openness of the development department's work, we put up a special board marked “to do”, “in progress”, “review”, ”test”, “done”, where all team members stick stickers with tasks (in the column “to do” ), and as they are performed, they are moved to subsequent points. And a happy ending is the “done” end point. This helps to get the big picture and gives you the opportunity to see what each participant is working on.
A very important point of the method (and organization of the workflow): after approval of all tasks (“to do”), the list is blocked for entry. Thus, new incoming tasks do not distract from the process and do not slow down the work.
All participants also evaluate each task in terms of time and material costs that will be required to complete. And the icing on the cake is weekly meetings at a specific time (Daily Scrum), where each team member briefly talks about what they are going to do today, what they did yesterday (and whether they faced any obstacles). This is important on the way to long-term goals - this is how you can understand in time that it is time to change your strategy.
We implemented Scrum on two tries because everyone, from the team to the users, wants a more predictable result. This is a plus of the methodology - clear rhythms streamline the team, increase the overall level of knowledge about the project. As a result, the result becomes more predictable, including for our “stakeholders” - users.
Teamwork also increases responsibility: everyone receives a bonus only if the team has completed the tasks set at a certain stage.
Agile is philosophy, scrum is structure, waterfall is method, kanban is management system. Scrum and kanban are agile options, but they have some clear differences. Scrum requires fixed roles, whereas kanban lacks the required roles. Scrum is based on iterations that combine planning, process optimization, and release. In kanban, this can be done regularly or whenever you need to. The scrum team requires an assessment of their work, while the kanban team does not.
Comments
To leave a comment
software project management
Terms: software project management