agile planning with microsoft team foundation server
W tym samouczku wyjaśniono, jak przeprowadzić planowanie zwinne przy użyciu programu Microsoft TFS, co pomoże kierownikom projektów w planowaniu i śledzeniu pracy w zespołach:
Wśród różnych artykułów opublikowanych na SoftwareTestingHelp.com na temat DevOps widzieliśmy kilka dobrych artykułów na temat DevOps z punktu widzenia ciągłej integracji i ciągłego dostarczania przy użyciu Microsoft TFS, AWS i oczywiście narzędzi open source, takich jak Ansible.
Jednym z warunków wstępnych DevOps jest pewien silny proces, taki jak AGILE, który zapewnia zwinność całego procesu SDLC, w którym głównym celem jest bardzo terminowe wydawanie oprogramowania z krótszymi cyklami wydawania i szybkimi informacjami zwrotnymi. Tak więc zwinny proces koncentruje się głównie na szybkości.
Czego się nauczysz:
Planowanie zwinne przy użyciu Microsoft TFS 2017
Zanim przejdziesz przez różne sekcje tego artykułu, dobrze byłoby zapoznać się z niektórymi z ważne terminologie używane w Agile. Te terminologie będą używane w całym artykule.
Wymagania wstępne: Microsoft TFS 2017
Utwórz projekt zespołowy TFS przy użyciu szablonu procesu SCRUM
Zaczniemy od utworzenia projektu zespołowego TFS przy użyciu szablonu SCRUM, wykonując kroki wymienione poniżej.
Zaloguj się do Microsoft TFS 2017 i kliknij Nowy projekt.
Wprowadź nazwę projektu i wybierz Scrum jako szablon. Kliknij Stwórz.
Po utworzeniu projektu dodaj członków do projektu, klikając + Ikona.
Utwórz Backlog Produktu
Jak wiesz, Microsoft TFS jest zintegrowanym narzędziem ALM, które pomaga tworzyć elementy pracy, planowanie projektów, tworzenie definicji kompilacji i definicji wydania z funkcją wykonywania testów ręcznych.
Przed jakimkolwiek planowaniem Agile musimy zacząć od zdefiniowania Sprinty czyli z góry określone ramy czasowe pracy do wykonania. Kliknij Ustawienia -> Praca a następnie zdefiniuj sprinty z datami rozpoczęcia i zakończenia.
Wybierz Sprint i ustaw datę rozpoczęcia i zakończenia.
Tutaj skupimy się na tworzeniu elementów pracy, które będą stanowić integralną część planowania Agile. Zacznijmy więc od utworzenia rejestru produktu, który zawiera uszeregowaną pod względem ważności listę wszystkich funkcji, które mają być częścią aplikacji lub produktu.
Właściciel produktu dba o ten backlog iz pomocą zespołu scrumowego decyduje o możliwości pracy w danym sprincie.
Aby utworzyć rejestr produktu z pliku W menu sekcji pracy wybierz Backlogs.
Kliknij Nowy, wprowadź tytuł dla pozycji w rejestrze i kliknij Dodaj .
Element rejestru produktu zostanie dodany do rejestru. W sensie teoretycznym można traktować element rejestru produktu jako historyjkę użytkownika lub żądanie zmiany. Zwykle są rozkładane w wielu zadaniach programistycznych i przypadkach testowych.
Możesz również ponownie złożyć zamówienie na podstawie priorytetu. Po prostu przeciągnij i upuść elementy pracy powyżej lub poniżej.
Otwórz element pracy i dodaj nakład pracy. W tym przypadku wysiłek może być zgodny z potrzebami projektu dotyczącymi punktów fabularnych lub dni lub godzin. Oszacowanie nakładu pracy zostanie dodane po rozłożeniu elementu na zadania. Przypisz plik właściciel w sekcji „Assigned To” i ustaw „State” na Zatwierdzony dla rozwoju. Kliknij Zapisz i zamknij.
Następnie przypisz element do Sprintu 1, przeciągając i upuszczając go do Sprintu 1.
Ścieżka iteracji zmienia element na Sprint1, jak pokazano na poniższym obrazku.
Gdy przenosimy element do Gotowy Stan, Prędkość, która definiuje całkowitą liczbę punktów opowieści, które zespół scrumowy osiąga w sprincie, jest wyświetlana po kliknięciu wykresu Prędkości w prawym górnym rogu.
Podsumowując, możemy powiedzieć, że zespół ukończył 8 punktów fabularnych w Sprincie 1, jak pokazano na powyższym wykresie prędkości.
Planowanie wydajności
Dla każdego Sprintu możemy określić liczbę godzin, które każdy członek będzie pracował nad przypisanym projektem. Określa to widok pojemności dla każdego sprintu. Ten widok obejmuje również działania, nad którymi pracuje każdy członek, takie jak projektowanie, tworzenie, raportowanie itp.
Kliknij odpowiedni Sprint. W takim przypadku otwórz Sprint 1 i przejdź do Widok pojemności . Zaktualizuj, jak pokazano poniżej.
Na powyższym zrzucie ekranu, ponieważ użytkownik Dev1 pracuje tylko 4 godziny dziennie w okresie sprintu trwającym 2 tygodnie, czyli 10 dni roboczych. Plik Praca przydzielona pokazuje, że jest przydzielony do zadania, które wymaga 8 godzin z 40 godzin w okresie sprintu trwającym 2 tygodnie. Oblicza się to jako 4 (godziny dziennie) * 10 (2 tygodnie) = 40 godzin.
Podobne obliczenia są wykonywane dla użytkownika Dev2.
Tworzenie zadań
Ponieważ mamy teraz zdefiniowany element rejestru produktu lub historię użytkownika, a także pojemność zaplanowaną dla każdego użytkownika w projekcie, możemy teraz podzielić go na zadania programisty. Na ekranie roboczym kliknij ikonę Sprint 1 a następnie kliknij znak Dodaj zadanie + dla pozycji rejestru produktu.
Przypisz go do dewelopera i wprowadź wartość godziny dla pozostałego pola pracy. Kliknij Zapisz i zamknij.
Utworzone zadanie jest połączone z pozycją w rejestrze produktu.
W tym przypadku pole Pozostała praca to liczba godzin pozostałych do wykonania zadania. Ponieważ w powyższym przykładzie ustawiliśmy pole na 8 godzin i powiedzmy, że programista pod koniec dnia wykonał tylko 2 godziny pracy nad zadaniem, to pole pozostałej godziny zostanie zaktualizowane do 6. Możesz to zrobić 0, gdy nie ma już pracy lub pozostaje 1 godzina lub mniej pracy lub gdzieś pomiędzy 0 a 1 godziną.
Na podstawie tej wartości TFS może utworzyć wykres wypalania dla sprintu, który jest jedną z bardzo przydatnych metryk w Agile. Powyższy proces dotyczy szablonu SCRUM i nie ma pola Original Estimate w elemencie roboczym Zadanie.
Jeśli projekt zespołowy TFS jest skonfigurowany przy użyciu szablonu procesu Agile lub CMMI, istnieje możliwość wprowadzenia pola Original Estimate.
Aby dodać pole Pierwotne oszacowanie ( Microsoft.VSTS.Scheduling.OriginalEstimate ) w typie elementu pracy Zadanie używającym szablonu procesu SCRUM należy go dodać jako pole niestandardowe. Możesz użyć witadmin exportwitd , która jest opcją wiersza poleceń. Dodaj pole w wyeksportowanym pliku XML i zaimportuj je z powrotem do projektu zespołowego.
Przyszłe sprinty
Element rejestru produktu lub historię użytkownika można również zaplanować na przyszłość, przeciągając element i upuszczając go na dowolny inny przyszły sprint.
Korzystanie z tablicy zadań
Ponieważ plan sprintu jest gotowy, możemy teraz wyświetlić postęp każdego zadania z widoku tablicy zadań. Tablica zadań zapewnia więc wizualny przepływ zadań i ich stanu. Tak więc podczas każdego spotkania scrumowego możesz przyjrzeć się statusowi każdego zadania przydzielonego członkom.
Możesz również wyświetlić podsumowanie całej pozostałej pracy do wykonania.
Monitorowanie statusu i postępów jest bardzo ważne i można to zrobić za pomocą tablicy zadań. Kliknij na Widok tablicy na Sprint.
brama domyślna niedostępna windows 10 wifi
Ta tablica jest bardzo użytecznym widokiem i może być używana do celów raportowania podczas codziennych spotkań.
do) Jeśli programiści z przypisanymi zadaniami rozpoczęli pracę nad zadaniami, możesz przenieść zadania z Do zrobienia stan do W trakcie stan, po prostu przeciągnij i upuść funkcję.
b) Zmień pozostałe godziny pracy zadania dla użytkownika Dev2 z 8 do pozostałych godzin 5. Godziny zadań w toku zostaną odpowiednio zaktualizowane.
do) Wykres spalania, po kliknięciu w prawym górnym rogu, jest automatycznie aktualizowany.
re) Teraz zamknij zadanie przypisane do Dev2, przeciągając i upuszczając zadanie Gotowy stan. Pozostałe godziny pracy dla tego zadania są automatycznie zmniejszane do 0, a wykres spalania jest również aktualizowany.
Przegląd i retrospektywa sprintu
Cóż, praca jest już zakończona, a ramy czasowe sprintu się skończyły. Czy zespół uważa, że nadszedł czas na relaks lub przerwę? Absolutnie duże NIE. Nadszedł czas, aby omówić bardzo ważną część cyklu życia SCRUM, jaką jest przegląd i retrospektywa.
Przegląd sprintu koncentruje się na rezultatach, przeglądaniu elementów z rejestru produktu DONE i udostępnianiu klientom wersji demonstracyjnej. Ponadto bardzo ważne jest, aby omówić, które pozycje z backlogu produktu nie zostały wykonane i dlaczego, a co najważniejsze, zebrać opinie klientów i zaplanować je na przyszłe sprinty. Przegląd sprintu jest zwykle wykonywany między właścicielem produktu, zespołem programistycznym i klientami.
Retrospektywa sprintu skupia się na takich aspektach procesu, jak to, co poszło dobrze, a co nie? Będziesz więc musiał również zebrać informacje zwrotne na temat procesu i ludzi. Ponieważ jest to bardzo ważny aspekt cyklu życia Agile, możesz dowiedzieć się więcej retrospektywy.
Jest więc bardzo prawdopodobne, że w każdym sprincie może być niedokończona praca. W tym scenariuszu przenieś PBI / Zadania albo do Backlogu Produktu albo do następnego Sprintu, który zdecyduje Właściciel Produktu.
Ale na razie gdzie przechowujemy recenzje i retrospektywy? Można je zapisać jako część dyskusji nad elementem roboczym lub utworzyć nowy element pracy, w którym będą przechowywane retrospektywne punkty działań i informacje zwrotne.
Wniosek
W tym artykule widzieliśmy, jak Microsoft Team Foundation Server jako narzędzie ALM zapewnia szybki i schludny sposób rozpoczęcia pracy nad aplikacją zgodnie z procesem Agile Scrum.
Musimy zapewnić, że wszystkie zespoły postępujące zgodnie z procesem Agile SCRUM muszą zdefiniować i stworzyć następujące aspekty, aby właściwie planować i zarządzać pracą swojego zespołu.
- Użyj odpowiedniego szablonu procesu SCRUM w Microsoft TFS
- Twórz rejestry produktów
- Określanie harmonogramu Sprintu i zdolności zespołu
- Wybieranie pozycji do rejestru sprintu
- Rozkładanie PBI lub historii użytkowników na zadania
- Użyj wykresów Burndown, aby śledzić postępy
- Bardzo ważne jest używanie tablicy zadań do monitorowania postępów
- Na koniec przeprowadź skuteczny przegląd sprintu i retrospektywę
rekomendowane lektury
- Jak być dobrym mentorem zespołu, trenerem i prawdziwym obrońcą zespołu w świecie testów zwinnych? - Inspiracja
- Terminologia Agile i Scrum: Słownik pojęć Agile / Scrum
- Jak sprawić, by proces oszacowania był łatwy dzięki Planning Poker
- Nowoczesne zasady testowania metodologii zwinnej w testowaniu
- Samowystarczalne zespoły Scrumowe: jak stworzyć samowystarczalny zespół?
- Zwinne spotkania retrospektywne - dlaczego jest to konieczne i zabawne sposoby ich prowadzenia
- 4 kroki w kierunku rozwoju podejścia do testowania zwinnego w celu pomyślnego przejścia do procesu zwinnego
- Format egzaminu ISTQB Foundation i wytyczne dotyczące rozwiązywania prac