Online Mind Mapping and Brainstorming

Create your own awesome maps

Online Mind Mapping and Brainstorming

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account? Log In

Agile Engineering by Mind Map: Agile Engineering
5.0 stars - 6 reviews range from 0 to 5

Agile Engineering


Mike Cohn - author on Scrum topics

Scrum Meeting

Questions, What has happened relative to the backlog since the last meeting, What obstacles got in the way of completing this work, What specific things do you plan to accomplish, relative to the backlog, between now and the next scrum

Time, Scrum should last 15 to 30 minutes

No extra work - anything extra should be arranged in another meeting

Scrum master - responsible for removing any obstacles to progress

Goals, focus effort on backlog, communicate priorities of backlog to team, keep everyone informed of progress and obstacles, remove obstacles quickly, track progress delivering backlog functionality, addressing and minimising project risk

Planning proceeds quickly because initial assumptions change as sprints deliver incremental functionality


Advantages, Product becomes a series of manageable chunks

Sprint planning, Team meets with the client/client representative and decides what can be achieved in the current sprint, Product owner gets a last chance to revise priorities, Once decided, the backlog is locked down until the next sprint, Decide acceptance tests, Team has sprint planning meeting - decides tasks for the sprint backlog, tasks can be no more than 16 hours in duration, Maintain sprint backlog detailing, responsibility, duration, hours remaining on tasks for each day of the sprint, status of the task


Refactoring is a way of changing a software system so that the external behaviour is not affected but the internal structure is improved

Constant process

Improve quality of the code

Remove dead code

Make code self describing, Code as it should have been written first time

Not about, Fixing bugs, Visible action - everything should stay the same

Aim to make changes that do not impact anyone else, Programmer should only change the code they have created

Complicated and nested structures are a good indicator of the need to refactor


Extract Class

Extract method

Extract interface

Move class

Move method

Move field

Rename variable

Looking for

Code Smells, Number of classes, Message chain, Duplicate code, Remove whenever possible, Large class, Too many responsibilities?, Long method, Too many responsibilities, difficult to maintain..., Long parameter list, Lots of parameters means more complex, Dead code

Programs that are hard to read

Programs that have a lot of duplicated logic

Programs with complex conditional code

Poor designs

Refactoring tasks

Generalising classes

Specialising classes

Improving encapsulation

Lowering impact of change

Merging subclasses into fields

Extracting fields into subclasses

Implementing interfaces

Adding abstract classes


Having a comprehensive set of tests ensures that refactored code behaves identically to previous code


Aim for a reasonable design rather than the best design, Ok to make changes

Agile Testing

Test Driven Development

Acceptance Test Driven Development

Behaviour Driven Development

Unit Testing

Test names should be descriptive

One test for each requirement

Write simplest code to make the test pass

If a test is too large, break it down

Test goal of code, not implementation

@setup and @teardown

Types of Testing

TDD (Test-Driven Development)

ATDD (Acceptance Test Driven Development), Ensure that the customer has an automated mechanism to decide if the software meets the acceptance test criteria, Keeps development team focused on what is required to complete the user story

BDD (Behaviour Driven Development), Create automated tests to look for the behaviour of the system, Framework such as JBehave, Establishes the prerequisites, Scenario, Given (Certain facts), When (Something occurs), Then (Carry out some action), Allows client to see if the software works as identified, Output shows in english statements that the system is working (or not)

Agile Testing: Past, Present and Future

Paper is a review of the literature on agile testing

Types of Paper Identified, Solution, novel solution, only proof of concept, Validation, further investigates a solution, no practice, Philosophical, new framework for understanding a field, Opinion, Author's personal opinions, Experience, Describes author's experience on a project, Evaluation, investigation of a problem in practice

Agile Metrics

How can code quality be defined?

Observation and Measurement

Code coverage

Measurement should be valid and reliable

Code Metrics

WMC - sum of all complexity measures of the methods, Number of methods per class if all of the complexities are equal to one, Predict time and effort needed to maintain the class, Use cyclomatic complexity of the method, correlation between cyclomatic complexity and error frequency, Number of linearly independent paths through given code

DIT - Depth of inheritance tree maximum path from the node to the root of the inheritance tree, Deep tree- complex design, less comprehensible greater potential re-use of methods

NOC - Number of children in inheritance tree, More children more reuse but less maintainable, More children class is influential, may need more testing

CBO - Coupling between objects, The number of other classes to which a class is coupled, Low coupling - more independence of classes, easier to reuse; less sensitivity to changes, greater maintainability

RFC - Response for class, Number of local methods called by local methods plus the number of local methods, High RFC = complex class, complex testing and debugging

LCOM - Lack of cohesion in methods, Number of non-intersecting sets of local methods, lack of cohesion, Better to split classes into subclasses, Complexity - classes trying to achieve different objectives

Agile metrics

Hartmann and Dymond, Goal: Maximise business value delivered, Questions: rate of return on investment, Metric: Cash flow per iteration, A good agile metric, Affirms and reinforces Lean and Agile principles, Supports customer intimate and value focused traits of agile., Measures outcome not output, Outcomes measured in terms of value delivered to the customer, Follows trends, not numbers, Belongs to a small set of metrics and diagnostics, Is easy to collect, Reveals rather than conceals its context and significant variables, Provides fuel for meaningful conversation, Provides feedback on a frequent and regular basis, May measure Value or Process, Encourages good-enough quality, Useful Diagnostics, Velocity, How much software is delivered per iteration, Over longer projects this will become stable, Useful at the project level, Velocity is not the same as value, Obstacles cleared per iteration, Team member loading, User stories carried over, Unit tests per story, Builds per iteration, On time delivery, Defects carried into next iteration, Diagnostics are helpful to measure the success of the agile process, Suggested Key Metrics (S McHugh), Business Value Delivered, Basis - net cash flow per iteration, On time delivery

Watch effects, Observer effect, If an individual developer is being monitored (individual velocity) this may have an impact on the individual's output, Street light effect, Tendency to look for answers in the obvious place, need to look for answers in the not so obvious places., Counting lines of code is easy but doesn't say where the bad code is.

Pair Programming


Some well respected programmers prefer

Seasoned pair programmers describe it as working twice and fast

Resulting code is simpler and easier to extend

Even relative novices contribute to an expert's programming

Costs and benefits paper

Continual design and code review more efficient defect removal rates

Solve impossible problems faster

Pair programmers learn a lot from each other

Learn to discuss and work together, improves team cohesiveness.

Multiple people familiar with same code, reduces staff-loss risk.

Satisfaction, Takes time for a solitary programmer to move out of comfort zone, Comforting to know that know major mistakes are being made

Design Quality, Superior quality from pair programmers, Same functionality in fewer lines of code, Better designs

Continuous reviews, Code inspections not enjoyable or satisfying, Not done unless mandated, Advantages, Mistakes are found as entered, Peer pressure means code standards followed closely, Team members learn to talk together and work together

Learning, Expert in earshot, Line of sight apprenticeship


Programming is taught as a solitary activity

Programmers viewed as a scarce resource, duplication on same task is waste

Many experienced programmers are reluctant to program with other, Code is 'personal', Another person will slow them down, Trouble coordinating work times or code versions

May take 15% longer to develop code but made up for by fewer defects

Some programmers are 'loners' who prefer to work on their own, Not one advocates for 'loners', Loners still interact with other team members

Sprint Review/Retrospective

Sprint Review

Scrum team shows what they have achieved during the current sprint

Must be kept informal

No PowerPoint

Natural result of the sprint

Participants, Product Owner, Scrum team, Scrum master

Project assessed against the goals established at the sprint planning meeting, Ideally the team has completed all items in the sprint backlog, More important to achieve the overall aim of the sprint

Sprint Retrospective

Meeting held to reflect on the sprint just done

Should happen after the sprint review

Aims, Discuss how to make things better, Improve process quality, Improve product quality

Helps to improve team's learning and work satisfaction

Procedure, Decide what went well (what to do the same), Decide what did not go well (what not to do again), Create a list of actions to take forward into the next sprint, KJ Method, Write positive and negatives onto cards, Group the cards onto a pin-board, Collect suggestions for improvement, Create a list of actions to take forward into the next sprint

Agile Planning

User Stories

User story structure

Acceptance tests

Lightweight, just-in-time requirements

Card, Conversation, Confirmation

The Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Works in short iterations

Focus on the business priorities, Priorities may change, but must be stable during each sprint so the team has a goal

Inspect and adapt

Ethical and Moral Responsibility

Software Engineers have a duty to


Client and Employer







BSC Code of Conduct

Public Interest, Have regard for privacy, wellbeing of others, have due regard to legitimate rights of 3rd parties, conduct professional activities without regard to personal differences, promote equal access to the benefits of IT

Professional Competence and Integrity, Don't claim competence you don't possess, Develop professional knowledge and skills, Knowledge and understanding of legislation, Respect and value alternative viewpoints, avoid injuring others, reject bribery

Duty to Relevant Authority, Avoid conflicts of interest, Accept professional responsibility for your work and for colleagues under your supervision, Do not disclose any confidential information without prior agreement, Do not withhold information on the performance of products systems or services or take advantage of lack of knowledge or inexperience of others

Duty to the Profession

Continuous Integration

Advantages of CI

Build automation

Single source repository

Everyone commits to the master every day

Keep the build fast

Test in a clone of build environment

Automate deployment

Everyone can see what's happening

Traditional Approach

Team manually create a test build

Test build may be sent to testing team

Unit testing may speed up the process

Drawbacks, Most recent reliable build may be quite old, May be significant integration bugs, Some libraries or components may have external dependencies, Changes to external components may have to be factored in, Unexpected problems may be encountered when code is run on a different machine for the first time

Requirements for CI

Unit Tested Code, Configuration management Server, Monitor for changes in project files, Execute the build script for the project, Log the results of the build on a web page and/or e-mail to developers, Build log shows all details of build process, All unit tests are run during build, CI Software, Build Server, Build script, Obtains and builds the software, Apache ANT etc, Retrieve all changes from the build server

Configuration Management

Aims - to manage all project files with versioning

Identification control

Change control

Status and audit information

Record and report upon status, Audit information, Verify completeness and correctness, Does item conform to technical documentation, Is the standard process being followed in the way we said it was, statistics, request for change, track problems

Change Control, Current status of component, Releases, A release is a version intended for external people/customers, Release record should be maintained, Manage configurations for different, Hardware platforms, Software platforms, Documentation, Who can make changes, Forms (very formal), Developers (via Github or some other), Storage control, Development library, Master library, Static library