Agile Development

Agile Development


The hottest word and most often used description for newer methods were the traditional waterfall methods are replaced with a more interaction and fluent working process. 

I really like this way of working: not only working in pairs most of the time (from XP), or having one to share the design and ideas with, but in this way (with Agile development phase) especially the  "design & program everything in MS Word first", has been replaced with a more smooth, interactive and customer pleased approach. 

I see a very smooth and tight controlled development flow, because problems (requiring decisions) can be handled at once. At least for the near future, (and this is perhaps a risk - working in this way, does postpone critical issues).
But if the team has made a thorough analysis on the main architecture/design, like performance, critical interfaces, most of it could be addressed up-front!

I also see some risk related to the overall project management - because it becomes less visual what the missing-parts are ... You only have a good look at the known parts (has been working on). Also in terms of planning SW releases, freezing specification and other interactions to eg. HW would be difficult to estimate.

 

COCOMO

Since COCOMO looks at 

  • capability, 
  • effort, 
  • knowledge, 
  • knowhow, 
  • skills, 
  • complexity of design, 
  • functional behavior and 
  • lines of code ... 

in a huge mathematic formula, you can pull out many types of calculations. Estimates all based on your code expectations, people skills, speed and quality etc...   And this is good for making estimations on the primary items in the project.

 

 AGILE PRO’s & CONs

Where Agile development (my point of view) has its strength with the 

  • 'Drop of the month/week' (architecture & design solution frozen, hole-through & beta releases ...)
  • Keep it simple approach - (though this can be by-passed)
  • Near-future planning, 
  • Better just-in-time activities
  • SW relationships and demands are exposed and review possible at an early stage
  • Elaborating current activity, progress, problems, ideas etc
  • Team sharing activities (and the can kick-in with ideas, you-must-remember ...bla bla)
  • Should/Could lead to faster integrations phases. (CI need too)
  • in parallel teams – smaller-steps means finding earlier point-of-problem (IF the teams are feature oriented, and actually uses what the other team delivers.)
  • Risk management (postponed and risky issues has to be recorded - for later action (evaluation))
  • pair activities possible (improved teamwork, knowledge sharing, general awareness in project)
  • Business people is directly involved in requirements – very early.
  • Reduce documentation to required/needed level!
  • Very good for upper or lower projects – not several in parallel!
    Upper à business à Feature focused (this must be technology independent!)
    Lower à Technology à Cheapest/fastest/highest power/? ... as possible

 

The 'dark' sides are (again my point of view):

  • Requirements tends to be more and more important,
  • Overall timing/planning is not known or its more floating due to small-step-at-the-time planning (Prj. Management),
  • Tuff customers can delay business (development flow) dramatically (if they interfere heavily),
  • Customers 'moods' can (easy) influence on already-made-decisions and work,
  • Compliance (customer's & system) and Requirements are often 'forgotten' (=not detailed written down), making it difficult at the test- & delivery stage,
  • Missing long term focus - The just-in-time could lead to locking situations that holds everything back ()
  • Only working on & focusing on 'what’s in scope' becomes risky ...
  • Multi-teams – missing same focus, postpones acceptance on delivers activities.
  • Business people involvement could delay initial work, discussing technical stuff and not features) as well as if they are not aware of their higher/changed responsibilities,
  • Some organization level are mixing business/feature requirements (what shall it do) with technology requirements (how is it done/impl) – typically unclear roles too.
  • Some project/product needs detailed development process & registrations (like in medico, automotive, mass-transportation, sitcom …) here documentation (only as we need) is not an option. You still need the full documentation!
  • Missing overview of technical areas – could lead to same but different development. (re-inventing the wheel). Making things twice …
  • Missing platform strategy leads to bad habits and difficult reuse of code base.
  • Platform strategy is mandatory for business – as well as for the technology!

 

On top of all this Agile development, one can chose many ways of testing & implementing. 
Unit testing with TDD (Test-Driven-Development), or other more traditional ways.

SCRUM

Generally lots of ways lead to Rom. I have been looking at SCRUM J Now working with for some years too. Not religious - but held daily and bi-weekly planning’s in teams. And I can tell you – if you are in a team where +30% of your activities is ‘customer’ related … forget about SCRUM and planning. That’ll only be waitsing your time. But its very good for keeping track, report to other in the team and ofcause make notes so people around you can see what your working on!

Today's most used tools are lacking performance and visibility for architecture & designing with agile methods. Most of the documentations are still written the traditional way (most companies using Word, more and more using UML etc). But for planning and keeping track of planning – link this to your actual work … well That is for sure to come … WE NEED IT!

I know RTC and CQ, ROOSE and other tools are now hiding that directions … nice J

 

Other interesting links - for Agile methods using Scrum:

Book: 'Feature Driven Development, Adaptive Project Management Using Scrum'

Adaptive Project Management Using Scrum - Part 1     Part 2     Part 3 

 

Resources:

  1. Scrum: It’s About Common Sense http://www.controlchaos.com and  more detailed   here
  2. Slide Deck accompanying this article: http://www.craigmurphy.com/sd/WhyScrumWorks.zip
  3. http://www.scrumalliance.org : Pay your £1, $1, €1 late-comer fee via this site!
  4. Software by Numbers: Low-Risk, High-Return Development, By Mark Denne, Jane Cleland-Huang. Prentice Hall PTR, 2003, ISBN 0131407287
  5. Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, 2004, ISBN 073561993X
  6. Agile Software Development with Scrum, Ken Schwaber, Mike Beedle, Prentice Hall, 2002, ISBN 0130676349



Another very important area is the SW re-usability - here defined as the re-usability value.

Comments

No Comments have been Posted.

Post Comment

Please Login to Post a Comment.

Articles Panel

  Article Posted By Date Reads
WCET - Worst Case Execution Timings Calculator
Tools
johnk
28-06-2015 19:2912413
Embedded-Tracer-System
Tools
johnk
16-03-2015 18:221893
NuttX - Step-By-Step
Tools
johnk
30-12-2013 17:185285
Tools used
Tools
johnk
27-10-2013 12:133048
List of my robots
My robots
johnk
19-07-2013 08:442800
JoKaBot - Home build from scratch
My robots
johnk
19-07-2013 08:045256
C-Sharp (references and projects)
Oldies
johnk
18-07-2013 19:193170
Home communications
Technology
johnk
18-07-2013 18:233401
Various links
My Collection
johnk
17-07-2013 09:046565
ARM - ARM7/9/11 + Cortex
Technology
johnk
17-07-2013 08:493382
AVR32
Technology
johnk
17-07-2013 08:413467
Raspberry PI
Technology
johnk
17-07-2013 08:368952
Robotics Links
Tools
johnk
17-07-2013 08:367125
Robotics in general
Robotics
johnk
17-07-2013 08:352692
Renesas processors (V850, RL78...)
Technology
johnk
17-07-2013 08:113260

Total Articles: 54 :: Total Article Categories: 16
 

Articles

My Collection (1) My robots (2)
Oldies (5)
Old Projects - very old
Process & Methods (7)
Projects (12) Robotics (1)
Technology (6) Testing (1)
Tools (12) Working on ... (7)
Projects Im currently working on
Render time: 0.03 seconds
668,815 unique visits