Tworzenie oprogramowania zgodnie z zasadami Agile nie ogranicza się do programistów
Nikt nie chce dostarczać oprogramowania, które będzie zawierało wiele błędów, powodowało problemy z wydajnością i przekładało się na niski poziom zadowolenia klientów. Ciągła integracja i przeglądy kodu pomagają tego uniknąć… Tylko kto ma na to czas, prawda? No cóż, zespoły Agile i DevOps go znajdują.
Twórcy oprogramowania korzystający z metodyk Agile stawiają na zrównoważoną pracę, a nie heroiczne zrywy. Zrównoważenie polega na właściwym szacowaniu, stosowaniu skutecznych strategii tworzenia gałęzi do zarządzania kodem, przeprowadzaniu zautomatyzowanych testów w celu ochrony jakości oraz ciągłym wdrażaniu w celu szybkiego uzyskania informacji zwrotnej od użytkowników.
Wdrożenie praktyk zrównoważonego programowania wymaga samodyscypliny, którą większość z nas — nie bez trudności — stara się osiągnąć. To dlatego, że nikt nie może działać zgodnie z zasadami Agile lub DevOps w izolacji. Kultura całej organizacji musi wspierać przyjęty model, a czasami potrzebny jest agent zmiany, na przykład inżynier DevOps. To oznacza skłonienie liderów projektu do przekonania, że jakość jest ważniejsza niż zakres lub harmonogram, co często stanowi najtrudniejszą część wdrażania metodyki Agile.
Ale warto to zrobić! Programiści zyskują swobodę oraz poczucie odpowiedzialności za zrównoważone tworzenie oprogramowania, przy jednoczesnym zachowaniu fantastycznych relacji z firmą. Firma z kolei może wprowadzić na rynek produkt wyższej jakości, co dodatkowo wzmacnia relację z zespołem inżynierskim. Ponadto (i to właśnie jest najlepsze) twórcy oprogramowania korzystający z metodyk Agile rzadko są zmuszeni do „śmiertelnej gonitwy”. Gdy programiści mają opóźnienia w realizacji harmonogramu, ponieważ utrzymanie wysokiej jakości zajmuje więcej czasu niż przewidywano, bok żelaznego trójkąta odpowiadający zakresowi może się wydłużać w odpowiedzi na tę sytuację — a nikt nie chce tracić wolnych weekendów.
Wszyscy twórcy oprogramowania znają „żelazny trójkąt” zarządzania projektami: zakres, harmonogram i jakość. Niemal każdy z nas uczestniczył w projektach, których zakres był mało elastyczny, harmonogram ulegał przekształceniom, a zespół programistów był przytłoczony narastającym długiem technicznym. Na domiar złego, czasami okazywało się nawet, że produkt końcowy nie spełniał oczekiwań rynku. To frustrujące i tragicznie znajome.
Ale bez obaw. Jest też dobra wiadomość.
W procesie tworzenia oprogramowania według zasad Agile zakres staje się zmienną dynamiczną, dzięki czemu zespoły mogą chronić jakość, budować żywą kulturę programistyczną i ściśle współpracować z firmą. W Atlassian metodyka Agile stanowi podstawę działań każdego zespołu programistycznego (a także wielu zespołów niezajmujących się oprogramowaniem). Nie dzieje się tak bez przyczyny.
Ta metodyka zapewnia poszczególnym osobom dostęp do praktyk, które pozwalają tworzyć solidne podstawy techniczne produktu oraz kulturę współpracy w zespole. Programiści w zespołach Agile są bardziej zaangażowani, tworzą lepszy kod, a praca przynosi im więcej zadowolenia.
Dobre relacje to lepszy produkt
Istotą modelu Agile jest praca zespołowa, co nie jest niespodzianką, ponieważ obecnie większość oprogramowania jest wynikiem pracy zespołów. Programiści nawiązują silne relacje z menedżerami produktów, zespołami projektowymi, kontrolą jakości oraz zespołami zajmującymi się eksploatacją systemów informatycznych, ponieważ pisanie zrównoważonego kodu oznacza pozostawanie w kontakcie ze wszystkimi składowymi projektu. Umożliwienie programistom bezpośredniej współpracy z innymi częściami firmy przyniosło firmie Atlassian ogromne korzyści w postaci lepszej jakości kodu i większego zadowolenia klientów. Lepszy koło, mniej nieporozumień (czyli mniej dublowania prac i/lub mniej kolidujących strumieni pracy) oraz bardziej efektywna współpraca osób pełniących różne funkcje to zaledwie kilka przykładów korzyści.
Mentoring też ma duże znaczenie. Członkowie zespołów Agile uczą się od siebie nawzajem, dzięki czemu w całym zespole rozprzestrzenia się znajomość bazy kodu. Jednym ze sposobów takiego przekazywania wiedzy są przeglądy kodu, które nie tylko zabezpieczają jego jakość, ale także pozwalają zapoznać się z kodem różnym członkom zespołu. Bez względu na sposób upowszechniania wiedzy, w zespołach Agile nie dochodzi do sytuacji, w których programiści pracujący nad ścieżką krytyczną nie mogą pójść na urlop, ponieważ są jedynymi osobami, które znają dany fragment kodu. Przecież nikt nie chce być takim programistą.
Ponadto programistom Agile łatwiej jest poruszać się w obrębie zestawu technologii własnego produktu w porównaniu z ich odpowiednikami w modelach kaskadowych, ponieważ zespoły Agile samodzielnie organizują swoją pracę, umożliwiając członkom nabywanie nowych umiejętności. Faktem jest, że programiści którzy dostarczają całe funkcje — od interfejsu użytkownika po bazę danych — w większym stopniu czują się odpowiedzialni za napisany kod. W Atlassian kształcimy programistów full stack, ponieważ wierzymy w potęgę dzielenia się wiedzą w zespole i w całej firmie.
Pisanie kodu, kultura i zadowolenie z tworzenia oprogramowania zgodnie z zasadami Agile
Istotą modelu Agile jest wypracowanie wspaniałej kultury programistycznej w organizacji. W dalszej części znajdziesz więcej informacji o skutecznych strategiach tworzenia gałęzi, technikach automatycznego testowania, ciągłej integracji oraz nawiązywaniu wartościowych relacji z innymi częściami firmy. W kolejnych artykułach przyjrzymy się bliżej konkretnym zmianom, które tysiące programistów wprowadziło w ramach przejścia na metodykę Agile i dzięki którym odniosło sukces.
Tworzenie oprogramowania zgodnie z zasadami Agile to proces. A my stoimy u Twojego boku na każdym jego etapie.
Zacznij korzystać za darmo z szablonu planu projektu DevOps
Twórz i wdrażaj aplikacje oraz zarządzaj nimi dzięki otwartemu podejściu do narzędzi.