Docstoc

Agile 2006 - 4TAU

Document Sample
Agile 2006 - 4TAU Powered By Docstoc
					Agile 2006
                              ?‫אז מה היה לנו‬

   Introductory Lectures
   Tracks:
       Hands-on
       Discovery Sessions
       Tutorials
       Research Papers
       Experience Reports
       Educators Symposium
   Evening events
Scrum
           Scrum is an agile
            process to manage and
            control development
            work
           Scrum is a wrapper for
            existing engineering
            practices
           Scrum is scalable from
            single projects to entire
            organizations (with
            over a thousand
            developers and
            implementers)
Scrum
   An iterative, incremental process for developing any
    product or managing any work (yep, just like XP)
What Is Agile Software Development?
   2001: Manifesto for Agile Software Development:
       Individuals and interactions over processes and tools
       Working software over comprehensive documentation
       Customer collaboration over contract negotiation
       Responding to change over following a plan
   Principles:
       Satisfy the customer through early and continuous delivery of
        valuable software
       Welcome changing requirements
       And much more… (http://www.agilemanifesto.org/)

Kent Beck                                         Jon Kern
Mike Beedle                Martin Fowler          Brian Marick
Arie van Bennekum          James Grenning         Robert C. Martin
Alistair Cockburn          Jim Highsmith          Steve Mellor
Ward Cunningham            Andrew Hunt            Ken Schwaber
Dave Thomas                Ron Jeffries           Jeff Sutherland
Research Papers
http://agile2006.com/program/Program
1.    AgileEVM – Earned Value Management in Scrum Projects
2.    Earned Value and Agile Reporting
3.    An Empirical Study of Using Planning Poker for User Story
      Estimation
4.    Executable Acceptance Tests for Communicating Business
      Requirements: Customer Perspective
5.    On Agile Performance Requirements Specification and Testing
6.    Refactoring with Contracts
7.    The Role of Story Cards and the Wall in XP teams: a
      distributed cognition perspective
8.    A Case Study on the Impact of Customer Communication on
      Defects in Agile Software Development
9.    Reflections on Reflection in Agile Software Development
10.   Critical Personality Traits in Successful Pair Programming
11.   What Lessons Can the Agile Community Learn from a
      Maverick Fighter Pilot?
Research Papers
http://agile2006.com/program/Program
1.    AgileEVM – Earned Value Management in Scrum Projects
2.    Earned Value and Agile Reporting
3.    An Empirical Study of Using Planning Poker for User Story
      Estimation
4.    Executable Acceptance Tests for Communicating Business
      Requirements: Customer Perspective
5.    On Agile Performance Requirements Specification and Testing
6.    Refactoring with Contracts
7.    The Role of Story Cards and the Wall in XP teams: a
      distributed cognition perspective
8.    A Case Study on the Impact of Customer Communication on
      Defects in Agile Software Development
9.    Reflections on Reflection in Agile Software Development
10.   Critical Personality Traits in Successful Pair Programming
11.   What Lessons Can the Agile Community Learn from a
      Maverick Fighter Pilot?
RP: Reflections on Reflection in Agile
Software Development
Reflections on Reflection in Agile
Software Development
   This paper analyzes the reflections of an agile team,
    developing a large-scale project in an industry setting
   The team uses an Iteration Summary Meeting practice,
    which includes four elements:
       The customer‘s summary
       Formal presentation of the system
       Review of metrics
       Reflection
   The proposed practice supports tracking past decisions
   It also incurs a lower overhead than existing alternative
    reflection practices (only 2.1% of the team's time, in
    contrast to 3.7% or 4.7% in other cases)
Reflections

   Reflection is the process according to which an
    individual (or a group) examines his/her/its actions
    during the accomplishment of the action or after it
   Reflective mode of thinking may improve the
    application of some of the XP practices:
       When a pair is engaged in a pair programming session, the
        navigator reflects on the drivers‘ coding
Research Settings
   The project is a business-critical enterprise
    information system, considered to be highly
    complex and intended for a large and varied
    user population.
   The agile software development method used
    in the project is based on Extreme
    Programming [2], with a few adaptations in
    line with the agile approach that were dictated
    by the project's size and the organization
   Regular reflection meetings and formal 2 weeks iteration
    summary meetings were conducted.
   Development team averaged 15 developers during this
    period
Research Method

   The main research method used in this paper is
    personal reflection of team members on the
    reflection
   Discuss a specific problem in the process
   Analyze, via written questionnaires, several months
    after the reflections in question took place
Agile Reflection Technique
   Only one specific problem is       Team members are
    discussed at each reflection        encouraged to speak their
    meeting                             own opinions
   The discussed problem should       The moderator records
    relate to the development           important insights and
    process, not the developed          proposed action items that
    product                             surface during the meeting
   The subject is chosen in           The moderator summarizes
    advance by the moderator            the meeting
   The reflection cannot exceed       The decided action items
    one hour                            are effective immediately
   The whole team is required to      The moderator publishes
    attend the reflection               the main insights and
   The reflection may be an open       action items to the teams
    discussion, or use some             soon after the reflection
    structured problem solving
    technique
Results
Reflections on the technique
of the reflection meeting
xUnit Test Patterns
            Improving Test Code and Testability
             Through Refactoring
            Expect to have just as much test code as
             production code!
            The Challenge: How To Prevent
             Doubling Cost of Software Maintenance?
A Recipe for Success
   Write some (easy) tests
   Note the Test Smells that show up
       Code Smells – Visible Problems in Test Code
       Behavior Smells – Tests Behaving Badly
       Project Smells – Testing-related problems visible to a
        Project Manager
   Refactor to remove obvious Test Smells
       Apply appropriate xUnit Test Patterns
   Write some more (complex) tests
   Repeat from Step 2 until:
       All necessary tests written
       No smells remain
Common Code Smells
   Conditional Test Logic
       Tests containing conditional logic (IF statements or loops)
       Hard to verify correctness. Does it always test the same
        thing?
       A cause of Buggy Tests (Project Smell)
   Hard to Test Code
   Obscure Test
   Test Code Duplication
   Test Logic in Production
Patterns
   Expected Objects
       Use AssertEquals on whole objects rather than comparing
        individual fields
   Guard Assertions
       Remove conditional logic associated with avoiding assertions
        when they would fail
   Custom Asserts
       Remove Test Duplication by factoring out common code
       Remove conditional logic associated with complex verification logic
   Test Doubles
       Test Stubs return test-specific values
       Mock Objects also verify method calls and arguments
       Fake Objects provide same services in a ―lighter‖ way
   Teardown
       Transaction Rollback
Common Behavior Smells
   Slow Tests
   Erratic Tests
       Interacting Tests:
        When one test fails, a bunch of other tests fail for no
        apparent reason because they depend on other tests‘ side
        effects
       Unrepeatable Tests:
        Tests can‘t be run repeatedly without intervention
   Fragile Tests
       The 4 sensitivities
   Assertion Roulette
   Frequent Debugging
   Manual Intervention
Patterns
   Shared Fixture
   Fresh Fixture
   Standard Fixture
   Minimal Fixture
   Lazy Setup
   Setup Decorator
   SuiteFixture Setup
Common Project Smells

   Developers Not Writing Tests
       Symptoms: No tests can be found when you ask to see:
           Unit tests for a task
           Customer tests for a User Story
   Buggy Tests
   Production Bugs
       Symptoms: Bugs are being found in production
   High Test Maintenance Cost
Refactoring Databases

   A database refactoring is a simple change to a database
    schema that improves its design while retaining both its
    behavioral and informational semantics
   A database schema includes both
    structural aspects such as table and
    view definitions as well as functional
    aspects such as stored procedures and
    triggers
   Important: Database refactorings are a
    subset of schema transformations, but
    they do not add functionality
Rename Column
The Process
                                                                   Deprecate the
          Verify that a               Choose the
                                                                      Original
         refactoring is                  Right
                                                                      Schema
            needed                    Refactoring
                                                                     (optional)

                [Not
                Needed]
                                             [Pass]


                                                                      Write a
                                     Run the tests
                                                                     Unit Test


                                            [Fail]




                                        Migrate                Update External
                      Change your
                                         Data                     Access
                        schema
                                       (optional)                Programs




                                                      [Fail]

                                     Run the tests    [Work
                                                      continues]

                                            [Finished]



                                      Announce
                                    The Refactoring




                                       Version
                                     Control Your
                                        Work
Other Database Refactorings
   Merge Columns                  Migrate Method From
                                    Database
   Add CRUD Methods
                                   Migrate Method to Database
   Add Mirror Table
                                   Move Column
   Apply Standard Codes
                                   Move Data
   Consolidate Key Strategy
                                   Parameterize Method
   Drop Column Constraint
                                   Rename Table
   Drop View
                                   Replace Column
   Introduce Calculated
    Column                         Replace One-To-Many With
                                    Associative Table
   Introduce Common Format
                                   Split Table
   Introduce Read-Only Table
                                   Substitute Algorithm
   Introduce Variable
                                   Use Official Data Source



      Database Refactoring Plug-In: www.eclipse.org/epf
Philosophies of Agile Data Method
   Data is one of several important aspects of software-
    based systems
   Enterprise issues should considered and acted upon
    by the development teams
   Enterprise Groups exist to nurture enterprise assets
    and to support other groups, such as development
    teams, within organization. These enterprise groups
    should act in an agile manner
   Unique situation for every project. One software
    process does not fit all and therefore the relative
    importance of data varies based on the nature of the
    problem being addressed.
   Work together
   Sweet spot. You should actively strive to find the path
    that works best for your overall situation.
Exploratory Testing
   Exploratory testing is simultaneous
    learning, test design, and test execution
   Learning Focus
       Testing a new product
       Improving your model of product by investigating its
        elements
       Using and operating a product, and searching for bugs
        while also searching for new testing ideas
       Scanning or mapping a delivered artifact with focus on
        potential exploitation, unexpected interaction, or
        emergent behavior)
       Interacting with a product to test your model of it
Contrasting Approaches

Scripted Testing                 Exploratory Testing
   Is directed from elsewhere      Is directed from within
   Is determined in advance        Is determined in the moment
   Is about confirmation           Is about investigation
   Is about controlled tests       Is about improving test
   Emphasizes predictability        design
   Emphasizes decidability         Emphasizes adaptability
   Like making a speech            Emphasizes learning
   Like playing from a score       Like having a conversation
                                    Like playing in a jam session
Coaching

   Coach – a team advocate, a person who helps a team produce
    a desired effect
       Coaches aid change and provoke change
       Coaching has ethical responsibilities
   All coaching relies on some model of human behavior
   The job of a coach is to find
    teachable moments, and
    help team members release
    the tension productively
Research Papers
http://agile2006.com/program/Program
1.    AgileEVM – Earned Value Management in Scrum Projects
2.    Earned Value and Agile Reporting
3.    An Empirical Study of Using Planning Poker for User Story
      Estimation
4.    Executable Acceptance Tests for Communicating Business
      Requirements: Customer Perspective
5.    On Agile Performance Requirements Specification and Testing
6.    Refactoring with Contracts
7.    The Role of Story Cards and the Wall in XP teams: a
      distributed cognition perspective
8.    A Case Study on the Impact of Customer Communication on
      Defects in Agile Software Development
9.    Reflections on Reflection in Agile Software Development
10.   Critical Personality Traits in Successful Pair Programming
11.   What Lessons Can the Agile Community Learn from a
      Maverick Fighter Pilot?
Coaching Techniques
   Conflict Identification       Name It
   Go Sideways                   The ‗Flounce‘
   Go Home                       Team Surgery
   ‗Antennae Up‘                 Push in the Water
   Pair Coaching                 Self-disintermediation
   Ask the Room                  Cheerleading
   Make It Physical              Cultivate Respect
   Active Listening
   Advance/Retreat
   Personal Encouragement /
    Discouragement
What does it really mean for a software
development organization to be agile?
   ―It may say agile on the box, but it doesn‘t feel agile‖
       Not every ―agile‖ project is agile
       Not every ―plan driven‖ project is not agile
   US Air Force Colonel John Boyd:
       To win in a competitive environment we ―must operate at a
        faster tempo or rhythm than our adversaries‖
       He defined agility as the ability to operate the Observation-
        Orientation-Decision-Action (OODA) loop faster than an
        adversary
     Observe          Orient          Decide            Act


     Unfolding
  Circumstances          Cultural
                        Traditions


                  Genetic       Analyses &
                  Heritage      Synthesis        Decision     Action
  Observations                                 (Hypothesis)   (Test)


                      New        Previous
                  Information   Experience



  Outside
Information



Agility: Execute your OODA loop more quickly than your adversary
Agility is a Cultural Phenomenon
   Blitzkrieg‘s principles:
       Trust: people feel safe taking the initiative rather than
        worrying how to justify their actions
       Skill and experience: enable people to clearly observe their
        environment and develop creative solutions
       Intent: opens the opportunity for people to take the initiative
       Vision: gives people direction, in those situations where no
        firm guidance has been given
   People, ideas, technology…in that order!
       Agility depends on the tempo at which we can exploit the
        OODA loop, and it is culture, not methodologies or tools that
        determine our OODA loop speed
   Agility‘s cultural dependency explains why a project
    using an agile methodology may not feel agile, and
    why a so called plan driven project may feel agile
Does a theory of competition apply to
software development?
   Yes!
     Uncertainty can have the same disorienting effect on a
      team as an explicit adversary
     The OODA loop is about getting into a position of
      advantage in an uncertain environment
     The OODA model is about groups of people working
      harmoniously together to accomplish a common purpose -
      even though everything is collapsing around them
     Our organization‘s objective is to survive on its own terms

     Software development is commerce and commerce is
      about competition
Implications of the OODA loop for
the Agile community
1.   Agility is a time based strategy for operational
     success and is not based on size
2.   Agility is a relative concept, not an absolute
     concept
3.   Agility is an essential attribute for project success,
     large or small
4.   Agility depends on organizational culture (unity,
     trust, intent, focus)
5.   We are late to the party
Research Opportunities

   Good team culture quickens the decision cycle. The
    principles of the Blitzkrieg —mutual trust, skill, intent,
    and vision — describe the necessary talents for an agile
    organization
   Unfortunately, these are generally not talents that
    emerge spontaneously in an organization
   Cockpit Resource Management
   Could we design a similar program for software
    developers? (Developer Resource Management
    Program, perhaps)
   Implications for software engineering education?
The End

				
DOCUMENT INFO