W zwinny sposób, w jaki sposób podstawowe zadania infrastrukturalne na początku projektu są planowane i przydzielane przy użyciu ścisłych ram zarządzania, takich jak TFS online?

Tutaj jestem w trakcie określania zakresu i szacowania stosunkowo małego projektu rozwoju nowego oprogramowania. Zapoznałem się z historiami użytkowników zasugerowanymi przez klienta i umieściłem zadania dla każdego z nich, wraz z oszacowaniem i krótkimi notatkami na temat tego, jak zadanie zostanie wykonane. Istnieją kryteria akceptacji. Wszystko powinno być dobre dla świata.

Patrząc na zaplanowaną pracę, zdałem sobie sprawę, że czegoś brakuje. Pierwszym nakładem będzie po prostu konfiguracja rzeczy, w które możemy wzmocnić funkcjonalność. Rzeczy, które należą do wszystkich historii użytkowników, a nie do jednej konkretnej historii użytkownika.

Na przykład część tej aplikacji to usługa analizująca XML. Z punktu widzenia użytkownika istnieją określone historie, w których należy wykonać różne czynności w zależności od zawartości XML. Właściwie pisanie parsera XML - bitów, które szukają pliku, czytają go i wyciągają odpowiednie dane przed podjęciem decyzji, co zrobić z zawartością - jest częścią tych wszystkich historii. Podobnie jak pakowanie go w usługę systemu Windows za pomocą instalatora itp. Jest to zadanie zorientowane na programistę, bez bezpośredniego związku z użytkownikiem.

Innym istotnym przykładem z tej konkretnej aplikacji jest pobieranie i przepisywanie bloku słabego starszego kodu, który jest użyteczny dla funkcji tej aplikacji. Ponownie, nie ma to natychmiastowych rezultatów dla użytkownika, ale wymaga pracy. Gdzie planowanie i realizacja tej pracy „na żywo” w planie projektu skoncentrowanym na historiach użytkowników?

Widziałem, jak ludzie rozwiązują ten problem, pisząc historie użytkowników „Jako programista chcę ...”, ale jak już wcześniej wspomniano, nie jest to historia użytkownika . To jest programista.

Szukam konkretnej odpowiedzi na to pytanie, aby pomóc mi (i innym) w planowaniu projektów przy użyciu ścisłych ram zarządzania, takich jak TFS online. Nie mają one zazwyczaj funkcji tworzenia „historii zainteresowanych stron” ani innych niejasnych meta-rozwiązań wymienionych w odpowiedziach na pytanie, w jaki sposób zespół Scrumowy uwzględnia zadania infrastrukturalne podczas spotkania planistycznego?

Podobają mi się inne odpowiedzi, które mówią o umieszczeniu w iteracji 0. jak największej liczby „narzędzi” kodu. Jednak czasem tego rodzaju narzędzia pojawiają się po rozpoczęciu projektu. Być może w Iteration 3 zdajesz sobie sprawę, że potrzebujesz uogólnionego widgetu analizatora składni XML, który będzie używany w różnych historiach.

W takim przypadku pierwszą historią użytkownika, która opiera się na tych wewnętrznych elementach architektonicznych, jest ta, do której należą . Jeśli masz zamiar pracować nad Historią # 345 i będzie ona zależeć od twojego parsera XML, zanim będzie mogła zostać uznana za „zrobioną”, to twój parser wielokrotnego użytku zostanie dołączony jako praca do ukończenia tej historii.

Mój zespół zastosował powyższe podejście i wydawało się, że działa dobrze dla nas.

Jeśli jest to infrastruktura, zwykle jest wprowadzana w Iteration Zero. Czym jest zero iteracji? Zwykle jest to czas między rozpoczęciem a planowaniem, zanim zaczną się rzeczywiste iteracje.

Przykład: powiedzmy, że potrzebujemy nowej usługi internetowej. Muszę więc stworzyć projekt, skonfigurować ciągłą integrację, skonfigurować repozytorium kontroli źródła, skonfigurować skrypt kompilacji i automatyczne wdrożenie itp. Użytkownicy tak naprawdę nie dbają o to, ale potrzebujemy ich niezależnie.

Tak więc praca ta byłaby wykonana w iteracji 0. Do czasu uruchomienia iteracji 1 istniałaby już nowa powłoka projektu, która skompilowałaby się, miała zautomatyzowany skrypt kompilacji i wdrożyła się. Teraz nie będzie żadnej funkcji użytkownika, ale jest gotowa do działania.

Nadal bym śledził i planował tę pracę w ramach iteracji 0.

Refaktoryzacja brzmi jak historia techniczna, która może przejść w dowolnej iteracji.

Zależy od infrastruktury.

Jeśli infrastruktura jest bardzo znacząca lub musi być zgodna ze skomplikowanymi przepisami dotyczącymi zgodności, możesz mieć oddzielny zespół infrastruktury, który może mieć własny harmonogram. To może być Zwinny, to może być wodospad. W takim przypadku budowa infrastruktury byłaby zarządzana w projekcie jako zależność zewnętrzna .

Jeśli twoja drużyna będzie zarządzać infrastrukturą i skonfigurować ją tylko raz, możesz użyć techniki iteracji 0, którą opisuje Jon.

Jeśli konfiguracja infrastruktury zajmie kilka iteracji (np. Może skonfigurowałeś teraz swój serwer kompilacji, ale serwery kontroli jakości i serwery przedprodukcyjne zostaną zbudowane nieco później), to ich budową można zarządzać jako niefunkcjonalne PBI. Funkcjonalne PBI mogą mieć pewne zależności od nich, które można skodyfikować w TFS za pomocą łącza „poprzednik”.

I oczywiście możesz łączyć i dopasowywać wszystkie powyższe. Na przykład nie można wiele zrobić bez ciągłego kompilowania serwera, więc można to zrobić w iteracji 0. Tymczasem Twoje serwery preprodukt mogą być zdefiniowane jako zadania dla iteracji 2 i 3 i mogą mieć zewnętrzne zależności od zespołu DBA ( którzy nie są zwinni), którzy będą alokować instancje DB w Twoim centrum danych. A może trzeba czekać na wydanie certyfikatów SSL dla niektórych funkcji; mogą przejść do iteracji 4, a wszelkie elementy funkcjonalne, które opierają się na tych certyfikatach, powinny być z nimi powiązane za pomocą relacji poprzednik / następca.

We wszystkich przypadkach pamiętaj:

1. Zawsze określ jasne kryteria akceptacji. Faceci ze sprzętem mają irytującą tendencję do wstania z serwera i nazwania go wykonanym, gdy nie został on w ogóle sprawdzony.
2. Podczas rozpoczęcia iteracji zespołu zespół będzie musiał zbadać zależności i ich dostępność przed zaangażowaniem się w dowolny PBI lub element pracy.