Więc zacząłem pracować dla dużego korpusu, jednego z tych 3 liter w nazwie, i oni próbują stać się Zwinnymi, ale mają mnóstwo procesów, które nie uważam za Zwinne.
Ten, który najbardziej mnie skończył, to recenzje kodu. Moja ostatnia praca dotyczyła startupu, który powiedziałbym, że jest najbardziej zwinnym zespołem programistycznym, jaki widziałem, w którym pracowałem i / lub kiedykolwiek słyszałem.
W każdym razie, moim argumentem jest to, że Code Review to strata czasu w iteracyjnym lub zwinnym rozwoju, w którym UX / UI jest ekstremalny / intensywny (pomyśl o doskonałości Apple / Steve Jobs). Może ktoś tutaj pomoże zrozumieć, zanim mnie zwolni?
Oto mój proces rozwoju i ten przy ostatnim uruchomieniu ... bardzo zwinny.
Robimy wczesne prace nad funkcjami sortowania zadań / zadań programistycznych. Wyśmiewalibyśmy kilka wersji i przedstawialiśmy użytkownikom, zespołowi i działowi marketingu, aby uzyskać opinie. Następnie wykonujemy kolejną iterację makiety, aby uzyskać jedną rundę od tych samych interesariuszy powyżej. Następnie podzielimy pracę i zaczniemy. Mamy kamienie milowe i daty do spełnienia, ale wciąż się rozłączamy. Nie mamy recenzji kodu w żadnym z tych przypadków. Kilka razy w ciągu tygodni naszego rozwoju ponownie przeprowadzamy sesje z interesariuszami, aby sprawdzić, czy nadal zgadzają się cechy / funkcje / UX / UI są nadal odpowiednie i zgodne z celem.
Gdy zbliżamy się do końca 8-tygodniowego cyklu iteracji, QA rozpoczyna testy, następnie przechodzi do użytkowników wersji alfa, a wreszcie do użytkowników wersji beta. Ale w fazie alfa i beta programiści omawiają nowe funkcje i starsze funkcje, wprowadzając iteracyjne codzienne lub godzinne zmiany w interfejsie użytkownika w celu ulepszenia interfejsu użytkownika. Tak więc funkcja, która była opracowywana w tym wydaniu, może zostać zmieniona jeszcze 3 razy w ciągu ostatnich czterech tygodni, aby ją ulepszyć i udoskonalić lub dodać kilka drobnych funkcji (np. Sprawić, że komponent będzie trochę płynniejszy lub inteligentniejszy). Czasami zmiany mogą być powierzchowne, co oznacza, że żadne operacje CRUD nie są zmieniane ani modyfikowane, ale wszystkie zmiany w interfejsie użytkownika ulegają zmianie.
Więc przy takim procesie rozwoju, ekstremalnie zwinny, czy recenzje kodu nie byłyby stratą czasu? Oznacza to, że gdybym miał innego programistę lub dwóch, którzy sprawdzili mój kod, ale ten kod zmienia się jeszcze 3 razy, zanim wyjdzie za drzwi, z powodu wszystkich ulepszeń interfejsu użytkownika / interfejsu użytkownika, czy nie marnujemy czasu na pierwsze 3 razy, gdy sprawdzili go kod, ponieważ ten kod / komponent / interfejs użytkownika został zezłomowany?
Nigdy nie mieliśmy wielu problemów z jakością z tym procesem i tak, jeśli programista opuścił całą wiedzę, wyszedł za drzwi, ale zawsze znaleźliśmy inteligentnych programistów, którzy mogliby ją przejąć i przejąć.
I tak, mamy wielu testerów, ponieważ mogą oni musieli przetestować rzeczy 3 lub 4 razy. Proszę też nie rozłączać się pytaniem, dlaczego wszystkie zmiany UI / UX ... tak właśnie się robi ... to wtedy aplikacja zdobywa mnóstwo nagród dla UI / UX, a użytkownicy zabiją za app. Proces myślowy polega na tym, że jeśli mogę coś ulepszyć nawet o 2%, ponieważ mam dodatkową godzinę, zrób to. Użytkownicy będą szczęśliwsi, co oznacza więcej $ lub użytkowników. I tak, nasi użytkownicy są w porządku z ciągłą zmianą aplikacji, ponieważ tak robiono od pierwszego dnia, aby nie postrzegali jej jako złej lub negatywnej.
Mam nadzieję, że ten post nie wygląda tak pompatycznie, ale po prostu nie widzę, jak Recenzje Kodeksu nie są marnotrawstwem. Być może 2% całego naszego kodu w sprawdzonym kodzie ma błędy. W każdym wydaniu możemy znaleźć 3 błędy poprzez przegląd kodu. Czyli kończy się 40 godzin sprawdzania kodu na programistę na wydanie (4 x 40 = 160 godzin), aby znaleźć 3 do 5 błędów? Szanse są 50%, że 3 do 5 błędów zostałoby wychwyconych przez QA. Czy nie lepiej byłoby spędzić 40 godzin na programistę, dodając nową funkcję lub ulepszając istniejące?