Ustanawianie nadzoru nad wspólnym projektowaniem

Ustanowienie skutecznych ram zarządzania wspólnym rozwojem jest ważnym elementem zapewniania spójności i powtarzalności w projektach definiowanych przez producenta i zespołach multidyscyplinarnych. W tym artykule opisano podejście do definiowania schematu zarządzania.

Definiowanie procesu od końca do końca

Poniższy proces można użyć jako przykładu i dostosować go do najlepszych rozwiązań organizacji. Nie jest konieczne ukończenie każdego kroku, o ile uzyskasz wymagany wynik.

Dodawanie funkcjonalności do backlogu

Listy prac umożliwiają zaplanowanie projektu przez dodanie funkcji, które wpływają na ogólny poziom obsługi. Lista prac pozwala również na ogólne wsparcie zespołu.

Podczas dodawania nowej funkcji do listy prac celem jest opisanie ogólnego zakresu. Każda funkcja definiuje wartość biznesową, wstępne tytuły historyjek, zakres i zmiany w modelu danych, które napędzają rozwój kodu.

Ponadto podczas dodawania funkcji krytycznej dla działania firmy zaleca się zidentyfikowanie wszelkich krytycznych scenariuszy w celu zautomatyzowania testowania. Po dodaniu swoich funkcji można zaplanować spotkanie w zakresie wyrównania.

Spotkanie dotyczące uzgodnienia zakresu

Skupienie się na tym spotkaniu powinno być ograniczone do przeglądania każdej proponowanej nowej funkcji, a następnie sprawdzania istniejących aplikacji, scenariuszy lub modeli danych, które już udostępniają tę funkcję, aby uniknąć duplikowania wysiłków. To spotkanie daje również możliwość omówienia wpływu na inne aplikacje. Ostatecznie należy sprawdzić, czy ta funkcja wymaga przeglądu doświadczenia.

Dodaj nową historię i serię ujęć do listy prac

Po zakończeniu spotkania w zakresie wyrównania można w obszarze funkcji dodać dowolne tytuły historii użytkowników wersji roboczej. W tym momencie szczegóły nie są wymagane, a stan historii użytkownika to "Nowy". Można je wyświetlić w widoku listy prac lub tablicy.

Na poniższej ilustracji przedstawiono przykładową historię użytkowników dodaną do listy zaległych.

W tym momencie ważne jest utrzymanie jakości dzięki organizowaniu pracy według strumienia pracy i aplikacji. Takie podejście pomaga zachować powiązane elementy robocze razem i umożliwia ekspertom w każdym strumieniu pracy opracowywanie i utrzymywanie głębokiego zrozumienia funkcjonalności i użycia danych w każdej aplikacji.

Przegląd doświadczenia

Przeglądy doświadczeń powinny skupić się na doświadczeniach użytkownika końcowego i upewnić się, że Państwa zespół przestrzega najlepszych praktyk organizacji. Ta spójność zapewnia, że wszystkie aplikacje zapewniają niezawodną i powtarzalną obsługę dla użytkowników końcowych i zespołów pomocy technicznej.

Dodawanie szczegółów artykułu

Dodanie typowej historii użytkownika może zawierać następujące informacje:

1. Tytuł: Jako <persona> mogę <zrobić coś, co><będzie miało wpływ/priorytet/wartość>
2. Opis: Opis zawiera (chociaż nie jest ograniczony do) pewnych kluczowych szczegółów, takich jak:
   • Krótki opis scenariusza, który podsumowuje żądany wynik
   • Narracja — opisuje działania podejmowane przez użytkowników w celu nawigowania i realizacji scenariusza
   • Alternatywna narracja — opisuje inne sposoby, w jaki użytkownicy mogą osiągnąć ten sam wynik
   • Uwagi dotyczące projektowania — rejestruje jednostkę, pola, widoki, ekrany makiety i reguły biznesowe skojarzone z historią użytkownika
   • Role bezpieczeństwa dotknięte zmianą — zawiera listę wszystkich ról bezpieczeństwa związanych z historią użytkownika.

Po dodaniu wszystkich tych szczegółów zmienisz stan historii użytkownika na "Gotowe do przeglądu". W większości przypadków zespół funkcji i zespół biznesowy (jeśli dotyczy) przeglądają historie użytkowników.

Przegląd scenariusza

Przeglądy historii zazwyczaj występują w zespole multidyscyplinarnym tak, aby upewnić się, że wszystkie szczegóły są wywoływane w historii i że nie będzie żadnych wątpliwości. Po zakończeniu wszystkich przeglądów zaleca się przypisanie historii użytkownika do członka zespołu. Zapewnienie, że twój zespół pozostaje spójny podczas procesu rozwoju, ma kluczowe znaczenie dla osiągnięcia ogólnych celów.

Dodawanie zadań i przypadków testowych

Po przejrzeniu scenariuszy członkowie zespołu tworzą zadania w usłudze Azure DevOps. Ogólny proces dodawania zadań i przypadków testowych jest następujący:

1. Otwórz log. Alternatywnie utwórz nowy sprint.
2. Dodaj istniejące elementy robocze do sprintu. Jeśli elementy robocze, które nie są już wyświetlane w obszarze, zostały już dodane, należy sprawdzić ich obszar i ścieżki roweru. Należy pamiętać, aby przypisywać wszystkie zadania bez elementów nadrzędnych do odpowiednich elementów pracy.
3. Dodaj zadania do elementów listy prac. Jeśli do użytkownika nie przypisano elementów listy prac, należy to zrobić teraz. Ustaw również daty rozpoczęcia i zakończenia sprintu.
4. Wypełnij formularz zadania. Zgodnie z ogólną zasadą zadania nie powinny trwać dłużej niż dzień. Zadania, które są większe niż ten harmonogram czasowy, powinny zostać podzielone.
5. Śledzić lub integrować wszelkie nierozsądne zadania. Możesz śledzić nierozsądne zadania, tak jak inne, lub przeciągnij je do istniejącego elementu listy prac do elementu nadrzędnego.

Po dodaniu zadań i przypadków testowych możesz przystąpić do ustawiania wydajności sprintu.

Aby uzyskać więcej informacji na temat dodawania zadań, zobacz Dodawanie zadań do backlogu, aby wspierać planowanie sprintu.

Przygotowywanie rozwiązań

Ważnym aspektem pomyślnego współtworzenia jest ustrukturyzowany proces zarządzania wydaniami. Rozwiązania to mechanizm implementowania zarządzania cyklem życia aplikacji (ALM); rozwiązania służą do dystrybuowania składników między środowiskami za pośrednictwem działań eksportu i importowania. Składnik reprezentuje artefakt używany w twojej aplikacji i coś, co możesz potencjalnie dostosować do swoich potrzeb. Składnikiem jest wszystko, co można włączyć do rozwiązania, np. tabele, kolumny, aplikacje kanwy i aplikacje oparte na modelu, przepływy Power Automate, czatboty, wykresy i dodatki plug-in.

Wdrożenia

Składniki mogą wymagać przeprowadzenia wielu sprintów w zależności od stopnia złożoności i szybkości działania zespołu. Składniki powinny być dodawane do rozwiązania w środowisku deweloperskim w miarę ukończenia zadań. Następnie rozwiązania są importowane do środowiska produkcyjnego po ich przetestowaniu. Zalecamy również obsługę jednego środowiska testowego w celu przeprowadzenia kompleksowego testowania i wypróbowania wdrożenia rozwiązania przed przejściem do środowiska produkcyjnego.

Środowiska platformy Power Platform

Środowiska to przestrzeń do przechowywania i udostępniania danych biznesowych, aplikacji i procesów biznesowych organizacji oraz zarządzania nimi. Służą one również jako kontenery do oddzielania aplikacji, które mogą mieć różne role, wymagania dotyczące zabezpieczeń lub docelowe grupy odbiorców.

Jeśli Twoja organizacja ma fuzję zespołów, gdzie każdy zespół opracowuje własne rozwiązania, ważne jest, aby koordynować czas trwania sprintów i wydań. Sprinty nie muszą mieć spójnej długości w harmonogramie projektu i mogą się różnić długością między zespołami, zgodnie z preferencjami każdego zespołu. Jednak czas trwania wydania nie może być krótszy niż krótki dla wszystkich zespołów.

Kontrola źródła

Rozważ wdrożenie systemu kontroli kodu źródłowego, takiego jak Azure DevOps. Azure DevOps oferuje deweloperom możliwość obsługi zespołów w celu planowania pracy, współpracy w zakresie projektowania kodu oraz budowania i wdrażania aplikacji.

Wyeksportowanie rozwiązania ze środowiska projektowego zawierającego aplikacje i dostosowania, rozpakowanie rozwiązanie i przechowanie składników w systemie kontroli źródła.

Zaawansowane temat: opinie funkcji pull request (PR)

Tworzenie usług PRs należy tworzyć tylko dla aktywnych i zatwierdzonych funkcji. Należy upewnić się, że wersjonowanie rozwiązań jest dokładne, zgodnie z wytycznymi sprint i dev określonymi w temacie Implementowanie praktyk Scrum dla twojego zespołu w Azure Boards. Wyniki testów z pr mogą być zrzutami ekranów lub filmów wideo przedstawiających wbudowane funkcje.

Automatyzacja procesu poprawy jakości materiałów pr pomaga zapewnić jakość kodu bez konieczności ręcznego przeglądu podstawowych testów, takich jak wersje rozwiązania.

Szablony i standaryzacja

Szablony i standaryzacja zapewniają wydajność, pomagając promować spójność w zespole. Wszystkie aspekty operacji zespołu — niezależnie od tego, czy są to zadania onboardingowe, prezentacje przeglądu historii, czy szablony elementów roboczych, które pomagają zaoszczędzić czas i zapewniają wskazówki zespołom podczas definiowania historii użytkowników, funkcji, usterek lub zadań — korzystają z standaryzacji i uproszczenia.

Implementowanie efektywnego modelu pomocy technicznej

Skuteczny model pomocy technicznej jest niezbędny dla długoterminowego sukcesu aplikacji po jej wdrożeniu, jak opisano w poprzedniej sekcji dotyczącej generowania macierzy obsługi. Błędy i awarie są nieuniknione, dlatego ważne jest, aby zespół miał ustrukturyzowane podejście do radzenia sobie z tymi wystąpieniami, a macierz obsługi zapewnia niezbędną strukturę.

Tworzenie umowy dotyczącej poziomu usług

Kluczowym czynnikiem w każdym modelu pomocy technicznej jest definicja umowy dotyczącej poziomu usług (SLA). Umowa SLA powinna być formalnym dokumentem, który zespół sporządza, zawierający sekcje, które obejmują następujące elementy:

• Awarie — jaki poziom awarii usług jest akceptowalny, kogo poinformować, jakie działania należy podjąć, potwierdzić wznowienie usługi i akcje, aby zapobiec powtórzeniu. Wszelkie zautomatyzowane procedury testowania używane przez zespół muszą być zgodne z oczekiwaną tolerancją awarii i odpowiednią umową SLA.
• Usterki — osoba odpowiedzialna za rozwiązanie problemu i wylogowanie się z rozwiązania problemu, przypisanie do nich poziomów klasyfikacji, akcji wykrywania.
• Eskalacje — poziomy eskalacji, przydzielanie pracowników do poziomów, obowiązki na każdym poziomie, listy dystrybucyjne dla każdego poziomu itd.

Umowa SLA powinna być przechowywana w portalu dokumentacji zespołu i aktualizowana zgodnie z potrzebami.

Dostarczanie obsługi aplikacji

Najlepszym podejściem do zapewnienia obsługi aplikacji określonej w umowie SLA jest to, aby zespół, który utworzył to rozwiązanie, również był odpowiedzialny za jego wsparcie. Zalety tego systemu to:

1. Zachęca to do opracowywania lepszej jakości, ponieważ ci, którzy utworzyli aplikację, wiedzą, że będą musieli ją obsługiwać.
2. Twórcy będą mogli znajdować i naprawiać usterki szybciej niż zespół innych firm, po prostu dlatego, że znają aplikację lepiej.
3. Delegowanie naprawiania potencjalnie krytycznego oprogramowania do innej grupy może być demoralizujące i czasochłonne dla tej grupy. Podobnie jak w przypadku innych faz tworzenia, programowania i wdrażania aplikacji zespół łączenia powinien współpracować z działem IT w celu uzyskania pomocy w razie potrzeby.

Monitorowanie zadowolenia i użyteczności aplikacji

Ostatnią częścią wysiłku pomocy technicznej jest monitorowanie i ocena zadowolenia i użyteczności wdrożonej aplikacji. Metryki są tutaj przydatne wraz z bardziej tradycyjnymi metodami, takimi jak sondowanie i kwestionariusze. Aby uzyskać więcej informacji na temat monitorowania użycia aplikacji, zobacz Admin Analytics for Power Apps (Analiza administracyjna dla usługi Power Apps).

Ostatecznie, jeśli klienci nie korzystają z opublikowanej aplikacji, ta aplikacja nie spełnia jej celu. Regularne spotkania przeglądowe mogą sprawdzić te metryki satysfakcji i użyteczności, aby stworzyć pozytywną pętlę opinii, która może zmienić lub dodać historie do zaległości w celu wygenerowania, a następnie wdrożenia zaktualizowanej wersji aplikacji.

Podsumowanie

Opracowywanie narzędzi bez kodu i narzędzi o niskim kodzie, takich jak usługa Power Apps, rozszerza opcje dla technologów biznesowych lub twórców w celu tworzenia, opracowywania i wdrażania aplikacji. Ten projekt działa najlepiej w środowisku zespołu zintegrowanego, obejmującym właściciela produktu, eksperta dziedzinowego, programistę i administratora, a zespół ten wprowadza inne zasoby zgodnie z potrzebami.

Integrowanie metodyk agile i scrum w zespołach fusion skutkuje szybszym tworzeniem aplikacji i wyższym prawdopodobieństwem pomyślnego wdrożenia z zestawem funkcji, który przynosi znaczącą wartość dla przedsiębiorstwa. Stosując te najlepsze rozwiązania, wytyczne i zalecenia, zespół łączenia będzie mógł korzystać z usługi Power Apps, aby sprostać wyzwaniom związanym z transformacją cyfrową w organizacji.