QA: Agile ICONIX

Agile Development ICONIX

 

  1.  

 

 

 

  • Goals of Agility

  • Respond to changing requirements in a robust and timely manner.

  • Improve the design and architecture of a project without massively impacting its schedule.

  • Give customers exactly what they want from a project for the dollars they have to invest.

  • Do all this without burning out your staff to get the job done.

  • Responsive v.s. Robust

    • Smarter practices to reduce risk instead of more effort

  • Safety nets

    • unit tests

    • Customer acceptance tests

    • design documents

    • defect tracking software

    • requirements traceability matrices

  • Vortex principles

    • The tighter knit ( or dense ) something is its angular velocity increases

    • tight knit groups work faster, more efficiently with less time spent on human issues

  • Design right up front

    • UML designs

    • refactoring immediately saves much time later

 

  1. What makes a project Agile?

  • Tuning process as you go

  • Keeping it low ceremony

  • Enhancing through good design

    • Instead, designing for change (also known as defensive programming) means following sound, object-oriented (OO) design principles, the following in particular:

    • Keep the code in a highly modular state. Make sure each class has just one responsibility, and that it handles that responsibility well. Also, make sure each method performs just one task (e.g., by delegating to other methods).

    • Keep your classes highly cohesive and loosely coupled. Make sure everything in each class fits well and is there to fulfill the reason for the class’s existence. Try to reduce the number of dependencies between classes.

    • Don’t overcomment your code. Any code that you have control over should be made self-explanatory (see the next point), reducing the need for comments. The exception is with calls to library code that you have no control over; often, some deftly placed comments can help a lot here.

    • Use method names that describe the method’s purpose, not how the method achieves that purpose. For example, instead of calling a method addToList(String str), call it addToCatalog(String productID).

    • Use class names that are closer to the problem domain than the implementation details. We’ll explore this in more detail when we talk about domain models in Chapter 3.

    • Don’t overcommit. That is, don’t use a concrete type where a more abstract type would suffice. For example, if you’ve declared a return type as a java.util.ArrayList, you might find it’s better to declare the return type as a Collection interface instead. And speaking of interfaces…

    • Use interfaces as return types and parameter types wherever possible.

  • Improving communication and teamwork

  • Reducing exposure to forces of change

  • Measuring progress with working software

    • Customer Acceptance tests prove software is working as needed – success!

  • Agile Planning

    • Adaptive Planning – planning ahead, tracking changes, adapting plan as needed

    • Planning for Agility – anticipating and controlling change

    • Consists of

      • Short sprints of 1-2 weeks for feature sets

      • Time Boxing – variable amount of features WILL be delivered

      • tracking velocity – speed of WORKING feature delivery

 

  • Managing Change

  • Delivering the System That the Customer Wants at the End of the Project, Not What He Thought He Wanted at the Start

 

 

  1. Challenges of Being Agile

  • Sticking to the path

  • Keeping Releases Short

  • Keeping Entropy at bay

    • look ahead even though focus is short term

    • Program for change

  • Doing less without Increasing Risk

  • Discovering your true master

  • Keeping the customer involved

  • managing change

  • Training

  • Avoiding the other extreme

  • Facing resistance to change

 

  1. What's in a software development process?

  •  

  •  

  •  

 

 

Deformat:

 

  •  

Tags

Copyright 2018· All rights reserved