Agile Engineering

Get Started. It's Free
or sign up with your email address
Agile Engineering by Mind Map: Agile Engineering

1. Sprints/Scrum

1.1. Mike Cohn - author on Scrum topics

1.2. Scrum Meeting

1.2.1. Questions

1.2.1.1. What has happened relative to the backlog since the last meeting

1.2.1.2. What obstacles got in the way of completing this work

1.2.1.3. What specific things do you plan to accomplish, relative to the backlog, between now and the next scrum

1.2.2. Time

1.2.2.1. Scrum should last 15 to 30 minutes

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

1.2.4. Scrum master - responsible for removing any obstacles to progress

1.2.5. Goals

1.2.5.1. focus effort on backlog

1.2.5.2. communicate priorities of backlog to team

1.2.5.3. keep everyone informed of progress and obstacles

1.2.5.4. remove obstacles quickly

1.2.5.5. track progress delivering backlog functionality

1.2.5.6. addressing and minimising project risk

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

1.3. Sprints

1.3.1. Advantages

1.3.1.1. Product becomes a series of manageable chunks

1.3.2. Sprint planning

1.3.2.1. Team meets with the client/client representative and decides what can be achieved in the current sprint

1.3.2.1.1. Product owner gets a last chance to revise priorities

1.3.2.1.2. Once decided, the backlog is locked down until the next sprint

1.3.2.1.3. Decide acceptance tests

1.3.2.2. Team has sprint planning meeting - decides tasks for the sprint backlog

1.3.2.2.1. tasks can be no more than 16 hours in duration

1.3.2.3. Maintain sprint backlog detailing

1.3.2.3.1. responsibility

1.3.2.3.2. duration

1.3.2.3.3. hours remaining on tasks for each day of the sprint

1.3.2.3.4. status of the task

2. Refactoring

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

2.2. Constant process

2.2.1. Improve quality of the code

2.2.2. Remove dead code

2.2.3. Make code self describing

2.2.3.1. Code as it should have been written first time

2.2.4. Not about

2.2.4.1. Fixing bugs

2.2.4.2. Visible action - everything should stay the same

2.2.5. Aim to make changes that do not impact anyone else

2.2.5.1. Programmer should only change the code they have created

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

2.3. Refactorings

2.3.1. Extract Class

2.3.2. Extract method

2.3.3. Extract interface

2.3.4. Move class

2.3.5. Move method

2.3.6. Move field

2.3.7. Rename variable

2.4. Looking for

2.4.1. Code Smells

2.4.1.1. Number of classes

2.4.1.2. Message chain

2.4.1.3. Duplicate code

2.4.1.3.1. Remove whenever possible

2.4.1.4. Large class

2.4.1.4.1. Too many responsibilities?

2.4.1.5. Long method

2.4.1.5.1. Too many responsibilities, difficult to maintain...

2.4.1.6. Long parameter list

2.4.1.6.1. Lots of parameters means more complex

2.4.1.7. Dead code

2.4.2. Programs that are hard to read

2.4.3. Programs that have a lot of duplicated logic

2.4.4. Programs with complex conditional code

2.4.5. Poor designs

2.5. Refactoring tasks

2.5.1. Generalising classes

2.5.2. Specialising classes

2.5.3. Improving encapsulation

2.5.4. Lowering impact of change

2.5.5. Merging subclasses into fields

2.5.6. Extracting fields into subclasses

2.5.7. Implementing interfaces

2.5.8. Adding abstract classes

2.6. Testing

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

2.7. Design

2.7.1. Aim for a reasonable design rather than the best design

2.7.1.1. Ok to make changes

3. Agile Testing

3.1. Test Driven Development

3.1.1. Acceptance Test Driven Development

3.1.2. Behaviour Driven Development

3.2. Unit Testing

3.2.1. Test names should be descriptive

3.2.2. One test for each requirement

3.2.3. Write simplest code to make the test pass

3.2.4. If a test is too large, break it down

3.2.5. Test goal of code, not implementation

3.2.6. @setup and @teardown

3.3. Types of Testing

3.3.1. TDD (Test-Driven Development)

3.3.2. ATDD (Acceptance Test Driven Development)

3.3.2.1. Ensure that the customer has an automated mechanism to decide if the software meets the acceptance test criteria

3.3.2.1.1. Keeps development team focused on what is required to complete the user story

3.3.3. BDD (Behaviour Driven Development)

3.3.3.1. Create automated tests to look for the behaviour of the system

3.3.3.2. Framework such as JBehave

3.3.3.2.1. Establishes the prerequisites

3.3.3.2.2. Scenario

3.3.3.2.3. Given (Certain facts)

3.3.3.2.4. When (Something occurs)

3.3.3.2.5. Then (Carry out some action)

3.3.3.3. Allows client to see if the software works as identified

3.3.3.4. Output shows in english statements that the system is working (or not)

3.4. Agile Testing: Past, Present and Future

3.4.1. Paper is a review of the literature on agile testing

3.4.2. Types of Paper Identified

3.4.2.1. Solution

3.4.2.1.1. novel solution, only proof of concept

3.4.2.2. Validation

3.4.2.2.1. further investigates a solution, no practice

3.4.2.3. Philosophical

3.4.2.3.1. new framework for understanding a field

3.4.2.4. Opinion

3.4.2.4.1. Author's personal opinions

3.4.2.5. Experience

3.4.2.5.1. Describes author's experience on a project

3.4.2.6. Evaluation

3.4.2.6.1. investigation of a problem in practice

4. Agile Metrics

4.1. How can code quality be defined?

4.1.1. Observation and Measurement

4.2. Code coverage

4.3. Measurement should be valid and reliable

4.4. Code Metrics

4.4.1. WMC - sum of all complexity measures of the methods

4.4.1.1. Number of methods per class if all of the complexities are equal to one

4.4.1.2. Predict time and effort needed to maintain the class

4.4.1.3. Use cyclomatic complexity of the method

4.4.1.3.1. correlation between cyclomatic complexity and error frequency

4.4.1.3.2. Number of linearly independent paths through given code

4.4.2. DIT - Depth of inheritance tree maximum path from the node to the root of the inheritance tree

4.4.2.1. Deep tree- complex design, less comprehensible greater potential re-use of methods

4.4.3. NOC - Number of children in inheritance tree

4.4.3.1. More children more reuse but less maintainable

4.4.3.2. More children class is influential, may need more testing

4.4.4. CBO - Coupling between objects

4.4.4.1. The number of other classes to which a class is coupled

4.4.4.1.1. Low coupling - more independence of classes, easier to reuse; less sensitivity to changes, greater maintainability

4.4.5. RFC - Response for class

4.4.5.1. Number of local methods called by local methods plus the number of local methods

4.4.5.1.1. High RFC = complex class, complex testing and debugging

4.4.6. LCOM - Lack of cohesion in methods

4.4.6.1. Number of non-intersecting sets of local methods

4.4.6.1.1. lack of cohesion

4.5. Agile metrics

4.5.1. Hartmann and Dymond

4.5.1.1. Goal: Maximise business value delivered

4.5.1.2. Questions: rate of return on investment

4.5.1.3. Metric: Cash flow per iteration

4.5.1.4. A good agile metric

4.5.1.4.1. Affirms and reinforces Lean and Agile principles

4.5.1.4.2. Measures outcome not output

4.5.1.4.3. Follows trends, not numbers

4.5.1.4.4. Belongs to a small set of metrics and diagnostics

4.5.1.4.5. Is easy to collect

4.5.1.4.6. Reveals rather than conceals its context and significant variables

4.5.1.4.7. Provides fuel for meaningful conversation

4.5.1.4.8. Provides feedback on a frequent and regular basis

4.5.1.4.9. May measure Value or Process

4.5.1.4.10. Encourages good-enough quality

4.5.1.5. Useful Diagnostics

4.5.1.5.1. Velocity

4.5.1.5.2. Obstacles cleared per iteration

4.5.1.5.3. Team member loading

4.5.1.5.4. User stories carried over

4.5.1.5.5. Unit tests per story

4.5.1.5.6. Builds per iteration

4.5.1.5.7. On time delivery

4.5.1.5.8. Defects carried into next iteration

4.5.1.5.9. Diagnostics are helpful to measure the success of the agile process

4.5.1.6. Suggested Key Metrics (S McHugh)

4.5.1.6.1. Business Value Delivered

4.5.1.6.2. On time delivery

4.5.2. Watch effects

4.5.2.1. Observer effect

4.5.2.1.1. If an individual developer is being monitored (individual velocity) this may have an impact on the individual's output

4.5.2.2. Street light effect

4.5.2.2.1. Tendency to look for answers in the obvious place, need to look for answers in the not so obvious places.

5. Pair Programming

5.1. Advantages

5.1.1. Some well respected programmers prefer

5.1.2. Seasoned pair programmers describe it as working twice and fast

5.1.3. Resulting code is simpler and easier to extend

5.1.4. Even relative novices contribute to an expert's programming

5.2. Costs and benefits paper

5.2.1. Continual design and code review more efficient defect removal rates

5.2.2. Solve impossible problems faster

5.2.3. Pair programmers learn a lot from each other

5.2.4. Learn to discuss and work together, improves team cohesiveness.

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

5.2.6. Satisfaction

5.2.6.1. Takes time for a solitary programmer to move out of comfort zone

5.2.6.2. Comforting to know that know major mistakes are being made

5.2.7. Design Quality

5.2.7.1. Superior quality from pair programmers

5.2.7.2. Same functionality in fewer lines of code

5.2.7.3. Better designs

5.2.8. Continuous reviews

5.2.8.1. Code inspections not enjoyable or satisfying

5.2.8.1.1. Not done unless mandated

5.2.8.2. Advantages

5.2.8.2.1. Mistakes are found as entered

5.2.8.2.2. Peer pressure means code standards followed closely

5.2.8.2.3. Team members learn to talk together and work together

5.2.9. Learning

5.2.9.1. Expert in earshot

5.2.9.2. Line of sight apprenticeship

5.3. Disadvantages

5.3.1. Programming is taught as a solitary activity

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

5.3.3. Many experienced programmers are reluctant to program with other

5.3.3.1. Code is 'personal'

5.3.3.2. Another person will slow them down

5.3.3.3. Trouble coordinating work times or code versions

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

5.3.5. Some programmers are 'loners' who prefer to work on their own

5.3.5.1. Not one advocates for 'loners'

5.3.5.2. Loners still interact with other team members

6. Sprint Review/Retrospective

6.1. Sprint Review

6.1.1. Scrum team shows what they have achieved during the current sprint

6.1.2. Must be kept informal

6.1.3. No PowerPoint

6.1.4. Natural result of the sprint

6.1.5. Participants

6.1.5.1. Product Owner

6.1.5.2. Scrum team

6.1.5.3. Scrum master

6.1.6. Project assessed against the goals established at the sprint planning meeting

6.1.6.1. Ideally the team has completed all items in the sprint backlog

6.1.6.2. More important to achieve the overall aim of the sprint

6.2. Sprint Retrospective

6.2.1. Meeting held to reflect on the sprint just done

6.2.2. Should happen after the sprint review

6.2.3. Aims

6.2.3.1. Discuss how to make things better

6.2.3.2. Improve process quality

6.2.3.3. Improve product quality

6.2.4. Helps to improve team's learning and work satisfaction

6.2.5. Procedure

6.2.5.1. Decide what went well (what to do the same)

6.2.5.2. Decide what did not go well (what not to do again)

6.2.5.3. Create a list of actions to take forward into the next sprint

6.2.5.4. KJ Method

6.2.5.4.1. Write positive and negatives onto cards

6.2.5.4.2. Group the cards onto a pin-board

6.2.5.4.3. Collect suggestions for improvement

6.2.5.4.4. Create a list of actions to take forward into the next sprint

7. Agile Planning

7.1. User Stories

7.1.1. User story structure

7.1.2. Acceptance tests

7.1.3. Lightweight, just-in-time requirements

7.1.4. Card, Conversation, Confirmation

7.2. The Agile Manifesto

7.2.1. Individuals and interactions over processes and tools

7.2.2. Working software over comprehensive documentation

7.2.3. Customer collaboration over contract negotiation

7.2.4. Responding to change over following a plan

7.2.5. Works in short iterations

7.2.6. Focus on the business priorities

7.2.6.1. Priorities may change, but must be stable during each sprint so the team has a goal

7.2.7. Inspect and adapt

8. Ethical and Moral Responsibility

8.1. Software Engineers have a duty to

8.1.1. Public

8.1.2. Client and Employer

8.1.3. Product

8.1.4. Judgement

8.1.5. Management

8.1.6. Profession

8.1.7. Colleagues

8.1.8. Self

8.2. BSC Code of Conduct

8.2.1. Public Interest

8.2.1.1. Have regard for privacy, wellbeing of others

8.2.1.2. have due regard to legitimate rights of 3rd parties

8.2.1.3. conduct professional activities without regard to personal differences

8.2.1.4. promote equal access to the benefits of IT

8.2.2. Professional Competence and Integrity

8.2.2.1. Don't claim competence you don't possess

8.2.2.2. Develop professional knowledge and skills

8.2.2.3. Knowledge and understanding of legislation

8.2.2.4. Respect and value alternative viewpoints

8.2.2.5. avoid injuring others

8.2.2.6. reject bribery

8.2.3. Duty to Relevant Authority

8.2.3.1. Avoid conflicts of interest

8.2.3.2. Accept professional responsibility for your work and for colleagues under your supervision

8.2.3.3. Do not disclose any confidential information without prior agreement

8.2.3.4. Do not withhold information on the performance of products systems or services or take advantage of lack of knowledge or inexperience of others

8.2.4. Duty to the Profession

9. Continuous Integration

9.1. Advantages of CI

9.1.1. Build automation

9.1.2. Single source repository

9.1.3. Everyone commits to the master every day

9.1.4. Keep the build fast

9.1.5. Test in a clone of build environment

9.1.6. Automate deployment

9.1.7. Everyone can see what's happening

9.2. Traditional Approach

9.2.1. Team manually create a test build

9.2.2. Test build may be sent to testing team

9.2.3. Unit testing may speed up the process

9.2.4. Drawbacks

9.2.4.1. Most recent reliable build may be quite old

9.2.4.2. May be significant integration bugs

9.2.4.3. Some libraries or components may have external dependencies

9.2.4.3.1. Changes to external components may have to be factored in

9.2.4.4. Unexpected problems may be encountered when code is run on a different machine for the first time

9.3. Requirements for CI

9.3.1. Unit Tested Code

9.3.1.1. Configuration management Server

9.3.1.1.1. Monitor for changes in project files

9.3.1.1.2. Execute the build script for the project

9.3.1.1.3. Log the results of the build on a web page and/or e-mail to developers

9.3.1.1.4. Build log shows all details of build process

9.3.1.2. All unit tests are run during build

9.3.1.3. CI Software

9.3.1.3.1. Build Server

9.3.1.3.2. Build script

9.4. Configuration Management

9.4.1. Aims - to manage all project files with versioning

9.4.2. Identification control

9.4.3. Change control

9.4.4. Status and audit information

9.4.5. Record and report upon status

9.4.5.1. Audit information

9.4.5.1.1. Verify completeness and correctness

9.4.5.1.2. Does item conform to technical documentation

9.4.5.1.3. Is the standard process being followed in the way we said it was

9.4.5.2. statistics

9.4.5.3. request for change

9.4.5.4. track problems

9.4.6. Change Control

9.4.6.1. Current status of component

9.4.6.2. Releases

9.4.6.2.1. A release is a version intended for external people/customers

9.4.6.2.2. Release record should be maintained

9.4.6.2.3. Manage configurations for different

9.4.6.3. Who can make changes

9.4.6.3.1. Forms (very formal)

9.4.6.3.2. Developers (via Github or some other)

9.4.6.4. Storage control

9.4.6.4.1. Development library

9.4.6.4.2. Master library

9.4.6.4.3. Static library