1 / 33

Lecture 3

Lecture 3. COMSATS Islamabad . E nterprise S ystems D evelopment (CSC447). Muhammad Usman , Assistant Professor . Agile Development.

ganya
Download Presentation

Lecture 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 3 COMSATS Islamabad Enterprise Systems Development (CSC447) Muhammad Usman, Assistant Professor

  2. Agile Development 2001: Kent Beck and 16 other software developers, referred to as “Agile Alliance”, signed the “manifesto for Agile software development”. It stated: Through this work we have come to Value: Individuals and interaction over processes and tool Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following plan That is, while there is value in the items on the right , we values the items on the left more.

  3. Agile Methods • Agile software development is a group of software development methodologies that are based on similar principles. • Agile methodologies generally promote a project management process that encourages • frequent inspection and adaptation • a leadership philosophy that encourages team work • a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals

  4. What are Agile Methods? • Agile software development is a conceptual framework for undertaking software engineering projects. • Most agile methods attempt to minimize risk by developing software in short timeboxes, called iterations, which may typically last one to four weeks. • Each iteration is like a miniature software project of its own, and includes all of the tasks necessary to release the mini-increment of new functionality.

  5. Agile Methods v/s Traditional Methods Agile methods emphasize real time communication, preferably face-to-face, over written documents. Agile methods like XP relies on the close collaboration of activity engaged individuals with ordinary talents and has the ability to flexibly schedule the implementation of functionality, responding to changing business needs. Reference: Extreme Programming explained: Embrace Change By: Kent Beck with Cynthia Andres; 2nd ed., 2005

  6. Different Agile Methods? Extreme Programming (XP) Scrum Agile Modeling Adaptive Software Development (ASD) Crystal Clear and Other Crystal Methodologies Dynamic Systems Development Method (DSDM) Feature Driven Development Lean software development Agile Unified Process (AUP)

  7. Extreme Programming • Emphasis on four characteristics of agility • Communication: continual interchange between customers and developers • Simplicity: select the simplest design or implementation • Courage: commitment to delivering functionality early and often • Feedback: loops built into the various activitites during the development process

  8. eXtreme Programming (XP) • Philosophy • Take known good practices and push them to extremes • For example • “If code reviews are good, we’ll review code all the time” • “If testing is good, we’ll test all the time” • “If design is good, we’ll make it part of everybody’s daily business”

  9. eXtreme Programming (XP)

  10. Essence of XP • Four variables in software development : • Cost, Time, Quality, Scope • Four Values • Communication, Simplicity, Feedback, and Courage • Five Principles • Provide feedback, assume simplicity, make incremental changes, embrace change, quality work • 12 Practices

  11. Pair programming Collective ownership Continuous integration (small increments) Sustainable pace (40 hours/week) On-site customer Coding standards Twelve Facets of XP • The planning game (customer defines value) • Small releases • Metaphor (common vision, common names) • Simple design • Writing tests first • Refactoring

  12. XP (Extreme Programming) XP Practices Planning game - programmers estimate effort of implementing customer stories and customer decides about scope and timing of releases Short releases - new release every 2-3 months Simple design - emphasis on simplest design Testing - development test driven…* Refactoring - restructuring and changes to simplify Pair Programming - 2 people at 1 computer

  13. XP (Extreme Programming)……. XP Practices Collective ownership - anyone can change any part of the code at any time. Continuous integration - new builds as soon as code ready 40 hour week - maximum 40-hour week. No overtime On-site customer - customer present and available full-time for team Coding standards - rules exist and are followed Open workspace - large room small cubicles Just rules - team has own rules but can be changed any at time

  14. Planning User stories are written. Release planning creates the schedule. Make frequent small releases The Project Velocity is measured. The project is divided into iterations. Iteration planning starts each iteration. Move people around. A stand-up meeting starts each day. Fix XP when it breaks. Key Practices….. Designing • Simplicity. • Choose a system metaphor. (system of names for your objects that everyone can relate to) • Use CRC cards for design sessions. • Create spike solutions to reduce risk. • Refactorwhenever and wherever possible.

  15. Coding The customer is always available. Code must be written to agreed standards. Code the unit test first. All production code is pair programmed. Only one pair integrates code at a time. Integrate often. No overtime. Key Practices Testing • All code must have unit tests. • All code must pass all unit tests before it can be released. • When a bug is found tests are created. • Acceptance tests are run often and the score is published.

  16. XP > Practices > “Circles of Life” On-site Customer CodingStandards Metaphor Refactoring AcceptanceTests Pair Programming ReleasePlanning Unit Tests ContinuousIntegration CollectiveOwnership Simple Design SustainablePace Small Releases Customer – Team – Developer Pair – Team – Customer Synergy >

  17. When is Extreme Too Extreme? • Extreme programming's practices are interdependent • A vulnerability if one of them is modified • Requirements expressed as a set of test cases must be passed by the software • System passes the tests but is not what the customer is paying for • Refactoring issue • Difficult to rework a system without degrading its architecture

  18. Scrum • In Rugby, a scrum is a way to restart the game after an interruption, e.g. after a minor foul. • “During a Scrum, the pack must work as a unit, not as 8 individuals. Everybody has a role to play. The important goal to bear in mind is that when you work well together as a unit, the whole is much greater than the sum of the parts.”The On-Line Rugby Coaching Manual

  19. What is Scrum? • Scrum is not an acronym • Scrum is • a team-based approach • to iteratively, incrementally develop systems and products • when requirements are rapidly changing • Assumes complicated, unpredictable environment • It produces a potentially shippable set of functionality at the end of every iteration

  20. How does Scrum work? • Small teams (< 10 people) • A series of Sprints (1-4 weeks) • Visible, usable increments • Time-boxed

  21. How does Scrum work?

  22. Sprint Rules Total focus—no unwanted diversion NO interruptions/changes from the outside New work may be uncovered by the team Very XP-ish

  23. What Happens During a Sprint? Frequent, short Scrum Meetings Each team produces a visible, usable increment Each increment builds on prior increments Clearly defined deliverables and responsibilities Each team member buys into the assignment

  24. What’s a Scrum Meeting? Short (15 - 30 min) frequent meetings, facilitated by the ScrumMaster All team members attend—even teleworkers One activity -- ScrumMaster asks each attendee 3 questions

  25. What Are The 3 Questions? 1. What have you completed (relative to the Backlog) since the last Scrum meeting? 2. What got in your way of completing this work? 3. What will you do between now and the next Scrum meeting?

  26. At the End of a Sprint? Status meeting with all stakeholders. Increments are delivered. Surprises are reported. ANYTHING can be changed, work can be added, eliminated, re-prioritized. New estimates and team assignments are made for the next Sprint. The project can be cancelled. “Experience from earlier increments allows better estimates and planning as project progresses. It's always easier to estimate shorter development periods”

  27. Rational Unified Process • S/W Engineering Process • Process Framework • Process Product • Workers, Activities, Artifacts, Workflows

  28. RUP Phases

  29. The Architecture of RUP

  30. You Didn’t Understand the RUP When… • You think that • Inception = requirements • elaboration = design • construction = implementation. • You think that the purpose of elaboration is to fully and carefully define models, which are translated into code during construction • You think that only prototypes are created in elaboration • You try to define most of the requirements before starting design or implementation. • You try to define most of the design before starting implementation • A “long time” is spent doing requirements or design work before programming starts • You try to plan a project in detail from start to finish, allocating the work to each iteration; you try to speculatively predict all the iterations • An organization wants believable plans and estimates for projects before they have entered the elaboration phase

  31. RUP Support • Templates • http://sce.uhcl.edu/helm/rationalunifiedprocess/process/templates.htm • http://pic.dhe.ibm.com/infocenter/reqpro/v7r1m0/index.jsp?topic=/com.ibm.reqpro.help/administering/projects/creating_modifying/r_rup_proj_template.html • Tools • http://www.rational.com.ar/tools/herramientas.html

  32. S/W Development Best Practices • Develop software iteratively • Manage requirements • Use component based architecture • Visually model software • Continuously verify software quality ? • Control changes to software

  33. Process Models • Waterfall • Prototyping • RAD • Incremental • Spiral • Agile • XP • SCRUM • RUP

More Related