Zalecenia dotyczące sformalizowania tworzenia oprogramowania i zarządzania nim

  • Artykuł

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

OE:03 Formalizowanie procesów ideacji i planowania oprogramowania. Korzystaj z ustalonych standardów branżowych i organizacyjnych. Użyj wspólnej, priorytetowej listy prac i wystarczająco szczegółowych specyfikacji. Na podstawie wyników należy prowadzić do ciągłych ulepszeń w procesie planowania.

W tym przewodniku opisano zalecenia dotyczące zarządzania praktykami tworzenia oprogramowania zgodnie z ustalonymi standardami. Zdolność Twojego zespołu do tworzenia oprogramowania o wysokiej jakości zależy od ustrukturyzowanego, wspólnego podejścia do planowania programowania. Właściciele produktów i menedżerowie muszą być w stanie jasno zrozumieć i wyrazić dla uczestników projektu pracę, którą deweloperzy wykonują w dowolnym momencie w cyklu projektowania. 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 ds. obciążeń efektywną współpracę, co zmniejsza ryzyko pomyłek dotyczących celów i oczekiwań.

Kluczowe strategie projektowania

Formalizuj 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.

Standardy planowania rozwoju

  • 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, dlatego włączenie jak największej liczby członków zespołu ds. obciążeń pomoże zapewnić, że ważne kwestie nie zostaną pominięte i że wszyscy wiedzą o wpływie na ich konkretną domenę. Współpraca pomaga również jasno zdefiniować zakres zmiany i sposób dzielenia niezbędnych zadań niezbędnych do wykonania zmiany w dobrze zdefiniowanych elementach roboczych, ponieważ większa grupa z wiedzą specjalistyczną w różnych domenach będzie w stanie zapewnić oparte na doświadczeniach oszacowania wymaganego nakładu pracy.

  • Narzędzia: używaj ustalonych, sprawdzonych w branży narzędzi i procesów, takich jak tablice Agile, Scrum i Kanban. Opracowywanie własnych narzędzi i procesów jest znaczącym przedsięwzięciem, biorącym czas i cykle programowania, które w przeciwnym razie mogą być poświęcane 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 nauki dotycząca ich wdrażania powinna być minimalna. Podobnie proces dołączania dla nowych pracowników będzie również korzystać z standardowych narzędzi i procesów, ponieważ mogą one mieć pewien stopień narażenia na te same narzędzia i procesy.

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

  • Wdrożenie: zaplanuj częste małe, iteracyjne wdrożenia zamiast dużych, rzadkich wdrożeń. 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 projektami i zmniejszyć ryzyko problemów na dużą skalę w przypadku niepowodzenia wdrożeń.

  • Terminy: Standaryzacja definicji ukończonych cykli programistycznych w celu zapewnienia pomyślnego ukończenia obsługi funkcji, w tym testowania, dokumentacji i funkcji ułatwień dostępu.

  • 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. Możesz na przykład 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.

  • Scenariusze użytkownika: standaryzacja szablonu dla scenariuszy użytkownika. Upewnij się, że każda historia użytkownika jest odrębną jednostką pracy napisaną z perspektywy użytkownika końcowego. Dobrze napisane scenariusze użytkownika 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ącą się pracą i pomaga zespołowi zrozumieć, czy praca nad daną historią 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 scenariuszy użytkownika, które można osiągnąć przez krótki czas.

    • Scenariusze użytkownika 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 zainteresowane widząc 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 dla scenariusza użytkownika jest eszacowalny z wysokim stopniem pewności siebie. Bez możliwości zbliżenia godzin wymaganych przez daną historię użytkownika planowanie będzie trudne, a potencjał braku terminów terminów wzrasta, co może spowodować kaskadowe skutki innych planowanych prac.

    • Dobrze napisane scenariusze użytkownika 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ądzać oraz pomóc w utrzymaniu możliwości wykonywania elementów roboczych.

    • Scenariusze użytkownika 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 danego scenariusza użytkownika, powinno być jasne zrozumienie sposobu opracowania testu w celu udowodnienia dostarczania funkcji.

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

  • Ś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, scenariuszy użytkowników i funkcji. Szczegółowe śledzenie może być również wymogiem prawnym w niektórych przypadkach, takich jak opieka zdrowotna, na przykład.

  • Przegląd: Regularnie przeprowadzaj wewnętrzne inspekcje praktyk programistycznych za pośrednictwem retrospektyw cyklu programowania i pośmiertności. 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 skutecznością historii i zadań użytkownika podczas definiowania niezbędnych zadań i dokładności oszacowań czasu.

  • Raporty: Standaryzacja raportów dla uczestników projektu, które zapewniają 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.

Ułatwienia dla 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ń.

Lista kontrolna doskonałości operacyjnej