programista
8 maja, 2020
App Dev Manager Darroll Walsh udostępnia programistom wprowadzenie do rozwoju CMMI.
capability Maturity Model Integrated (CMMI) to program doskonalenia i oceny procesów, który integruje się z innymi programami doskonalenia procesów, takimi jak Project Management Body of Knowledge (PMBOK) i Agile. Działa w celu usprawnienia i Standaryzacji wszystkich procesów oraz zapewnienia środków nadzoru i przydatnych wskaźników rozwoju, usług, zarządzania dostawcami, dojrzałości cybernetycznej i innych.
co chcę zrobić, to przedstawić przegląd CMMI Dev z perspektywy dewelopera. Będziemy pomijać zarządzanie projektami, analityka biznesowego, zarządzanie konfiguracją i testowanie części CMMI DEV, aby skupić się na wpływie CMMI na zespół programistów. Jeśli istnieje zainteresowanie innymi rolami lub możliwościami, które mogą być dobrym tematem na późniejszy wpis na blogu. Pamiętaj tylko, że przed rozpoczęciem pracy programistów jest dużo pracy, nawet w zwinnym rozwoju.
zaczynajmy:
BRS, czyli Specyfikacja wymagań biznesowych to miejsce, w którym wszystko się zaczyna, jest to jedno źródło prawdy. To tutaj wymagania biznesowe, które podpisuje product owner. Podczas gdy programiści mogą być konsultowani w sprawie tworzenia BRS, jest to głównie odpowiedzialność BA. jednak to jest miejsce, w którym programista może naprawdę poznać aplikację, którą opracowuje; miejsce, w którym można uzyskać duży obraz.
projekty wysokiego i niskiego poziomu to dokumentacja architektury, która pokazuje, w jaki sposób komponenty aplikacji są połączone. W projektowaniu wysokiego poziomu, będziemy rozkładać zależności zewnętrzne i jak użytkownicy i / lub systemy będą współdziałać z naszym systemem. Konstrukcja niskopoziomowa określiłaby, w jaki sposób komponenty wewnętrzne oddziałują ze sobą. Zapoznanie się z nimi dałoby innemu programiście bardzo szybkie zrozumienie działania aplikacji.
SRS, czyli Specyfikacja wymagań oprogramowania, jest miejscem, w którym programista dokumentuje, w jaki sposób aplikacja ma zostać zbudowana. W tym miejscu dokumentowane są usługi, ustalane są Zależności i ogólnie sposób działania kodu, w oparciu o utworzone standardy BRS. Zazwyczaj odbywa się to przed napisaniem kodu i jest standardowym zadaniem. Wiem, że niektórzy pytają, dlaczego mielibyśmy to robić. Mój kod sam się dokumentuje. I chociaż jestem pewien, że tak jest, kod jest rozprowadzany przez setki plików i tysiące linii kodu. A czasami intencja nie jest tak jasna, jak byśmy chcieli. SRS daje nam jeden dokument, na który należy spojrzeć z wyraźnym zarysem tego, czego możemy się spodziewać. Przedstawia przypadki użycia i oczekiwane zachowanie w spójnym dworku.
po zdefiniowaniu tego, co zamierzamy zrobić, a następnie napisaniu kodu, nadszedł czas, aby ktoś przejrzał to, co zrobiliśmy. Wprowadź przegląd kodu. Jest to nie tylko dobra praktyka, aby wyłapać wszelkie błędy i upewnić się, że przestrzegamy najlepszych praktyk i wytycznych, to świetny sposób na podzielenie się tym, co robi aplikacja. Sam akt przeglądu kodu przez drugą parę oczu daje nam drugą osobę, która jest zaznajomiona z tym, jak działa kod. Ponieważ stało się to standardową praktyką w większości zespołów programistycznych, Nie będę belabor tego.
testy jednostkowe to kolejny główny pobyt większości programów rozwojowych. Testy jednostkowe, czy to w ramach Test Driven Development, czy po napisaniu kodu, są jednym z najlepszych sposobów, aby upewnić się, że przyszłe zmiany nie wprowadzają błędów do naszego kodu. W potoku CI / CD możemy upewnić się, że wszystkie testy przechodzą zanim pozwolimy na Sprawdzenie kodu. Pomaga nam to utrzymać kod w dobrym stanie.
indywidualnie w każdym zestawie powyższych dokumentów jest wartość, jednak prawdziwe zyski zaczynają się, gdy można powiązać wszystkie te informacje. Na początku procesu zbierania wymagań uruchamiamy matrycę identyfikowalności wymagań, która pozwala nam połączyć wymagania biznesowe, wymagania programowe, kod, testy jednostkowe, plany i przypadki testów oraz akceptację użytkowników. Wyobraź sobie sześć miesięcy w dużym projekcie, a zmiana powoduje, że przypadek testowy nie powiedzie się. Możemy teraz wrócić do wymagań, dowiedzieć się, jaki jest cel tego kodu, dokładnie wiedzieć, gdzie jest kod dla tej logiki, zmodyfikować test jednostkowy, aby złapać nowy przypadek i wdrożyć poprawkę w ciągu godzin, a nie dni.
w perspektywie krótkoterminowej CMMI może wydawać się przesadą, ale nawet w przypadku małych projektów wiedza zdobyta przez śledzenie procesu skraca cykl, im dłużej jesteś z dala od projektu. Nie wspominając o tym, że nigdy wcześniej nie pracowałeś nad projektem.
Wsparcie Dla Programistów
App Dev Customer Success Account Manager, Wsparcie Dla Programistów Microsoft
Obserwuj