Agile Models. Software Engineering Marco Scotto Software Engineering

Transcription

1 Agile Models Marco Scotto

2 Content Introduction Tame projects & wicked projects Win-Win Spiral software development model XP software development process Enforcing the process 2

3 Introduction Plans are too rigid, often not dynamic enough for businesses Plans cannot address uncertainty and irreversibility properly Alternative agile methodologies: More agility in structures More flexibility in workforce Win-Win Spiral Model extreme Programming (XP) 3

4 Content Introduction Tame projects & wicked projects Win-Win Spiral software development project XP software development process Enforcing the process 4

5 Tame and wicked projects To choose the best approach to a project we must identify its nature Tame Projects Work well with plan-based models Wicked Projects Require something different 5

6 Tame projects Carried out with plan-based approach Given a suitable plan, the project can be carried out successfully Analyzability, not necessarily simplicity The structure can be decomposed into multiple tasks Three beasts appear individually Example: finding a needle in a haystack 6

7 Wicked projects Cannot be accomplished using plans Regardless of the plan, the project will end up with a partial or a complete failure Dynamic, not necessarily difficult A wealth of factors has to be taken into account Path dependency Previous versions of tools or data formats constraining future decisions At least 2 or 3 beasts have to be present and mixed together Example: a chess game 7

8 Recognizing a Wicked Project (1/2) Ten rules: 1. No definitive, analytical formulation of problem Beast: complexity 2. No stopping rule identifying when the problem is solved Beast: uncertainty 3. Solutions are good/bad, not right/wrong Beast: complexity 4. No immediate or final test for a solution Beast: uncertainty 5. Solutions have irreversible consequences Beast: irreversibility 8

9 Recognizing a Wicked Project (2/2) 6. No clear, widely accepted set of potential solutions Beast: uncertainty 7. Essentially unique; hard to find analogous projects Beast: complexity 8. Problem targeted is the cause or result of another problem interlocking issues Beast: complexity 9. Project and its causes can be interpreted in several ways by different people Beast: uncertainty 10. Project cannot go wrong Beast: irreversibility 9

10 3 beasts in wicked projects Proposition on wicked projects Comple xity Irreversibility Uncertainty 1. They do not have a definitive formulation 2. They do not have a stopping rule 3. Solutions are not true/false but good/bad 4. There is no ultimate test of a solution 5. Each solution has consequences 6. A set of potential solutions does not exists 7. Each project is essentially unique 8. Each project can be considered a symptom of another project 9. Their causes can be explained in several ways 10. The project cannot go wrong 10

11 Examples of wicked projects Customers want a fixed price but are uncertain about their desires Irreversibility in commitment of price & uncertainty in customer requirements Developers build a complex but not fully documented architecture Complexityin system & uncertainty in usage Developers have to build a complex project with a fixed budget and a deadline Complexityin system & irreversibility in resources and time 11

12 Path dependency Previous versions of tools or data formats constraining future decisions A form of irreversibility contributes to the wicked-ness of software system Examples: Users of a software product continue to use its newer version instead of switching to a better product for reason of compatibility with valuable old files QWERTY keyboard not replaced by more efficient keyboard Learning involved during the replacement period will be too much trouble 12

13 Content Introduction Tame projects & wicked projects Win-Win Spiral software development project XP software development process Enforcing the process 13

14 Win-Win Spiral Software Development Model Originated by the work of Barry Boehm, the first software engineering researcher to formalize an agile process Based on two existing approaches: The win-win approach to requirement negotiation The spiral software development model 14

15 Win-win approach Requirement negotiation is critical Elicitation of customer s desires Establishing mutual understanding Two possibilities of outcomes No accommodation can be made, no agreement Positions of both sides accommodated 15

16 Win-win approach Mutual understanding Developers acknowledge customer's desires Customer realizes what the developer can provide given certain budget and time frame Win-Win situation Goal: Satisfaction of both customer and developer Means: Make the process transparent Include Manager, Marketing Rep AND Developer in negotiation 16

17 Win-win approach Win conditions: Customer: job done Developer: paid and good reputation Process must be transparent Agreement is set of selected alternatives which: Address issue to be solved Can be carried out by developer Satisfy both customer and developer 17

18 Win-Win Negotiation Process Set of selected alternatives satisfying both customer and developers Win-win alternative can be carried out with satisfaction by * Agreement Is composed of * Selected alternative Labor provider Funds provider Addresses Developer Customer * Issue to solve Win-win condition Has been identified as 18

19 The 3 Beasts in the Negotiation Process Irreversibility agreement between customer and developer is irreversible Complexity: multi-stakeholder environment Uncertainty: different perspectives and backgrounds 19

20 The Structure of the Spiral model The spiral ring replaces the increment: Organized in terms of functions deployed to the customers Not in terms of inner functionality At each increment or ring of the spiral More complete vision of system Everything is repeated, including feasibility study and customer interactions customer is involved every ring (step) of the way Each ring contains functionalities that are useful to the end costumer Each ring does not require the rebuilding of the entire infrastructure 20

21 Spiral development model (2/3) Sample model Commit the ring Identify stakeholders for the ring to develop Validate the product built so far with the customer Determine the - win win condition, if exists time Test the ring with everything built so far Code the ring based on what has already been built and the new - win win condition Analyse the ring based on what has already been built and the new -win win condition Design the ring based on what has already been built and the new win-win condition 21

22 Spiral development model (3/3) The sample model Each ring starts at the identification of stakeholders The 8 steps are repeated for every ring in a V-shaped manner Nucleus The first ring; very critical Requires a good understanding of what to develop Requires ability to build a system without too much commitment of future developers Applying frameworks requires construction piece by piece in each ring burden to developers 22

23 Win-Win Spiral Model (1/2) The model in eight steps: 1.Identification of stakeholders of ring involves customers or those who relate to what to do next 2. Determination of the win-win condition involves customers, developers and, if needed, managers 3. Analysis on the basis of win-win condition reconcile what to build with what has already been built 4. Design on the basis of win-win condition extend the previously built design 23

24 Win-Win Spiral Model (2/2) 5. Code ring on basis of win-win condition extend the previous functionalities 6. Test of the new ring Test the ring alone and within the entire system 7. Evaluate the new version of the system evaluation with the costumer 8. Commit the work done so far 24

25 The 3 beasts in the Spiral Model Uncertainty reduced: Costumer/developers interactions increased, as they are present in each ring Irreversibility reduced: Decisions affect small portions of the system trough spiral model Likelihood of wrong irreversible decisions reduced trough costumer interactions Complexity of system reduced: Developers concentrate on one ring at the time Complexity of coordination increased 25

26 3 beasts in win-win spiral model Beast Approach Uncertainty Development prioritized based on what user wants first limits uncertainty and possible wrong communication channels on the developer s side. User has concrete perception of system growth at each ring reduces uncertainty on user s side. Irreversibility Focusing on what the user wants first limits the scope of irreversible decisions. Specifics on how to do this effectively are limited, however. Complexity Complexity is handled by limiting scope of development in each ring. The coordination complexity gets even higher. 26

27 Common output coordination mechanism Similar to incremental model Higher coordination complexity Hard to obtain required customer's involvement Flexible terms for development more suitable than fixed terms Customer needs to have confidence in developers 27

28 Evaluation of win-win spiral model (1/2) Customer-driven; direction connection with customers Development halt at any time is possible Flexible system; adaptive control of development No big architectural phase Possible shift in overall direction at each ring Less upfront investment Developer required to have technical and customer service skills 28

29 Evaluation of win-win spiral model (2/2) Small ring sizes Simplify flow of communication Reduce frequency & significance of panic situations OO methodologies suitable However, Higher coordination complexity Cannot be managed by using only standard planbased techniques Theoretically-based Instances of the model and knowledge of its application are limited 29

30 Content Introduction Tame projects & wicked projects Win-Win Spiral software development XP software development process Enforcing the process 30

31 XP software development process XP was born as a support for a very specific project, not as an original model 31

32 Three drivers Focus on value and on what generates the value Constant flow of activities driven by customer s desire Aim at eliminating defects without any trade-off decision 32

33 Four founding values Communication Among developers and with customers Simplicity Simplest solution preferred; no fancy details Feedback From other developers and from customer Courage Developers not afraid to make changes and discuss issues with customer Customer not worried about developers wasting money 33

34 Drivers & values (1/2) Focus on the value and on what generates value Simplicity: consider only features of interest Communication & feedback: customer defines focus Constant flow of activities driven by customer s desire Feedback & courage: negotiation about priorities and functionality Aim at highest possible absence of defects Simplicity: prevent inserting defects Feedback: from tools and customer Communication: among developers Courage: test code under severe circumstances 34

35 Drivers & values (2/2) Relationship between XP drivers and values Focus on value Communication Constant flow Simplicity Feedback Absence of defects Courage 35

36 12 practices Planning game Addresses uncertainty Short releases Addresses uncertainty, irreversibility, and complexity Metaphor Addresses uncertainty and complexity Simple design Addresses uncertainty, irreversibility, and complexity Testing Addresses uncertainty, irreversibility, and complexity Refactoring Addresses irreversibility and complexity Pair programming Addresses uncertainty and complexity Collective code ownership Addresses complexity Continuous integration Addresses uncertainty, irreversibility, and complexity 40 hours working week Addresses complexity On-site customer Addresses uncertainty Coding standards Addresses complexity 36

37 Drivers, values, & practices Drivers Values Focus on value Constant flow No defects Communications Simplicity Feedback Courage Planning game Short release Metaphor Simple design Testing Refactoring Pair program. Collective code ownership Continuous integration 40hrs week On-site customer Coding standard 37

38 Addressing the 3 beasts Uncertainty Communication and feedback limit miscommunication Simplicity prevents creation of confusing structures Irreversibility Deferring decisions on issues not of highest level priority Gathering frequent and fast feedback from customer Complexity Simplicity suppresses complexity XP tries to eliminate waste from complexity 38

39 Common output coordination mechanism Complicated; deters some from using XP Constraints not appear as superimposed All developers can modify code if satisfying test cases Planning done by all 3 parties Customer Manager Developers Same pace, code, and standards XP's practices keep system simple and amenable Dependencies Start-to-start for overall project End-to-start among activities within iteration 39

40 XP practices & the 3 beasts Which practices reduce or eliminate the beasts XP Practices Beasts Uncertainty Irreversibility Complexity Planning game Short releases Metaphor Simple design Testing Refactoring Pair programming Collective code ownership Continuous integration 40 hours working week On-site customer Coding standards 40

41 XP & cowboy coding (1/2) Practices between the two are compared For disproving the claim of similarity between the two styles XP practices Cowboy coding Planning game: priorities based on both technical and business considerations with customers Short releases Metaphor: a lingua franca between customer and developer. Simple design: design and code kept simple, supported by collective code ownership and refactoring Priorities based only on technical consideration and decided by developers. Releases are usually long and driven by phone calls of complaint from customer. There is no lingua franca between customer and developer. Usually no consideration for simplicity. Refactoring is not an issue. Test first: test cases are developed upfront The test cases, when exist, are developed at the end, without a rigorous process. 41

42 XP & cowboy coding (2/2) XP practices Pair programming: the pairs change constantly. Sharing knowledge is a must. Collective code ownership: everyone can modify any part of the system if it satisfies all tests. Continuous integration: code is centralized and tools are used for continuous integration. 40 hours a week: trying to keep the amount of work constant across the project. Coding standards: shared across the team. On-site customer: there is a high communication band with him/her using a win-win principle. Cowboy coding Programming is done by individuals who usually are gurus, not willing to share their knowledge. Everyone touches any part of the system without any rule. The code is kept randomly by developers without a common repository. People work in spikes. No work done for some weeks. Weeks with 100 hours of work when the deadline is near. Coding standards are mainly based on personal criteria. The customer perceived as an enemy, kept away from the coding site. Spaghetti codes behind closed door 42

43 Evaluation Even higher coordination complexity compared to spiral model Adaptation rather than implementation Not be treated as a religion Other possibilities are available Should not be used extensively with plan-based tools Key to success Short releases Adaptive approach 43

44 Creating your own XP process Adaptation rather than implementation XP a religion Extensive use of plan-based tools for XP Careful consideration of the 3 drivers when moving to XP The drivers are not unique for all projects Proceed gradually when introducing practices Key: Short releases and adaptive approach Remember, XP is not the only possibility 44

45 Content Introduction Tame projects & wicked projects Win-Win Spiral software development XP software development process Enforcing the process 45

46 Enforcing the process Enforcing a process, yet not compromising the human nature of software development Difficult to control the commitment of developers in plan based processes XP and other agile processes are even more selfcoordinated Trust and cooperation become the major factors Hard rules to simplify coordination and to help process management in XP E.g., Pair programming, coding standards, 40 hours week, etc. 46