1. Be sure to join Virginia Tech's Human Factors Engineering and Ergonomics Center (HFEEC) & chapter of the Human Factors and Ergonomics Society (HFES) and the Laboratory for User-Centric Innovations in Design (LUCID) in affiliation with Virginia Tech's Center for Human-Computer Interaction (CHCI) in a celebration of World Usability Day 2008 (http://www.worldusabilityday.org/) on today, 13 November 2008, from 5:00pm - 6:00pm in Room 1110 of the Knowledge Works II Building (KW 1110).http://www.worldusabilityday.org/ REFRESHMENTS WILL BE PROVIDED! This year's theme is "Usability in Transportation" and we will be joined by Mr. Greg Fitch, Research Associate - VTTI's Center for Truck and Bus Safety. Greg, a Ph.D. candidate in Industrial and Systems Engineering, will be highlighting some innovative work in driver alert systems design in a talk titled "Communicating Integrated Collision Avoidance System Alerts through a Haptic Driver Seat". A reception featuring light refreshments will follow Greg's talk. All are welcome in this our 3rd year of celebrating our contributions in "making life easy."

4.  Suggested by Hartson and Hix (1989)  Important features: Evaluation at the center of activities No particular ordering of activities; development may start in any one Derived from empirical studies of interface designers

6.  “light-weight methods”  Goal of creating software in ways that are:  Lighter  Faster  more people-centric

7.  Individuals and interactions  Individuals and interactions over processes and tools  Working software  Working software over comprehensive documentation  Customer collaboration  Customer collaboration over contract negotiation  Responding to change  Responding to change over following a plan

8. 1. Satisfy the customer through early and continuous delivery of valuable software 1. Satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements 2. Welcome changing requirements, even late in development. 3. Deliver working software frequently 3. Deliver working software frequently, in weeks to months (“Timebox”) 4. Business people and developers must work together 4. Business people and developers must work together daily throughout the project. motivated individuals 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. face-to-face conversation 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity 10. Simplicity--the art of maximizing the amount of work not done--is essential. self-organizing teams 11. The best architectures, requirements, and designs emerge from self-organizing teams. the team reflects on how to become more effective 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

9.  The waterfall model steps through  requirements  Capture  Analysis  Design  Coding  testing  Progress is generally measured in terms of pre-planned sequence deliverable artifacts:  requirement specifications  design documents  prototypes  code / implementation  evaluation

10.  Waterfall model:  separate stages  commitments are made early on  difficult to react to changes in requirements  Iterations are expensive.  Agile methods:  produce completely developed features (very small subset of the whole) every few weeks.  smallest workable piece of functionality to deliver business value early  continually improving it/adding further functionality throughout the life of the project.

11. For  management of software development projects  for running software maintenance teams  program management approach

12. based on the joke  A pig and a chicken are walking down a road. The chicken looks at the pig and says, "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed but you'd only be involved.“  pigs are committed to building software regularly and frequently  everyone else is a chicken: interested in the project but really irrelevant, though needs and desires are addressed

13.  Product Owner  the voice of the customer  writes User Stories, prioritizes themUser Stories  then places them in the Product Backlog.Product Backlog  ScrumMaster: Facilitator  primary job is to remove impediments to the ability of the team to deliver the sprint goal.  not the leader of the team (as they are self-organizing)  acts as a buffer between the team and any distracting influences.  The ScrumMaster is the enforcer of rules.  Team  responsibility to deliver the product.  5-9 people with cross-functional skills to do the actual work  designer, developer etc.

14.  Chicken roles  not part of the actual Scrum process, but taken into account.  involve / engage users, business and stakeholders in the process.  provide feedback into the outputs for review and planning of each sprint.  Users  Stakeholders (Customers, Vendors)  Managers (of users, organizations)

15.  ScrumMaster : (project manager) maintains the processes  Product Owner: represents the stakeholders  Team : developers  During each sprint (15-30 day period) potentially shippable  team creates an increment of potentially shippable (usable) software.  featuresproduct backlog  features for sprint come from the product backlog, prioritized high level requirements of work to be done.  planning meetings  planning meetings determine the backlog items ▪ Product Owner informs the team of the items in the product backlog ▪ The team determines how much they can commit to during the next sprint ▪ no one can change the sprint backlog, the requirements are frozen for a sprint.

17.  Project status meetingguidelines:  The meeting starts precisely on time.  punishments for tardiness  e.g. money, push-ups, hanging a rubber chicken around your neck  All are welcome, but only "pigs" may speak timeboxed  The meeting is timeboxed at 15 minutes  All attendees should stand (it helps to keep meeting short)  The meeting should happen at the same location and same time every day  During the meeting, each team member answers three questions: [1] [1]  What have you done since yesterday?  What are you planning to do by today?  Do you have any problems preventing you from accomplishing your goal?

18.  every 15-30 days  all team members reflect about the past sprint.  purpose is to make continuous process improvement.  This meeting is timeboxed at four hours.  Two main questions are asked in the sprint retrospective:  What went well during the sprint?  What could be improved in the next sprint?

19.  Enables the creation of self-organizing teams  by encouraging co-location of all team members  and verbal communication across all team members  recognition of “requirements churn”  during a project the customers can change their minds about what they want and need  unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner  As such, Scrum adopts an empirical approach  accepting that the problem cannot be fully understood or defined  focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.