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ł.
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.
źródło
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 software
i skrócenie czasu potrzebnego na jego dostarczenie, zastępując tradycyjną praktykę stosowania kontroli jakości po zakończeniu całego rozwoju.źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło