Spisu treści:
Bycie zwinnym zespołem programistycznym z pewnością oznacza różne rzeczy dla różnych ludzi. Istnieją stopnie przyjęcia w bardzo szerokim spektrum i najwyraźniej bardzo niewiele organizacji uważa, że robią to dobrze. Według ankiety na temat stanu Agile firmy VersionOne (opublikowanej w kwietniu 2017 r.) 80% respondentów twierdzi, że „jest na lub poniżej jeszcze dojrzewającego poziomu”. Niestety, zespoły programistyczne często nie wkładają wiele wysiłku w „uczącą się” część iteracji. Chcemy się pospieszyć i zakończyć ceremonie Scruma, abyśmy mogli wrócić do pisania kodu. W końcu jest tak dużo do zrobienia! Ale czy naprawdę problemem jest niewystarczający czas kodowania?
Dla wielu z nas walka z ogniem może być równie dobrze wymieniona w naszym opisie pracy. Codziennie chodzimy do pracy, wiedząc, że musimy być gotowi, by w każdej chwili zsunąć się z słupa, chwycić za czapki i wskoczyć na ciężarówkę. Akceptujemy to takim, jakim jest, i zakładamy, że nic nie możemy na to poradzić. Ale co, jeśli podstawową przyczyną naszych zmagań jest poważny brak wydajności? Wszyscy wiedzą, jak ważne jest, aby robić to lepiej niż ta inna firma. Po prostu nie możemy się tam dostać - wydaje się, że nie mamy odpowiedniej przepustowości. Menedżerowie dodają więcej ludzi i powiększają swoje organizacje, a mimo to wciąż mają te same problemy. Wydaje się, że nie możesz się przebić, ponieważ Twoje zespoły nie opracowują oprogramowania efektywnie (i nie jesteś sam).
Zasady efektywnego rozwoju
Pixabay
Więc co powoduje, że jesteśmy nieefektywni? Większości z nas pierwszą rzeczą, która przychodzi na myśl, jest brak automatyzacji (automatyczne kompilacje, wdrożenia, testowanie). „Kiedy osiągniemy wystarczającą automatyzację, życie się polepszy”. Niestety to tylko część rozwiązania. Rozważ wpływ przeróbek na swój projekt. Najskuteczniejszym sposobem tworzenia funkcji jest utworzenie jej raz poprawnie i nigdy więcej nie wracaj i nie dotykaj jej. Błędy, refaktoryzacja i inne podobne czynności zasadniczo powodują ponowne otwarcie pacjenta po opuszczeniu sali operacyjnej i wiąże się z tym nieodłączne ryzyko. Nie możemy wyeliminować przeróbek, ale z pewnością powinniśmy starać się je zminimalizować.
„Ale czy agile nie obejmuje przeróbek (np. Refaktoryzacji)?” W pewnym sensie tak się dzieje, ponieważ twórcy agile zrozumieli, że dwie kluczowe przyczyny przeróbek to nieprzewidziane okoliczności i zmieniające się wymagania biznesowe. Okazuje się, że ludzie strasznie przepowiadają przyszłość. Twórcy Agile zrozumieli również, że ogromnym czynnikiem przyczyniającym się do nieefektywności jest to, co programiści nazywają „pozłacaniem” - pakowanie w funkcjonalność, z której naszym zdaniem ktoś skorzysta, mimo że użytkownicy końcowi nigdy o to nie prosili. To jak wieprzowina dla twojego oprogramowania - kompletna strata czasu. „Nie buduj stacji kosmicznej, kiedy wszystko, o co proszą, to Volvo”. Firmy mądrze zaczęły więc pomijać wieprzowinę i zamiast tego wprowadzać refaktoryzację, dodając funkcjonalność tylko wtedy, gdy istnieje wyraźna potrzeba. Ale nieprzewidywalność życia nie jest jedynym motorem przeróbek, prawda?
Pominięte szczegóły na którymkolwiek etapie rozwoju funkcji ostatecznie zmarnują czas i pieniądze. Skuteczna współpraca z góry z czasem pozwoli Ci zaoszczędzić mnóstwo poprawek (radzenie sobie z pominiętymi wymaganiami, krótkowzrocznym projektem itp.). Wszyscy mamy martwe punkty i wszyscy potrzebujemy dodatkowych zestawów oczu. Wiele zespołów programistycznych wykorzystuje to na zapleczu podczas przeglądu kodu, ale poświęca znacznie mniej energii na współpracę na wczesnym etapie, gdy problemy można rozwiązać tanio i przy minimalnych inwestycjach.
Ile razy zaimplementowałeś funkcję i pod koniec znalazłeś znaczące błędy, które powinny zostać wykryte podczas dyskusji na temat wymagań / projektu? To tak, jakby próbować jechać z Atlanty do Montgomery i zdać sobie sprawę, że po kilku godzinach podróży przypadkowo pojechałeś do Birmingham. Ile czasu poświęcono próbom uzyskania odpowiedniego kodu tylko po to, aby później ponownie otworzyć pacjenta, ponieważ pominięto istotne wymagania? Całkowite wykorzystanie zbiorowej inteligencji pozwoliłoby zaoszczędzić czas i pieniądze, ale zamiast tego programiści często pracują nad funkcjami w izolacji.
Tradycyjne rojenie
Pixabay
Tradycyjny rój oznacza, że zespół pracuje wspólnie nad historiami z kilkoma osobami pracującymi jednocześnie nad małym elementem, skracając pętlę sprzężenia zwrotnego i skracając całkowity czas ukończenia funkcji (tj. Dziel i rządź). Zasadniczo roi się to w każdej dyscyplinie (programiści zaplecza, programiści UI itp.). Przed rozpoczęciem programowania programiści interfejsu użytkownika pracują nad identyfikacją niezależnych zadań, które można wykonywać jednocześnie. Omawiają punkty styku, aby każdy wiedział, jak jego element pasuje do całości. Członkowie zespołu mogą następnie przystąpić do wykonywania przydzielonych im zadań i na koniec zebrać wszystko razem podczas integracji. Częste zatwierdzenia i okresowe przeglądy kodu pomagają zapewnić, że wszystko pozostanie na szynach. Takie podejście wymaga współpracy między programistami,co i tak pomaga uzyskać lepszy efekt końcowy. Często traktujemy priorytetowo czas poświęcony na pisanie kodu (dowolnego kodu) nad czas spędzony na upewnianiu się, że nie napiszemy niewłaściwego kodu. Gdy weźmiesz pod uwagę potencjalnie zaoszczędzony czas, wartość staje się jasna.
Odblokowanie
Pixabay
Innym cennym podejściem do roju jest skupienie się zespołu na wczesnym etapie łagodzenia zależności w celu ułatwienia równoczesnego rozwoju w różnych dyscyplinach. Rozważ naturalny przebieg rozwoju funkcji interfejsu użytkownika. Testerzy automatyzacji (SDET) są zależni od działającego interfejsu użytkownika do testowania, programiści interfejsu użytkownika są zależni od działającego interfejsu API zaplecza, a programiści zaplecza są zależni od konfiguracji, aktualizacji baz danych i zautomatyzowanych kompilacji / wdrożeń. Dlatego programiści UI mogą nie rozpocząć pracy, dopóki interfejsy API nie zostaną ukończone, a SDET mogą nie rozpocząć pracy, dopóki funkcja nie zostanie ukończona. Każda dyscyplina działa w izolacji, co utrudnia współpracę, ponieważ ludzie, z którymi musisz wchodzić w interakcje, są zajęci pracą nad innymi rzeczami.Ale co by było, gdybyś mógł wcześniej złagodzić zależności i pozwolić wszystkim dyscyplinom pracować jednocześnie nad tą samą funkcją?
Oto kilka przykładów:
1. Wdrożony funkcjonalny interfejs użytkownika ze skrótami
Aby odblokować SDET, programiści UI mogą dać im funkcjonujący interfejs użytkownika, który działa tylko na tyle, aby umożliwić im pisanie testów. Integracja interfejsu API zaplecza i style CSS mogą nadal być w toku, ponieważ zautomatyzowane struktury testowe, takie jak Selenium, nie będą się przejmować, czy te rzeczy są niedokończone. Może to być dym i lustra. Chociaż mogą wystąpić zmiany powodujące pewne poprawki, korzyści wynikające z wczesnego rozpoczęcia testów przeważają nad tym ryzykiem.
2. Wdrożone interfejsy API zaplecza (gotowe, zakodowane dane)
Zapewnienie interfejsów API zaplecza, na podstawie których programiści interfejsu użytkownika mogą testować, umożliwia wczesne wykrywanie problemów z integracją między interfejsem a interfejsami API. Czasami okazuje się, że udostępniony interfejs API nie spełnia potrzeb programistów front-endowych. Może brakować całych wywołań, może być nieprawidłowy podpis lub struktura danych może mieć problemy. Jeśli występuje rozłączenie, równie dobrze możesz się o tym dowiedzieć wcześniej, zanim cokolwiek stwardnieje.
3. Utwórz wersję HelloWorld nowych aplikacji i usług.
Jeśli potrzebna jest nowa usługa (np. Mikrousługa), utwórz repozytorium i utwórz wersję usługi „hello world”. Dzięki temu zasoby deweloperów mogą rozpocząć pracę od zadań Jenkins i skryptów wdrożeniowych, zanim usługa zostanie faktycznie opracowana.
Te optymalizacje ułatwiają wczesną pętlę sprzężenia zwrotnego, w której ktoś może powiedzieć „Potrzebuję czegoś innego”, zanim zakończy się tworzenie komponentu wymagającego zmiany.
Podsumowując to
Niezwykle ważne jest, abyśmy wymyślili, jak skrócić czas wprowadzania na rynek funkcji, nad którymi pracujemy. Firma nie czerpie żadnej korzyści z posiadania wielu funkcji, które są w toku, a programiści rozpaczliwie potrzebują szybkiego wdrożenia funkcji, aby usterki można było usunąć jak najbliżej miejsca wstrzyknięcia. Programiści również desperacko muszą ze sobą współpracować, mimo że wszystko, czego naprawdę chcą, to napisanie kodu. Jest to lepsze dla wszystkich zaangażowanych, w tym dla użytkownika końcowego, który po prostu chce lepszego produktu. Jeśli im tego nie dasz, pójdą gdzie indziej, aby to znaleźć.
Rój jest niezwykle cennym narzędziem w zestawie narzędzi Twojej organizacji, jeśli ludzie poświęcają czas, aby nauczyć się, jak to zrobić. To nie jest schemat ani nawet działanie - to sposób myślenia. W przypadku każdej historii użytkownika członkowie zespołu zadają sobie dwa pytania:
- W jaki sposób zorganizujemy zadania w tej historii, aby kilka osób współtworzyło naraz?
- Jakie minimum muszę zrobić, aby odblokować kogoś, kto na mnie czeka?
Co się stanie, jeśli Twój zespół szybko utworzy funkcje razem, zamiast powoli tworzyć kilka funkcji niezależnie? Mogliby faktycznie reagować na zmieniające się wymagania biznesowe i zaspokajać potrzeby firmy, gdy ta wymaga ich spełnienia. Konkurenci baliby się Ciebie - klienci by Cię kochali. To przepis na udany biznes.
© 2017 Mike Shoemake