Czy to sprawia, że ​​jestem złym programistą, jeśli nie lubię metodyki Agile? [Zamknięte]

Lubię małe iteracje. Lubię testy jednostkowe. Lubię przegląd kodu. To, co mi się nie podoba, to rozpoczęcie od małej dokumentacji lub jej braku. Czy jestem w tym sam? Czy mam po prostu nieporozumienie z tym procesem?

Wszelkie myśli będą mile widziane.

Pamiętaj, że zwinne nie oznacza braku dokumentacji, zwinne oznacza, że ​​rozumiesz, że „klient” nie wie wszystkiego, czego chcą, więc nie mogą dać ci dokumentu wymagań, który opisuje wszystko. Zwinni zwolennicy ciągłej rozmowy z klientem i mówienia „Czy tego właśnie chcesz?” lub „Jak działa X, gdy Y się zdarzy?” więc razem tworzysz wymagania.

To powiedziawszy, nie ma nic złego w tobie, jeśli nie podoba ci się konkretna metodologia. Wydaje się, że większość ludzi wybiera różne aspekty różnych metodologii.

Metodologia zwinna stwierdza, że ​​robisz tylko to, czego potrzebujesz w tym czasie. Jeśli potrzebujesz / potrzebujesz więcej dokumentacji niż jest podana, to jest problem z procesem i to nie ty. Są chwile, kiedy do kontynuowania projektu potrzebna jest duża ilość dokumentacji. Potrzebowanie tego nie jest sprzeczne z Agile. Nie można usprawiedliwić zwalniania z wymagań pod postacią Agile. To właściwie duży problem, który widziałem. Wiele osób leniuchuje z góry i zrzuca to na proces. Należy zadać prawdziwe pytanie: „Czy deweloperzy mają to, czego potrzebują?” Jeśli odpowiedź brzmi „nie”, należy wykonać więcej pracy.

Teraz można to doprowadzić do skrajności, a ktoś może powiedzieć: „Cóż, nie mogę nad tym pracować, chyba że cały program jest udokumentowany”. Czasami jest to prawda, ale zespół musi się przyjrzeć i sprawdzić, czy jest to naprawdę konieczne.

Nie rozumiem, dlaczego uczyniłoby cię złym programistą tylko dlatego, że nie lubisz określonej metodologii. Może to utrudniać integrację ze sklepami, które go wdrażają; mając na uwadze, że mam wątpliwości co do tego, jak skutecznie jest wdrażany wszędzie.

To, co czyni cię złym programistą, to zły kod - łatwo to wiem - ale możesz polubić / być genialnym we wszystkich metodologiach, jakie lubisz, i nadal być złym programistą, ponieważ twój kod nie jest odpowiedni.

Podstawową ideą Agile jest to, że jeśli nie masz daru wstępnego poznania, nie możesz przewidzieć dalekiej przyszłości. Zatem nie możesz dokumentować tego, czego nie możesz przewidzieć.

To nie znaczy, że nie masz żadnej dokumentacji. Dokumentujesz projekt techniczny dla bieżących wymagań (i oczywiście sam dokumentujesz wymagania) i dokumentujesz bieżącą implementację. Nie musisz dokumentować, jak system będzie wyglądał po 10 kolejnych sprintach, ponieważ żyjesz w dynamicznym świecie, wymagania mogą się zmienić.

Myślę, że źle rozumiesz ten proces. Jakiej dokumentacji chcesz? Przed rozpoczęciem potrzebujesz jakiegoś celu. Zaczynam od przypadków użycia, które zbieram z rozmów z moim klientem. Nie spędzam dni na tworzeniu fantazyjnych diagramów. Rozmawiamy, a potem piszę stronę Wiki i przeglądamy to. Potem piszę kilka testów. Potem piszę kod.

Istnieje nieskończona kombinacja wielkości zespołu, domen, języków, osobowości, budżetów i wymagań. Nie ma jednej metodologii, która byłaby najlepsza dla każdej sytuacji. Podobnie wiele osób ma osobiste preferencje i style.

Nawet jeśli ci się nie podoba, warto wypróbować nowe pomysły i krytycznie przeanalizować wyniki. Jest wiele rzeczy, których nie lubię, ale po pewnym czasie próbuję nauczyć się kochać. Jak oliwki.

Inną rzeczą jest to, że moda zmienia się regularnie. Wychowałem się w Waterfall, pracowałem w zespole, który starał się zrobić wszystko w Rational Unified Process, co było wtedy „najlepszą rzeczą”. Wkrótce Agile zostanie zastąpione czymś nowszym i lepszym, a nikt więcej nie wymieni słowa Agile.

Więc nie czuję, że trzeba polubić jedną metodologię jak Agile. (Osobiście mi się to nie podoba) Nie czyni cię złym programistą.