Mam problem ze starszym dyrektorem, który nie rozumie iteracyjnego rozwoju (a tym bardziej zwinnego). Nalega, aby nasza specyfikacja projektu oprogramowania była kompletna przed napisaniem dowolnego wiersza kodu. Kompletny, dla niego, oznacza, że ​​wszystkie funkcjonalne szczegóły są dostępne. Ponadto, będąc byłym programistą Cobola, chce zobaczyć „moduły” i schematy blokowe. To jest aplikacja internetowa Java do głośnego płaczu!

W każdym razie staram się znaleźć proste miejsce, aby delikatnie wskazać mu, aby pokazać, że karta charakterystyki nie musi być w 100% kompletna przed rozpoczęciem kodowania (ani nie może być kompletna). Jakieś sugestie?

Dzięki!

Jako konsultant rozumiem jedną prostą zasadę konsultacji:

• Nie możesz pomóc ludziom, którzy nie chcą pomocy.

Nie możesz zmusić nikogo do zrobienia czegokolwiek, czego nie chce, chyba że siłą władzy, której nie masz.

Jako trener przedstawiam Agile z trzema zasadami:

1. Nie można zebrać wszystkich wymagań na początku projektu.

2. Niezależnie od wymagań Ci zrobić zbierają są gwarantowane do zmian.

3. Zawsze będzie więcej do zrobienia niż czas i pieniądze na to pozwalają.

i jeden cel:

• Dostarczaj coś wartościowego co tydzień.

To wszystko, czego potrzebujesz, aby zacząć.

Przekonanie swojego menedżera to inna sprawa.

Nie możesz „zmusić” menedżera do zrozumienia zwinnego inaczej niż możesz sprawić, że programista to zrozumie. Musisz przedstawić mu argumenty (książki Kenta Becka są dobrym początkiem) i pozwolić mu podjąć decyzję.

Możesz też poprosić go o pozwolenie na przeprowadzenie eksperymentu. Weź mały projekt i uruchom go z iteracyjnym rozwojem i miej oko na czas, budżet, problemy z jakością i satysfakcją zespołu. Porównaj go z poprzednimi projektami (lub wydaniami) i sprawdź, czy było lepiej, gorzej czy neutralnie.

Ty nie

Po pierwsze, dlaczego Starszy Dyrektor w ogóle bierze udział w wyborze metodologii tworzenia oprogramowania? Ta decyzja jest znacznie niższa niż jego płaca, klepie mikrozarządzaniem i mówi wiele nieufności.

Po drugie, dlaczego w ogóle musi to rozumieć? Jeśli specyfikacje oprogramowania są utrwalone w kamieniu, nastąpi dokładnie jedna iteracja. Jeśli nie, nastąpi wiele iteracji. To nie jest jego decyzja .

Jeśli myśli, że to jego decyzja, podważa autorytet kierownika IT, kierownika projektu, architekta IT, kierowników zespołów i zespołu programistów. Powinien więc napisać oprogramowanie @ # $% ing lub STFU i pozwolić profesjonalistom wykonywać swoją pracę bez obciążania mózgów dinozaurów.

Nie żartuje. Jeśli nie może ci ufać, że wykonujesz swoją pracę, powinien to zrobić sam, a ty uciekaj krzycząc .

„Tworzenie oprogramowania jest jak tworzenie filmu, musisz zaplanować z góry, ale podczas filmowania musisz zrobić powtórki, ponownie odwiedzić stare sceny i edytować produkt końcowy, aby zapewnić dobry wynik”

Z drugiej strony jest menedżerem, więc w jego słowach:

„Musimy wykorzystać naszą synergiczną elastyczność, aby stworzyć kompleksowe rozwiązanie serwisowe na czas”

Obowiązuje stare powiedzenie: możesz zabrać konia do wody, ale nie możesz go pić.

Jak zauważyli inni, dla tego starszego dyrektora tak naprawdę powinna mieć znaczenie wartość biznesowa. Możesz spróbować szybko oszacować, ile czasu poświęcisz na opracowanie jego schematów blokowych i schematów modułów oraz napisanie „kompletnej” karty charakterystyki (niedorzeczna koncepcja, ale daj mu to, czego chce). Jeśli wiem coś o tych rzeczach (a kiedy zacząłem pisać oprogramowanie, tak to zostało zrobione), to wasz szacunek z łatwością wyniesie kilka osobo tygodni, jeśli nie więcej, na spory projekt. Wyraź tę liczbę w pieniądzu.

Następnie pokaż mu, ile funkcji możesz dostarczyć w tym samym czasie. Porozmawiaj z kilkoma osobami z branży o tym, ile czasu zaoszczędziłoby im posiadanie podstawowej aplikacji internetowej wykonującej czynności, które możesz dostarczyć w tym samym czasie. Następnie pomnóż tę oszczędność, chociaż często używają tej funkcji, powiedzmy, za 3 lata. Wyraź to w pieniądzach.

Prawdopodobnie istnieją inne korzyści biznesowe, które można wyrazić w pieniądzu. Moim ulubionym jest zawsze zapobieganie „goofball”. Jeśli twoje oprogramowanie pomaga zminimalizować liczbę katastrof lub całkowicie ich uniknąć, znajdź ostatnią katastrofę i wyraż ją w kategoriach pieniężnych. Następnie powiedz swojemu szefowi: Gdybyśmy mieli to teraz, zaoszczędzilibyśmy te pieniądze.

A jeśli sztuczka z pieniędzmi nie zadziała, może powinien podejść do niego i powiedzieć mu, żeby przestał zarządzać swoim zespołem. Chociaż z mojego doświadczenia wynika, że ​​bardziej prawdopodobne jest, że zostaniesz zwolniony niż cokolwiek innego.

Prostym miejscem może być Manifest dla Agile Software Development .

Informacje, które znajdziesz w tym miejscu, dotyczą podstawowych zasad zwinnego tworzenia oprogramowania, określonych przez grupę dobrze znanych specjalistów.

To jest

• Osoby i interakcje dotyczące procesów i narzędzi
• Działające oprogramowanie w obszernej dokumentacji
• Współpraca z klientami w zakresie negocjacji umów
• Reagowanie na zmianę po wykonaniu planu

Ale spójrz dokładnie na stronę, aby uzyskać pełną intencję.

Proponuję spróbować pokazać mu, że wykonując „Rapid Prototyping” (czyli rozpoczynanie kodowania pierwszych kilku iteracji) możesz szybciej i dokładniej opracować swoją kartę charakterystyki (co oznacza mniej przeróbek później) i zacząć dostarczać wartość biznesową wcześniej. Naprawdę, najbardziej prawdopodobna wartość biznesowa jest najważniejsza dla tego dyrektora i zdecydował, że najlepszym sposobem na osiągnięcie tego jest ten sekwencyjny proces. Musisz pokazać mu w kategoriach, dlaczego twoje podejście jest lepsze.

Może to być pomocne - http://www.youtube.com/watch?v=4u5N00ApR_k

W tym filmie „Chcę uruchomić zwinny projekt” śledzimy doświadczenia jednego z takich odważnych liderów projektu, Luke'a, ponieważ ma on wiele różnych spotkań w całym przedsiębiorstwie, pracując nad stworzeniem i dostarczeniem swojego projektu zwinnego.