Agile Experts vs. Agile Manifesto

Czy uważasz, że „lokalny ekspert ds. Zwinności” przeczytał Manifest zwinny? Czy ty? Cóż, to nie jest problem… jeśli nie używasz słowa „Agile” na co dzień! Ale jeśli to robisz (lub robi to twój lokalny ekspert)… cóż - to coś w rodzaju ludzi, którzy za dużo mówią o religii, ale nie otworzyli Biblii (ostrzeżenie o poprawności politycznej) lub wybranej przez siebie świętej księgi od czasu zajęć z literatury 10 lat temu… Nie lubimy ich. Z powodu.

Ok, nie komentujmy innych ludzi i ich opinii. Zamiast tego przejrzyjmy krok po kroku „Biblię zwinną”.

Cytaty z Manifestu Zwinnego zostaną podane w

tego rodzaju blok tekstu

a nasze komentarze będą podawane w regularnych tiret takich jak ten. Chodźmy!

Manifest, jeden i jedyny!

Naszym najwyższym priorytetem jest zadowolenie klienta
poprzez wczesną i ciągłą dostawę
cennego oprogramowania.

To świetny pomysł! To było naprawdę rewolucyjne w momencie, w którym powstało! Ale realizacja tego pomysłu jest o wiele trudniejsza niż te kilka linii mogło być postrzegane.

Główny problem: każdy, kto miał bezpośredni kontakt z klientem, wie, że ten Manifest jest co najmniej nieco trudny.

Niestety, klient nie zawsze jest pewien, czego chce (chce) lub chce (chce) zbyt wielu rzeczy w tym samym czasie, i nie może odpowiednio ustalić ich priorytetów! Co więcej, może się zdarzyć, że niektóre z rzeczy, które klient pomyślał (a), że chciał, a później nie chciał…

Jeśli odłożymy to na bok - punkt Manifestu potwierdza jego wartość dla sukcesu produktu! Ale tych wyjątków NIE należy lekceważyć, ponieważ mogą być śmiertelne!

Następny punkt dotyczy czegoś podobnego, kontynuujmy ten temat.

Mile widziane zmiany wymagań, nawet późno
rozwój. Zwinne procesy zmiany wiązki przewodów dla
przewaga konkurencyjna klienta.

To jest świetne. Ale ciągłe obracanie się i nacisk na zespół programistów powoduje, że produkt jest kruchy. Szybkie kodowanie z dużą ilością przekierowań projektu powoduje, że jakość kodu produktu jest niska, więc zmiany stają się trudniejsze. Bardziej racjonalny i spokojny rozwój poprawia efektywność wprowadzania zmian na późniejszych etapach rozwoju produktu. Zgadzamy się, że zmiany powinny być mile widziane, ale inne klauzule umowne / umowy powinny również zostać proporcjonalnie zmienione! W wielu przypadkach oczekuje się, że produkt zostanie wdrożony w tym samym czasie, co w przypadku braku dodatkowych wymagań zmian. Nie fajnie.

Zwinność polega na byciu przygotowanym na oczekiwane zmiany, a nie na zmianie wszystkiego i zawsze. Osoby akredytowane do komunikowania się z potencjalnym klientem / klientem powinny od początku negocjować realistyczne porozumienie. Często 10 minut z długopisem i papierem we właściwym czasie (rozpoczęcie projektu) oszczędza dni, tygodnie, a nawet miesiące rozwoju (przekierowanie, obracanie, zmiana) na późniejszych etapach! Ten zastój na początku produktów należy uznać za nieprofesjonalny, ponieważ tak naprawdę jest! Mentalność „po prostu weźmy klienta, później pomyślimy o czymś do skończenia pracy” jest nieetyczna i zbyt często przychodzi deweloperom „ratować dzień” (praca w godzinach nadliczbowych, weekendy, praca w domu, praca w stresujące otoczenie)… Nie fajnie. I naprawdę - nawet nie zwinny.

Dostarcz działające oprogramowanie
często od
od kilku tygodni do kilku miesięcy, z
preferencja do krótszej skali czasowej.

Mam tylko dobre doświadczenia z tym. Daje to możliwość wczesnego uzyskiwania informacji zwrotnych poprawiających testy trakcji. Świetne rzeczy, jeśli koncepcja Agile ma zastosowanie w tworzeniu oprogramowania potrzebnego rodzaju produktu. (Nie zawsze tak jest, wierzcie lub nie.)

Ludzie biznesu i programiści muszą pracować
codziennie codziennie przez cały projekt.

Ok, może nie codziennie, ale także - kciuki do góry! My (ludzie) nie zdołaliśmy zrujnować tego przez ostatnie 15 lat… Daj nam czas.

Twórz projekty wokół zmotywowanych osób.
Daj im środowisko i wsparcie, którego potrzebują,
i zaufaj im, że wykonają zadanie.

To tutaj większość tak zwanych agilistów nie działa według Agile Manifesto. Często brakuje im szacunku dla osób, które są, jeśli nie ekspertami, wciąż lepszymi profesjonalistami, biorąc pod uwagę ich specjalizację, niż „zwinny” kierownik projektu. To sprawia, że ​​menedżer zbytnio angażuje się w pracę innych ludzi, co łamie ważne „maszyny”, jeden po drugim. Zmniejszenie dalszej zwinności i niezawodności „maszyny” przy zmianie. Który jest przeciwny.

Najbardziej wydajna i skuteczna metoda
przekazywanie informacji do i w ramach rozwoju
zespół to rozmowa twarzą w twarz.

Cóż, nie możemy nic powiedzieć przeciwko temu. Wręcz przeciwnie, brawo!

Działające oprogramowanie jest podstawową miarą postępu.

Tak. Problem polega na tym, że wielu tak zwanych agilistów również nie przestrzega tej klauzuli.

Zwinne procesy promują zrównoważony rozwój.
Sponsorzy, programiści i użytkownicy powinni mieć taką możliwość
utrzymywać stałe tempo w nieskończoność.

Trudne do osiągnięcia, ale oczywiście - świetna wskazówka.

Ciągła dbałość o doskonałość techniczną
a dobry design zwiększa zwinność.

Ponownie, niestety, tak zwani zwinni menedżerowie projektów często zapominają o tym, powodując poważne, jeśli nie śmiertelne, konsekwencje.

Prostota - sztuka maksymalizacji kwoty
nie wykonanej pracy - jest niezbędny.

Witaj, prostota!

Najlepsze architektury, wymagania i projekty
wyłaniają się z samoorganizujących się zespołów.

Zdrowaśka!

W regularnych odstępach czasu zespół zastanawia się, jak to zrobić
aby stać się bardziej efektywnym, a następnie dostraja i dostosowuje
jego zachowanie odpowiednio.

Amen!