# 1.3 Ketterä projektinhallinta ja käytännöt

1990-luvulla ohjelmistoala kohtasi merkittäviä haasteita. Ensinnäkin se oli suhteellisen nuori, eikä päteviä ohjelmistokehittäjiä ollut tarpeeksi saatavilla. Toiseksi, ala luotti tiukkaan projektinhallintatapaan, jota kutsuttiin "vesiputous"-menetelmäksi. Tämä menetelmä painotti laajojen vaatimuslistojen luomista, usein enemmän laillisten sopimusten vuoksi kuin yhteistyöhön asiakkaiden kanssa. Tämä yhteistyön puute johti laajaan epäluottamukseen.

Lisäksi ohjelmistokehitys poikkesi nykyään käytetystä inkrementaalisesta lähestymistavasta. Sen sijaan, että ohjelmistoja parannettaisiin vähitellen, ohjelmistot luotiin suurina paketteina. Ajattele ohjelmistoa kuten vanhaa Office 95:ttä, joka sisälsi lukuisia ominaisuuksia, joita useimmat ihmiset eivät käyttäneet. Näin laajojen pakettien kehittäminen vei vuosia ja johti usein ohjelmistovirheisiin. Pareton laki osoitti, että vain noin 20% ohjelmistosta käytettiin, jättäen 80% resursseista hukkaan.

<figure><img src="/files/nFJ1drZTcnJ2ThnGH75Q" alt=""><figcaption><p><a href="https://apifuse.io/blog/agile-vs-waterfall-methodology/">Vesiputous vs Ketterä</a></p></figcaption></figure>

Perinteisessä "vesiputous"-menetelmässä ohjelmistoprojekti saattoi kestää kokonaisen vuoden ilman minkäänlaista asiakkaan panosta. Ketterällä lähestymistavalla sama ohjelmisto toimitetaan asiakkaalle joka kuukausi tai "sprintin" aikana, mikä mahdollistaa varhaisen palautteen ja asteittaiset parannukset. Näin ollen vuoden lopussa sinulla on onnistunut lopputuote.

[Ketterän kehitysprosessin](https://www.ariadgroup.com/en/blog/all-about-scrum-Agile/details-about-scrum-Agile-components) sisältää useita keskeisiä käytäntöjä. Ensinnäkin on "tuotejonon" eli vuoden aikana haluttujen ominaisuuksien ja tehtävien luettelo. Sitten joka kuukausi sinulla on "sprintin jonon", joka on tehtävälista kyseisen kuukauden aikana työstettäväksi. Ketterä sykli tapahtuu säännöllisesti, yleensä joka toinen viikko tai kerran kuukaudessa, tiimin päätöksen mukaan, ja se sisältää vaiheet kuten suunnittelu, suunnitelma, kehittäminen, testaaminen ja ohjelmiston julkaisu. Tämä sykli toistuu, jossa jokainen sprintti ammentaa sprintin jonosta, ja se johtaa lopputuotteen toimittamiseen.

<figure><img src="/files/v4bFrxflF3TlTZwIbS4F" alt=""><figcaption><p><a href="https://www.altexsoft.com/whitepapers/agile-project-management-best-practices-and-methodologies/">Ketterä kehityssykli</a></p></figcaption></figure>

Erilaisia menetelmiä ja lähestymistapoja voidaan käyttää työskentelyyn ketterällä tavalla. Kaikki ne noudattavat aikaisemmin puhuttuja periaatteita ja arvoja.

Jotkin tunnetut [ketterät kehykset ohjelmistokehityksessä](https://www.altexsoft.com/whitepapers/Agile-project-management-best-practices-and-methodologies/) sisältävät Scrum, Kanban, Hybrid, Lean, Bimodal, XP ja Crystal. Näistä Scrum on laajimmin käytetty.

<figure><img src="/files/8xSZvOlCrfoVVIIWbQyv" alt=""><figcaption><p><a href="https://www.altexsoft.com/whitepapers/agile-project-management-best-practices-and-methodologies/">Miten Scrum-kehys toimii</a></p></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://results-fi.agilexr.eu/projektin-tulos-1/1-guide-agile-teamwork-in-web-based-learning/chapter-1-agile-in-software/1.3-agile-project-management-and-practices.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
