Podstawy zwinnego wytwarzania oprogramowania

Zdjęcie od Sohrab Salimi
Sohrab Salimi
2 min Czas czytania
Ta treść została przetłumaczona przez AI. Zobacz oryginał

Zwinne wytwarzanie oprogramowania jest – z wyjątkiem opisanym poniżej – iteracyjne. Iteracja to krótki okres trwający od jednego miesiąca do zaledwie jednego tygodnia. Z mojego doświadczenia wynika, że średnia długość iteracji w różnych zespołach wynosi od miesiąca (standard Scrum) do tygodnia, co jest moją rekomendacją dla cyklu XP. Myślę, że obecny trend to dwa tygodnie.

Ale odbiegam od tematu. Najważniejszy element Agile, conditio sine qua non, warunek konieczny, podstawa, to coś, co bezwzględnie trzeba robić:

Zespół musi na koniec każdej iteracji dostarczyć działające, przetestowane i zintegrowane oprogramowanie; w Scrumie powiedziałoby się, że musi być „done-done"

Nie ma od tego odwrotu. Nie możesz dostarczać czegoś tylko co drugą iterację. Nie możesz też dostarczać prawie gotowego oprogramowania i naprawiać go w kolejnej iteracji. Nie próbuj się od tego wymigać. Musisz dostarczać oprogramowanie.

Wyjątek

Jeśli myślałeś, że tutaj znajdziesz sposób, żeby się od tego uwolnić, to się mylisz. Jedynym wyjątkiem od dostarczania gotowego oprogramowania w każdej iteracji jest dostarczanie go jeszcze częściej. Niektóre topowe zespoły pracują obecnie w rodzaju trybu Kanban, w którym zasadniczo ciągle dostarczają nowe funkcje – zazwyczaj co kilka dni.

Niestety, nie ma od tego ucieczki

Prawdziwe, działające, zintegrowane, przetestowane, done-done oprogramowanie – i to w każdej pojedynczej iteracji, albo po prostu w sposób ciągły. Na tej drodze będziesz musiał się nauczyć, co to wszystko oznacza, i z pewnością napotkasz trudności. Ale z pewnością też zauważysz, że „done" oznacza więcej, niż myślałeś. Oczywiście obejmuje to dokumentację użytkownika. Oczywiście obejmuje to szkolenia dla użytkowników. Oczywiście obejmuje to wszystko, o czym myślałeś, że jest niemożliwe.

Nobody's perfect

Twój zespół nie jest doskonały i prawdopodobnie nie osiągnie tego wszystkiego w każdej iteracji. To, co jednak powinieneś bezwzględnie robić, gdy masz jeszcze miejsce na poprawę, to coś, co w Scrumie nazywa się „Inspect & Adapt". Kent Beck ujął to kiedyś następująco: „Znajdź swój największy problem, rozwiąż go metodą XP i powtórz".

Jeśli potrzebujesz pomocy, poszukaj jej.

A teraz zacznij dostarczać to oprogramowanie!

Tekst pochodzi z bloga Rona Jeffriesa i został przez nas przetłumaczony na język polski.

Więcej na ten temat

Czy znasz swoich interesariuszy jako Product Owner?

Kim są Twoi interesariusze? Jako Product Owner powinieneś zawsze być świadomy, kto jest kluczowy w rozwoju produktu. Więcej na blogu!

Czy Apple naprawdę jest „Agile"?

Jak zwinnie działają wielcy gracze, tacy jak Apple, Google czy Spotify? Dowiedz się tego w naszej bazie wiedzy na Agile Academy!

Produkty, które poniosły porażkę

Dlaczego produkty ponoszą porażkę i jak można to przewidzieć lub zapobiec? Na to i więcej pytań odpowiadamy w sekcji wiedzy Agile Academy!

Porozmawiaj z naszym asystentem Porozmawiaj z naszym asystentem