Czy zespoły Agile powinny codziennie dostarczać nowe funkcje?

Moja firma jest w trakcie przejścia od rozwoju w stylu wodospadu do Agile / Scrum. Mówi się nam między innymi, że oczekujemy, że pod koniec każdego dnia będziemy mieć nowe działające, testowalne (według QA) funkcje.

Większość naszych deweloperów traci około 2 godzin dziennie na spotkania i inne przedsięwzięcia biznesowe. Oznacza to, że w danym 6-godzinnym (co najwyżej) okresie musimy zaprojektować, napisać, przetestować jednostkę, zbudować i wdrożyć (z uwagami do wydania) wystarczającą ilość kodu, aby stworzyć pełną funkcję zapewniania jakości przez QA. Rozumiem, że informacje o kompilacji / wdrożeniu / wydaniu można zautomatyzować przy odpowiedniej konfiguracji CI, ale jeszcze tego nie ma.

Mamy również duży kontyngent morski, który pisze nasz kod po stronie serwera, a 12-godzinna różnica czasu czyni to jeszcze trudniejszym.

Staramy się wypowiadać historie w wąskie, głębokie pionowe segmenty, aby jak najszybciej uzupełniać funkcje od końca do końca, ale przez większość dni czuję się raczej szalony i często przyłapuję ludzi na głupich, delikatnych skrótach, aby upewnić się, że QA ma swoją wersję. Problem ten nasila się po kilku dniach sprintu, gdy nieuchronne usterki zaczynają się pojawiać i muszą zmieścić się w tym samym 6-godzinnym oknie.

Czy to normalne tempo dla zespołów Agile? Nawet jeśli uda nam się wdrożyć konfigurację CI, nie widzę, jak będziemy w stanie utrzymać to tempo i nadal tworzyć oprogramowanie wysokiej jakości.

Edycja: Jest tu kilka dobrych odpowiedzi. Uświadomiłem sobie, że tak naprawdę pytam, czy zespoły Agile powinny codziennie dostarczać nowe funkcje . Zaktualizowałem odpowiednio tytuł.

Przestępstwa popełniane obecnie w imieniu Agile sprawiają mi smutek. Wiele osób ma trudności z przejściem.

Zwinny Manifest: „Cenimy ludzi i interakcje nad procesem i narzędziami”. Kiedy ludzie wyraźnie krzywdzą, proces jest zły. Nie chcę ci mówić, jak to zrobić, ale podzielę się tym, jak to robię.

W moich zespołach ważną częścią jest unikanie angażowania się we wspólny kod repo, który jest uszkodzony w sposób, który zmarnuje resztę czasu zespołu. Tylko w tym sensie staram się „dostarczać działający kod każdego dnia”. Nie łam QA. Nie blokuj innych programistów. Idealnie nigdy nie sprawdzam żadnych błędów. (ha ha).

Implikacja nie polega na tym, że musisz coś popełniać każdego dnia. Sugeruje to, że powinieneś popełniać tylko dobre rzeczy, aby każdego dnia można było uzyskać kompilację wszystkich dobrych rzeczy, które każdy popełnił. W ten sposób zespół strzela do wszystkich cylindrów.

W moich zespołach kontrola jakości jest stała. Buduję produkty komercyjne, więc projekt nigdy się nie kończy, dopóki produkt nie jest przestarzały. Inżynierowie ds. Kontroli jakości testują funkcje dostępne do testowania. Inżynierowie QA zawsze mają zaległości. Nigdy nie ma wystarczająco dużo czasu na kontrolę jakości lub automatyzację wszystkiego, czego idealnie chcielibyśmy.

Jeśli programiści potrzebują wielu dni przed scaleniem zmian dla funkcji lub poprawki, to dobrze, zachęcamy, jeśli pomaga im to w uzyskaniu odpowiedniego kodu, zanim zaryzykuje nasz czas. Programiści mogą przekazywać kod do swojego prywatnego repozytorium lub oddziału bez wpływu na zespół lub kontrolę jakości. Programiści mogą uruchamiać testy jednostkowe lub automatyzację regresji na kodzie zbudowanym z repozytorium dewelopera lub oddziału prywatnego. W szczególnie ryzykownych przypadkach Inżynier ds. Kontroli jakości będzie współpracować z programistą w celu przetestowania przed połączeniem, aby chronić zespół przed opóźnieniem.

W tym sensie ćwiczę to, czego chcą Twoi menedżerowie. Niemal codziennie przez ostatnie 12 lat moje zespoły programistyczne miały kod działający we współdzielonym repozytorium. Zawsze jesteśmy prawie gotowi do wysyłki. Czasami nie osiągamy tego, ale nie przejmujemy się tym zbytnio. Czasami jest celowe, aby uwzględnić poważne zmiany narzędzi lub trudne połączenia.

Dla mnie Manifest Agile stanowi podsumowanie nowego sposobu myślenia o procesie rozwoju, który pojawił się w latach 90. Prawie wierzę w te zasady, ale szczegóły procesu mogą się różnić. Moim zdaniem zwinne jest dostosowanie procesu do potrzeb produktu i klientów, a nie bycie niewolnikiem przetwarzania.

Jeśli miałeś działające oprogramowanie wczoraj, dlaczego nie miałoby działać dzisiaj? Jeśli nie ukończyłeś dzisiaj żadnych zadań, dzisiejsza wersja będzie taka sama jak wczoraj. Codzienne kompilacje i tempo rozwoju to osobne rzeczy. To, że masz codzienne wersje, nie oznacza, że ​​masz nowe funkcje w każdej wersji.

Kiedy w końcu jakaś funkcja zostanie ukończona i zameldowana w głównej gałęzi, powinieneś mieć zautomatyzowany proces, który tworzy oprogramowanie i uruchamia testy. Jeśli wystąpi problem z budowaniem lub uruchomieniem testów, zespół jest powiadamiany i dokładają wszelkich starań, aby ponownie uruchomić. Tak działa CI i pomaga w ciągłym wypuszczaniu działającego oprogramowania.

Krótka odpowiedź: Nie . Po prostu nie można tego robić codziennie.

Zwinny zespół miał jednak dostarczać działające elementy oprogramowania lub historie użytkowników w każdym sprincie . Zwykle spotkania statusu odbywają się codziennie, aby zobaczyć postęp i przeszkody.

Jeśli chodzi o oprogramowanie wysokiej jakości , obowiązujące procesy ciągłej integracji (CI) zapewnią, że kontrola jakości zostanie zastosowana do niewielkich nakładów pracy (odprawy) i będzie przeprowadzana tak często, jak skonfigurowano. Ma również na celu poprawę quality of softwarei skrócenie czasu potrzebnego na jego dostarczenie, zastępując tradycyjną praktykę stosowania kontroli jakości po zakończeniu całego rozwoju.

Nie, nie należy oczekiwać dostarczania nowych funkcji każdego dnia. Nie wszystkie funkcje można podzielić na tak małe, aby deweloper mógł ukończyć tę funkcję w około 6 godzin czasu programowania.

Jeśli wykonujesz scrum, powinieneś ćwiczyć na co najmniej 2-tygodniowych sprintach, z funkcjami, których ukończenie zajmie około 0 do 8 dni. Obietnicą dla właściciela produktu jest dostarczenie nowego, przetestowanego i zweryfikowanego poprawnego kodu roboczego, który można wprowadzić do produkcji na koniec sprintu. (UWAGA: Nie trzeba go faktycznie wprowadzać do produkcji, ale celem jest, aby tak było, gdybyś chciał)

Dobra metodologia sugerowała skonfigurowanie serwera CI (Continuous Integration), na którym zautomatyzowano tworzenie co najmniej jednej codziennej wersji działającego oprogramowania. Chodzi o to, by sprawdzić kod, jak tylko skończysz tę funkcję, aby mogła być w następnym cyklu kompilacji, a następnie w rękach kontroli jakości w celu przetestowania.

Pamiętaj, że celem jest wykonanie i przetestowanie funkcji do końca sprintu! Nie będziesz musiał zmuszać kontroli jakości do ostatniego dnia sprintu, abyś mógł zbudować kompilację, a następnie kazał im przetestować wszystkie funkcje. Nie będą mieli czasu na przetestowanie wszystkiego, a ty nie będziesz miał czasu na naprawienie błędów ...

Jeśli nie możesz skonfigurować serwera CI, praktyka powinna polegać na tym, że musisz ręcznie tworzyć nową kompilację do kontroli jakości za każdym razem, gdy programista sprawdza gotowy kod i twierdzi, że jest gotowy z funkcją i gotowy do przekazania kontroli jakości.

To zależy od wielkości projektu; jeśli projekt jest duży, nie ma realnego sposobu na osiągnięcie tego.

Codzienne (a nawet częściej) kompilacje, które powstają z narzędzi ciągłej integracji, nie oznaczają działającego oprogramowania; ledwo oznacza kompilowalny kod.

Istnieje wiele projektów, które dostarczają codzienne kompilacje, które dzięki ciągłej integracji działają oprogramowanie. Przynajmniej w teorii.

Oznacza to, że niekoniecznie zawiera nowe funkcje. Może kilka drobnych poprawek lub wcale.

Teoretycznie, jeśli nie jesteś w stanie zapewnić codziennej kontroli jakości więcej pracy, musisz albo zwiększyć liczbę programistów, albo zmniejszyć liczbę testerów. Okropny pomysł!

Twoim zadaniem jest załatwienie sprawy.

Powiedz QA, że dostaną coś do przetestowania, kiedy to się skończy. Musisz wyjaśnić im, dlaczego.

Myślę, że nie rozumiesz idei „CI”. Możesz odwiedzić ten znakomity artykuł Martina Fowlera na temat tego, jak CI działa w praktyce. To powinno odpowiedzieć poprawnie na twoje pytanie.