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 fuzyjnych. W tym artykule opisano sposób definiowania schematów blokowych.

Definiowanie procesu end-to-end

Przykładem może być następujący proces i dostosowanie go do najlepszych praktyk organizacji. Nie trzeba wykonać każdego kroku, jeśli osiągnąć wymagany wynik.

Dodawanie funkcji do listy zaległej

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

Podczas dodawania nowej funkcji do listy zaległej celem jest opisanie zakresu ogólnego. Każda funkcja definiuje następnie wartości biznesowe, tytuły historii, zakres i zmiany modelu danych, które wpływają na działania programistologiczne dotyczące kodu.

Ponadto podczas dodawania funkcji o znaczeniu krytycznym dla działalności zaleca się zidentyfikowanie wszystkich najważniejszych scenariuszy automatyzowania testowania. Po dodaniu swoich funkcji można zaplanować spotkanie w zakresie wyrównania.

Spotkanie w zakresie wyrównania

Celem tego spotkania powinno być przejrzenie każdej proponowanych nowych funkcji, a następnie sprawdzenie wszystkich istniejących aplikacji, scenariuszy lub modeli danych, które już zapewniają tę funkcję, aby uniknąć powielania działań. To spotkanie stanowi także możliwość omówienia wpływu na inne aplikacje. Na koniec należy sprawdzić, czy ta funkcja wymaga przeglądu doświadczeń.

Dodaj nową historię i tablicę historii do backloga

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

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

W tym momencie należy zachować wysoką jakość, organizując pracę dzięki strumieniowi pracy i aplikacji. Ta metoda ułatwia utrzymywanie powiązanych elementów roboczych razem i umożliwia ekspertom w każdej z aplikacji zrozumienie funkcji i sposobu korzystania z danych w poszczególnych aplikacjach.

Przegląd doświadczeń

Przeglądy doświadczeń powinny koncentrować się na interfejsie użytkownika końcowego i zapewnić, że zespół korzysta z najlepszych praktyk organizacyjnych. Dzięki temu wszystkie aplikacje będą niezawodny i powtarzalne dla użytkowników końcowych i zespołów pomocy technicznej.

Dodawanie szczegółów historii

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

1. Tytuł: jako <persona>, mogę <do something> żeby <impact/priority/value>
2. Opis: Opis zawiera (chociaż nie wyłącznie) niektóre kluczowe informacje szczegółowe, takie jak:
   • Krótki opis scenariusza, który zawiera podsumowanie żądanego wyniku
   • Dane dotyczące akcji, które zostaną podjęte w celu nawigowania i zrealizowania scenariusza
   • Alternatywna alternatywa — opisuje inne sposoby realizacji tego samego wyniku przez użytkowników
   • Notatki dotyczące projektowania — rekordy encji, pól, widoków, ekranów i reguł biznesowych skojarzonych z historii użytkownika
   • Rola zabezpieczeń — dotyczy to listy wszystkich ról zabezpieczeń, które mają wpływ na użytkownika lub istotnych dla historii użytkownika.

Po dodaniu wszystkich tych szczegółów stan historii użytkownika należy zmienić na "Gotowa do przeglądu". W większości przypadków zespół funkcji i zespół biznesowy (jeśli ma to zastosowanie) przejrzyj ustawienia użytkownika.

Przegląd historii

Przeglądy historii zazwyczaj występują w zespole 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ądu zaleca się przypisanie historii użytkownika do członka zespołu. Zapewnienie, że zespół pozostaje wyrównany w trakcie procesu projektowania, jest niezbędne do realizacji celów ogólnych.

Dodawanie zadań i spraw testowych

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

1. Otwórz log. Możesz również utworzyć nowy tekst.
2. Dodawanie istniejących elementów roboczych do pliku roboczego. 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ć dowolne nierozsłane zadania do odpowiednich elementów pracy.
3. Dodaj zadania do elementów backlogu. Jeśli do użytkownika nie przypisano elementów backlogu, należy to zrobić teraz. Ustaw również daty rozpoczęcia i zakończenia.
4. Wypełnij ten formularz zadania. Ze względu na regułę wykonywania zadań nie powinno trwać dłużej niż 1 dzień. Zadanie o rozmiarze większym niż ten czas jest przerwane.
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 backlogu do elementu nadrzędnego.

Po dodaniu zadań i spraw testowych można następnie ustawić wydajność.

Aby uzyskać więcej informacji na temat dodawania zadań, zobacz artykuł Dodawanie zadań do elementów backlogu w celu obsługi planowania.

Przygotuj rozwiązania

Ważnym aspektem udanego projektowania jest ustrukturalryzowany proces zarządzania wydaniami. Rozwiązania to mechanizm wdrażania zarządzania cyklem życia aplikacji (ALM); korzystasz z rozwiązań do dystrybucji komponentów w środowiskach poprzez działania eksportowe i importowe. Składnik reprezentuje artefakt używany w twojej aplikacji i coś, co możesz potencjalnie dostosować do swoich potrzeb. Komponentem jest wszystko, co można włączyć do rozwiązania, np. tabele, kolumny, aplikacje kanwy i oparte na modelach, przepływy Power Automate, chatboty, wykresy i wtyczki.

Wdrożenia

W zależności od stopnia złożoności i zależności od zespołu, składniki mogą wykonać wiele instalacji. W celu ukończenia zadań składniki należy dodawać do rozwiązania w środowisku projektowym. Rozwiązania są następnie importowane do środowiska produkcyjnego po przetestowaniu. Zaleca się, aby zachować jedno środowisko testowe w celu przeprowadzenia testowania end-to-end i przetestowania wdrożenia rozwiązania przed rozpoczęciem pracy w środowisku produkcyjnym.

Środowiska: Power Platform

Środowiska to przestrzeń do przechowywania i udostępniania danych biznesowych, aplikacji i procesów biznesowych organizacji oraz zarządzania nimi. Pełni ono również rolę pojemnika oddzielającego aplikacje, które mogą mieć różne role, wymagania dotyczące zabezpieczeń lub odbiorców docelowych.

Jeśli w organizacji istnieje konfiguracja wielu zespółów, w której każdy zespół opracowuje własne rozwiązania, ważne jest, aby koordynowanie czasu trwania na wszystkich wersjach i wersjach. Nie muszą mieć spójnej długości w harmonogramie projektu i mogą się różnić czas trwania między zespołami, zgodnie z preferencjami poszczególnych grup. Jednak czas trwania wydania nie może być krótszy niż krótki dla wszystkich zespołów.

Kontrola źródła

Wziąć pod uwagę przyjęcie systemu kontroli kodu źródłowego, takiego jak Azure DevOps. Program 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 informacje o wersji rozwiązania są dokładne, zgodnie z wytycznymi dotyczącymi wdrażania i wdrażania systemu Scrum w pracy zespołu w języku Azure Wsad. 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 standardizowanie zapewniają wydajność, pomagając w zwiększaniu spójności zespołu. Wszystkie aspekty operacji zespołu — bez względu na to, czy są to zadania związane z pierwszymi użytkownikami, prezentacje przeglądu historii, czy szablony elementów pracy, które pomagają zaoszczędzić czas i wskazówek dla zespołów podczas definiowania użytkowników, funkcji, aplikacji czy zadań — korzyści z standaryzacji i ich tworzenia.

Implementacja skutecznego modelu pomocy technicznej

Efektywny model pomocy technicznej jest niezbędny do długiego sukcesu aplikacji po jej wdrożeniu, co podkreślono w poprzedniej sekcji dotyczącej generowania macierzy pomocy technicznej. Relacje i przechyłki nie są możliwe, więc zespół ma ustrukturalnie podchodząc do tych zdarzeń, a macierz pomocy technicznej zapewnia niezbędny strukturę.

Tworzenie umowy o gwarantowanym poziomie usług

Kluczem dla każdego modelu pomocy technicznej jest definicja umowy sla poziomu usług. Umowa SLA powinna być oficjalnym dokumentem, który członkowie zespołu mogą obejmować sekcje zawierające następujące kwestie:

• Przechyłki — zakres dopuszczalnych działań jest dopuszczalny, dla których są podejmowane działania, jakie należy podjąć działania, potwierdzenie ponownego podjęcia usługi i działania mające na celu zapobieganie ich powtarzaniu. Wszystkie procedury testowania zautomatyzowanego, które są używane przez zespół, muszą być zgodne z oczekiwanym i właściwymi umowami SLA.
• Błędy — osoba odpowiedzialna za rozwiązanie problemu i wylogowanie się z rozwiązania problemu, przypisanie do nich poziomów klasyfikacji, akcji wykrywania.
• Eskalacja — poziomy eskalacji, przypisanie pracowników do poziomów, obowiązki na każdym poziomie, listy dystrybucyjne dla poszczególnych poziomów itp.

Umowa SLA powinna być przechowywana w portalu dokumentacji zespołu i uaktualniana w razie potrzeby.

Dostarczanie wsparcia aplikacji

Najlepszym podejściem do zapewnienia pomocy technicznej dotyczącej aplikacji określonej w umowy SLA jest to, aby zespół, który utworzył rozwiązanie, był także odpowiedzialny za jego obsługę. Zalety tego systemu to:

1. Zachęca do lepszej jakości projektowania, ponieważ osoby, które utworzyły aplikację, wiedzą, że będą ją musiał obsługiwać.
2. Dzięki temu twórcy będą mogli szybko znaleźć i naprawić błędy niż zespół innych firm, ponieważ lepiej znają aplikację.
3. Delegowanie poprawiania oprogramowania, które może mieć krytyczne znaczenie dla jej zadaniem, w innej grupie może być demoralizujące i czasochłonne. Podobnie jak na innych etapach tworzenia, projektowania i wdrażania aplikacji, w razie potrzeby zespół ten powinien zostać partnerem z IT.

Monitorowanie zadowolenia i możliwości aplikacji

Ostatnia część działań pomocy technicznej to monitorowanie i ocena zadowolenia i przydatności wdrożonej aplikacji. Są tu przydatne metryki wraz z bardziej tradycyjnymi metodami, takimi jak sondowanie i kwestionariusze. Aby uzyskać więcej informacji na temat monitorowania użycia aplikacji, zobacz informacje o analizach dla administratorów dotyczące rozwiązania Power Apps.

Ostatecznie, jeśli klienci nie będą używać opublikowanej aplikacji, ta aplikacja nie zrealizuje swojego celu. Regularne spotkania przeglądowe mogą sprawdzić te metryki satysfakcji i użyteczności, aby stworzyć pozytywną pętlę informacji zwrotnych, 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 niewymagających i niskokodowych, takich jak Power Apps, rozszerzyło możliwości dla technologów biznesowych lub twórców w celu tworzenia, opracowywania i wdrażania aplikacji. Ten projekt najlepiej się sprawdza w środowisku zespołu ds. projektowania, wymaga od właściciela produktu, eksperta z domeny, specjalisty ds. projektowania i Administrator, a w razie potrzeby zespół ten będzie dostępny w innych zasobach.

Integracja podejścia zrębnego i szybkiego projektowania w zespołach umożliwia szybsze opracowywanie aplikacji i większe prawdopodobieństwo pomyślnego wdrożenia dzięki zestawowi funkcji, który stanowi istotne znaczenie dla działalności firmy. Stosując te najlepsze praktyki, wytyczne i zalecenia, Twój zespół ds. fuzji będzie mógł używać Power Apps, aby sprostać wyzwaniom związanym z transformacją cyfrową Twojej organizacji.