"Waterfall" model with the preparation of technical specifications and releases do not provide end-users need quick results. The team itself should be aware of how to prioritize. It's time to Agile. Perhaps here and revealed the potential that we have accumulated - namely, the ability to achieve success in situations where there is no clear assignment of tasks and the number of unknown variables significantly exceeds collected and established facts. The success of each of these projects always is in the awareness of actions performed by a team that is in the understanding of what really needs to be done here and now. Tool management awareness of the whole team in the development of a software product is beklog (magazine) "features" and product components.
If the team is always aware of what is important and what is not whether, in this case to resort to the documents, to fix the state of understanding of the requirements? The answer to this question is not as straightforward as it might seem at first glance. Largely fixation "cold" information is already losing its relevance, and can not be used to create the product team.
On the other hand, to move forward, it is important to rely on maloizmenyaemye elements. In the practice of creating a software product or the analytical element of this is the canonical model of the data used.
Ultimately prototype itself does not change, and the order components generated therein, each of the components at any given moment of time always the same. In this case, I do not need anyone from the top, who's to say how to do right, as awareness prioritize should be the team itself. And when the team realizes that to move forward in a set of simple and clear artifacts, it is the team itself will be able to formulate it.
Path to Agile
The time when the fever Agile Agile will reach you, just around the corner. I advise you to pre-acquainted with this concept (there are many different practices, for example, SAF, or Scaled Agile Framework). We continue to respond to the changing conjuncture, when we are required more and more: more new ideas, greater breakthroughs, more efficiency. Perhaps proposed Agile approach - the most appropriate of the international practices, to iron out all the "roughness" of aging requirements and goals, and go to modeling reality as it understands the command.
We do not immediately come to such an approach. We started, like most, with models waterfall (cascade development), but faced with the fact that it is not necessary to provide a rapid result of end-users, and existing resource constraints have hampered the development ETL development. Moreover, if the direction of movement has been selected correctly, then we lost a lot of time without showing the final results to business users.
The first thing we did - went to use the calendar sprints (iterations of development). This allowed the team to focus around a specific time slots in two weeks, during which they managed to implement a specific set of tasks bekloga.
It so happened that the product owner'ov (customers), we had multiple, which is atypical for Agile, since the methodology for one team should have one product owner. In our case, it turned out that every product owner represented a particular functional satellite business intelligence (ACRM, Collection, financial statements, etc.). We have formed a regular "train", which has a certain number of seats, but they are not guaranteed. That is, if you hit him in his task, it does not mean that the task will be completed within the sprint. "Tickets" on our regular "train" we "sell" in accordance with the order to which program objectives are themselves. There are tasks releases space for which is already guaranteed to "train", as these tasks have already been once balanced with release calendar. If you are "casual traveler" will certainly have to skip ahead of all the "privileged." If they are not - you are free to engage in their place.
When planning the development sprints, we first used the clock and found an interesting oddity. We painted the available time in the team sprint, you assess the problem in hours and load balancing, but in fact we do not have time for a sprint to do whatever they wanted. As a result of observation of the results of the sprint we derived the optimal number of tasks (regardless of hours) that the team can perform, we conducted an experiment, and really able to perform 100%. So the team came to an understanding of how many tasks can be done in the sprint. Who has tried to go on the tasks (they equated to storipointam - milestones).
The business analysts are a little different - we come to it as a service, and an analyst with the product owner form the understanding of what exactly it represents minimally useful product (minimal valuable product). This allows you to get a result (prototype) and hold it have a demonstration in one sprint. Moreover, these artifacts (input) must be prepared prior to the task of preparing a product owner - it is his vision of the analytical service.
Artifacts and awareness are useful, but a very important part of the success of a new culture around us - this is a demonstration of what is it that we've got in the end. This is probably the most important part in the whole process of development and creation of the new service, because you can get feedback about what is it that made the team in such a short sprint, as well as to motivate all participants to finish their work.
The demo shows how we "heard" and understood each other and understand what is the "pain", which aims to solve our product. The most important aspect in the demo - the ability to tell a story. Because if the team has done an excellent job, but it can not provide it, and tell the story, it is epic fail. It is unlikely that someone will realize that behind this sleepless night, thousands of lines of code, and elegant technological solutions invented by the architects or developers.
Ultimately, you buy what you see, and so you need to be able to show people more than they can see.
If the team is always aware of what is important and what is not whether, in this case to resort to the documents, to fix the state of understanding of the requirements? The answer to this question is not as straightforward as it might seem at first glance. Largely fixation "cold" information is already losing its relevance, and can not be used to create the product team.
On the other hand, to move forward, it is important to rely on maloizmenyaemye elements. In the practice of creating a software product or the analytical element of this is the canonical model of the data used.
Ultimately prototype itself does not change, and the order components generated therein, each of the components at any given moment of time always the same. In this case, I do not need anyone from the top, who's to say how to do right, as awareness prioritize should be the team itself. And when the team realizes that to move forward in a set of simple and clear artifacts, it is the team itself will be able to formulate it.
Path to Agile
The time when the fever Agile Agile will reach you, just around the corner. I advise you to pre-acquainted with this concept (there are many different practices, for example, SAF, or Scaled Agile Framework). We continue to respond to the changing conjuncture, when we are required more and more: more new ideas, greater breakthroughs, more efficiency. Perhaps proposed Agile approach - the most appropriate of the international practices, to iron out all the "roughness" of aging requirements and goals, and go to modeling reality as it understands the command.
We do not immediately come to such an approach. We started, like most, with models waterfall (cascade development), but faced with the fact that it is not necessary to provide a rapid result of end-users, and existing resource constraints have hampered the development ETL development. Moreover, if the direction of movement has been selected correctly, then we lost a lot of time without showing the final results to business users.
The first thing we did - went to use the calendar sprints (iterations of development). This allowed the team to focus around a specific time slots in two weeks, during which they managed to implement a specific set of tasks bekloga.
It so happened that the product owner'ov (customers), we had multiple, which is atypical for Agile, since the methodology for one team should have one product owner. In our case, it turned out that every product owner represented a particular functional satellite business intelligence (ACRM, Collection, financial statements, etc.). We have formed a regular "train", which has a certain number of seats, but they are not guaranteed. That is, if you hit him in his task, it does not mean that the task will be completed within the sprint. "Tickets" on our regular "train" we "sell" in accordance with the order to which program objectives are themselves. There are tasks releases space for which is already guaranteed to "train", as these tasks have already been once balanced with release calendar. If you are "casual traveler" will certainly have to skip ahead of all the "privileged." If they are not - you are free to engage in their place.
When planning the development sprints, we first used the clock and found an interesting oddity. We painted the available time in the team sprint, you assess the problem in hours and load balancing, but in fact we do not have time for a sprint to do whatever they wanted. As a result of observation of the results of the sprint we derived the optimal number of tasks (regardless of hours) that the team can perform, we conducted an experiment, and really able to perform 100%. So the team came to an understanding of how many tasks can be done in the sprint. Who has tried to go on the tasks (they equated to storipointam - milestones).
The business analysts are a little different - we come to it as a service, and an analyst with the product owner form the understanding of what exactly it represents minimally useful product (minimal valuable product). This allows you to get a result (prototype) and hold it have a demonstration in one sprint. Moreover, these artifacts (input) must be prepared prior to the task of preparing a product owner - it is his vision of the analytical service.
Artifacts and awareness are useful, but a very important part of the success of a new culture around us - this is a demonstration of what is it that we've got in the end. This is probably the most important part in the whole process of development and creation of the new service, because you can get feedback about what is it that made the team in such a short sprint, as well as to motivate all participants to finish their work.
The demo shows how we "heard" and understood each other and understand what is the "pain", which aims to solve our product. The most important aspect in the demo - the ability to tell a story. Because if the team has done an excellent job, but it can not provide it, and tell the story, it is epic fail. It is unlikely that someone will realize that behind this sleepless night, thousands of lines of code, and elegant technological solutions invented by the architects or developers.
Ultimately, you buy what you see, and so you need to be able to show people more than they can see.
