Nie trudno zauważyć, że projekty różnią się od siebie. Zamiast działać „na jedno kopyto”, można z większym powodzeniem realizować projekt w sposób dostosowany do jego cech. Które podejście wybrać? Czym się kierować? Intuicyjnie czujemy, że warto wziąć pod uwagę rozmiar projektu. Ale jest o wiele więcej czynników do rozważenia:)
Barry Boehm i Richard Turner zastanawiali się przez wiele lat jak zrównoważyć zwinność i dyscyplinę. Wg nich każdy projekt potrzebuje nieco swobody i nieco porządku. Jednak wielką sztuką jest umiejętnie balansować między tymi dwoma światami. Znaleźli oni główne czynniki, które różnią oba podejścia i mogą posłużyć jako wskazówka w wyborze odpowiedniego dla naszego projektu.
Zatem (zgodnie z poniższą tabela), jeśli klient potrzebuje szybko systemu i przewidujemy wiele zmian w trakcie projektu, to lepiej będzie stosować podejście zwinne, jeśli natomiast wymagania są przewidywalne i należy zapewnić wysoką jakość, lepiej wybrać sterowane planem, itd.
| Charakterystyki | Podejście zwinne | Podejście sterowane planem |
| Application | ||
| Główne cele | szybkie dostarczenie wartości klientowi, szybka reakcja na zmiany | przewidywalność, stabilność, zapewnienie jakości |
| Rozmiar | mniejsze projekty i zespoły | większe projekty i zespoły |
| Środowisko | szybko zmieniające się, skupione na koncepcji produktu | wolno zmieniające się, skupione na informatyzowanej organizacji |
| Zarządzanie | ||
| Relacje z klientem | klient do ciągłej dyspozycji zespołu, skupiony na kolejnych wydaniach produktu | klient do sporadycznej dyspozycji zespołu, skupiony na umowach/kontraktach |
| Zarządzanie i kontrola | plany tworzone przez zespół, kontrola jakościowa (testy) | plany udokumentowane, kontrola ilościowa (liczba spełnionych wymagań) |
| Komunikacja | niejawna wiedza współdzielona przez zespół | jawna udokumentowana wiedza |
| Techniczne | ||
| Wymagania | priorytetyzowane nieformalne historyjki, | |
| Programowanie | ||
| Testowanie | ||
| Personel | ||
| Klienci | ||
| Programiści | ||
| Kultura |
