{"id":245,"date":"2024-06-18T18:42:00","date_gmt":"2024-06-18T18:42:00","guid":{"rendered":"https:\/\/permutationcity.co.uk\/bp\/?p=245"},"modified":"2024-06-17T17:48:42","modified_gmt":"2024-06-17T17:48:42","slug":"a-brief-history-of-agile","status":"publish","type":"post","link":"https:\/\/permutationcity.co.uk\/bp\/2024\/06\/18\/a-brief-history-of-agile\/","title":{"rendered":"A brief history of Agile"},"content":{"rendered":"\n

To deal with\nendless change<\/a>\nthe industry seems to have settled on\nAgile software development<\/a>.\nHowever the original definition of Agile coming from the\nAgile Manifesto<\/a>\nin 2001 hasn’t really survived.\nAll these techniques call themselves agile but often it’s just a popular label rather than something deeper.\nDealing with change is not new and existed before the word Agile.<\/p>\n\n\n\n

Before the manifesto<\/h2>\n\n\n\n

The Waterfall model<\/a>\nis the classic heavyweight engineering method.\nThis has a strict separation between a series of phases:\nrequirements capture, analysis, design, coding, testing, operations.\nEach phase should be completed before moving on to the next.\nHowever if problems occur or changes are required at later stages then\nthis necessitates returning to and repeating earlier phases.\nAny changes are likely to result in a much longer and more expensive project.\nThis technique favours well understood technology with clear goals for it’s use.\nEven some of the originators of the model acknowledged problems with the dogmatic application of it.<\/p>\n\n\n\n

More incremental approaches<\/a>\ntake phases of the waterfall model and turn it in to a cycle,\nI learned this as the spiral model<\/a>.\nA project is the result of many cycles.\nEarly ones will focus more on capture and design but may include coding.\nLater ones would focus more on coding and testing but may still include design.\nBy including some coding early on their is the possibility of discovering problems early.\nBy including some design later on it encourages leaving flexibility to cope with changes that may be required.\nThis technique is more open to less understood technology.<\/p>\n\n\n\n

Even more flexible approaches were taken in\nextreme programming<\/a>.\nHere the expected that customers will change their requirements over time as the problem is better understood.\nTherefore the method concentrates on high quality but flexible coding using:\npair programming<\/a>,\ncode reviews<\/a>,\nunit testing<\/a> and\nsticking to essential code<\/a>.\nA short release cycle gives high visibility for progress allowing for course corrections.\nHowever with an extreme focus on the short term this can miss out on long term savings\nthat planning and investment in code can bring.<\/p>\n\n\n\n

That’s just a couple, there were others:<\/p>\n\n\n\n