AGILE IN ONE WORD Agile=Adaptive AGILE IN ONE SENTENCE • Agile development is iterative and incremental AGILE MANIFESTO • Individual and interactions over Processes and tools • Working Software over Comprehensive documentation • Customer Collaboration vs Contract Negotiation • Responding to a change to Following a plan COMMON CHARACTERISTICS OF AGILE METHODOLOGIES • • • • • • • •
Iterative Development Working List/Features/Product One Small Feature at a time Sustainable pace Cross Functional Self Organizational Team Automated Testing and builds Embracing Change Inspect and Adapt
EXTREME PROGRAMMING • XP is programming-centric model that focus on the ongoing rapid delivery of small release of software • Interval between software release is 30-180 days • iteration result is production ready code and iteration cycle is 1 to 4 weeks • Team set its own coding standard • XP has four key values – Communication, Simplicity, Feedback and Courage • XP has 13 principles • Unit code can written even before code is written • Planning game simplifies both release and iteration planning • Simplicity means develop the product defined in user story rather than to add extra or additional functionalities which may not be used • Collective code ownership • Shared work spaced-Generalized teams • Sustainable pace- not more than 40 hrs per week XP PRINCIPLES 1. 2. 3. 4. 5. 6. 7.
Planning Game Small Releases Metaphor Simple Design Testing Refactoring Pair Programming
8. Collective Code Ownership 9. Continuous Integration: 10. Sustainable Pace: 11. Whole Team 12. Coding Standards 13. Onsite Customer
XP ROLES 1. Customers : create and provide us ongoing feedback 2. Development coach : monitor development praises 3. Business Coach : represent and guide customer 4. Developer : plan writes and fact code CUS 5. Business Analytic : 6. System Engineer : SME of XP development term 7. Tracker 8. Tester : acceptance test
9. Big Boss : assembly XP terms, look after workshops 10. XP focuses on programming practices SCRUM SCRUM is an Agile Project Management framework SCRUM emphasis on management process empirical control SCRUM is based on short daily meeting SCRUM heart is SPRINT which has 2 -4 weeks duration SCRUM Empirical PROCESS Transparency • Visible process • Definition of done Inspection • Skilled inspector • Designated time Adaption Four formal opportunities for inspection and adaption • Sprint planning meeting • Daily scrum • Sprint review meeting • Sprint retrospective SCRUM consist of scrum team and their associated Roles: development team, SM, PO Event: sponsor, design Sprint review Artifacts: product backlog, sprint backlog Rules: bind together the roles, events and artifacts SCRUM TEAM Scrum team consist of Product Owner, SCRUM Master, Development Team
Product Owner is responsible for managing the product backlog Product Owner is one person Development Team is 3-9 excluding PO and SM SCRUM MASTER SM job is to make sure SCRUM is understood and enacted SPRINT CONTAINS AND CONSIST OF • Sprint planning meeting • Daily scrum • Development work • Sprint review meeting • Sprint retrospective Only PO can cancel the sprint Sprint planning meeting 8 hrs- for 1 month sprint TWO PARTS OF SPRINT PLANNING • What will be delivered in the increment • How will the closer work get done What will be delivered in Product Backlog • • •
Forecast functionality Order product functionality Understand the work item
Only development team will identify what they can achieve Scrum team craft scrum goal – why it is building How will the chosen work get done? Product Backlog item + plan for delivering them Sprint goal may be a milestone DAILY SCRUM • 15 minutes time boxed
•
Same time and same place each day to reduce complexity
Scrum master ensure them is a daily meeting Development team is responsible for conducting the dialogue Only Development team participates in the daily scrum SPRINT REVIEW SPRINT REVIEW- 4 hour for 1 month Scrum team and stakeholders Result of SPRINT is reviewed Discuss product Backlog item for the next sprint SPRINT RETROSPECTIVE SPRINT RESTROSPECTIVE – 3 hrs for 1 month Sprint SCRUM Team to inspect itself People, process, tools and relationships Identify the major steps that went well Sprint retrospective provides the dedication to event focused on inspection and adaption SCRUM ARTIFACTS:
Product backlog is a list of everything that might be needed in the product and is the single source of requirement for any changes to be made to the product. Product owner is responsible for its content, order, availability Product backlog is dynamic and exist as long as product exists. Product backlog lists all features, functions, requirements, enhancements and fixes that constitute the changes to be made to the product in future release. Product backlog items have the attributes of a description order and estimate.
Multiple scrum teams – one product backlog is used to describe the upcoming work on the product PRODUCT BACKLOG GROOMING:
Adding details, estimates and grooming is a part time activity during sprint Grooming consumes not more than 10% of the capacity Development team is responsible for estimates monitoring progress towards a goal At any point in time the total work remaining to reach a goal can be summed PO tracks this total work remaining at least for every sprint review. The PO compares this amount with work remaining Scrum does not consider the time spent working on product backlog item Remaining work and date are the only variable of interaction Burndown and Burnup and other practices have been used to forecast progress Only development team can change its sprint backlog during a sprint MONITORING SPRINT PROGRESS : Development team tracks this total work remain at least in daily scrum meeting INCREMENT: The increment is the sum of all the product backlog items completed during a sprint and all previous sprints At the end of a sprint the new increment must be done, which means it must be in useable condition
DEFINITION OF DONE Product backlog item or increment is described as done Development team defines the done criteria
LEAN • Lean is derived from Lean Production Processes • Lean Provides the guidelines for streaming the development methods • Lean focuses on Project Management rather than technical • Lean prefers the more cross-functional team approach Team provides guidelines for streamlining the development process Lean is based on 7 key principle 1. 2. 3. 4. 5. 6. 7.
Eliminate waste – unnecessary steps Promote and incorporate continuous - ongoing testing Delay decisions Deliver software as fast as possible Empower the programming team Build a focus on system integrity Focus on the whole system
Kan ban • Kan ban evolved from lean principle • Kan ban is a Japanese word with Card of board meaning • Kan ban is based on Pull method rather than push method • Kan ban doesn’t prescribe team roles • Kan ban doesn’t specify the duration of iteration • Kan ban uses a presentation board with User stories listed • Each user story should refer as Minimal Marketable Feature or MMF Kan ban CHARACTERISTICS: • Streamline workflow • Relies on self organizing team • Involves incremental development • Make it easy to measure lead time and track progress
Feature Driven Development : Perspective model for Agile development All aspects of software development are planned, managed and tracked Develop overall models FDD-SPECIFIC ROLES 1. 2. 3. 4. 5. 6. 7. 8. 9.
Project manager Chief architect Development manager Chief programmer Class owner Domain expert Tester Developer Technical writer
FDD teams use several specific tools to track and report progress • • • • •
Task list for each feature 2 milestone table for each feature A line graph showing completed features across a project end A feature set progress report Each feature has six milestones Domain walk through, design, design inspection code, code, code inspection
ASD- ADAPTIVE SOFTWARE DEVELOPMENT Jim Highsmith – complex adaption system • ASD is an organic theory and highly responsive • ASD is collaborative learning cycle Speculates, collaborate and learn Plan
Build
Learn
ASD Team comprised of AGENT: Team members and other stakeholder ENVIRONMENT: Including those that are organizational, technological and process EMERGET OUT COMES: results
NO HIERARCHY: independent agents PROJECT MANAGER: facilitates an ASD project Follow a pattern rather than process ASD model inputs can be expected or unexpected Organic management system
ASD LIFE CYCLE INCLUDES FIVE STEPS: PROJECT INITIATION involves speculation. At the outset of a project ADAPTIVE CYCLE PLANNING All team member, stakeholder, customer participates They establish a project is mission, objectives, constraints and key risks System requirement, estimate product size and scope CONCURRENT COMPONENT engineering team collaborate implement the work QUALITY REVIEW • Development cycle ends with learning obtained through quality reviews
• • •
Quality review includes feedback from end user who’ve tried using the developed software Quality review should also include inspection and end with postmortem Team brainstorm ideas for resolving any identified problems
FINAL QA AND RELEASE: The final QA and release phase occurs once at the end of a project KEY CHARACTERSTICS OF ASD:
• • • •
time boxed mission driven component based design to accommodate changes in each cycle
AUP- AGILE UNIFIED PROCESS • unified process is detailed framework for the iterative and incremental development of software • AUP simples UP, adapting it specifically for agile software development • AUP – four serial phases Inception, Elaboration, Construction, Transition INCEPTION: Initial scope potential architecture project finally and stakeholder of system ELABORATION: Improve team development based on highest priority needs of the customer CONSTRUCTION During construction the development of the system is completed TRANSITION: System testing is completed and software is deployed
AUP- Domains 1. Conceptual model of software - modeling 2. Building the software – implementation 3. Verifying and validity – testing 4. Implementation in product environment 5. Managing changes and implementing version control 6. Keeping a project on schedule and worth in budget 7. Ensuring resources and process are in place to facilitates development
AUP emphasis early development of workable system architecture CRYSTAL: • Crystal is a family of methodologies • Crystal methodologies vary based on size and complexity • of the project • Size is defined as number of people involved in the project • Criticality is defined as the potential for the system to cause Spike Functionality DYNAMIC SYSTEM DEVELOPMENT METHODOLOGY • Based on business perspective rather than technical • It is not recommended for safety critical system • Large number of artifacts and configuration PRIORITIZATION MCSCOW 9 KEY PRINCIPLES 1. Active user involvement 2. Empower team to deliver 3. Frequent delivery is key 4. Acceptance criteria for delivery is based on its fitness with business purpose 5. Iterative and incremental delivery 6. All Changes during the project lifecycle are reversible 7. Requirements are baselined at high level
8. Integrated testing during lifecycle 9. Collaboration and Cooperation between all
RELEASE • Primary purpose of release planning is better understanding of project’s visibility • Index cards are used by Agile teams for release planning ITERATION • Team forecasts to stories they can complete in iteration • Team works on prioritized stories • During iteration teams meats daily USERSTORY • Customer or User writes the User Story • User Story Contains functionality, conversations, and Acceptance Test Three C’s • User stories vetting criteria INVEST ( independent, Negotiable, Valuable, Estimable, Small, Testable) STORYPOINTS • Typically story point is one ideal day of work VELOCITY Velocity is a measure of team rate of progress per iteration TEST DRIVEN DEVELOPMENT • TDD is a design technique that emphasize of utilizing unit testing • Unit Test written before the code • TDD produces 100% coverage testing • TDD cycle is – Unit Test, Coding and Refactoring INFORMATION RADIATOR Displays information in a place where passerby can see it Information Radiator is used to report current work assignments, completed assignments, important dates, and people in the project OSMOTIC COMMUNICATION
Information exchanged by accident or due to team close sitting environment
BURNDOWN CHART • •
Burndown is used for tracking and forecasting the project progress Burndown charts are useful to track remaining amount of work
AGILE EVM • Agile EVM works forward and forecasts completion dates and final costs • Progress is measure at the release level functions COMPLIANCE Compliance Assurance in Agile team is the PMO Responsibility
