Jak przyjąć zwinną metodologię opracowywania oprogramowania układowego / oprogramowania systemów wbudowanych?

Zawsze zastanawiałem się, jak zastosować zwinne metody, tak naprawdę w dużym złożonym oprogramowaniu do systemów wbudowanych (ponad 100 inżynierów). Opracowywanie oprogramowania układowego ma pewne unikalne cechy, które utrudniają sprawne działanie (tj. Sprzęt nie jest dostępny do późnej fazy tworzenia; po wydaniu produktu nie można łatwo zaktualizować oprogramowania układowego; itp.)

Normą w tego rodzaju projektach jest gruba dokumentacja i wyczerpujące recenzje. Nie można uzyskać prostej poprawki kodu, takiej jak zmiana nazwy zmiennej bez 2-3 podpisów. (Trochę przesadzam, ale jest to typowe. Ponadto wiele osób stosuje skróty, a kierownicy projektów nawet je zatwierdzają, zwłaszcza w obliczu trudnych terminów rynkowych).

Chciałbym usłyszeć wszelkie wskazówki lub wytyczne dotyczące stosowania metodyki zwinnej w projektach oprogramowania układowego.

Myślę, że dwie techniki są kluczowe:

• Opracuj pełny symulator lub środowisko testowe dla sprzętu, abyś mógł rozwijać oprogramowanie tak, jakbyś miał prawdziwy sprzęt. Nie skąp i nie używaj tutaj skrótów: opracowanie dobrego symulatora się opłaci.

• Napisz wiele testów jednostkowych na symulatorze.

Kiedy już zaczniesz działać, a ludzie będą pewni, że symulator i testy jednostkowe dają dokładne wyobrażenie o tym, jak wszystko będzie działać ze sprzętem, łatwiej będzie zastosować inne zwinne techniki (krótkie iteracje, nieustanne refaktoryzowanie itp.) .

Wpływ Agile na proces rozwoju z udziałem wielu dostawców można porównać do tego, co dzieje się, gdy firma przechodzi w JIT.

Aby dostarczyć JIT, każdy z dostawców firmy musi dostarczyć JIT.

function deliversJIT( company ) { 
    return company.isJIT() && map( deliversJIT, company.suppliers() );
}

Podobnie, jeśli chcesz opracować złożony produkt zgodnie z metodologią Agile, każda podgrupa w łańcuchu powinna być w stanie działać w ten sposób.

Jeśli chodzi o rozwój „przyrostowy” (znany również jako Tracer Bullets sprzed 15 lat), oznaczałoby to, że „rdzeń” zostanie wkrótce udostępniony kierowcy, a sterownik podstawowy będzie dostępny dla integratora, a interfejs GUI być rozwijanym, jednocześnie za pomocą jednego przycisku i pola edycyjnego.

Trudność polega na przekonaniu projektantów sprzętu, wywodzących się z solidnej dyscypliny inżynierskiej, do przyłączenia się do naszego społeczeństwa majsterkowiczów.

Drugą najtrudniejszą częścią jest znalezienie sposobu na stopniowy rozwój w świecie, w którym wydruk sprzętu należy zamówić z 3-tygodniowym wyprzedzeniem. Myślę, że emulatory, FPGA jest tutaj. Ale nie jestem facetem od sprzętu.

Jeśli chcesz rzucić okiem na stopniowy rozwój sprzętu, możesz, podobnie jak na granicy łańcucha JIT, przewidzieć mechanizm buforowania, który pozwoli zespołom Agile na awans.

Nie bądźmy ślepi: Agile musi również radzić sobie z procesami o dużej masie! Nie proś zespołu Agile o „refaktoryzację” swojej bazy kodu Java do Pythona w następnym sprincie. Tylko dlatego, że niektóre części są naprawdę bardzo stabilne, możemy zatańczyć na nich nasze ruchy Agile.

Agile Manifesto: http://agilemanifesto.org/

„Osoby i interakcje dotyczące procesów i narzędzi”

• Poznaj więcej. Wciśnij mniej papieru.

„Działające oprogramowanie w ramach obszernej dokumentacji”

• Prototypowanie i budowanie skoków technologii wcześnie i często.

• Rozwiąż prawdziwy problem użytkownika, zamiast budować wybredne przestrzeganie specyfikacji. Oznacza to ewolucję rozwiązania . Pomysł, że musimy go poprawnie zbudować, ponieważ nigdy nie możemy go zbudować, jest błędny. Zaplanuj iterację. Włącz go do strategii marketingowej i wdrożeniowej.

„Współpraca z klientem w zakresie negocjacji umów”

• Hiper-skomplikowane procesy kontroli zmian to tylko sposób na powiedzenie klientowi „nie”.

• Blokowanie wszystkich wymagań z góry, a następnie narzucanie kontroli zmian to kolejny sposób na powiedzenie „nie”.

• Jeśli już planujesz więcej niż jedną wersję, możesz łatwiej odłożyć wymagania na późniejszą wersję. Gdy klient ma urządzenie z oprogramowaniem wbudowanym, kolejna wersja zmieni swoje priorytety.

„Reagowanie na zmianę po wykonaniu planu”

• Podczas gdy złożona integracja wymaga złożonego planu, ogólnego „programu” (lub sekwencji projektów) nie da się za wcześnie sprecyzować.

Metodologia całkowicie zwinna (tj. Scrum) może nie mieć sensu dla systemu osadzonego.

Manifest Agile zapewnia jednak sposoby pozwalające na zmianę bez pozwalania na prosty chaos.

Mój problem ze scrumem w systemach wbudowanych polega na tym, że jest wiele zadań do wykonania, szczególnie na początkowych etapach, których nie można wykazać. Zaczęliśmy od płyty deweloperskiej, bez systemu operacyjnego, bez wyświetlacza, bez komunikacji szeregowej itp. Nie mieliśmy naszego wyświetlacza przez 6 sprintów.

Pierwsze 4 sprinty to: Uruchomienie RTOS Tworzenie zadań Pisanie sterowników sieciowych i szeregowych Pisanie procedur przerwań dla przycisków, komunikatorów itp. Pisanie podstawowych klas i metod bazy danych Pisanie menu debugowania szeregowego

Większość z tych zadań nie jest dobrze dopasowana do historii użytkowników. W rzeczywistości jedynym interfejsem w całym systemie było menu debugowania szeregowego, wbudowane w sprint 3, więc nie było nic do zademonstrowania na końcu sprintu. Nawet menu szeregowe było przeznaczone do użytku wewnętrznego, a nie użytkownika końcowego.

Oczywiście, każda klasa, którą piszemy, ma powiązane testy jednostkowe i używamy struktury testów jednostkowych do automatyzacji wykonywania wszystkich testów.

Skończyliśmy pisać „historie użytkowników”, takie jak „Jako programista ...”, z czego nie jestem zadowolony, ale korzystając z Target Process (www.targetprocess.com), nie ma pojęcia o pozycji zaległości, która jest zadanie lub obowiązek.

Chciałbym usłyszeć, jak inni poradzili sobie z tymi sytuacjami.