Zespół programistów, do którego należę, niedawno przystosował się do pracy zgodnie z praktykami Agile. To osobiście podkreśliło fakt, że nie mogę powstrzymać się od pozłacania kodu (i dokumentacji), aw konsekwencji przekraczam oryginalne szacunki, kiedy mogłem dostarczać rozwiązania, które spełniają wymagania znacznie wcześniej.
Myślę, że moja etyka graniczy z obsesyjnością, ponieważ zbyt przywiązuję się do mojego kodu i rzadko jestem zadowolony, że mogę go opublikować, zanim dokonam jego przebudowy i dopracowania do n-tego stopnia. Cieszę się, że zdałem sobie z tego sprawę, ale jak mogę zmienić swoje nastawienie / mentalność, aby zadowalać się postępami i zamiast tego wydawać je na czas?
agile
programming-practices
productivity
development-process
scrum
Andy Bowskill
źródło
źródło
Odpowiedzi:
Najlepszy jest wróg wystarczająco dobry.
Zawsze możesz przeprowadzić więcej testów, napisać lepszą dokumentację, wyłapać te narożne skrzynki, uzupełnić brakujące funkcje, sprawić, że architektura będzie czystsza. To się nigdy nie kończy. To jednak musi się skończyć. Muszą być dotrzymane terminy, ograniczenia zewnętrzne, które zależą od ukończonej części produktu. Dążenie do perfekcji w jednej niewielkiej części produktu szkodzi całemu produktowi.
źródło
Po pierwsze, chciałbym, aby więcej programistów miało ten problem, nie dlatego, że oprogramowanie zostanie wydane później niż oczekiwano, ale dlatego, że prawdopodobnie będzie to wydanie wyższej jakości.
Jeśli przekraczasz swoje pierwotne szacunki, być może musisz uwzględnić kroki „pozłacania” jako część swoich szacunków. Jeśli nie są to twoje własne szacunki, być może powinieneś być zaangażowany w ich formułowanie.
W każdym razie, jeśli masz termin wydania, powinieneś go dotrzymać. Wszelkie „pozłacanie” należy pozostawić jako ostatni krok, który nie powinien wstrzymywać wydania. Jeśli uważasz, że musi to zostać uwzględnione w ramach wydania, rozważ dodanie „pozłacania” we własnym czasie (tj. Poza godzinami pracy).
To, co powinieneś zrobić, to przedstawić swoje „pozłacane” kroki zespołowi i / lub kierownictwu i przedyskutować, dlaczego uważasz, że są one ważne. Jeśli możesz przekonać ich, że te kroki są korzystne, powinny stać się częścią przyszłych wydań.
źródło
Oprogramowanie pozłacane
Po raz pierwszy zobaczyłem złocenie użyte jako opis oprogramowania w artykule Barry'ego Boehm'a, w którym podał on następującą pierwotną przyczynę:
W swoim opisie zaleca stosowanie metod opisanych w swoich badaniach, w tym modelu cyklu życia oprogramowania spiralnego, w ramach którego opracowano projekty w celu wyprodukowania serii prototypów jeden na cykl, a wraz ze wzrostem liczby spiral produkt w pełni funkcjonalny. Spiral miał szeroki wpływ na badaczy oprogramowania i był ważnym pomostem między wodospadem a Agile. Krytycznym ograniczeniem spirali jest to, że za każdym razem wokół spirali cykle stają się dłuższe i droższe.
Podobnie jak w przypadku Agile, spirala próbuje uniknąć pozłacania, ograniczając zakres i planując dostarczenie projektu wystarczająco długo, aby zespoły mogły ukończyć wymagania, a jednocześnie być wystarczająco krótkie, aby umożliwić skupienie się na celu od pierwszego dnia do dnia dostawy. Jednym ze sposobów, w jakie metody zwinne, takie jak Scrum, są lepsze, jest to, że Scrum biegnie w ramach czasowych, które nie są dłuższe z iteracjami. Z pracy wynika, że zarządzanie projektami ma większy wpływ na pozłacanie niż w przypadku indywidualnych deweloperów.
Talent do boksowania czasu
Możliwość wyznaczania przedziału czasu jest bardzo ważna, ale nie jest to umiejętność binarna. Nie masz go lub go brakuje. Jesteś z tym lepszy lub mniej dobry. Niezależnie od tego, czy pochodzi od twojego szefa, czy od ciebie, wolałbym, gdyby nikt nie powiedział, że nie możesz przestać pozłacać. To brzmi osobiście, wszechobecnie i na stałe.
Analiza przyczyn źródłowych może pomóc zidentyfikować kilka problemów. Jestem pewien, że nie wszyscy będą na ciebie wskazywać i że jeśli nie będziesz pracować z psychopatami, inni w twoim zespole zobaczą podobne potrzeby, aby poprawić swoje umiejętności Agile. Jeśli znasz kogoś bez problemów, nie znasz go zbyt dobrze. Jeśli znasz kogoś, kto myśli, że nie musi się poprawiać, nie zna się zbyt dobrze.
Mam nadzieję, że zidentyfikowane usprawnienia będą rozwiązaniami, które można rozwiązać dzięki własnej świadomości i pomocy zespołu. Myślę jednak, że nie na tym koniec. Oczekuję od przełożonego lub kierownika, który pisze wasze recenzje, że mogą oni również szkolić swoich podwładnych, aby odnieśli sukces. Jest to szczególnie ważne, gdy organizacja przechodzi rewolucyjną zmianę, taką jak przejście z planowania na Agile (lub ad-hoc na Agile).
Szybki i brudny czy zarządzany ryzykiem prototyp?
Miałem menedżera, który zwykł prosić o wykonanie zadań w określony sposób.
Znał głupotę tego i było to częścią jego cierpkiego poczucia humoru. Wiele osób mówi takie rzeczy i są śmiertelnie poważne. Gdzieś jest kompromis lub szansa na złagodzenie problemu dzięki ulepszonej technologii lub podejściu.
Co możemy poświęcić, aby dopasować się do naszego przedziału czasu?
W pierwszym rozdziale książki „ Extreme Programming Explained” , drugie wydanie, Kent Beck mówi o tym, czego potrzeba, aby szybko się poruszać. Jego odpowiedź brzmi: „robisz tylko to, co musisz zrobić, aby stworzyć wartość dla klienta”.
Ryzyko
W pierwszym wydaniu tej samej książki Beck bardziej utożsamia się z poglądami Boehm'a na temat kontrolowania ryzyka jako kluczowymi dla jego metodologii, mówiąc:
W obu edycjach Beck wymienia i opisuje osiem typowych zagrożeń, po których następuje stwierdzenie, że XP (lub być może rozszerzenie Agile) odnosi się do każdego z nich w określony sposób. Dla mnie większość jego wyjaśnień sprowadza się do użycia mniejszych przyrostów, a szybsze iteracje pozwalają nam cofnąć wszystko na kurs, zanim ryzyko stanie się zbyt duże, aby sobie z tym poradzić.
Mentalność wystarczalności
Beck omawia zasoby w kontekście opowieści o ludziach górskich i ludziach leśnych i wprowadza koncepcję zwaną „mentalnością wystarczalności”. W kontekście twojej sytuacji pyta: „Jak byś to zrobił, gdybyś miał wystarczająco dużo czasu?” Tylko ten pierwszy rozdział, dostępny jako podgląd książki, może dostarczyć wiele do myślenia na temat tego, jak XP (i inne metody Agile) myślą o ograniczeniach takich jak czas.
Kompulsja może być objawem, a nie chorobą
Wiele lat temu spojrzałem na książkę o zwlekaniu, która głosiła, że wiele zwlekania rodzi się ze strachu. Jeśli nie zaczniesz, nie popełnisz błędu i być może nie będziesz krytykowany. Kompulsja i perfekcjonizm dają coś, co mówi nam nasz zmysł moralny, jest lepsze niż zwlekanie, ale prawdopodobnie ma ten sam skutek. Zastanów się, że być może masz problem z odkładaniem na później w innej formie?
Krytyka i konkurencja
W metodologiach zwinnych, takich jak Scrum, szanse na krytykę lub karanie za zwlekanie nigdy nie były większe. To błędne koło. Zwlekam, ponieważ jestem krytykowany, jestem krytykowany, ponieważ zwlekam. Dzięki codziennym spotkaniom scrumowym jesteśmy zawsze w pogotowiu, ponieważ zawsze jesteśmy o jeden dzień lub krócej od zgłoszenia zespołowi tego, co osiągnęliśmy.
W idealnym zespole Scrum daje codzienną możliwość korekty zwlekania. Błędy nie powinny mieć czasu, aby się rozrosnąć, zanim nadejdzie pomoc. Zespoły nie zawsze są tam, gdzie powinny być zaufane, więc przywódcy w zespole mogą potrzebować proaktywnie zająć się krytyką lub obawą przed krytyką, aby pozwolić na rozwój.
W naszym świecie pracy każda osoba w zespole musi również konkurować z innymi. Trochę schizofrenikiem jest wierzyć w posiadanie zespołu, który dzieli pracę i chwałę za osiągnięcia, ale następnie korzysta z corocznego procesu zarządzania wydajnością, który nagradza 20% swoich członków, karze lub wydala 10% lub więcej członków, oraz udaje, że 70% większość przyczynia się najlepiej bez zachęt. Myślę, że jest to wielki słoń w pokoju WRT promujący pracę zespołową, a nawiązując do historii Kenta Becka, pokazuje głębokie kulturowe powiązania z byciem Górą.
Droga naprzód
Jako członek zespołu Agile dobrze byłoby uczyć się i rozmawiać z innymi na temat tego, co działa. Jeśli Twój zespół korzysta z TDD do automatyzacji testów jednostkowych za pomocą narzędzia, poproś osobę, która najlepiej się z tobą wyszkoli. Jeśli Twój przełożony lub kierownik ma problem z podejściem do dokumentacji, dowiedz się, co mu się podoba lub kto robi to tak, jak lubi, i zastosuj się do niego. Jeśli sprowadza się do surowej prędkości kodowania, sprawdź, co potrzeba, aby kodować szybciej.
Liderzy mogą podejmować kroki we właściwym kierunku, modelując pożądane zachowania, takie jak szczera rozmowa o własnych problemach (nie cudzych), oferując pomoc i postępując zgodnie z nią, prowadząc dialog o tym, jak zespół może przejść do stylu Agile Marine (tj. Bez mężczyzny) pozostawione). Nie wszyscy w drużynie mają takie same umiejętności. Właściwe może być zbadanie członków zespołu parującego lub przypisanie zadań i ról, które mogą podkreślać uzupełniające się mocne strony zaangażowanych osób. Planowanie rozwoju lub naprawy umiejętności powinno być satysfakcjonującą częścią pracy zarówno dla przełożonego, jak i podwładnego, ale musi odbywać się wcześnie i często, aby było skuteczne.
źródło
Czy programujesz też dla zabawy? Zirytowały mnie również ograniczenia w pracy, które zabierają zabawę z programowania, a żeby to zrekompensować, czasami odpalam nowy projekt w domu i „robię to dobrze”. Podział pozwala mi zaspokoić zarówno moje potrzeby, jak i firmę.
Lub możesz rozwinąć nową umiejętność inną niż programowanie, aby robić w wolnym czasie, która (ostatecznie) zaspokoi to, czego praca nie może zapewnić. ;)
źródło