Agile Practices

1. Short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.
2. Defer details and capture them through discussion just in time for development
3. Captured by team members, product owners, scrum master and users
4. Usually in the format of Role-Feature-Reason
5. Why?
   1. Useful for planning work
   2. Focus on delivering value to stakeholders
   3. Eliminate waste effort by just-in-time elaboration
   4. Vehicle to add features in iterative development
   5. Bill Wake

      Anmerkungen:

      • Bill Wake's invest model to write user stories 1. Independent 2. Negotiable 3. Valuable 4. Estimateable 5. Small 6. Testable
6. Non-Functional Requirements

   Anmerkungen:

   • e.g. Speed & availability
   1. Technical stories

      Anmerkungen:

      • e.g. The system will conform to corporate user interface guidelines
   2. are
      1. Cross-cutting
      2. Pertinent to many functional requirements (user stories)
      3. Typically maintained outside of the work item list
      4. Addressed throughout the entire project
      5. Often technical constraints on your solution
   3. Drive
      1. Development of acceptance or system tests

         Anmerkungen:

         • which validate that your solution conforms to those requirements
      2. Development of architectural aspects
      3. The definition of what it means to be done at the end of an iteration

Anmerkungen:

• Also called  Backlog Refinement or Story Time
• act of adding detail, estimates and order to items in the Product Backlog.  If this is not doen at Backlog Grooming meeting, the tasks will be done in a sprint planning meeting

1. Ongoing process conducted by the collaboration of the Product Owner and team members
2. Help make Sprint Planning Meeting more efficient and enhance quality through better understanding
3. Grooming usually time-boxed to 5-10% of the Development Team's capacity
4. Typically 3 days before Sprint Planning Meeting and on a weekly basis
5. Development Team is responsible for all estimates. Product Owner supports team by helping understand items and select trade-offs
6. Development Team is responsible for all estimates. Product Owner supports team by helping understand items and select trade-offs
7. How grooming is performed is determined by the Scrum Team
8. Ideally discuss 2 sprints worth of backlog items
9. 3 common ways to add details
   1. Create graphics and/or text to describe a user story
   2. Break up a complex user story into a few simple user stories
   3. Identify Acceptance Criteria for a user story

Anmerkungen:

• prioritised user stories / features will be added to product backlog.
• product backlog will also contain technical tasks, defects to be fixed, and knowledge acquisitions tasks.

1. Product Owner

   Anmerkungen:

   • Prioritisation is performed by the product owner, who balances the needs of all stakeholders, not just users.
2. Team Member

   Anmerkungen:

   • suggest priorities but must be able to explain the reasoning and trade-offs invoved
3. done at:
   1. when creating the initial user stories / features that define initial scope of the backlog
   2. Sprint Planning meeting
   3. any time required by Stakeholders (decided by product owner)
4. Approaches
   1. Value-driven approach (core approach)

      Anmerkungen:

      • assign in-scope high-level requirements across all Sprints in priority oder by business value
   2. Risk - Value Driven Approach (disciplined approach)

      Anmerkungen:

      • Assign high-risk items, particularly architecturally significant requirements, to early iterations

1. Break into Tasks & Effort Estimate

Anmerkungen:

• A graph that shows the remaining units to complete that is measurable and will eventually become zero Scrum Master keeps track of the points completed and remaining in each and plot them in charts and put up on a whiteboard

1. Iteration burndown

   Anmerkungen:

   • estimated effort hours remaining in the iteration
2. Release burndown

   Anmerkungen:

   • estimated functionality yet to be built for the release
3. Product burndown

   Anmerkungen:

   • estimated functionality yet to be built spanning multiple releases

Anmerkungen:

• process that makes progress through successive refinement. 

1. Sustainable pace

   Anmerkungen:

   • the rate of work that a team can consistently maintain without burning out team members
   1. Xp

      Anmerkungen:

      • popularised by the Extreme Programming (XP) methodology
   2. 40 hour work week

      Anmerkungen:

      • brief spurts of overtime are acceptable, but can't be sustained indefinitely.
      • reconise sustained overtimer as failure
   3. Strategies
      1. Acknowledge - you're still working productivly at sustainable pace
      2. Organise - the project into short iterations
      3. Avoid mini-waterfalls
      4. Adopt a continuous integration strategy
      5. Collaborate frequently with team membrs
2. Iterations & Incremental Development
   1. Incremental process

      Anmerkungen:

      • process which software is built and delivered in pieces.  Each piece, or increment, represents a complete subset of functionality.  The increment ma be either small or large, perhaps ranging from just a system's login screen on the small end, to a highly flexible se of data management screens
   2. Iteration process

      Anmerkungen:

      • An iterative process is one that makes progress through successive refinement.  A development team takes a first cut at a system, knowing it is incomplete or weak in some (perhaps many) areas.  The team then iteratively refines those areas until the product is satisfactory.  With each iteration the software is improved through the addition of greater detail

Anmerkungen:

• Practice of merging all developer working copies with a shared mainline sereval times a day. was first named and proposed as part of Extreme Programming
• The practice involves team members integrate their work frequently, usually each person integrates at least daily leading to multiple integrations per day.  Version Control to repository and continuous build tools are used for integration the code nd build, and then automated tests are run to get immediate feedback on integration problems.
• Key benefits: identify integration problems early andaddress them before they build up to more complex problems, or integration Hell as described by XP

Anmerkungen:

• The practice of dveloping a functionality by writing unit tests before the code is written.  By default, it requires tests to be automated.

1. Add a Test

   Anmerkungen:

   • To start developing new functionality, write a test for the new functionality and then add the test to the list of existing tests.
   • To write a test, the developer must clearly understand the feature's specification and requirements.  They come from User Stories and related discussions
2. Run all Tests

   Anmerkungen:

   • The newly added tests should fail because no code has been written to fulfill the feature yet. This gives you some confidence that the test is working
3. Wrte More Code

   Anmerkungen:

   • Write just enough code to pass all the failed tests.  It is ok if the code is not elegant at this stage
   1. Run all Tests Again

      Anmerkungen:

      • Test your new code.  Note that is also tests whether your new code breaks old functionalities.  If the tests failed, writes code to pass it
   2. Pair Programming

      Anmerkungen:

      • The concept comes from Extreme Programming (XP).  2 or more developers work on the same piece of code together - typyically one watching over the shoulder of the other for a period of time and then switch
      1. Benefits
         1. Enhanced quality

            Anmerkungen:

            • The pair or group checks the artifact for quality
         2. Redused Cost of Development

            Anmerkungen:

            • Inconsistencies and bugs are caught early in the cycle
         3. Knowledge sharing

            Anmerkungen:

            • Domain knowledge and development techniques are shared among individuals (pair or group).
      2. POtential barriers
         1. Work in pairs

            Anmerkungen:

            • Some ppl might not be comfortable or feel intimidated working in pairs
         2. Culture / habits

            Anmerkungen:

            • Some cultural aspects  personal habits can be obstacles to pairing
4. Refactor Code
   1. Refactoring

      Anmerkungen:

      • Simple change to your source that improves the design without changing its semantics
      • by refactoring you can evolve your development assets in a controlled manner, maintain the high quality of your design.
      1. Code Refactoring

         Anmerkungen:

         • A small change to your code to improve your design that retain the behavioural semantics of your code.
         • eg Rename a method, move a method, remove a setting method
      2. Database Refactoring

         Anmerkungen:

         • Simple change to a database schema that improves its design while retaining both its behaviour and informational semantics eg Move a column, rename a table, replace a blob with a table
      3. User Interface Refactoring

         Anmerkungen:

         • A simple change to the user interface that improves the design without changing the semantics of the function that is provided to the user. e.g. Align widgets, standardise formats, move a widget