MTAT Software Engineering Management

Transcription

1 MTAT Software Engineering Management Lecture 05: Agile Principles and Processes Part A Dietmar Pfahl Spring dietmar.pfahl@ut.ee

2 Announcements Exam dates (incl. retake) and rooms are now fixed and in SIS There is one project topic available defined by RIA (Estonian Information Systems Authority) eesti.ee is the key government portal in Estonia exposing user interfaces to x-road services operated by service providers. More than 800 services are currently available. Currently, the service providers develop the service and the small eesti.ee team builds the user interface. We are looking at ways to have a single development process covering the entire cycle from creating the service to building the UI. Contact: Andres Kütt - andres.kutt@ria.ee

3 Project Teams Status on March 09: Team 01: Vitalii Peretiatko & Tatevik Ishikyan: Topic? Team 02: Ijlal Hussain & Khalil ur Rehman: Topic? Team 03: Israel Cuautle & Anmol Gautam: RIA topic Team 04: Madhu Tipirishetty & Margus Sellin: Improvement of inaccurate planning and estimating with Scrum" 18 students still missing Silver Samarütel and Veronika Prokopova have posted partnering inquires on Message Board! Short Presentation date: Wednesday, March 25

4 Structure of Lecture 05 Feedback on Homework 1 Homework 2 -- Light-weight (agile) processes / Evolutionary development Extreme Programming (XP) Scrum (intro)

5 Homework 1: Introduction to SPI Administrative information: This homework has to be done individually. Maximum number of marks: 3 Submission deadline is Monday, 16-Feb-2015, at 20:00 sharp. If you don t submit in time, you receive a penalty as follows: Late delivery until Tuesday, 17-Feb-2015, at 20:00 1 mark penalty (-33% of maximum) Late delivery after Tuesday, 17-Feb-2015, 20:00 3 marks penalty (-100% of maximum) No exceptions from the penalty-rules will be made! Submit your homework using the Submission function provided on the course web-page: ion IMPORTANT: Only files in PDF format will be accepted! I won t look at files that are not PDF. Write your name and student id in the report (ideally, also put a date and give the report a proper heading)

6 Homework 1: Solution Sketch Q-1 [0.5 marks]: According to SI s managers, what were the shortcomings of Scrum in SI s development context? Answer (sketch): They felt that Scrum was too rigid, didn t scale, and was unsuitable for maintenance tasks. They also feared that the combination of inaccurate estimates and timeboxes gave longer lead times and what they perceived as waste, such as Scrum planning meetings, reduced productivity and quality. (p. 48, 2 nd paragraph)

7 Homework 1: Solution Sketch Q-2 [0.5 marks]: SI used quantitative and qualitative approaches to evaluate whether Kanban is actually better than Scrum. What data was collected for the quantitative evaluation? Answer (sketch): Process type PT = {Scrum, Kanban} Type of work item WI = {Bug, PBI (Project Backlog Item)} Time Year.quarter = {2009.1,, } Churn = Number of lines added + deleted + modified Lead time: Number of days from next state to ready for release state on the board Production: #WI developed per quarter (often called throughput ) Productivity: Production per developer = throughput/developer Productivity 2: Total churn per developer per quarter Quality: Number of weighted bugs with weights: blocking (weight 8), critical (4), moderate (2), and minimal (1) (Cf. contents of Table 1).

8 Homework 1: Solution Sketch Q-3 [1.5 marks]: SI measured productivity in two different ways. Give precise definitions of all measures that SI used to measure productivity. Did Kanban perform better or worse with regards to productivity? Answer (sketch): They measured productivity in two ways (cf. Table 1): Productivity (1): Production per developer, with Production = Number of work items developed per quarter, with Type of work item = Bug or Project backlog item (PBI) Productivity 2: Total churn per developer per quarter, with Churn = number of code lines added, deleted, or modified (Churn can be due to Bug fixing or PBI development)

9 Homework 1: Solution Sketch Q-3 [1.5 marks]: SI measured productivity in two different ways. Give precise definitions of all measures that SI used to measure productivity. Did Kanban perform better or worse with regards to productivity? Answer (sketch): What was better? For measure Productivity : when using Bugs, Scrum was better than Kanban; when using PBI, Kanban was better than Scrum (cf. Figure 4) For measure Productivity 2 : when using Bugs, Scrum was better than Kanban; when using PBI, Kanban was better than Scrum (cf. Figure 5) For Productivity 2 the changes were (in both directions) relatively smaller than for Productivity (i.e., 15.3 down to 12.1 (-21%) versus 0.46 to 0.41 (- 11%), and 5.9 to 10.2 (+73%) versus 1.28 to 1.55 (+21%)

10 Homework 1: Solution Sketch Q-4 [0.5 marks]: What did SI do to evaluate Kanban versus Scrum qualitatively? What do you think is more important: quantitative or qualitative evaluation? Underpin your answer with arguments. Answer (sketch): They let the first author of the paper, the professor of Oslo University, conducted interviews with 4 individuals working at SI, including the head of products operations and the CTO, as well as a team leader and a developer. Each of them was asked about their perceptions regarding Scrum and Kanban. Both quantitative and qualitative evaluations are equally important. Quantitative evaluation helps to get hard facts. Qualitative evaluation helps interpreting the hard facts properly and adding additional information not captured by the hard facts

11 Homework 1: Distribution of Marks Students enrolled: 25 HW1 submitted: 23 Penalty of -1: 1 Average marks: 2.2 No name on sheet: >3

12 Structure of Lecture 05 Feedback on Homework 1 Homework 2 -- Light-weight (agile) processes / Evolutionary development Extreme Programming (XP) Scrum (intro)

13 Homework 2: Software Process Modeling Background information: Deadline: Monday, 16-March-2015, at 20:00 (sharp!) Recall Exercise 2 from the lecture where you modeled a process using one of the (equivalent) notations shown in Figure 1 below. Then perform the tasks described on the next page.

14 Homework 2: Software Process Modeling Task T1 [3 marks]: Have a look at the description of Scrum published in the Eclipse Process Framework (EPF) Wiki at Create a process model using the table notation shown in Figure 1. Make a note/comment, if you think, information is missing (incomplete) or inconsistent in the process description provided by the EPF Wiki. Note: Marking will consider completeness and correctness of the model as well as appropriateness of your notes/comments

15 Homework 2: Software Process Modeling Task T2 [2 marks]: In the model you created in Task T1, select at least three activities that are directly connected via product-flow (i.e., one activity consumes at least one artifact produced by another activity). Then create a graphical representation of this subset of the Scrum process model. You can choose one of the following three notations (and tools): Notation from Figure 1 Spearmint (you find information on how to download and install Spearmint on the course wiki Lecture 4) Bizagi (you find information on how to download and install Bizagi Process Modeler on the course wiki Lecture 4) Note: Marking will consider completeness and correctness of the model and consistency with the model developed in Task T1.

16 Homework 2: Software Process Modeling Task T3 [1 mark]: Explain your choice of the notation/tool in Task T2. What was the reason why you chose it and what are the advantages and disadvantages of the notation you chose? To get full marks, you need to define and discuss at least two criteria that guided your decision. For example, you may use a table notation as shown below:

17 Structure of Lecture 05 Feedback on Homework 1 Homework 2 -- Light-weight (agile) processes / Evolutionary development Extreme Programming (XP) Scrum (intro)

18 Requirements and Customers

19 Process Types Waterfall Incremental Iterative/Evolutionary

20 Process Types Challenges: - Changing Requirements - Fixed-price/fixed-scope/fixed-deadline projects - Heavy-weight process models (prescriptive) - Taylorism, trying to create many specialised roles Waterfall Incremental Iterative/Evolutionary

21 The Agile Manifesto Kent Beck et al. (2001): Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

22 There exists more than one Agile Method! Scrum Crystal Clear DSDM FDD LEAN XP AUP = Agile Unified Process DSDM = Dynamic Systems Development Method FDD = Feature-Driven Development XP = Extreme Programming AUP KANBAN

23 Structure of Lecture 05 Feedback on Homework 1 Homework 2 -- Light-weight (agile) processes / Evolutionary development Extreme Programming (XP) Scrum (intro)

24 Extreme Programming (XP) Origin: Kent Beck, Ward Cunningham, Ron Jeffries (end of 1990s) Idea: light weight process model, agile process Characteristics: Minimum of accompanying measures (docs, modeling, ) Team orientation (e.g., joint responsibility for all dev. artifacts) Small teams (12-14 persons) Involvement of user/client at an early stage Social orientation Scope: Pilot or small projects with low criticality of the results

25 13 XP Practices Project Cycle Planning Game (Poker) Small Releases Whole Team Customer Tests Development Cycle Simple Design Pair Programming TDD (Unit Test) Refactoring Supporting Practices Coding Standard Sustainable Pace (40-hour week) Metaphor (Common Understanding) Continuous Integration Collective Ownership (Acceptance Tests) (On-site Customer) (Short Increments)

26 Requirements vs. User Stories Traditional requirement shall statements: The system shall provide a user configurable interface for all user and system manager functions The user interface shall be configurable in the areas of: Screen layout Font Background and text color Corresponding User Story : As a system user or system manager, I want be able to configure the user interface for screen layout, font, background color, and text color, So that I can use the system in the most efficient manner

27 From Requirement to User Story Functional Requirements Requirement: The system shall provide the capability for making hotel reservations. User Story 1: As a premiere member, I want to search for available discounted rooms. User Story 2: As a vacationer, I want to search for available rooms. User Story 3: As a vacationer, I want to save my selections.

28 From Requirement to User Story Non-Functional Requirements Requirement: The system shall User Story 4: As a vacationer and user of the hotel website, I want the system to be available 99.99% of the time. User Story 5: As a vacationer, I want web-pages to download in <4 seconds. User Story 6: As the hotel website owner, I want 10,000 concurrent users to be able to access the site at the same time with no impact to performance.

29 7 6 Planning Poker Participants in planning poker include all of the developers on the team Step 1: Give each estimator a deck of cards Step 2: Moderator reads description of User Story to be estimated. Step 3: Product owner answers any question the estimators may have about the User Story. Step 4: Each estimator privately selects a card representing his or her estimate. Cards are not shown until each estimator has made a selection.

30 7 6 Planning Poker (cont d) Step 5: When everyone has made an estimate, the cards are simultaneously turned over. Step 6: If estimates differ, the highest and lowest estimates are explained by the estimators - otherwise the estimation is completed for this User Story. Step 7: The group can discuss the story and their estimates for a few more minutes. The moderator can take any notes he/she thinks will be helpful when this story is being programmed and tested. After the discussion, each estimator re-estimates by selecting a card. -> Go to Step 5. Note: In many cases, the estimates will already converge by the second round. But if they have not, continue to repeat the process. The goal is for the estimators to converge on a single estimate that can be used for the story. It rarely takes more than three rounds, but continue the process as long as estimates are moving closer together.

31 Simple Design Characterisation: Four characteristics of simple design, listed in priority order: The system runs all the tests. It contains no duplicate code. The code states the programmers' intent very clearly. It contains the fewest possible number of classes and methods. The practice of TDD describes how the system is created in many small steps, driven by tests that programmers write. Each of these tests is a probe into the design of the system, allowing the developers to explore the system as it is being created. Thus, in XP, design interleaves with coding, i.e., design quite literally happens all the time. Guidelines to help in arriving at a simple design: Look for a simple but not stupid way to solve a problem. Pay attention to good design principles when forming a system incrementally. (-> design patterns) Don t add infrastructure or other features that might be needed later. Chances are they won't be (YAGNI: You Aren't Going to Need It). Let the user stories force you to change the design. Don't generalize a solution until it is needed in at least two places. Follow the first rule above and keep implementation simple. Let the second user pay for the generality. Seek out and destroy duplication and other code smells (or: design smells ). The practice of refactoring is the most powerful tool in the arsenal. It is through removing duplication that new classes, methods, and larger scale systems are born. Remember that it is just code. If it is getting overly complex and painful, delete it. It can always be recreated again in less time and better than the first time by leveraging what was learned the first time.

32 Test-Driven Development (TDD) namespace UnitTestingExamples.Library { using System; namespace UnitTestingExamples.Tests { using System; using NUnit.Framework; } [TestFixture] public class BankAccountTests { [Test] public void TestDeposit() { BankAccount account = new BankAccount(); account.deposit( ); account.deposit( 25.0 ); Assertion.AssertEquals( 150.0, account.balance ); } } Unit Test Functionalityoriented Regressiontesting can be automated public class BankAccount { private double _balance = 0.0; } } public void Deposit( double amount ) { _balance += amount; } public double Balance { get { return _balance; } } (Source: Wikipedia)

33 TDD package helloworldapp; /** * dietmar */ public class HelloWorldApp { } /** args the command line arguments */ public static void main(string[] args) { System.out.println("Hello World!"); }

34 TDD package helloworldapp; /** * dietmar */ public class HelloWorldApp { /* * To change this license header, choose License Headers in Project Properties. * To change this template file, choose Tools Templates * and open the template in the editor. */ package helloworldapp; import java.io.bytearrayinputstream; import java.io.bytearrayoutputstream; import java.io.printstream; import org.junit.afterclass; import org.junit.beforeclass; import org.junit.test; import static org.junit.assert.*; public class HelloWorldAppTest { public HelloWorldAppTest() { } Test Class Test Fixture private final ByteArrayOutputStream outcontent = new ByteArrayOutputStream(); } /** args the command line arguments */ } public static void main(string[] args) System.out.println("Hello World!"); } public void setupstreams() { System.setOut(new PrintStream(outContent)); public void cleanupstreams() { System.setOut(null); } /** * Test of main method, of class HelloWorldApp. public void testmain() { System.out.println("main"); String[] args = null; HelloWorldApp.main(args); assertequals("hello World!", outcontent); } Set Up Clean Up Test Method

35 Test-Driven Development (TDD) Context User Story (new functionality) Write a failing test. Clean up code. Make the test pass.

36 What is Refactoring? Refactoring Maintenance Evolution

37 Beck s Definition A change to the system that leaves its behavior unchanged, but enhances some nonfunctional quality simplicity, flexibility, understandability, performance (Kent Beck, Extreme Programming Explained, page 179)

38 Fowler s Definition A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior (Martin Fowler, Refactoring, page 53)

39 A Trivial Example (Martin Fowler, Refactoring)

40 Context Test-Driven Development (TDD) User Story (new functionality) Write a failing test. Clean up code. Make the test pass.

41 Refactoring Comprehensive Definition Changes made to the system that Do not change observable behavior (all the tests still pass) Remove duplication or needless complexity Enhance software quality: - Make the code simpler and easier to understand - Make the code more flexible - Make the code easier to change

42 How to Refactor? Ensure all tests pass Make sure your tests pass Find some code that smells Determine how to simplify this code Make the simplifications Run tests to ensure things still work correctly Find code that smells Determine simplification Repeat the simplify/test cycle until the smell is gone Ensure all tests still pass Make simplification

43 Code Smells Indicators that something may be wrong in the code Can occur both in production code and test code

44 The Catalogue of Refactorings (1) Add Parameter Change Bidirectional Association to Unidirectional Change Reference to Value Change Unidirectional Association to Bidirectional Change Value to Reference Collapse Hierarchy Consolidate Conditional Expression Consolidate Duplicate Conditional Fragments Decompose Conditional Duplicate Observed Data Dynamic Method Definition Eagerly Initialized Attribute Encapsulate Collection Encapsulate Downcast Encapsulate Field Extract Class Extract Interface Extract Method Extract Module Extract Subclass Extract Superclass Extract Surrounding Method Extract Variable Form Template Method Hide Delegate Hide Method Inline Class Inline Method Inline Module Inline Temp Introduce Assertion Introduce Class Annotation Introduce Expression Builder Introduce Foreign Method Introduce Gateway Introduce Local Extension Introduce Named Parameter Introduce Null Object Introduce Parameter Object Isolate Dynamic Receptor Lazily Initialized Attribute Move Eval from Runtime to Parse Time Move Field Move Method Parameterize Method Preserve Whole Object

45 The Catalogue of Refactorings (2) Pull Up Constructor Body Pull Up Field Pull Up Method Push Down Field Push Down Method Recompose Conditional Remove Assignments to Parameters Remove Control Flag Remove Middle Man Remove Named Parameter Remove Parameter Remove Setting Method Remove Unused Default Parameter Rename Method Replace Abstract Superclass with Module Replace Array with Object Replace Conditional with Polymorphism Replace Constructor with Factory Method Replace Data Value with Object Replace Delegation With Hierarchy Replace Delegation with Inheritance Replace Dynamic Receptor with Dynamic Method Definition Replace Error Code with Exception Replace Exception with Test Replace Hash with Object Replace Inheritance with Delegation Replace Loop with Collection Closure Method Replace Magic Number with Symbolic Constant Replace Method with Method Object Replace Nested Conditional with Guard Clauses Replace Parameter with Explicit Methods Replace Parameter with Method Replace Record with Data Class Replace Subclass with Fields Replace Temp with Chain Replace Temp with Query Replace Type Code with Class Replace Type Code with Module Extension Replace Type Code With Polymorphism Replace Type Code with State/Strategy Replace Type Code with Subclasses Self Encapsulate Field Separate Query from Modifier Split Temporary Variable Substitute Algorithm

46 Code Smells & Refactoring Full document posted on course wiki (list shown here is not complete)

47 Refactoring Summary Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. (Invented by Martin Fowler) Many refactorings can be automated Catalogue of refactorings: Note: It is not always clear (a) how to detect refactoring opportunities and (b) what refactoring(s) are most appropriate (-> code smells : )

48 Pair Programming Characterisation: Two programmers work together at one computer. One, the driver, writes code while the other, the observer (or navigator[1]), reviews each line of code as it is typed in. The two programmers switch roles frequently. Benefits: Studies found that programmers working in pairs produce shorter programs, with better designs and fewer bugs faster Challenges: Total amount of effort (person-hours) increases. Management needs to balance faster completion of the work and reduced testing and debugging time against the higher cost of coding. The benefit of pairing is greatest on tasks that the programmers do not fully understand before they begin: that is, challenging tasks that call for creativity and sophistication. On simple tasks, which the pair already fully understands, pairing results in a net drop in productivity. Productivity can also drop when novice-novice pairing is used without coaching.

49 Structure of Lecture 05 Feedback on Homework 1 Homework 2 -- Light-weight (agile) processes / Evolutionary development Extreme Programming (XP) Scrum (intro)

50 The Term Scrum Originates from Rugby Meaning crowded Complex move that requires team work

51 What is Scrum? Agile Management Framework for SW development projects With a few clear rules: Roles: Product Owner, Team, Scrum Master Product Backlog, Sprint Backlog, few compact reports Short work cycles (-> Sprints ) for incremental development Based on the Agile Manifesto of Kent Beck at al. Human-centred Technology and tools have secondary role Close cooperation with customer Empirical learning process Scrum does not define a development methodology, QA strategy, or risk management approach, but asks the team to take care of these issues appropriately.

52 Scrum Elements Overview

53 Scrum Process Simplified Overview

54 Scrum: Backlogs Product Backlog Collection of requirements (user stories) for the product at project start: a few, little detailed user stories; collection evolves over time and requirements will be refined over time Managed by the Product Owner Sprint Backlog Collection of requirements (user stories) that are selected for implementation during next sprint Manged by the Team

55 Scrum: Sprint Sprint Period (max. 30 calendar days) in which a shippable product increment (executable, tested, and documented) is created by the Team Time-boxed, i.e., ends exactly at the scheduled time At the end of the Sprint, the Product Owner has to accept the final results (i.e., the software) Partially completed or incorrect results will not be shipped (no compromise on quality) and go back to the Product Backlog for inclusion in the next Sprint (Backlog)

56 Scrum: 3 Roles Product Owner Decides which requirements are implemented for a product version Decides about when product increments will be shipped Team Implements requirements Decides how many requirements are implemented in a Sprint Organizes its activities (-> tasks) independently Scrum Master Takes care of the proper implementation of Scrum Supports the team in process-related issues

57 Scrum: Product Owner Elicits and collects customer needs Describes requirements Decides on release dates and contents Is responsible for project success and the profitability of the product Prioritizes requirements according to market value Adjusts requirements and priority, as needed Accepts or rejects work results

58 Scrum: Product Owner (cont d) Works closely with the team Helps to understand customer needs and requirements Details requirements Checks resulting work products and approves them Integrates all stakeholders in the development and regularly elicits their needs Besides customer also marketing and sales Product owner combines and filters stakeholder requirements Has a sound technical understanding Makes general overall design decisions Combines classical product manager, project manager, and chief architect

59 Team Small team size: Typically 5 to 9 team members Cross-functional: Design, coding, testing, etc. Members must have a broad range of competencies Every team member is an expert in his/her field but can also take over responsibilities of other team members Teams are independent/empowered Decides which requirements to include in next Sprint (i.e., team has power to reject too many requirements) Decides independently which tasks to perform to implement the requirements

60 Team (cont d) Teams are self-organizing Joint, consensual decisions on tasks to perform for obtaining the goal of the Sprint, and on work distribution Work is coordinated via Sprint Backlog, Burn-down Chart, and Daily Scrum Members should work in close distance (ideally in the same room) Members should be full-time Membership should change only between sprints

61 Scrum Master Represents management to the project Responsible for enacting Scrum values and practices Removes impediments Ensures that the team is fully functional and productive Enables close cooperation across all roles and functions Shields the team from external interferences

62 Typical Scrum Project

63 Slice of a Typical Scrum Project To be continued in the next lecture.

64 Next Lecture Topic: Agile Principles and Processes Part B For you to do: Start working on Homework 2 Have a look at materials on course wiki: Scrum Reference Card Scrum Training Series (6 videos)