Czy Twój zespół działa dobrze bez przestrzegania metodologii pracy (takiej jak scrum)?

Przez ostatnie 9 lat pracowałem w wielu małych zespołach. Każdy z nich miał oczywiste dobre praktyki, takie jak krótkie spotkania, kontrola wersji, oprogramowanie do ciągłej integracji, śledzenie problemów i tak dalej.

Przez te 9 lat nigdy nie słyszałem wiele o metodologii rozwoju; na przykład, nigdy nie było „robimy scrum”, „Let's do agile” ani niczego więcej niż przelotny odnośnik. Wydawało się, że wszystkie zespoły działają dobrze, bez konieczności przeprowadzania wielu procedur, po prostu działaliśmy swobodnie i po prostu działaliśmy dobrze.

Czy ktoś jeszcze rozwijał się przez długi czas, nie spotykając scrum / agile / etc?

Jedyne, z czym się zetknąłem, to witryny takie jak ta. Czytam pytania takie jak Spotkania Sprint - o czym rozmawiać ... i wszystkie te rozmowy wydają się opisywać niemal robotykę, jak ludzie, którzy stosują metodologię skończonej maszyny stanów. Czy to naprawdę (choć przesadzone) tak? Zastanawiam się, czy osoby publikujące w Internecie po prostu głośno popierają „najlepsze praktyki”, z podobnymi widokami podręczników, tak naprawdę nie odzwierciedlają sposobu, w jaki ludzie pracują ... Lub że spotkałem niektóre zespoły, które w naturalny sposób opracowują swoje procesy.

Co więcej (jestem w Wielkiej Brytanii, co może być istotne) ... Myślę, że jeśli metodologia zostałaby wprowadzona do któregokolwiek z zespołów, nad którymi pracuję, po prostu odrzuciłaby ją jako głupią i niepotrzebną ... na. Zgadzam się, że następujące procesy wydają się trochę nienaturalne. Czy to jest typowe czy powszechne?

Ponad 20 lat doświadczenia w programowaniu i nigdy nie stosowałem formalnej metodologii. Nigdy ich nie potrzebowałem i nie planuję ich używać w przyszłości. Metodologie mogą być odpowiednie dla niektórych osób, ale nie zastępują wykwalifikowanych programistów, którzy piszą dobry, przetestowany kod.

Osobiście uważam, że dużo osób byłoby mniej zainteresowanych dbaniem o najnowszą najnowszą metodologię tego dnia i skupienie się bardziej na jakości kodu.

Szczerze mówiąc, jeśli twój mały zespół dobrze pracował bez poważnych incydentów przez te wszystkie lata bez myślenia o procesie, prawdopodobnie robiłeś jakąś formę zwinną. Wszystko, co oznacza zwinny proces, polega na tym, że jest on zgodny z „Zwinnym Manifestem” http://agilemanifesto.org/, który ma zaskakujące niewiele do powiedzenia na temat iteracji, scenariuszy itp. Pierwszym najemcą zwinnego jest to, że wolisz „Osoby i interakcje dotyczące procesów i narzędzi ". Każdy zespół, który dobrze ze sobą współpracuje, tak naprawdę nie musi intensywnie myśleć o procesie.

Różne marki zwinne (takie jak Scrum itp.) Są bardzo przydatne, jeśli masz zupełnie nowy zespół, który nie jest przyzwyczajony do współpracy. W pewnym sensie ustalili ramy dla budowania spójnego zespołu, który z kolei zbuduje spójny produkt.

Jeśli to, co robisz, działa, rób to dalej. Jeśli ciągle spóźniasz się z dostawami, musisz rutynowo wyciągać nadgodziny lub naprawiać poważne błędy po wdrożeniu czegoś - wtedy coś jest nie tak. Wtedy dokonujesz serii drobnych zmian, aby rozwiązać problemy.

Jeśli wszystko jest w porządku i zawsze jest w porządku, nie ma problemu - więc wprowadzenie nowej (twoje zespoły zastosowałyby jakąś metodologię - formalną lub inną) metodologię rzeczywiście byłoby stratą czasu.

Tam, gdzie metodologie naprawdę pomagają, to wtedy, gdy zespół napotyka problemy lub mają problemy ze źródłami zewnętrznymi - metodologia nie tylko wprowadza dobre praktyki, ale pomaga je chronić . Znacznie łatwiej jest utrzymać dobre praktyki pod wpływem stresu, gdy robisz je świadomie, w przeciwnym razie mogą one zostać szybko wyciśnięte.

Nie sądzę, żebyś potrzebował formalnej metodologii - ale każdy zespół potrzebuje jakiegoś wzorca (niekoniecznie powtarzającego się, może być napędzany zdarzeniami), aby jego praca była skuteczna IMHO.

Jeśli nie masz problemu do rozwiązania, na szczęście.

Widziałem wiele zespołów (szczególnie w bardzo małych firmach) pracujących dobrze bez żadnej określonej metodologii.

Wdrażanie metodologii (lub techniki), ponieważ jest zabawne lub ponieważ czytasz ten post na blogu w Internecie, jest bardzo niebezpieczne.

Jeśli nic ci nie jest, nie zmieniaj niczego. Po prostu spróbuj optymalizacji, kiedy możesz.

Istnieje wiele metodologii, niektóre całkiem rozsądne, inne graniczące z obłąkanymi. Wszyscy wydają się kodyfikować zdrowy rozsądek , nadać im zabawną nazwę, a następnie sprzedać wiele książek / seminariów / itp.

Teraz, jeśli twojemu zarządowi, a nawet zespołowi, brakuje zdrowego rozsądku i organicznie nie mają własnych rozsądnych metod (świadomych lub niewypowiedzianych), być może warto je studiować, a następnie wziąć pod uwagę części metodologii istotne dla doświadczeń tego zespołu .

Narzucenie powszechnych najnowszych <insert-buzzword-here>praktyk roboczych może powodować większe zamieszanie, niż ma na celu rozwiązanie. Ale zazwyczaj może dostarczyć wiele wskaźników pola wyboru, które kierownik niekodujący linii może entuzjastycznie zaznaczyć.

Może nie nazwałeś go zwinnym lub scrumem, ale to nie znaczy, że nie miałeś żadnego procesu i nie korzystałeś z niego.

Podobnie jak samo tworzenie oprogramowania. Prawdopodobnie będziesz używać kilku wzorców projektowych, nawet jeśli nie myślisz o nich po imieniu.