Udostępnij za pośrednictwem

Rekomendacje dotyczące formalizowania praktyk w zakresie zarządzania rozwojem oprogramowania

  • Artykuł

Dotyczy tego Power Platform zalecenia dotyczącego listy kontrolnej doskonałości operacyjnej Well-Architected:

OE:03 Formalizuj ideę oprogramowania i proces planowania na podstawie ustalonego standardu branżowego i organizacyjnego. Użyj typowych, priorytetyzowanych dzienników zaległości i wystarczająco szczegółowych specyfikacji. Stale usprawniaj proces planowania w zależności od wyników.

W niniejszym przewodniku opisano zalecenia dotyczące zarządzania praktykami projektowania obciążeń zgodnie z określonymi standardami. Zdolność Twojego zespołu do tworzenia wysokiej jakości oprogramowania zależy od ustrukturyzowanego, opartego na współpracy podejścia do planowania rozwoju. Zespoły ds. obciążenia pracą powinny rozumieć i jasno komunikować się z interesariuszami na temat wykonywanej pracy. Mówiąc dokładniej, zespoły zajmujące się obciążeniem pracą powinny mieć jasny obraz pracy, którą należy wykonać w cyklu rozwoju, i upewnić się, że wszyscy interesariusze są zgodni co do tego, "dlaczego" wykonać tę pracę. Ustalone standardy definiują sposób postępowania w zakresie projektowania i umożliwiają zespołowi pracowi efektywne współpracę, zmniejszając ryzyko nieporozumień dotyczących celów i oczekiwań.

Kluczowe strategie projektowania

Należy formalizować metody projektowania prac, aby pomóc w zrozumieniu celów i oczekiwań.

Nie traktuj obciążeń niskokodowych jako mało złożonych. Nadal korzystasz z formalizacji tworzenia obciążeń niskokodowych i zarządzania nimi. Informacje od innych zespołów projektowania oprogramowania. Dysponuj matrycą decyzyjną, która określa wymagany poziom formalizacji w oparciu o złożoność i krytyczność obciążenia.

Standardy planowania projektowania

Poniższe standardy mogą pomóc w opracowaniu kompleksowej strategii planowania projektowania.

  • Ustalanie priorytetów: Planowanie kolejności i zakresu prac wiąże się ze zrozumieniem prawdziwego wpływu i wartości funkcji obciążenia pracą na biznes. Dotyczy to również oceny tych skutków w stosunku do innych żądań pracy oraz całości oceny produktu lub programu. Jednym ze sposobów ustalania priorytetów obciążeń jest ocena wartości biznesowej całego obciążenia. Może się okazać to również przydatne do oceny poszczególnych funkcji obciążenia dla wartości biznesowej.

  • Kategoryzacja: Ustanów procesy, które zapewniają, że krytyczne aplikacje mają niezbędne bariery ochronne do ich obsługi. Jednocześnie upewnij się, że scenariusze produktywności nie są spowalniane ani tłumione przez zbyt wiele rygorystycznych procesów.

  • Współpraca: Proces definiowania proponowanych zmian w obciążeniu pracą powinien być wspólnym wysiłkiem. Większość zmian w obciążeniu ma wpływ na wiele funkcji i składników, więc zaangażowanie jak największej liczby członków zespołu ds. obciążenia pomaga zapewnić, że ważne kwestie nie zostaną pominięte i że wszyscy są świadomi wpływu na ich konkretną domenę. Współpraca pomaga również jasno określić zakres zmiany i sposób podziału niezbędnych zadań na dobrze zdefiniowane elementy pracy. Większa grupa posiadająca wiedzę specjalistyczną z różnych dziedzin jest w stanie przedstawić poparte doświadczeniem szacunki dotyczące wymaganego wysiłku.

  • Narzędzia: Korzystaj ze sprawdzonych, sprawdzonych w branży narzędzi i procesów, takich jak Agile, Scrum i tablice Kanban.

Kompromis: Metodologia Agile może stać się zbyt rygorystyczna, jeśli jest zbyt nakazowa. Staraj się osiągnąć równowagę między dobrze zdefiniowanymi standardami a innowacjami.

  • Wdrożenie: zaplanuj używanie częstych małych, iteracyjnych wdrożeń zamiast dużych, rzadkich wdrożeń.

  • Warunki: Ustandaryzuj definicję zakończonych cykli programowania, aby zapewnić pomyślne ukończenie funkcji pomocniczych, w tym testowania, dokumentacji i funkcji ułatwień dostępu.

  • Komunikacja: Zdefiniuj standardowe protokoły dla product ownerów i menedżerów projektów, aby podwyższyć poziom nadchodzących wydań.

  • Historie użytkownika: Standaryzacja szablonu dla historii użytkownika. Dobrze napisana historia użytkownika powinien postępować zgodnie z podejściem INVEST:

    • I–Independent (niezależna): każda historia użytkownika powinna być niezależna od innych, co umożliwia zespołowi dostarczanie niewielkich kroków.
    • N–Negotiable (z możliwością negocjowania): historie użytkowników powinny być negocjowalne i otwarte na dyskusje oraz zmiany.
    • V–Value: Historyjki użytkowników powinny dostarczać wartość klientowi.
    • E–Estimable (godna szacunku): historie użytkowników powinny być godne szacunku i mieć jasną definicję zakończenia.
    • S-Small (krótkie): historie użytkownika powinien być krótkie i powinny być ukierunkowane na jedną funkcję.
    • T–Testable (z możliwością testowania): historie użytkowników powinny mieć możliwość testowania i mieć jasne kryteria akceptacji.

  • Kryteria akceptacji: Ustandaryzowanie szablonu kryteriów akceptacji. Upewnij się, że kryteria akceptacji dotyczą historii użytkownika i mogą być jednoznacznie sprawdzone, korzystając z jednego lub większej liczby testów akceptacji.

  • Śledzenie: Upewnij się, że proces programowania jest możliwy do prześledzenia. Należy jasno śledzić stan obciążenia produkcyjnego i skojarzony kod z powrotem do testowania jakości, kryteriów akceptacji, użytkowników i funkcji. Szczegółowe śledzenie może być również wymogiem regulacyjnym w niektórych przypadkach, takich jak opieka zdrowotna.

  • Przegląd: Regularnie przeprowadzaj wewnętrzne audyty swoich praktyk programistycznych poprzez retrospektywy cyklu rozwoju i analizy końcowe. Proces, który można zastosować, powinien nie przypisywać winy i powinien się skoncentrować na uczeniu się, co można zastosować jako udoskonalenia. Należy się upewnić, że zespół odzwierciedlał skuteczność historii użytkownika i zadań w definiowaniu niezbędnych zadań oraz dokładności szacowania czasu.

  • Raporty: Standaryzacja raportów dla interesariuszy, które zapewniają przydatne wskaźniki koncentrujące się na zmianach. Skupienie się na zmianach pozwala śledzić przyspieszanie i zwalnianie produktu. Pomocne metryki mogą obejmować zmiany w:

    • Miesięczny wskaźnik przyrostu wdrażania
    • Wydajność
    • Czas trenowania
    • Częstotliwość zdarzeń

    Raportowanie nie powinno być używane jako narzędzie do oceny pracy poszczególnych osób, więc należy unikać metryk, takich jak punkty historii lub wiersze kodu dla każdego inżyniera.

Ułatwienia Power Platform

Chociaż nie Power Platform ma produktów, które bezpośrednio ułatwiają tę rekomendację, możesz użyć innych narzędzi w stosie Microsoft . Azure Boards to usługa internetowa, która umożliwia zespołom planowanie, śledzenie i omawianie pracy w całym procesie programowania.

GitHub Projects to konfigurowalne narzędzie do zarządzania projektami służące do organizowania projektów i integrujące się z problemami i żądaniami ściągnięcia w usłudze GitHub.

Następne kroki

Lista kontrolna doskonałości operacyjnej