*Agile development/Ketterä kehitys

Ketterä kehitys on 2000-luvun alussa yleistynyt tapa tehdä ohjelmistoja. “Vanha” tapa noudatteli yleensä ns. “vesiputousmallia”, jossa ensin tehdään vaatimusmäärittely, sitten toteutus, tämän jälkeen testaus ja viimeisenä käyttöönotto. Vesiputousmallin ongelmana on se, että saattaa kulua useita vuosia ohjelmiston tilauksesta siihen, että asiakas näkee mitään valmista. Lopputulos ei yleensä tyydytä ketään.Ketterässä kehityksessä ohjelmistoa rakennetaan pikku hiljaa, pala palalta. Kehitys koostuu sykleistä, jotka voivat olla esimerkiksi kahden viikon tai kuukauden mittaisia. Jokainen sykli pitää sisällään vesiputousmallin vaiheet. Kehitys ei välttämättä ole sen nopeampaa (ohjelmisto ei valmistu lyhyemmässä ajassa) kuin vesiputousmallilla, mutta pääasiallinen hyöty on se, että asiakas pääsee näkemään jatkuvasti miltä ohjelmisto näyttää, kuinka se toimii ja kykenee antamaan palautetta siitä mihin suuntaan ohjelmistoa tulisi kehittää. Tarkoitus on, että heti ensimmäisestä syklistä lähtien käytössä on “toimiva järjestelmä”, joka tekee ainakin jotain. Siihen lisätään uusia ominaisuuksia yhteisymmärryksellä päätetyssä järjestyksessä. “Valmistuttuaan” ohjelmisto siis hyvin todennäköisesti tekee sitä mitä sen pitääkin.

Agile development is a way of developing software, that has become more common in the beginning of the 21st century. "The old" way of doing things was the waterfall method, where first requirement specifications are written, then implemented, tested and finally deployed. The waterfall model's drawback is that it can take years from the software order to the deployment. The end result is thus rarely satisfying. In agile development, the software is developed bit by bit. The development consists of development cycles or sprints, that can last for example two weeks or a month per sprint. Each sprint includes all the phases of the traditional waterfall method. The development might not be any faster than in the waterfall method, but the main benefit is that the customer can see almost in real time what the software looks like and how it works, and can give feedback and guidance for the development. The purpose is, that starting from the very first development sprint, "functional system" exists and does at least something. New features are then added in an order agreed together. Once the system is "ready", it most likely does what is supposed to.