Programowanie a planowanie [zamknięte]

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?

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.

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.

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.

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.

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.

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.

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.