Date: 2018-11-27 16:34:34
Agile Development
Agile Development

Agile Development

What is Agile?

The ability to create and respond to change in order to succeed in an uncertain and turbulent environment.

Why go Agile in Software Development?

Agile development accelerates the delivery of initial business value, and through a process of continuous planning and feedback, is able to ensure that value is continuing to be maximized throughout the development process. But we have been using plan oriented development(methods) this whole time. Why would we need to switch to agile for a project? — Agile development isn’t always the right way to go. It goes with small groups of Level 2 and 3 programmers. You should use it when the problem hasn’t been specified fully at the beginning and you need to adapt to clients requests during development.

Plan-oriented development problems:

  • long life cycle
  • hard to learn and use the methods, not adjustable
  • documentation, documentation, documentation
  • difficult to implement changes during development process
  • having to know the whole and final solution before starting

Agile is all about simplicity.

Never do more work than you have to. Never make documents that try to predict the future. Modeling and documentating by sense of what are you are going to need.

Agile methods/approaches:


XP — eXtreme Programming
AD — Agile Database Techniques
AM — Agile Modeling
ASD — Adaptive Software Development
AUP — Agile Unified Process


FDD — Feature Driven Development
DSDM — Dynamic Systems Development Method
LSD — Lean Software Development
TDD — Test-Driven Development

Features of AP:

  • Incremental, iterative development. Short cycles. The result of every cycle is usable code.
  • Prototype, reuse
  • Constant communication with clients
  • Easy and simple to use
  • Easily adaptable

Agile efficiency:

Agile development process is relatively new and still needs to fully prove it’s self. But comparisment studies have shown significant results by now

Agile vs. Waterfall:

The diagram below displays the differences between agile and waterfall development processes. By delivering working, tested, deployable software on an incremental basis, agile development delivers increased value, visibility, and adaptability much earlier in the life cycle, significantly reducing project risk.

Agile groups efficiency:

Agile vs. Traditional System Development


Culture that thrives on chaos
Small/creative team
Adapts to change
Creative process
Low documentation
Low risk
Client collaboration
Experienced Developers (full stack)
People oriented


Culture that thrives on order
Large team
Follows plan
Constructive Process
High documentation
High risk
Contract negotiations
Inexperienced developers (for coding)
Process oriented



The SCRUM methodology is constructed of three phases:

  1. Start — big goals for the project, start sketching basic architecture
  2. Repeat sprints — in each sprint we develop an increment of the system
  3. Finish — finish the documentation needed, look at what we learned

Sprint cycle is in iteration of development, the result of which is a new functionality of the system. The development team is self-organized and autonomous; multiple groups can implement different functionalities at the same time. Sprint has daily scrum meetings.


  • Product owner
  • SCRUM team
  • SCRUM master — in charge of development process. Ensures SCRUM is indeed used and provides everything for it to take place
  • Observers — others that have interest in the project, can be involved, but can’t make any observations or remarks

Mandatory meetings

  • sprint planning meeting
  • -Daily scrum
  • -sprint review meeting -sprint retrospective meeting

Mandatory files

  • Product backlog (Prioritized features. at the begining, done with product owner)
  • Sprint backlog (Features for a sprint. Done by team)
  • Sprint burn down chart (makes the work process visible)

XP — eXtreme Programming

XP follows 5 basic principles for project improvement.

  • communication
  • -simplicity
  • -feedback
  • -respect
  • -courage

Here the programmers are constantly communicating with project owner and users. Feedback is beeing gathered from day one. The project is deployed as soon as possible. Further features are done after. This increaces addaptability and changes can be made at the very end. We aren’t commited to scheduled integrations, but insted daily integrations are done.


The kanaban model encourages small, constant and inkremental changes. It can be used when a team has a common understanding of work flows, development processes and the final goal. Then each member can contribute to taking measures that will improve the the product.

Oblikovano in razvito s ♥︎
© 2019 VALUS - Vse pravice pridržane