1 / 12

Agile Development Process

Agile Development Process. Stumbling Towards Chaos. Team Interactions. PLANNING. The Agile Process defines development needs so we can concentrate development on the most vital features of a project. Project Plan defines overall scope and goals and work across the entire project.

kare
Télécharger la présentation

Agile Development Process

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. Agile Development Process Stumbling Towards Chaos

  2. Team Interactions PLANNING

  3. The Agile Process defines development needs so we can concentrate development on the most vital features of a project. • Project Plan defines overall scope and goals and work across the entire project. • Release plans define a critical need within a project and summarize the strategy to address it. • User Stories define vital features for a release in a clear and testable way. • Prioritizing User Stories will help clarify what features are needed to define a release.

  4. Software Engineering Process Map Development Cycle Release Cycle Planning Cycle • Velocity • Hours • Daily Stand-up • Estimate Effort • Scope Iteration

  5. A User Story defines a feature well enough to be coded and tested so we can ensure features are implemented. • Concentrate on Telling a Story about using the application. • Define WHO is acting in this story. (person, user role, application or service) • Define WHAT they are doing in a simple and clear way. • Define WHY they are doing it so everyone can keep the overall goals in mind and clear up and questions. • Use well written user stories to communicate what an application can do now that it couldn’t do before.

  6. A Trac Site provides a way to Create and Update a Release Plan to communicate development progress and facilitate Hand-Offs • Create a Trac Milestone for each Release • Create a Trac Wiki Page to list the User Stories using the Development Plan Template. • Link the Release Wiki Page to the Roadmap. • Planners and Developers work together to create User Stories. • Developers add Tasks to User Stories and estimate their complexity.

  7. Lets Look at a Trac Site and Release Plan The dWranglerTrac Site

  8. Bad User Stories are Bad • Fail to communicate needs in a way that someone can address. • Often unclear what is trying to be accomplished. • Don’t conveying in any meaningful way what an application can do now that it couldn’t do before. • Are Difficult to Test. • Lack clarity on why this feature is important.

  9. User Story Examples • Good User Stories (or at least not so bad) • (Rushdie) Researchers can search and browse Rushdie emails via the web search interface. • (GHC) User can browse each chronicle by content type, people, country, and date. • (dWrangler) Project Editors can import Ticket Information from a Trac Site to track development progress and display trends in project planning. • (ETD) CST author can login to ETD site and successfully create and submit a record. • Bad User Stories • (DigWf) Fedora-Commons Ingest • (DifWf) User is able to call the getItemsapi function twice in a row using the refresh button without getting an empty results on the second call. • (Rushdie) Researchers have easy access to digital help documents in Researcher Workstation environment. • (ETD) Researchers can cite ETD records using bibliographic services like Zotero.

  10. Communication

  11. Common Problems • Not Planning or Planning at the last minute. • Not create good User Stories. • No support plan after handoff or not accepting responsibility across the organization. • Incomplete plans and revisiting issues.

  12. Questions?

More Related