вторник, 2 июня 2015 г.

Waterfall is dead

"Waterfallmodel with the preparation of technical specifications and releases do not provide end-users need quick resultsThe team itself should be aware of how to prioritize. It's time to AgilePerhaps here and revealed the potential that we have accumulated - namelythe 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 factsThe 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 nowTool management awareness of the whole team in the development of a software product is beklog (magazine) "featuresand product components.

If the team is always aware of what is important and what is not whetherin this case to resort to the documentsto fix the state of understanding of the requirementsThe answer to this question is not as straightforward as it might seem at first glanceLargely fixation "coldinformation is already losing its relevanceand can not be used to create the product team.

On the other handto move forwardit is important to rely on maloizmenyaemye elementsIn 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 changeand the order components generated thereineach of the components at any given moment of time always the sameIn this caseI do not need anyone from the top, who's to say how to do rightas awareness prioritize should be the team itselfAnd when the team realizes that to move forward in a set of simple and clear artifactsit is the team itself will be able to formulate it.

Path to Agile

The time when the fever Agile Agile will reach youjust around the cornerI advise you to pre-acquainted with this concept (there are many different practicesfor exampleSAFor Scaled Agile Framework). We continue to respond to the changing conjuncturewhen we are required more and moremore new ideasgreater breakthroughsmore efficiencyPerhaps proposed Agile approach - the most appropriate of the international practicesto iron out all the "roughnessof aging requirements and goalsand go to modeling reality as it understands the command.

We do not immediately come to such an approachWe startedlike mostwith models waterfall (cascade development), but faced with the fact that it is not necessary to provide a rapid result of end-usersand existing resource constraints have hampered the development ETL developmentMoreoverif the direction of movement has been selected correctlythen 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 weeksduring which they managed to implement a specific set of tasks bekloga.

It so happened that the product owner'ov (customers), we had multiplewhich is atypical for Agilesince the methodology for one team should have one product ownerIn our caseit turned out that every product owner represented a particular functional satellite business intelligence (ACRMCollectionfinancial statementsetc.). We have formed a regular "train", which has a certain number of seatsbut they are not guaranteedThat isif you hit him in his taskit does not mean that the task will be completed within the sprint. "Ticketson our regular "trainwe "sellin accordance with the order to which program objectives are themselvesThere are tasks releases space for which is already guaranteed to "train", as these tasks have already been once balanced with release calendarIf you are "casual travelerwill 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 sprintswe first used the clock and found an interesting oddityWe painted the available time in the team sprintyou assess the problem in hours and load balancingbut in fact we do not have time for a sprint to do whatever they wantedAs a result of observation of the results of the sprint we derived the optimal number of tasks (regardless of hoursthat the team can performwe conducted an experimentand really able to perform 100%. So the team came to an understanding of how many tasks can be done in the sprintWho 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 serviceand 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 (prototypeand hold it have a demonstration in one sprintMoreoverthese artifacts (inputmust be prepared prior to the task of preparing a product owner - it is his vision of the analytical service.

Artifacts and awareness are usefulbut 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 endThis is probably the most important part in the whole process of development and creation of the new servicebecause you can get feedback about what is it that made the team in such a short sprintas well as to motivate all participants to finish their work.

The demo shows how we "heardand understood each other and understand what is the "pain", which aims to solve our productThe most important aspect in the demo - the ability to tell a storyBecause if the team has done an excellent jobbut it can not provide itand tell the storyit is epic failIt is unlikely that someone will realize that behind this sleepless nightthousands of lines of codeand elegant technological solutions invented by the architects or developers.

Ultimatelyyou buy what you seeand so you need to be able to show people more than they can see.