http___www.info-novitas.hr_o-nama_metodologije-rada_scrum-procesni-framework__1.xml
1.1 1.2 1.3 1.4 1.5 1.6 1.7 2.1 3.1 3.2 4.1 4.2 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 6.1 6.2 7.1 8.1 9.1 10.1 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 12.1 12.2 13.1 14.1 15.1 16.1 17.1 17.2 18.1 18.2 18.3 18.4 18.5 19.1 19.2 20.1 20.2 20.3 20.4 20.5 20.6 21.1 21.2 21.3 22.1 22.2 22.3 22.4 23.1 23.2 23.3 23.4 24.1 24.2 24.3 24.4 25.1 26.1 27.1 28.1 29.1 30.1 31.1 32.1 33.1 34.1 34.2 34.3 34.4 34.5 34.6 34.7 34.8 34.9 34.10 34.11 34.12 35.1 36.1 36.2 36.3 36.4 36.5 36.6 36.7 36.8 36.9 36.10 36.11 36.12 36.13
The best place to learn more is at the SCRUM Methodology website. I will be going to a SCRUM Master course the end of August to learn more. The class is being taught by Mike Cohn, founder of Mountain Goat Software. Most of this page is based on information I have learned from Mike Cohn and in his class. This page only includes the high level information. I have also included SCRUM.org for Glossary definitions. To better understand the SCRUM process, I would highly recommend taking Mike Cohn’s class. SCRUM Roles SCRUM is divided into four main groups. Mike gave an example of a race car, I have expanded it a bit to describe all four roles: - Project Owner (PO) – SCRUM.org defines it as “the role in Scrum accountable for maximizing the value of a product, primarily by incrementally managing and expressing business and functional expectations for a product to the Development Team(s).” The person who sets the objectives for the team and helps guide the team to the completion of each sprint and project – the race car driver - The Team (Team) – The Team usually refers to the Development Team (“the role within a Scrum Team accountable for managing, organizing and doing all development work required to create a releasable Increment of product every Sprint” SCRUM.org). The group of people (usually 5-9, with a maximum of 14) who decide on the specific tasks and do the work each sprint, usually includes (but is not limited to) lead programmer, programmers, testers, technical writers. The term Team, according to can also refer to the larger SCRUM Team, SCRUM.org: “a self-organizing team consisting of a Product Owner, Development Team and Scrum Master.” The teams are self-organizing. If one person is on two teams, that person should be assigned to one of the teams at least 60% of the time. Since the teams are small, each person should be willing to do whatever needs to be done to succeed in completing each Sprint, no matter what their preferred roll is. It is critical that all team members help the team to succeed. – the parts of the race car that must work together for the sprint to succeed. - SCRUM Master (SM) – SCRUM.org defines it as “the role within a Scrum Team accountable for guiding, coaching, teaching and assisting a Scrum Team and its environments in a proper understanding and use of Scrum.” The person who is more concerned on how to complete the Sprint successfully, the provider of the tools and methodology so that the member of the Team can accomplish the tasks that are specified to be completed during the sprint – the mechanic, keeps the race car running smoothly, by providing the guidance, tools, and materials to help each part work at its optimal best. - Shareholders – the people who benefit most and have a direct interest in a successful completion of the sprint and overall project – the car owners, get excited each time the car completes a lap (sprint), get paid when the car crosses the finish line. Terms The key terms that are needed to be understood to do SCRUM well are: - [User] Stories – The building blocks of the project, usually written in the form: “As a  , I   so that  ” - Story-Writing Workshop – These should be held about quarterly with the whole team and product owner. At the start of any big project, the SCRUM Master associated with the product and any contributing stake holders should also be included. Stake holder stories are a critical part of what eventually needs to be done within a project, but just the team’s input is required on how the “epic” story is divided into stories that can be completed each Sprint. The SCRUM Master needs to have a feel for the “epic” story and how this is divided into doable stories. The SCRUM Master needs to be looking ahead a few sprints at a time to make sure everything is in place for the team to be able to deliver a “potentially shippable product” at the end of each Sprint. It is a brain storming session only, without prioritizing any of the stories created. Stories generated here can be added to the Product Backlog. Remember, everyone’s opinion is important. - Working Agreement – There are certain agreements that need to be made within the group of people who will be working together. A few of the basic ones are: - Everyone’s opinion needs to be considered because it is important. - Listen to each person, if needed have a way to give the floor to one person at a time. - Live in the present, look for ways to work together now and not bring up old misunderstandings. - Answer all team e-mails before going home at night. - Meetings are rare and short, agree to pay a fine if late to one. Put the fines into paying for a fun event at the successful completion of the Sprint. - Product Backlog – Most often written in the form of stories that tell what the stake holders want the system to do and when they want the system to be delivered. This is from where the stories are taken that will be used in each Sprint. Backlog stories are often given difficulty ratings or time estimates on how long each phase (design/code/test/automate test/document/…) will take. The product owner is responsible for the Product Backlog and prioritizing the needs for the solutions to each story. This input is used by the team to determine what will be the goal for each Sprint. - Product Backlog Refinement – If part of a Sprint, they are usually done during the Sprint Planning Meeting where the stories from the Product Backlog are presented by the Product Owner in the form of “epic” (large) stories. It is up to the team to decide how the stories would be divided to create more detailed stories that can be developed during a sprint. - Sprint – Fixed length of time to develop, test, and delivery solutions to the stories selected for implementation. The number of stories selected for each sprint should be challenging but not impossible. The time is the key. If any stories are not completed by the end of the sprint, they are placed in the Sprint Backlog. At the end of a sprint, the product must be a “potentially shippable product” that forwards the progress of the total project in a high quality and tested release. The parts to a sprint are: - Sprint Backlog – These are derived from the selected Product Backlog that goes into defining specific Sprints. Stories are placed here when they need to be completed before the desired product can be delivered. Usually they are stories that were not able to be completed in the current Sprint or tentatively were planned for an upcoming Sprint. - Defects (Bugs) – When discovered, determine the cause and severity. If introduced in this Sprint, fix in this Sprint if there is time. If not enough time, put into the Sprint Backlog. If a discovered older defect, it should go into the Product Backlog and then ranked along with the other stories to determine when it will be fixed. - Definitions of “Done” – SCRUM.org defines it as “a shared understanding of expectations that software must live up to in order to be releasable into production. Managed by the Development Team.” It is vitally important that the product be “Potentially Shippable” at the end of each Sprint. The areas that can be done are: - Planning – There is both Product/Project Planning and Sprint Planning. Sprint Planning should be complete at the start of each Sprint. The high-level Product/Project Planning will be complete at its start. However, as the Sprints are executed, these plans will need to be modified as more is known about the Product/Project. - Analysis - Design - Coding - Test - Performance - User Acceptance Test - Pilot - Live Organization A SCRUM is based on the rugby term, where a group of people advance a project through working together in SPRINTs on a specific set of stories (or tasks) that can be accomplished in a specific length of time. A large project has an overall goal. The Product Owner specifies what should be accomplished in the long term. The SCRUM Master provides the framework and tools for the Team to accomplish the project one sprint at a time. The Team, with the help of the SCRUM Master and Product Owner, decide what specific tasks should be done each SPRINT. Each SPRINT is one to four weeks long. The usual length is two weeks. Each SPRINT should be long enough to accomplish a significant amount of work to move the team closer to delivering the specified project. The SCRUM Master and Product Owner help the team choose what are the most important tasks to complete in the next few SPRINTs. A totally detailed plan for the entire project is not specified, because as progress is made there will be changes needed in what needs to be done next. The purpose of a SPRINT is to accomplish as much work as possible in a fixed amount of time. When the SPRINT clock runs out, the SPRINT is done. Productivity The reason why the SCRUM Methodology was invented was to stream-line the development process. A SCRUM Master has to ask if a certain activity helps or hinders the progress of the team in each Sprint. If the answer is helps, then do it. If the answer is hinders, then you need to ask yourself “what is the purpose of this activity?” For example, if you insist that you attend all meetings, even one-on-one meetings, you may be hindering the process. Of course this is obvious for team members meeting with each other. However, some SCRUM Masters insist that they attend all meetings between the Product Owner and any Team Member. Some of these meetings relay vital information to the developer and can be very short. What is the purpose of you being there? Are you truly helping the product be produced faster? If this is not the case, then maybe attending every meeting is not a good use of your time. Think about the consequences. The SCRUM Masters job is to help the Sprints to be challenging and to get them done on-time with a “potentially shippable” product.
1.1 1.2 1.3 2.1 2.2 2.3 2.4 3.1 3.2 3.3 3.4 3.5 4.1 4.2 5.1 5.2 6.1 6.2 6.3 7.1 7.2 7.3 7.4 7.5 7.6 7.7 8.1 8.2 8.3 8.4 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 10.1 10.2 11.1 11.2 11.3 11.4 11.5 11.6 12.1 12.2 13.1
Scrum je procesni framework koji se koristi za upravljanje kompleksnim razvojem. Scrum nije metodologija ili tehnika razvoja sooftware-a , nego je okvir unutar kojega se mogu koristiti razni procesi i tehnike (npr. ekstremno programiranje). Kao što je već spomenuto Scrum framework se sastoji od Scrum timova, njihovih pridruženih uloga, događaja, artefakata i pravila. Scrum tim sastoji se od vlasnika proizvoda (engl. Product Owner), razvojnog tima (engl. Development team) i Scrum mastera. Scrum isporučuje proizvode iterativno i inkrementalno, maksimirajući moguće povratne informacije. Vlasnik proizvoda je odgovoran za maksimizaciju vrijednosti proizvoda i rada razvojnog tima. Načina na koji se to postiže vrlo je različit između raznih organizacija, timova i ljudi. Vlasnik proizvoda je jedini odgovoran za upravljanje Product Backlogom. Što uključuje jasno objašanjvanje razvojnom timu vizije, ciljeve i stavke na Product Backlogu. Razvojni tim radi prema naputcima Vlasnika stoga i cijela organizacija mora poštivati njegove odluke. Razvojni tim sastoji se od profesionalaca koji rade konkretan posao isporučujući inkrement proizvoda na kraju svakog Sprinta. Samo članovi razvojnog tima stvaraju inkrement proizvoda. Scrum master je odgovoran da se Scrum razumije i koristi. Scrum Masteri to postižu na način da osiguravaju da se Scrum timovi pridržavaju teorije, prakse i pravila Scruma. Scrum koristi propisane događaje radi uspostave pravilnosti i minimizacije potrebe za sastancima koji nisu definirani Scrumom. Scrum koristi vremenski ograničene događaje na način da svaki vremenski događaj ima određeno maksimalno trajanje. Na taj način se osigurava da se dovoljno vremena koristi za planiranje bez uzaludnog trošenja vremena. Srce Scruma je Sprint, vremenski ograničeni period od jednog mjeseca ili manje tijekom kojega se proizvede „završen“, upotrebljiv i potencijalno isporučiv inkrement proizvoda. Sprintovi su jednakog trajanja tijekom cijelog razvoja proizvoda. Novi Sprint započinje neposredno nakon što završi prethodni. Sprint se sastoji od sastanka za planiranje Sprinta, dnevnog Scruma, posla razvoja, revizije Sprinta i retrospektive Sprinta. Svaki Sprint se može smatrati projektom čiji horizont ne prelazi mjesec dana. Poput projekata Sprint se koristi da se obavi neki posao. Svaki Sprint ima definiciju što će se obaviti, na koji način i koji će odrediti izradu, posao i konačni proizvod. Dnevni Scrum je 15-minutni, vremenski ograničen događaj, koji služi da razvojni tim uskladi aktivnosti i donese plan za sljedeća 24 sata. To se čini kontrolom rada od prethodnog dnevnog Scrum sastanka i procjenom posla koji bi mogao biti odrađen prije slijedećeg sastanka. Dnevni Scrum se održava uvijek na istom mjestu svaki dan da bi se smanjila kompleksnost. Scrum master forsira pravilo da samo razvojni tim sudjeluje na dnevnom Scrum sastanku i da sastanak traje 15 minuta. Product backlog je sortirana lista svega što će možda biti potrebno za proizvod i jedini izvor zahtjeva za bilo kakvim promjenama koje se rade na proizvodu. Vlasnik proizvoda je odgovoran za Product backlog, uključujući njegov sadržaj, raspoloživost i sortiranje. Product backlog nikad nije konačan. U početku sadrži samo one zahtjeve koji su inicijalno poznati i razumljiviji. Product backlog evoluira kako evoluira proizvod i okolina na kojoj će se primjenjivati. Product backlog sadrži listu svih mogućnosti, funkcionalnosti, zahtjeva, unaprijeđenja i popravaka koja zajedno čine promjene koje će se primijeniti nad proizvodom u budućnosti. Obično je sortiran prema vrijednosti, riziku, prioritetu i nužnosti. Stavke na vrhu backloga su dio trenutnih razvojnih aktivnosti. Sprint backlog je skup stavki s Product Backloga koje su odabrane za Sprint plus plan realizacije Inkrementa i realizacije Cilja Sprinta. Sprint Backlog je procjena razvojnog tima koje funkcionalnosti će biti u sljedećem Inkrementu i posao koji je potreban za realizaciju tog Inkrementa. Sprint backlog je plan sa dovoljno detalja da bi se na Dnevnom scrumu mogle razumjeti aktualne promjene. Razvojni tim mijenja Sprint backlog tijekom Sprinta, te se na njega dodaju zadaci tijekom Sprinta . Ti zadaci se događaju kada Razvojni tim, radeći prema planu, nauči nešto više o poslu koji je potreban da se zadovolji cilj Sprinta. Kako se pojavi potreba za novim poslom, Razvojni tim ga dodaje na Sprint backlog. Samo razvojni tim može mijenjati Sprint backlog tijekom Sprinta. Sprint backlog je vidljiva slika posla u realnom vremenu kojeg Razvojni tim namjerava obaviti tijekom Sprinta i koji pripada isključivo Razvojnom timu. Info Novitas d.o.o. - Dizajn / Izrada / Hosting || Zaposlite se u Info Novitas, surađujte s nama! Hosting: IN-Hosting | Dizajn: IN Web Dizajn