Agile + Analysis

Domain vs. Problem vs Solution Analysis

Domain Analysis: Learning about a general field of business/technology/capabilities that a client is based in (and may use software for it!)

Problem Analysis: Investigation of the cause of an incident , issue or failure to help identify potential improvements or changes to systems, processes, designs, culture, etc.

Solution Analysis: Assessment/Evaluation of existing and/or potential solutions to a problem

Systems: hardware, software, people, data, procedure. 

-  An organized set of doctrines, ideas or principles

-  Typical goal is to explain the arrangements or working of a whole

-  Any set of interrelated, interacting components that function together [to achieve specific objectives]

-  Natural and artificial

-  Systems are always part of larger systems, and can be partitioned into smaller systems

System Analysts' responsibility:

• Define problem -- talk to users, gather requirements

• Prioritize issues -- decompose problems into manageable puzzle pieces

• Identify minimum requirement -- understand what would be your first minimal viable product.

• Identify how to solve problem, i.e. Build – focus on the “how”

Analysis vs. Design

• Analysis focus on the “what”, that is to break down the big problem into managable pieces and prioritize them.
  • Understanding and documenting business needs
• Design focus on the "how", that is to build things up rather than breaking things apart.
  • Choosing among alternative implementations

SDLC (Software Development Cycle):

A well-designed set of partially ordered steps intended to reach a goal;

the goal is to build a software product or enhance an existing one.

Create order, eliminate chaos, lower risks

ADD cost!

• Example: Waterfall, Agile

• Phases: 

activities clustered around a common intent.

        

• Stages:

Software engineering steps ordered in time 

Agile

Agile manifesto

Individuals and interactions over processes and tools – More effective to Collaboration than to worry about process

Working software over comprehensive documentation – Create just enough to create a software (a working software is the demonstration)

Customer collaboration over contract negotiation – Discussion with customer is more efficient than doing long documentation of req

Responding to change over following a plan – If the product is not working, STOP; If the product is good, move FASTER!

12 Agile Principles

1. highest priority is to satisfy the customer -- early and continuous delivery
2. welcome changing requirements -- support just in time analysis of requests, change quickly
3. deliver working software frequently -- to get timely feedback
4. business people and developers working together daily -- for those who build and those who use the solution to collaborate to avoid insatisfactory after costly development for a long time.
5. build projects around motivated individuals -- motivated people, empowering them and trusting them
6. sustainable development -- constant pace, that means the work is distributed evenly throughout the development process
7. working software -- i.e. small pieces of features/function, is the primary measure progress instead of 进度条
8. face-to-face conversation -- ensure efficient and effective conveying of information
9. technical excellence and good design -- Don’t do something that makes it fast in the short run but is more costly in the long run.
10. Simplicity – the art of maximizing the amount of work not done – is essential -- eliminating anything that is not value add to the customer
11. self-organizing teams -- let the people closest to the work make decisions on architectures, requirements and designs
12. tunes and adjusts -- do reflection regularly to achieve higher efficiency

Agile vs. Waterfall

• Timeline:

  • Incremental vs. Linear 

  • Sprints (do a little of everything all the time) vs. Phases

• Requirements & Scope:

  • Undefinded scope vs. Defined scope

  • Just enough req vs. Lots of req

  • req completion Just in time vs. Up front

Agile Sprints

• Sprints can be 1-4 weeks, typically 2 weeks. Each sprint repeats iteration cycle.

• Each iteration starts with requirement (green) and ends with evaluation (pink).

Scrum

Roles:

• Owner: 
  • Owns the Product Backlog
  • Constantly re-prioritizeing
  • Creates long-term vision
  • Goal is to maximizing the return on investment (ROI)
• Master:
  • Project manager of the scrum team
  • NOT the HR manager
  • NO management authority
  • Facilitates the Scrum process
• Development Team
  • Cross-functional
  • Self-organizing / self-managing
  • 7 ± 2 members

Artifacts

• Portfolio Backlog
  • Highest level 
  • We prioritize it to get Product Backlog
• Product Backlog
  • Middle level
  • We pick items from it to form Sprint Backlog
• Sprint Backlog
  • What we work on during the current sprint

Burndown Chart

• Definition: work left to do versus time
• Useful for predicting when all of the work will be completed
  • monitoring the project scope creep
  • Keeping the team running on schedule
  • Comparing the planned work against the team progression

User stories

1. Definition: description of a feature from a user’s perspective
2. Format: As a <type of user>, I want <some goal> so that <some reason>.

 Daily Scrum Meetings 

• Daily, ~15 minutes

• Stand-up

• What I did Yesterday, what I will do today, what are the blockers/impediments

Sprint Review

• Chicken & Pigs will join
• At the end of each sprint
• What it accomplished during the sprint 
  • Demo working product (not a written report)
  • Product owner check-off (if a req is completed, check-off; otherwise, go back to backlog)