Software Engineering. M Umair.

Transcription

1 Software Engineering M Umair

2 Advantages of Agile Change is embraced With shorter planning cycles, it s easy to accommodate and accept changes at any time during the project. There is always an opportunity to refine and reprioritize the backlog, letting teams introduce changes to the project in a matter of weeks. Ref:

3 Advantages of Agile End-goal can be unknown Agile is very beneficial for projects where the end-goal is not clearly defined. As the project progresses, the goals will come to light and development can easily adapt to these evolving requirements. Task: Find examples of such projects. Ref:

4 Advantages of Agile Faster, high-quality delivery Breaking down the project into iterations (manageable units) allows the team to focus on high-quality development, testing, and collaboration. Conducting testing during each iteration means that bugs get identified and solved more quickly. And this high-quality software can be delivered faster with consistent, successive iterations. Ref:

5 Advantages of Agile Strong team interaction Agile highlights the importance of frequent communication and face-to-face interactions. Teams work together and people are able to take responsibility and own parts of the projects. Task: How to improve face-to-face communication skills? Ref:

6 Advantages of Agile Customers are heard Customers have many opportunities to see the work being delivered, share their input, and have a real impact on the end product. They can gain a sense of ownership by working so closely with the project team. Ref:

7 Advantages of Agile Continuous improvement Agile projects encourage feedback from users and team members throughout the whole project, so lessons learned are used to improve future iterations. Ref:

8 Disadvantages of Agile Planning can be less concrete It can sometimes be hard to pin down a solid delivery date. Because Agile is based on time-boxed delivery and project managers are often reprioritizing tasks, it s possible that some items originally scheduled for delivery may not be complete in time. And, additional sprints may be added at any time in the project, adding to the overall timeline. Task: Learn more about time-boxed delivery. Ref:

9 Disadvantages of Agile Team must be knowledgeable Agile teams are usually small, so team members must be highly skilled in a variety of areas. They also must understand and feel comfortable with the chosen Agile methodology. Ref:

10 Disadvantages of Agile Time commitment from developers Agile is most successful when the development team is completely dedicated to the project. Active involvement and collaboration is required throughout the Agile process, which is more time consuming than a traditional approach. It also means that the developers need to commit to the entire duration of the project. Ref:

11 Disadvantages of Agile Documentation can be neglected The Agile Manifesto prefers working software over comprehensive documentation, so some team members may feel like it s less important to focus on documentation. While comprehensive documentation on its own does not lead to project success, Agile teams should find the right balance between documentation and discussion. Ref:

12 Disadvantages of Agile Final product can be very different The initial Agile project might not have a definitive plan, so the final product can look much different than what was initially intended. Because Agile is so flexible, new iterations may be added based on evolving customer feedback, which can lead to a very different final deliverable. Ref:

13 Extreme Programming (XP) Also known as XP, Extreme Programming is a type of software development intended to improve quality and responsiveness to evolving customer requirements. The principles of XP include feedback, assuming simplicity, and embracing change. Ref:

14 Extreme Programming (XP) Pair Programming Pair programming (also known as pairing ) is part of the Extreme Programming (XP) practices. It is when two programmers share a single workstation, which includes sharing one screen, keyboard, and mouse. The purpose of this technique is to encourage better communication, clarification of the problem, and understanding of the solution. Ref:

15 Scrum Scrum is one of the most popular ways to implement Agile. It follows a set of roles, responsibilities, and meetings that never change. Sprints, usually lasting one to two weeks, allow the team to deliver software on a regular basis. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Ref:

16 Scrum Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is: Lightweight Simple to understand Difficult to master Ref:

17 Scrum Scrum has been used to develop Software Hardware Embedded software Networks of interacting function Autonomous vehicles Schools Government Marketing Managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies. Ref:

18 The essence of Scrum Small team of people which is highly flexible and adaptive. These strengths continue operating in single, several, many, and networks of teams that develop, release, operate and sustain the work and work products of thousands of people. Ref:

19 Scrum Theory Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Class Discussion: Your point of view? Ref:

20 Scrum Theory Three pillars uphold every implementation of empirical process control: Transparency Inspection Adaptation Ref:

21 Scrum Theory Transparency Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen. For example A common language referring to the process must be shared by all participants. Those performing the work and those inspecting the resulting increment must share a common definition of Done. Ref:

22 Scrum Theory Inspection Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work. Ref:

23 Scrum Theory Adaptation If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation. Ref:

24 Ref:

25 Scrum Theory Product Backlog The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. Ref:

26 Scrum Theory Product Backlog As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog. Ref:

27 Scrum Theory Sprint Planning The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team. Ref:

28 Scrum Theory Sprint Planning Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box. Ref:

29 Scrum Theory Sprint Planning Sprint Planning answers the following: What can be delivered in the Increment resulting from the upcoming Sprint? How will the work needed to deliver the Increment be achieved? Ref:

30 Scrum Theory Sprint Planning Topic One: What can be done this Sprint? The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint. Ref:

31 Scrum Theory Sprint Planning Topic Two: How will the chosen work get done? The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Ref:

32 Scrum Theory Sprint Backlog The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a Done Increment. Ref:

33 Scrum Theory Development Team Characteristics They are self-organizing Cross functional No titles for Development Team members No sub-teams in the Development Team Individuals have specialized skills and areas of focus Ref:

34 Scrum Theory Scrum Master The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values. Ref:

35 Scrum Theory Scrum Review A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Attendees collaborate on the next things that could be done to optimize value Ref:

36 Scrum Theory Scrum Review The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. Ref:

37 Further scrum.org Ref: