Transcription
Agile Developmentand Project ManagementCogSci 121 - HCI Programming StudioAdapted from slides by Mountain Got Software, Shahid N. Shah
Agile Software Developmenthttps://www.youtube.com/watch?v OJflDE6OaSc2
Manifesto forAgile Software DevelopmentWe are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items onthe right, we value the items on the left more.3
The principles of agile methodsPrincipleDescriptionCustomer involvementCustomers should be closely involved throughout thedevelopment process. Their role is provide and prioritize newsystem requirements and to evaluate the iterations of the system.Incremental deliveryThe software is developed in increments with the customerspecifying the requirements to be included in each increment.People not processThe skills of the development team should be recognized andexploited. Team members should be left to develop their ownways of working without prescriptive processes.Embrace changeExpect the system requirements to change and so design thesystem to accommodate these changes.Maintain simplicityFocus on simplicity in both the software being developed and inthe development process. Wherever possible, actively work toeliminate complexity from the system.4
XP Practices[See additional slides at the end]5
XP: Embrace Change Recognize that:– All requirements will not be known at thebeginning– Requirements will change Use tools to accommodate change as a natural process Do the simplest thing that could possibly work andrefactor mercilessly Emphasize values and principles rather than process6
The Scrum process7
Scrum in 100 words Scrum is an agile process that allows us to focus on deliveringthe highest business value in the shortest time.It allows us to rapidly and repeatedly inspect actual workingsoftware (every two weeks to one month).The business sets the priorities. Teams self-organize todetermine the best way to deliver the highest priorityfeatures.Every two weeks to a month anyone can see real workingsoftware and decide to release it as is or continue to enhanceit for another sprint.8
Characteristics Self-organizing teams Product progresses in a series of month-long “sprints” Requirements are captured as items in a list of“product backlog” No specific engineering practices prescribed Uses generative rules to create an agile environmentfor delivering projects One of the “agile processes”9
Scrum24 hoursSprint2-4 weeksSprint goalReturnSprint backlogPotentially shippableproduct incrementGift wrapCancelProductbacklog10
Sprints Scrum projects make progress in a series of “sprints”– Analogous to Extreme Programming iterations Typical duration is 2–4 weeks or a calendar month atmost A constant duration leads to a better rhythm Product is designed, coded, and tested during thesprint11
Sequential vs. ther than doing all ofone thing at a time.Scrum teams do a littleof everything all the timeSource: “The New New Product Development Game” by Takeuchi andNonaka. Harvard Business Review, January 1986.12
Scrum frameworkRoles Product owner ScrumMaster TeamCeremonies Sprint planning Sprint review Sprint retrospective Daily scrum meetingArtifacts Product backlog Sprint backlog Burndown charts13
Scrum frameworkRoles Product owner ScrumMaster TeamCeremonies Sprint planning Sprint review Sprint retrospective Daily scrum meetingArtifacts Product backlog Sprint backlog Burndown charts14
Product owner Define the features of the product Decide on release date and content Be responsible for the profitability of the product(ROI) Prioritize features according to market value Adjust features and priority every iteration, asneeded Accept or reject work results15
The ScrumMasterRepresents management to the projectResponsible for enacting Scrum values and practicesRemoves impedimentsEnsure that the team is fully functional andproductive Enable close cooperation across all roles andfunctions Shield the team from external interferences 16
The team Typically 5-9 people Cross-functional:– Programmers, testers, user experience designers, etc. Members should be full-time May be exceptions (e.g., database administrator) Teams are self-organizing– Ideally, no titles but rarely a possibility Membership should change only between sprints17
Scrum frameworkRoles Product owner ScrumMaster TeamCeremonies Sprint planning Sprint review Sprint retrospective Daily scrum meetingArtifacts Product backlog Sprint backlog Burndown charts18
TeamcapacityProductbacklogBusinessconditionsSprint planning meetingSprint prioritization TechnologySprintgoalSprint planning CurrentproductAnalyze and evaluate productbacklogSelect sprint goal Decide how to achieve sprint goal(design)Create sprint backlog (tasks) fromproduct backlog items (userstories / features)Estimate sprint backlog in hoursSprintbacklog19
Sprint planning Team selects items from the product backlog they can commit tocompleting Sprint backlog is created– Tasks are identified and each is estimated (1-16 hours)– Collaboratively, not done alone by the ScrumMaster High-level design is consideredAs a vacation planner, I want tosee photos of the hotels.Code the middle tier (8 hours)Code the user interface (4)Write test fixtures (4)Code the foo class (6)Update performance tests (4)20
The daily scrum Parameters– Daily– 15-minutes– Stand-up Not for problem solving– Whole world is invited– Only team members, ScrumMaster, product owner,can talk Helps avoid other unnecessary meetings21
Everyone answers 3 questionsWhat did you do yesterday?What will you do today?Is anything in your way?123 These are commitments in front of peers22
The sprint review Team presents what itaccomplished during thesprint Typically takes the form of ademo of new features orunderlying architecture Informal– 2-hour prep time rule– No slides Whole team participates Invite the world23
Sprint retrospective Periodically take a look at what is and is not workingTypically 15–30 minutesDone after every sprintWhole team participates– ScrumMaster– Product owner– Team– Possibly customers and others24
Start / Stop / Continue Whole team gathers and discusses what they’d like to:Start doingThis is just oneof many ways todo a sprintretrospective.Stop doingContinue doing25
Scrum frameworkRoles Product owner ScrumMaster TeamCeremonies Sprint planning Sprint review Sprint retrospective Daily scrum meetingArtifacts Product backlog Sprint backlog Burndown charts26
Product backlogThis is theproduct backlog The requirements A list of all desired workon the project Ideally expressed suchthat each item has valueto the users or customersof the product Prioritized by the productowner Reprioritized at the startof each sprint27
A sample product backlogBacklog itemPriorityAllow a guest to make a reservation3As a guest, I want to cancel a reservation.5As a guest, I want to change the dates of areservation.As a hotel employee, I can run RevPARreports (revenue-per-available-room)Improve exception handling.388305028
The sprint goal A short statement of what the work will be focused onduring the sprintLife SciencesDatabase ApplicationSupport features necessary forpopulation genetics studies.Make the application run on SQLServer in addition to Oracle.Financial servicesSupport more technical indicators thancompany ABC with real-time, streamingdata.
Attendance30
(Agile) Project Management ToolsGantt Chart: A bar chart. While visually appealing on a task/duration basis, it is limited because it does not show task orresource relationships well. Strength: easy to maintain and read.31
(Agile) Project Management ToolsNetwork Diagram: A wire diagram, Also known as a PERT networkdiagram. A diagram that shows tasks and their relationships.Limited because it shows only task relationships. Strength: easyto read task relationships.32
Project ControlWork with the client to determine the project needs & constraints (ANALYZE)Define project milestones and deliverables (PLAN)while project has not been completed or cancelled (EXECUTE)Draw up project scheduleInitiate activities according to scheduleWait ( for a while )Review project progressRevise estimates of project parametersUpdate the project scheduleRe-negotiate project constraints and deliverablesif ( problems arise ) thenInitiate technical review and possible revisionend ifend loopClose project (DELIVER)33
An example Writing a research paper34
1: Requirements Definition{product goals}– 20 pages– Double spaced– On a topic addressing a question of the effectiveness ofagile and waterfall methods– Includes a literature review– Includes a proposal for a research study– Includes hypotheses & expected results– IEEE citation format– Reference at least 10 peer-reviewed papers
2: Work Breakdown Structure{logical units of work to accomplish goals}1. PlanningA. Pick topic & research questionB. Brainstorm potential research studiesC. Make list of papers to readD. Document A-C in a proposalE. Discuss proposal with professor2. ResearchingF. Read research papersG. Document key ideas3. WritingH. Outline paperI. Write first draftJ. Discuss draft with professor4. Editing & PolishingK. Revise draftL. Check references and citation formatM. Check length and formattingN. ProofreadO. Submit erablemilestone
Project Management Tools TrelloBasecampJiraAsanaGithub ZenHubTom’s PlannerGantterGithub Zenhub37
Amy’s Personal RecommendationTrelloFor capturingrequirementsand sortingthem intoprioritiesGantter Turningrequirementsinto a WBS andscheduling w/dependenciesGithub Zenhub Source control feature trackinglinked tocommits *
Agile reading list Agile and Iterative Development: A Manager’s Guide, by CraigLarman Agile Estimating and Planning, by Mike Cohn Agile Project Management with Scrum, by Ken Schwaber Agile Retrospectives, by Esther Derby and Diana Larsen Agile Software Development Ecosystems, by Jim Highsmith Agile Software Development with Scrum, by Ken Schwaber andMike Beedle Scrum and The Enterprise, by Ken Schwaber Succeeding with Agile, by Mike Cohn User Stories Applied for Agile Software Development, by Mike Cohn39
Agile Development for your familyhttps://www.ted.com/talks/bruce feiler agile programming for your family?40
Next Steps Today: Design Critique, by Amy Fox Problems to Solve, Jacob Browne Thursday: Design Critique, Elevator Pitch Friday: Technical Discussions / Studio (required)-Debriefing on Assignment 3-Quiz on Week 6 Content Readings (required)- Meirelles (Design for information: an introduction to the histories, theories, and the best practices behindeffective information visualizations) — Chapter 4 Chapter 5 Next Week:-Design Critique: Data Flow and Architecture
THANKS42
Extreme programming Perhaps the best-known and most widely used agilemethod. Extreme Programming (XP) takes an ‘extreme’approach to iterative development.– New versions may be built several times per day;– Increments are delivered to customers every 2weeks;– All tests must be run for every build and the buildis only accepted if tests run successfully.1543
XP IntroductionExtreme Programming (XP) XP does not involve bungee cords!– It does not encourage blind hacking. It is a systematic methodology.– It predates Windows “XP” (2001) Developed by Kent Beck:– XP is “a light-weight methodology for small to medium-sized teamsdeveloping software in the face of vague or rapidly changingrequirements.” Alternative to “heavy-weight” software development models(which tend to avoid change and customers)– "Extreme Programming turns the conventional software processsideways. Rather than planning, analyzing, and designing for thefar-flung future, XP programmers do all of these activities a littleat a time throughout development.”-- IEEE Computer , October 199944
XP valuesFour Core Values of XP CommunicationSimplicityFeedbackCourage45
XP valuesCommunication XP emphasizes value of communication in many ofits practices:– On-site customer, user stories, pairprogramming, collective ownership (popularwith open source developers), daily standupmeetings, etc. XP employs a coach whose job is noticing whenpeople aren’t communicating and reintroducethem46
SimplicityXP values ''Do the simplest thing that could possiblywork'' (DTSTTCPW) principle– Elsewhere known as KISS (Keep It Simple, Stupid!) A coach may say DTSTTCPW when he sees an XPdeveloper doing something needlessly complicated YAGNI principle (''You ain’t gonna need it'')47
XP valuesFeedback Feedback at different time scales Unit tests tell programmers status of the system When customers write new user stories,programmers estimate time required to deliverchanges Programmers produce new releases every2-3 weeks for customers to review48
Courage The courage to communicate and accept feedback The courage to throw code away (prototypes) The courage to refactor the architecture of asystem Do you have what it takes?49
The Extreme Programming ReleaseCycle50
Extreme Programming practicesPrinciple or practiceDescriptionIncremental planningRequirements are recorded on story cards and the stories to beincluded in a release are determined by the time available andtheir relative priority. The developers break these stories intodevelopment ‘Tasks’Small releasesThe minimal useful set of functionality that provides businessvalue is developed first. Releases of the system are frequent andincrementally add functionality to the first release.Simple designEnough design is carried out to meet the current requirementsand no more.Test-first developmentAn automated unit test framework is used to write tests for a newpiece of functionality before that functionality itself isimplemented.RefactoringAll developers are expected to refactor the code continuously assoon as possible code improvements are found. This keeps thecode simple and maintainable.51
Extreme Programming practicesPair programmingDevelopers work in pairs, checking each other’s work andproviding the support to always do a good job.Collective ownershipThe pairs of developers work on all areas of the system, so thatno islands of expertise develop and all the developers takeresponsibility for all of the code. Anyone can change anything.Continuous integrationAs soon as the work on a task is complete, it is integrated intothe whole system. After any such integration, all the unit tests inthe system must pass.Sustainable paceLarge amounts of overtime are not considered acceptable as thenet effect is often to reduce code quality and medium termproductivityOn-site customerA representative of the end-user of the system (the customer)should be available full time for the use of the XP team. In anextreme programming process, the customer is a member of thedevelopment team and is responsible for bringing systemrequirements to the team for implementation.52
Advantages of pair programming It supports the idea of collective ownership and responsibility forthe system.– Individuals are not held responsible for problems with thecode. Instead, the team has collective responsibility forresolving these problems. It acts as an informal review process because each line of code islooked at by at least two people. It helps support refactoring, which is a process of softwareimprovement.– Where pair programming and collective ownership are used,others benefit immediately from the refactoring so they arelikely to support the process.53
Agile reading list Agile and Iterative Development: A Manager’s Guide, by Craig Larman Agile Estimating and Planning, by Mike Cohn Agile Project Management with Scrum, by Ken Schwaber Agile Retrospectives, by Esther Derby and Diana Larsen Agile
