Udostępnij za pośrednictwem


Zalecenia dotyczące formalizacji tworzenia oprogramowania i zarządzania nimi

Dotyczy tego zalecenia z listy kontrolnej dotyczącej doskonałości operacyjnej platformy Azure Well-Architected Framework:

OE:03 Formalizowanie procesów opracowywania i planowania oprogramowania. Czerpać ze ustalonych standardów branżowych i organizacyjnych. Użyj wspólnej, priorytetowej listy prac i wystarczająco szczegółowych specyfikacji. W oparciu o wyniki możesz prowadzić do ciągłego ulepszania procesu planowania.

W tym przewodniku opisano zalecenia dotyczące zarządzania praktykami tworzenia oprogramowania zgodnie z ustalonymi standardami. Zdolność Twojego zespołu do tworzenia oprogramowania wysokiej jakości opiera się na ustrukturyzowanym, wspólnym podejściu do planowania rozwoju. Właściciele produktów i menedżerowie muszą być w stanie jasno zrozumieć i przedstawić uczestnikom projektu pracę, którą deweloperzy wykonują w dowolnym momencie w cyklu rozwoju. Z drugiej strony deweloperzy muszą zrozumieć cele cyklu projektowania za pomocą dobrze napisanych funkcji, scenariuszy użytkowników i kryteriów akceptacji. Ustalone standardy definiują sposób wykonywania praktyk programistycznych i umożliwiają zespołowi obciążeń efektywną współpracę, co zmniejsza ryzyko nieporozumień dotyczących celów i oczekiwań.

Kluczowe strategie projektowania

Sformalizuj praktyki tworzenia oprogramowania, aby zapewnić, że właściciele produktów, menedżerowie projektów i deweloperzy rozumieją cele każdego przebiegu i zapewniają spójną jakość uczestnikom projektu. Aby zapoznać się ze wskazówkami dotyczącymi praktyk programistycznych, zobacz przewodnik dotyczący ciągłej integracji.

Ustanawianie standardów współpracy i komunikacji

  • Współpraca: Proces definiowania proponowanych zmian w obciążeniu powinien być nakładem pracy zespołowej. Większość zmian w obciążeniu będzie mieć wpływ na wiele funkcji i/lub składników, tak aby uwzględnić jak najwięcej członków zespołu obciążeń, co możliwe, pomoże zapewnić, że ważne zagadnienia nie zostaną pominięte i że wszyscy wiedzą o wpływie na ich określoną domenę. Współpraca pomaga również jasno zdefiniować zakres zmiany i sposób dzielenia niezbędnych zadań potrzebnych do przeprowadzenia zmiany w dobrze zdefiniowanych elementach roboczych, ponieważ większa grupa z wiedzą w różnych domenach będzie mogła zapewnić szacunkowe szacunki oparte na doświadczeniach dla wymaganych wysiłków.

  • Komunikacja: Zdefiniuj standardowe protokoły dla właścicieli produktów i menedżerów projektów, aby promować nadchodzące wydania wewnętrznie i zewnętrznie. Na przykład można ustanowić standard komunikacji z stronami zewnętrznymi dotyczącymi nadchodzących wydań. Standard może dyktować, że komunikacja powinna zostać wysłana dwa tygodnie przed wydaniem, a przypomnienie powinno zostać wysłane 24 godziny przed wydaniem.

  • Przegląd: Regularnie przeprowadzaj wewnętrzne inspekcje praktyk programistycznych za pomocą retrospektyw cyklu programowania i pośmiertnych. Odbicie procesów powinno być bez winy i powinno skupić się na uczeniu się, które można zastosować jako ulepszenia. Upewnij się, że zespół zastanawia się nad tym, jak skuteczny był scenariusz użytkownika i zadania podczas definiowania niezbędnych zadań oraz dokładności szacowania czasu.

  • Raporty: Standaryzacja raportów dla uczestników projektu, które udostępniają przydatne metryki koncentrujące się na zmianach. Skupienie się na zmianach umożliwia śledzenie przyspieszania i zwalniania produktów. Przydatne metryki mogą obejmować zmiany w:

    • Miesięczny wskaźnik wzrostu wdrożenia.

    • Wydajność.

    • Czas trenowania.

    • Częstotliwość zdarzeń.

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

Wybieranie standardowych narzędzi branżowych

Używaj ustalonych, sprawdzonych w branży narzędzi i procesów, takich jak Agile, Scrum i tablice Kanban. Opracowywanie własnych narzędzi i procesów jest znaczącym przedsięwzięciem, biorąc pod uwagę czas i cykle programowania, które w przeciwnym razie mogą być wydawane na obciążenie. Większość doświadczonych inżynierów i właścicieli produktów DevOps zna te typy narzędzi i procesów, więc krzywa uczenia się w ich wdrożeniu powinna być minimalna. Podobnie proces dołączania nowych pracowników skorzysta również z używania standardowych narzędzi i procesów, ponieważ prawdopodobnie będą one miały pewien stopień narażenia na te same narzędzia i procesy.

Kompromis: Metodologia Agile może stać się zbyt ścisła, jeśli jest zbyt nakazowa. Dążyć do równowagi między dobrze zdefiniowanymi standardami a innowacjami.

Wdrażanie standardu w celu przechwytywania scenariuszy użytkownika końcowego

  • Scenariusze użytkownika: standaryzacja szablonu scenariuszy użytkownika. Upewnij się, że każda historia użytkownika jest dyskretną jednostką pracy napisaną z perspektywy użytkownika końcowego. Dobrze napisane historie użytkowników powinny mieć następujące cechy:

    • Każda historia użytkownika powinna być całkowicie niezależna od siebie. Zachowanie relacji użytkowników niezależnie od siebie pozwala uniknąć pomyłek z nakładającymi się pracami i pomaga zespołowi zrozumieć, czy praca nad danym scenariuszem użytkownika opiera się na pracy nad innymi osobami, co pomaga w planowaniu i określaniu priorytetów.

    • Każda historia użytkownika jest negocjowana. Perspektywy użytkowników końcowych i członków zespołu obciążeń są niezbędne do przechwytywania realistycznych historii użytkowników, które można osiągnąć w krótkim czasie.

    • Historie użytkowników są przydatne dla użytkownika końcowego. Podczas pisania historii użytkowników z perspektywy użytkownika końcowego przechwytuje się zmiany, które są im interesujące, i które będą miały wartość dodaną do ich środowiska. Utrzymanie tego fokusu, ponieważ historia użytkownika jest podzielona na elementy robocze, pomaga zapewnić, że każde wdrożenie zapewnia ulepszone środowisko.

    • Nakład pracy wymagany w przypadku scenariusza użytkownika jest godny uwagi przy wysokim stopniu pewności siebie. Bez możliwości zbliżenia godzin wymaganych przez daną historię użytkownika planowanie będzie trudne i potencjalne zwiększenie brakujących terminów, co potencjalnie może spowodować kaskadowy wpływ na inne planowane prace.

    • Dobrze napisane scenariusze użytkowników są małe, dzięki czemu można je ukończyć w ciągu kilku tygodni. Mniejsze scenariusze o określonym zakresie pomagają zachować je do oszacowania i zarządzania oraz pomóc w utrzymywania możliwości wykonywania elementów roboczych.

    • Scenariusze użytkowników powinny być testowalne. Bez możliwości przetestowania, czy funkcja została dostarczona, użytkownik końcowy nie może mieć pewności, że cel został osiągnięty. Nawet jeśli test nie został już napisany dla danej historii użytkownika, należy jasno zrozumieć, jak można rozwinąć test, aby udowodnić dostarczanie funkcji.

  • Kryteria akceptacji: standaryzacja szablonu dla kryteriów akceptacji. Upewnij się, że kryteria akceptacji odnoszą się konkretnie do historii użytkownika i mogą być jednoznacznie sprawdzone przy użyciu co najmniej jednego testu akceptacyjnego.

Standaryzacja praktyk wdrażania

  • Wdrożenie: zaplanuj częste małe, iteracyjne wdrożenia zamiast dużych wdrożeń rzadko używanych. Użycie tego podejścia pomoże zachować możliwości zarządzania scenariuszami użytkowników i elementami roboczymi z punktu widzenia zarządzania projektem oraz zmniejszyć ryzyko problemów na dużą skalę, gdy wdrożenia kończą się niepowodzeniem.

  • Terminy: Standaryzacja definicji ukończonych cykli programowania w celu zapewnienia, że funkcje pomocnicze, w tym testowanie, dokumentacja i funkcje ułatwień dostępu, zostały ukończone pomyślnie.

  • Śledzenie: upewnij się, że proces programowania jest możliwy do śledzenia. Należy wyraźnie śledzić stan obciążenia produkcyjnego i skojarzony kod z powrotem do testowania kontroli jakości, kryteriów akceptacji, historii użytkowników i funkcji. Szczegółowe śledzenie może być również wymaganiem prawnym w niektórych przypadkach, takich jak opieka zdrowotna, na przykład.

Ułatwienia platformy Azure

Azure Boards to usługa internetowa, która umożliwia zespołom planowanie, śledzenie i omawianie pracy w całym procesie programowania. Jest ona odpowiednia dla praktyk programistycznych opartych na metodyce Agile.

GitHub Projects to dostosowywalne narzędzie do zarządzania projektami, które umożliwia organizowanie projektów i integrowanie ich przy użyciu problemów i żądań ściągnięcia w usłudze GitHub.

Lista kontrolna doskonałości operacyjnej

Zapoznaj się z pełnym zestawem zaleceń.