Dlaczego ALM ?
praca zespołowa, łatwe zarządzanie zespołem, dodawanie nowych członków
organizacja projektu, przepływ informacji w zespole
kontrola kodu, ograniczenie błędów
dbałość o jakość produktu
zwiększenie produktywności
większa szansa sukcesu, ograniczenie kosztów
Systeem do zarządzania projektami programistycznymi.
zarządzanie projektami (różne schematy: Agile, kaskadowy,…) - process templates
serwer kontroli wersji (Team Foundation Version Control, Git, SVNBridge)
wspiera zarządzanie pracą w zespole
wspiera koordynowanie budowania aplikacji na różne platformy
rozbudowany system raportów
automatyzacja: build, testy (kodu, aplikacji), środowisko uruchomieniowe, raporty, powiadomienia, deployment…
zarządzanie wymaganiami, kosztami, ocena ryzyka
współpraca z innymi produktami MS Project, Web Acces, …
Rdzeń systemu zarządzania cyklem życia aplikacji (application lifecycle management – ALM).
VisualStudio
Test Manager (testowanie aplikacji)
MS Project - zarządzanie projektem i zadaniami (m. kaskadowa), analiza ryzyka
Excel - zarządzanie zadaniami
Office - wymiana dokumentów
WebAcces
PowerPoint (od TFS 2013), storyboard (analiza wymagań), moźliwośc połączenia z zadaniami
Team Explorer Everywere: wtyczka Eclipse + klient konsolowy (także Linux)
-
metoda przyrostowa : produkt powstaje w kolejnych iteracjach
sprawny (ale niekompletny) produkt już po pierwszej iteracji
sprawna kontrola nad przebiegiem prac (narzędzia TFS)
wczesne wykrywanie problemów
zespoły 7+-2
kontrola czasu - czynność musi być zakończona w określonym czasie
Zespół ma charakter samoorganizujący
product owner - odpowiada za projekt przed klientem
scrum master - odpowiedzialny za proces wytwarzania, organizację pracy, podział ról
team members
sprint - iteracja: planowanie, realizacja, podsumowanie
planowanie sprintu () - wybór zadań, czas realizacji zadań z góry ustalony, lista zadań nie powinna się zmieniać w czasie iteracji
codzienny scrum: spotkanie 15 min. na stojąco prowadzone przez scrum master
przegląd: podsumowanie na zakończenie sprintu, retrospektywa sprintu
product backlog - rejestr produktu, odpowiedzialny właściciel
sprint backlog - lista zadań w sprincie, odpowidzialny master i zespół
effort - wskaźnik postępu ukończenia kolejnych funkcjonalności
Typowy cykl życia zgłoszenia:
osoba posiadająca uprawnienia do raportowania wprowadza informację o błędzie
osoba lub system określa osobę, której dotyczy błąd i generowane jest powiadomienie
(jabber, email i inne kanały komunikacji),
osoba, która otrzymała powiadomienie, akceptuje go do poprawy lub deleguje ten błąd do innej osoby,
osoba odpowiedzialna kończy pracę nad błędem na jeden z kilku sposobów – informując, że błąd został poprawiony, odłożony w czasie, nie jest możliwy do poprawy czy, że zgłoszenie błędu było niepoprawne,
jeśli błąd usunięto, osoba odpowiednio uprawiona osoba weryfikuje, czy błąd faktycznie został usunięty i zwykle zgłoszenie błędu jest zamykane.
po ostatecznym rozwiązaniu problemu (np. po opublikowaniu albo instalacji u klienta wersji pozbawionej błędu) błąd jest zamykany.
Żródło: http://trac.edgewall.org/chrome/common/guide/basic-workflow.png
Inne przykłady
task, bug, issue, user story, test case, …
połączenia między zadaniami: hierarchiczne lub płaskie
każdy typ posiada swój własny cykl życia
możliwość definiowania własnych typów (XML)
integracja z systemem kontroli wersji, z systemem buildów, testów
połączenia zadań z różnymi zasobami: strony www, dokumenty, multimedia,
Team Foundation Version Control
synchronizacja plików serwer ↔ kopia robocza (Workspace)
Check out - pobieranie źródeł z repozytorium
aktualizacja do najnowszej wersji
Check In - wysłanie lokalnej wersji do repozytorium
pobieranie konkretnej wersji z historii (changeset)
przeglądanie plików w repozytorium, dodawanie, usuwanie i zmiana nazwy i położenia plików i katalogów
pending changes, oglądanie aktualnie naniesionych zmian, cofanie zmian, śledzenie historii zmian
Lock/unlock - blokowanie plików i katalogów
rozwiązywanie konfliktów
porównanie różnych wersji plików i katalogów
tworzenie gałęzi (Branch) i łączenie gałęzi (projekty, katalogi, pliki)
odkładanie na półkę (Shelve)
etykiety (labels) - wersje zamrożone
właściwości plików i katalogów
kompilacja na różne architektury
testy: unit test, web test, load test
wirtualne testowe środowisko uruchomieniowe
powiadomienia, np. e-mail
raporty:
wykresy przyrostu
statystyki: ilość zamkniętych zadań, wykrytych błędów, itp.
statystyki dla poszczególnych osób
CodePlex Project Hosting for Open Source Software
About the CodePlex Site
„CodePlex is Microsoft's open source project hosting web site. You can use CodePlex to create new projects to share with the world, join others who have already started their own projects, or use the applications on this site and provide feedback.”
30 dni bez konieczności publikacji (konfiguracja projektu, opis, import źródeł, ustawienia dostępu, licencja)
source control:
strona WWW projektu, nazwa_projektu.codeplex.com, wiki opisujące projekt
dostęp do repozytorium, przeglądanie historii plików
downloads - wersje do pobrania, recenzje oprogramowania
dokumentacja projektu, wiki
lista dyskusyjna
issue tracker, przeglądanie i zarządzanie zadaniami
zarządzanie członkami projektu, przydział ról i dostępu
śledzenie postępów i aktywności w projekcie, RSS, powiadomienia e-mail
Licencje: open source, 10 do wyboru (np. GPL2)
Role (Uprawnienia)
editor
coordinator
developer
tytuł
opis
Status: Proposed, Active, or Fixed.
Type: Feature, Issue, or Task.
Impact: Low, Medium or High.
Assigned To: coordinators or developers.
Component: No component
załączone pliki
Okna
Source Control Explorer - zarządzanie projektami, katalogami i plikami umieszczonymi z systemie kontroli wersji TFS
Team explorer - zarządzanie zadaniami, raporty, harmonogramu kompilacji i automatycznych testów
Work Items, filtrowanie za pomocą zapytań (Queries), edytor zapytań
Builds, okno Build Explorer
Source Control
Pending Changes (oczekujące zmiany), zmiany dokonane w lokalnej kopii roboczej
TFS w Chmurze
brak możliwości definiowania szablonów procesu wytwórczego
brak wsparcia dla Lab Menagement
automatyczna, skalowalna farma buildów (lokalnie potrzeba wielu serwerów automatyzujących ten proces)
w praktyce nieskończenie skalowalne testy obciążeniowe
nowe funkcjonalności co 3 tygodnie (wersja serwerowa co 3 miesiące)
