Programowanie a planowanie [zamknięte]

15

Ostatnio otrzymałem więcej zadań planowania na wysokim szczeblu z powodu odejścia głównego programisty mojego zespołu. Nienawidzę planowania długoterminowego. Mój mózg po prostu nie wydaje się do tego podłączony i nie jestem wystarczająco zainteresowany, aby poświęcić czas na naukę (wystarczająco trudno jest nadążyć za stroną programistyczną obrazu).

Czy można być dobrym programistą, nie będąc również specjalistą od planowania?

Czy jako starszy programista powinien być dobry w planowaniu całego produktu i wybieraniu daty zakończenia?

MattW
źródło
Jeśli masz stanowisko programisty, dlaczego planujesz? Może szacunek, ale nie plan
superM
tak to mozliwe. W tym przypadku jednak Twoja produktywność będzie silnie zależeć od tego, jak dobry jest Twój menadżer / lider zespołu
gnat
1
To naprawdę interesujące pytanie. Nie sądzę, że musisz robić wiele specyfikacji technicznych, aby być dobrym starszym deweloperem - w rozwoju Agile pojawia się wiele funkcji nowego systemu lub projektu. Zobacz moją odpowiedź, aby uzyskać więcej informacji.
Robin Winslow,
1
Jak tam ten cytat? „Dni kodowania mogą zaoszczędzić godziny planowania” lub coś w tym rodzaju.
Drake Clarris

Odpowiedzi:

17

Szczegółowe długoterminowe plany projektów są znane z tego, że zwykle są bardzo niedokładne. Funkcjonalność systemu nieuchronnie zmieni się przed uruchomieniem, a ludzie zwykle spędzają dużo czasu na opracowywaniu specyfikacji, które wchodzą w specyfikację tylko po to, aby zainteresowane strony obdarzyły ją w najlepszym razie pobieżnym spojrzeniem.

Powinieneś przeczytać więcej na temat planowania Agile , może się okazać, że bardziej pasuje do twojego sposobu myślenia. Wiele metodologii Agile próbuje znaleźć sposoby na odejście od szczegółowego, długoterminowego planowania.

Zwinne metodologie próbują zminimalizować szczegółowe specyfikacje techniczne i dokumentację na rzecz samodokumentującego się kodu i odizolowanych, atomowych historii użytkowników i ostatecznie działającego oprogramowania. W sprawnym zespole Agile minimalna ilość czasu poświęcona jest na planowanie.

Przeczytaj Manifest Agile i zajrzyj do Scruma . Użyj metody rozwoju iteracyjnego i dynamicznego, aby poprowadzić projekt.

Główną wadą podejść zwinnych jest to, że musisz otwarcie przyznać , że nie znasz dokładnego zakresu projektu , a uzyskanie poparcia menedżerskiego dla tego pomysłu może być niezwykle trudne i zwykle zajmuje trochę czasu. Zobacz to pytanie i odpowiedź oraz ten post, aby uzyskać kilka wskazówek na ten temat.

Jednak z pewnością prawdą jest, że gdy zostaniesz starszym programistą, prawdopodobnie będziesz robić mniej kodowania, ale myślę, że w zwinnym zespole zamiast oznaczać, że piszesz więcej specyfikacji technicznych, oznaczałoby to, że poświęcisz więcej czasu na zarządzanie i nauczanie członkowie twojego zespołu i podejmowanie decyzji architektonicznych dotyczących kodu.

Robin Winslow
źródło
4
„Szczegółowe długoterminowe plany projektów są znane z tego, że zwykle są bardzo niedokładne”. DING DING DING +1
Ryan Kinal
11

Tak to mozliwe. Jeśli jednak chcesz być dobrym inżynierem oprogramowania lub architektem oprogramowania, w grę wchodzi planowanie na wysokim poziomie. Dla mnie główną różnicą między programistą a inżynierem była możliwość zobaczenia dużego obrazu.

Blaise Swanwick
źródło
1
Nie mam nic przeciwko planowaniu pracy, którą wykonuję teraz / w ciągu najbliższych 2 tygodni. Oznacza to, że jeśli to, co zamierzam napisać, obejmuje wiele utworów, nie mam nic przeciwko planowaniu tego na wysokim poziomie, a następnie robieniu tego (w rzeczywistości - właśnie to bym zrobił). Nie udaje mi się wymyślić randki miesiącami w przyszłości - a potem próbować dowiedzieć się, dlaczego tego nie zrobimy. Właśnie tam zaczyna się moja osobista frustracja.
MattW
Staram się, aby nie denerwowało mnie to osobiście. Staram się przypiąć takie rzeczy do kierowników projektów;).
Blaise Swanwick,
Aby dodać do komentarza Blaise'a. Zli menedżerowie nalegają na dotrzymanie harmonogramu i winią zespół za brak „zobowiązań”. W tym środowisku harmonogramy z pewnością są frustrujące. Dobrzy menedżerowie zdają sobie sprawę z tego, że początkowy harmonogram jest podstawowym przypuszczeniem, a nie zobowiązaniem. Wiedzą, że niektóre zadania potrwają dłużej, a niektóre krócej. Najbardziej interesują ich trendy długoterminowe. np. Obecnie mamy opóźnienie o 20% w stosunku do wyjściowego harmonogramu w ciągu 3 miesięcy. Oznacza to, że prawdopodobnie wykonamy 20% pozostałych pozostałych podobnych zadań. Następnie używają tego nowego harmonogramu do zarządzania projektem.
Dunk
9

Czy można być dobrym programistą, a nie planistą wysokiego poziomu?

Przez chwilę tak. Czy można to zrobić długo? Nie.

Obecnie wielu pracodawców jest standardową procedurą operacyjną zapewniającą koszty utrzymania konkurencyjnych podwyżek. Jeśli nie poprawisz siebie, nie próbuj stawiać czoła większym i trudniejszym problemom, te konkurencyjne w branży podwyżki spowodują, że wycofasz się z rynku za pięć lub dziesięć lat. Tak trzymaj, a twój pracodawca w końcu zacznie szukać powodu, aby się ciebie pozbyć, a twoja zdolność do zatrudnienia w innym miejscu również zostanie drastycznie zmniejszona.

David Hammen
źródło
Jestem zdezorientowany. Teoretycznie podwyżka COL powinna nadążać za stopą inflacji. Czy sugerujesz, że prawdziwe dolary wypłacane twórcom oprogramowania stopniowo maleją z czasem? A może podwyżki COL są na ogół więcej niż faktyczny wzrost kosztów utrzymania? Powiedziałbym, że większym problemem jest to, że niemożność wykazania wzrostu jest ogólnie uważana za negatywną. Istnieją jednak inne sposoby wykazania wzrostu, takie jak większy zasięg lub głębia umiejętności technicznych.
Ethel Evans,
1
Powinienem powiedzieć, że podwyżki konkurencyjne w branży, a nie podwyżki kosztów utrzymania. Zredagowałem swoją odpowiedź, żeby to powiedzieć. Te konkurencyjne w branży podwyżki są całkiem słodkie dla młodych dorosłych, zwykle znacznie lepsze niż inflacja. Podwyżki kosztów utrzymania są dla starych zamglących. Występuje problem, gdy ktoś dostaje podwyżki wyższe niż inflacja, ale umiejętności tej osoby pozostają niezmienione.
David Hammen
Gotcha! Dzięki za wyjaśnienie, to zdecydowanie ma sens.
Ethel Evans
Twierdzę niestety, że z czasem umiejętność programowania staje się łatwiejsza do nauczenia się, a zatem istniejąca, niezwiązana z rozwojem umiejętność inżyniera dewaluuje poza COL.
Nowa Aleksandria,
6

Jasne, możesz być dobrym programistą z punktu widzenia programisty. Z punktu widzenia zarządzania to zupełnie inne pytanie. Z mojego doświadczenia wynika, że ​​udział w procesie planowania jest najlepszym sposobem na 1) uzyskanie ciekawszych zadań programistycznych i 2) wykonanie ich tak, jak chcesz.

Innymi słowy, gdy sprowadza się to do planowania krótkoterminowego, wiele opcji nie wchodzi w grę. Jeśli preferowane rozwiązanie zajmie sześć tygodni, ale budżet ma tylko dwa, utkniesz z tym, co zdecydowali. Jeśli masz obawy dotyczące czegoś, co już omawiali w planowaniu długoterminowym, nie będą chcieli tego przerabiać.

Jeśli jesteś zadowolony z tego stanu rzeczy, daj więcej mocy. Większość ludzi staje się tym mniej zadowolona, ​​im więcej zdobywa doświadczenia.

Ta brudna tajemnica jest taka, że nikt nie jest zbyt dobry w długoterminowym planowaniu i szacowaniu. Lepsi planiści są tymi, którzy są świadomi swoich ograniczeń, więc wierzcie lub nie, jesteście na dobrej drodze. Przeprowadź szkolenie w zakresie rozliczania niepewności w szacunkach. Spójrz na techniki takie jak planowanie oparte na dowodach lub scrum, które opierają się na danych historycznych, aby pokazać, jak dokładne są twoje szacunki. W dłuższej perspektywie będziesz szczęśliwszy, jeśli będziesz miał większy głos w pracy.

Karl Bielefeldt
źródło
„Ten brudny mały sekret jest taki, że nikt nie jest zbyt dobry w długoterminowym planowaniu i szacowaniu”. Czy to nie prawda! +1 za to. Nawet z dobrą historią istnieje wiele liczb, które należy wyciągnąć z czystego nieba, ponieważ następny projekt nigdy nie jest dokładną kopią żadnego z poprzednich projektów. Gdyby tak było, moglibyśmy ponownie wykorzystać cały kod w obecnej postaci i zrobić to jak najszybciej. Zawsze jest coś nowego, a wyniki z przeszłości nie zawsze są dobrym wskaźnikiem tego, ile wysiłku potrzeba na te nowe rzeczy.
David Hammen
Ok - więc może frustracja (a nawet ego ) to więcej tego, czym muszę zarządzać. Jeśli nie potrafię się zbyt mocno pobić i z czasem jestem lepszy (zamiast mówić „nie lubię tego robić”) - na dłuższą metę będę lepszy. Mogę być dla siebie trudny, kiedy robię to źle - ale wydaje się (na podstawie tutaj odpowiedzi) powinienem nauczyć się robić to dobrze, jeśli chcę pozostać zatrudniony jako inżynier oprogramowania. Doceniam myśli wszystkich. Naprawdę nie mam w mojej firmie nikogo, kto mógłby się tego nauczyć - więc wysłuchanie tego od wszystkich tutaj jest ogromną pomocą!
MattW
3

Czy można być dobrym programistą, a nie planistą wysokiego poziomu?

Krótka odpowiedź: Tak, jest to możliwe.

Im więcej zdobędziesz doświadczenia z rodzajem projektów, w które jesteś zaangażowany, tym lepsze pomysły na planowanie. Idealnie, jako programista, mamy pewne podejście do rozwiązania problemu lub szukamy jednego. Jeśli więc znamy podejście, możemy zacząć myśleć o planowaniu :)

Inną możliwą drogą jest to, że programista, który staje się dobrym planistą, w końcu zmierza w kierunku zarządzania projektami. Dlatego jeśli interesujesz się zarządzaniem projektami, możesz włożyć dodatkowy wysiłek w tym kierunku.

Jusubow
źródło
1

Tak i Nie to twoje odpowiedzi.

Z jednej strony jesteś nakłaniany do zarządzania projektami. IMO, wszyscy dobrzy programiści mają pewne możliwości zarządzania projektami, ale są to różne zestawy umiejętności. Możliwość długoterminowego planowania poprawia umiejętność komunikowania się z faktycznym zarządzaniem projektem. Więc „nie”, nie możesz być dobrym programistą bez umiejętności planowania długoterminowego.

To powiedziawszy, zarządzanie projektami to inny zestaw umiejętności, który odwołuje się do aspektów powiązanych, ale innych niż programowanie. Oto, gdzie pojawia się „tak”. Nie musisz być kierownikiem projektu, aby być świetnym programistą.

W konkretnej sytuacji staraj się być bardziej obiektywny w zakresie potrzeb firmy i tego, co lubisz robić. W twoim pytaniu znajduje się trochę za dużo ego, co osłabia twoją zdolność patrzenia na tę sytuację. Jeśli potrafisz znaleźć sposób, aby wnieść większy wkład w pracodawcę, jednocześnie robiąc to, co lubisz, powinieneś rozważyć je i przedyskutować sprawę z szefem.


źródło
1

Planowanie i szef Bungie

Dilbert ma wiele pasków o szefie bungie. Nasze wyzwania i oczekiwania dotyczące planowania mogą być zarówno przyczyną, jak i skutkiem rezygnacji z przywództwa. Moje doświadczenie w firmie z listy Fortune 100 polegało na tym, że w ciągu roku wszyscy, którzy rozpoczęli ten rok jako kierownik projektu, odeszli. Być może było to spowodowane problemem planowania. Nie jestem pewien, czy z tego powodu odszedł twój poprzedni potencjalny klient, ale kiedy twoja rola wymaga, musisz opracować plan z zaangażowaniem, jeśli nie dojdzie do skutku, często skutkuje wyjściem z terminu.

Kontekst organizacyjny planowania

Jeśli czujesz się niekomfortowo z planowaniem, być może czujesz się nieswojo z odpowiedzialności za zobowiązania wobec marketingu lub innych interesariuszy, zanim problemy do rozwiązania zostaną udokumentowane lub zrozumiane. To dobry instynkt.

Planowanie jest ważnym narzędziem. Nie zaniedbuj tego. Nie zrozum tego źle.

Planowanie jest integralnie powiązane ze zobowiązaniami, rozliczalnością i siłą negocjacyjną. Zwinne planowanie ma wiele zalet. Powinieneś znać jego techniki, a także techniki planowanych metodologii. Twoja organizacja może mieć własne podejście, a porady i praca z kimś, kto przetrwał kierownictwo wielu projektów, mogą być zaskakująco pomocne.

Prosty przykład planowania - nie może dotyczyć oprogramowania ...

Jeśli firma dachowa przyszła do mojego domu, aby licytować na wymianę, jeśli licytuje zbyt nisko, może stracić pieniądze na pracy, ale jeśli licytują zbyt wysoko, w ogóle nie dostaną pracy. Tak czy inaczej, są nieczynne. W nowej roli, jeśli ugryziesz się zbyt nisko, będziesz prowadzić projekt, dopóki nie zacznie się odpowiedzialność, wtedy będziesz mieć problemy. Jeśli oszacujesz projekt z wystarczającą ilością paddingu, aby zapewnić sukces przed upływem terminu, wielu po prostu wybiera kogoś innego do kierowania. Kickerem jest to, że nie jesteś jak dekarz. Widzi, jak duży jest dach, i ma dane historyczne dotyczące długości dachu.

Zostań lepszym planistą

Możesz rozważyć jakiś rodzaj treningu. W metodologiach zwinnych i najnowszych planowanych metodach szacowanie jest działaniem obejmującym cały zespół. W związku z tym powinieneś rozważyć szkolenie dla swojego zespołu.

Z doświadczenia mogę powiedzieć, że uzyskanie frustracji od członków zespołu, którzy ją odłożą, może być frustrujące, dać szacunki dokonane w ciągu dwóch minut na podstawie nazwy zadania bez odniesienia do opisu wymagania lub funkcji lub istniejącego kodu, lub którzy twierdzą, że kilka zadań, które wymieniasz, można wykonać w ułamku dnia, nawet jeśli poprzednie projekty poświęcały tygodnie na podobne problemy.

Istnieją różne szkolenia i certyfikaty dla kierowników projektów, ale chciałbym szukać takich, które uzyskały niezależną akredytację. Warto się zastanowić, zanim zdecydujesz się na certyfikację metodami opartymi na planowanych metodach, jeśli spodziewasz się pracy z zespołami Agile (lub na odwrót).

SLIM to metoda wymyślona przez Putnama po pracy w GE i innych firmach nad projektami DoD w latach siedemdziesiątych. SLIM ma wpływ, a jego firma QSM oferuje certyfikat, który wydaje się wypływać z narzędzia, które wykonują. W zależności od tego, czy Twoja firma przyjęła swoje narzędzie, może ono nie mieć żadnej wartości lub wysokiej wartości.

Steve McConnell (autor Code Complete) napisał także książkę o szacowaniu oprogramowania, a jego firma Construx prowadzi dwie klasy kredytów PDU, które są akredytowane przez Project Management Institute. Mam jego książkę i gdybym chciał dowiedzieć się na ten temat poprzez szkolenie w klasie, prawdopodobnie wybrałbym Construx. Robią także szkolenia Scrum i administrują różnymi ocenami Scrum akredytowanymi przez Scrum.org.

Innym źródłem, które mogłoby zapewnić doskonałe szkolenie akademickie na temat szacowania projektów oprogramowania, byłaby grupa Barry'ego Boehm'a w USC , oparta na ich obszernych pracach nad konstruktywnym modelowaniem kosztów COCOMO i COSYSMO, które zostało wykorzystane w NASA i innych dużych kontrahentach do oszacowania bardzo dużych projektów. Nie jestem pewien, czy naprawdę wierzę w COCOMO, ale podoba mi się praca empiryczna, którą wykonali, aby skorelować wpływ czynników skali i kosztów na czas trwania harmonogramu.

Znalazłem również rozdział z podręcznika opublikowanego przez O'Reilly, który krótko omawia najważniejsze metody szacowania oprogramowania, w tym Watts Humphreys PROBE i grę planistyczną Kenta Becka. PROBE zawiera koncepcję, że inżynierowie śledzą metryki dotyczące ich własnej produktywności, a następnie stosują je do swoich zadań w nowych projektach. Gra planistyczna jest bardzo wysoce współpracująca między programistami i innymi interesariuszami.

DeveloperDon
źródło