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ę:
Pozłacane. Stałe specyfikacje wymagań przed projektowaniem zachęcały do pozłacania oprogramowania. Użytkownicy pytani o swoje wymagania często rozumowali: „Nie wiem, czy będę potrzebować tej funkcji, czy nie, ale równie dobrze mogę to określić na wszelki wypadek”.
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.
Szybka i brudna, ale piękna.
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:
„Ryzyko jest podstawowym problemem przy tworzeniu oprogramowania”
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.