18_Agile_Development

1 .Lecture 18 – Agile Development Describe the waterfall development approach, identify drawbacks Provide and overview of agile development Define User Stories , Tasks , Sprints List drawbacks of agile development Give examples when Agile is appropriate and not appropriate for a development project Learning Goals © Paul Davies, C. Antonio Sanchez. Not to be copied, used, or revised without explicit written permission from the copyright owner.

2 .Waterfall Development Intro to System Software Engineering 2 Software Life Cycle or Waterfall model of software development This software life-cycle paradigm implies a sequential approach to software, beginning at the system level, and progressing through stages until the final product is delivered. In reality, stages get revisisted , usually leading to several iterations .

3 .Waterfall Development Many large-scale projects have failed while following this approach. T he waterfall model assumes a once-only delivery in one single software release. It does not address the element of risk : it assumes that all requirements are equally important and are tackled in the same way. High risk activities such as interfacing the system to an unknown database, using unknown tools , hiring staff that are not familiar with them, miss-perception of user requirements , or flaws in the initial design may not be discovered until much later in the process . This can lead to massive delays and cost-overruns towards. Finally unless multiple projects are on-going , it leads to poor staff utilisation, analysts are only employed at the beginning of a project and testers only at the end. Intro to System Software Engineering 3

4 .Agile Development Intro to System Software Engineering 4 Not really a single methodology. Attempts to adjust development practice to be more flexible : Shorter cycles to reduce risk Ability to adjust quickly to changing requirements Iterative Development: software is delivered to customer regularly, with each new significant functionality developed and tested. Starts with a minimum working version. Short life-cycles with specific targets Immediate feedback with each feature Paid throughout development for each release Better staff utilization

5 .Waterfall vs Agile Waterfall Method: predictive Carefully documents requirements, implements, tests up front Suitable for large engineering projects where cost to change is prohibitive (e.g. building bridges, car manufacturing, etc.) Intro to System Software Engineering 5 Agile Method: adaptive Iterative process that adapts to requirements change, or as realities are better understood Collaborative, customer-centric Cheap to change (more suitable in software engineering)

6 .The Agile Manifesto Intro to System Software Engineering 6 2001: a group of software developers organized to express dissatisfaction with being forced to use the waterfall model. Strong emphasis on documentation before design , contract negotiation , lack of flexibility . Formed the Agile Alliance, wrote the Agile Manifesto. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan While there is value in the things on the right, we value the things on the left more Beck, Kent, et al, "Manifesto for Agile Software Development". Agile Alliance, 2001

7 .User Stories Intro to System Software Engineering 7 Agile approaches seek to uncover the functionality required of a system through a process of exploring user stories . User stories: short, simple narrative descriptions of a feature told from the perspective of the person who desires it: As a < my role >, I want to be able to < some goal > so that < some reason > . Often written on index cards or sticky notes , stored in a shoe box , or arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

8 .User Stories Product Backlog: set of goals/features that the system must meet. This is the what, not the how. Usually divided into a set of small sub-features that represent manageable chunks of work. Intro to System Software Engineering 8

9 .Sprints Intro to System Software Engineering 9 Development divided into sprints , each lasting 1-3 weeks Within each sprint you design , implement , and test a version of your product Each version gets progressively closer to your release version. Important: the result of each sprint is something you can demonstrate (not just a bunch of code and functions). So consider the development of say a “ PAC Man game”, The 1 st sprint might focus on developing the maze and displaying the screen. The 2 nd sprint might implement the single player game strategy etc. The 3 rd sprint might allow for multiple players and customization .

10 .Intro to System Software Engineering 10 Sprints are then broken down into smaller tasks Each task involves writing , testing , and integrating a piece of code Each task takes no more than a few hours/days. If it does then break it down into smaller task as it’s probably too complex for 1 task So for example, for Sprint 1 of our Pac Man game: There may be 10’s of tasks per sprint . Tasks are often dependent on other tasks . Sprints Task 1 : draw maze on the screen Task 2 : draw player on the screen Task 3 : Read player input Task 4 : Update player’s location based on input

11 .The Agile Board Intro to System Software Engineering 11 http://www.techno-pm.com/2017/05/scrum-board-example.html Tasks are written on post-its, placed in the “To-Do” or Product Backlog column sorted by priority . Rather than managers pushing work, developers pull work from the To-Do column, place in the “ In Progress ” column When task is ready to be tested, it moves to the next column… Can add as many columns as necessary

12 .Scrum Meetings Intro to System Software Engineering 12 In many companies, scrums (or daily stand-up meetings) are short meetings ( 5 - 15min ) typically held at the start of each day. Usually, everyone stands to keep it short. A “ scrum master ” runs the meeting. Each group member summarises: What has been done since the last scrum What he or she intends to do before the next scrum. Any obstacles preventing progress .

13 .Intro to System Software Engineering 13 Scrum Illustration 1-3 Week Sprint (retrospective meeting) 1 day Daily scrum : What have I done? What am I doing? What is holding me up? Release backlog Product backlog “ Shippable ” Product Increment with latest features List of product features ( User Stories ) yet to be implemented Prioritised list of features, broken down into tasks and estimates of time Sprint: Design, test and release next version/iteration User Story : Proposed by Stake holders, customers etc. Written in the form of “ As a (my role) I want the system to be able to do (task) so that (benefit)”

14 .Agile Software – axosoft Intro to System Software Engineering 14

15 .Agile Software – Trello Intro to System Software Engineering 15

16 .Agile Software – JIRA Intro to System Software Engineering 16

17 .Drawbacks of Agile Intro to System Software Engineering 17 Agile development works well for some projects especially when requirements, technology are not well understood or are changing . It’s main criticism is that project management is often non-existent, and that the only documentation is the Source code itself. It is also dependent on the idea that : “ the software will be ready when it’s ready ”.

18 .No One-Size-Fits-All Approach Agile can present problems when: The Software is large/complex and developed over years not weeks i.e. relies on the designs being on paper, not in the head of a developer Software that has a deadline so that marketing, training, budgets etc can be coordinated. Software is safety critical e.g. fly by wire aircraft where certification may be necessary. Agile has it’s sceptics, but it’s currently the favoured approach for many small software development projects in certain fields e.g. web/app type stuff. Many companies will have their own versions of agile development. Sprints can be 3 months, weekly stand-ups, etc… usually develop according to company culture. Intro to System Software Engineering 18

19 .Intro to System Software Engineering 19 https://i2.wp.com/media.giphy.com/media/xT1XGOGdyDrL2BTfxK/giphy.gif?resize=400%2C225&ssl=1 Silicon Valley, S01E05