Weeding real agile from modne zwinne w wywiadzie

Ostatnio przeprowadzam wywiady dla spółdzielni (płatne staże), a wiele firm, z którymi przeprowadzam wywiady, mówi, że używają Scruma lub innej zwinnej metodologii (najbardziej popularny jest Scrum). Wiem, że istnieją prawdziwe sklepy zwinne i są miejsca, które mówią, że używają zwinnej metodologii, ale naprawdę robią coś innego i używają zwinnego jako modnego słowa.

Moje pytanie brzmi: jakie pytania mogę zadać w wywiadzie, który oddzieliłby te sklepy?

EDYCJA: Kiedy szukam stażu, czuję, że te pytania dotyczą wszystkich. Część stażu jest kontekstem.

Zawsze zaczynam od zadania tego pytania:

Jaki jest czas trwania twoich iteracji?

Oceń ich odpowiedź:

1 tydzień jest niesamowity, 2 tygodnie są świetne, 3 są w porządku, a 4 przeciętne. Dłużej niż to wskazuje, że walczą, a ponad 8 tygodni to po prostu dziwne. Jeśli odpowiedź jest zależna , wiesz, że nie mają pojęcia.

Kontynuuj za pomocą:

Jak często wypuszczasz?

Ma to na celu zweryfikowanie pierwszego pytania. Prawidłowa odpowiedź to dzień lub koniec każdego sprintu . Agilista wiedziałby, że nie powinno być technicznej różnicy między wydaniem wewnętrznym i zewnętrznym.

Poproś ich, aby bronili zwinnych metodologii. A następnie poproś ich o obalenie go przez wskazanie jego słabości. Punkty bonusowe, jeśli mogą poruszać się po tym kursie bez zaśmiecania go bezsensownymi modnymi słowami.

Zapytaj ich, dlaczego go używają .

Od razu się dowiesz.

Poprosiłbym ich o opisanie cyklu życia oprogramowania przy użyciu metodyki Agile. Jeśli się z tym zapoznają, powinni być w stanie dokładnie opisać każdą fazę w SDLC.

EDYCJA : Właśnie zdałem sobie sprawę, że pytasz z punktu widzenia rozmówcy, a nie ankietera. W takim przypadku prawdopodobnie zapytałbym ich o ich SDLC i sprawdził, czy kroki, które, jak twierdzą, podejmują, pasują do tego, czym naprawdę jest Agile.

Podejście, które podchodzę naprawdę nie ma wiele wspólnego ze zwinnymi modnymi słowami, ale ma związek ze zwinnymi praktykami. Jedną ze wspólnych cech wszystkich zwinnych zespołów jest krótka iteracja, większość ludzi bierze tę część (jest to jedna z 12 zasad zwinności na stronie http://agilemanifesto.org ). Celem tej krótkiej iteracji jest wczesne uzyskanie opinii na temat jakości opracowanego oprogramowania. Od tego zaczynam.

1. Zapytaj o testy jednostkowe. Przeważnie odpowiedź, którą tu otrzymałem, brzmiała: „uh, wycięliśmy to, ponieważ nie mieliśmy wystarczająco dużo czasu” (uwaga: pierwsze 2 flagi ostrzegawcze - brak czasu i brak testów jednostkowych)
2. Zapytaj o to, kiedy oprogramowanie było testowane i jak często. Odpowiedzi mogą być kreatywne tutaj. Szczególnie, jeśli zespół używa „Agile” jako wymówki, aby odrzucić cały proces na bok. Jeśli odpowiedź jest pod koniec projektu lub coś innego niż przy każdej iteracji, nie wiedzą, co to jest zwinne.

Jak dotąd nie musiałem iść dalej, aby wiedzieć, że osoba nie wie, co to jest zwinność. Byłem także tylko w jednym wywiadzie z firmą, która ma już ugruntowane procesy zwinności.

Jest więcej niż jeden sposób na zwinność, a bardziej zależy mi na zasadach zwinności niż na jakiejkolwiek konkretnej marce lub modnym słowie.

Istnieje kilka rzeczy, które oddzielają tych, którzy „działają” zwinnie od tych, którzy są zwinni:

• Zapytaj o ciągłą integrację, jeśli nie używają CI odejmij punkt. Dodaj punkt, jeśli są. Dodatkowe punkty:
  1. Dodaj 1, jeśli używają zatwierdzeń dwufazowych (kod musi się pomyślnie skompilować, zanim programista będzie mógł się zalogować).
  2. Dodaj 1, jeśli skrypt kompilacji obejmuje uruchomienie zestawu testów
  3. Dodaj 1, jeśli kompilacja nie powiedzie się, jeśli zasięg kodu spadnie poniżej określonego progu
  4. Dodaj 2, jeśli można wdrożyć aplikację, aby była gotowa do uruchomienia jednym kliknięciem
• Zapytaj o TDD (rozwój oparty na testach) odejmij 2 punkty, jeśli nie używają TDD, dodaj 1, jeśli to zrobią.
• Zapytaj o iteracje, jak długo one trwają (odejmij 2 punkty, jeśli nie robią iteracyjnego rozwoju, odejmij 1, jeśli iteracja trwa dłużej niż miesiąc lub krócej niż dwa tygodnie, dodaj 1, jeśli to 2 tygodnie)
• Zapytaj, w jaki sposób dokonuje się oszacowania, dodaj 1, jeśli wykorzystują punkty historii, dodaj 2, jeśli planują pokera lub coś podobnego, odejmij jeden, jeśli używają szacunków czasu bezwzględnego, odejmij 2, jeśli programiści nie są zaangażowani w proces szacowania.
• Zapytaj, jak budowane są funkcje, dodaj 1, jeśli programista jest odpowiedzialny za funkcję od góry do dołu (pionowy wycinek) odejmij 1, jeśli programiści są odpowiedzialni za określoną warstwę (wycinek poziomy)

Istnieje wiele innych wskaźników, ale same te powinny dać ci dobry obraz, jeśli zespół faktycznie jest zwinny. Drużyna z 5 lub więcej punktami kwalifikuje się. Wszystko inne oznacza, że ​​„robią” zwinnie. Zwinność to nie tylko iteracje, ale także umożliwienie zespołowi łatwego dostosowania się do zmian. Jeśli iteracyjnie piszesz niepoprawny, zagmatwany kod, napisany pod presją zewnętrzną, to po prostu piszesz bzdury w iteracjach. Zauważ, że możesz zdobyć wiele punktów tylko dzięki ciągłej integracji. Ale to nie wystarczy, aby przynieść ci ponad 5, jeśli nie przestrzegasz innych praktyk.

Tak jak w przypadku wszystkich tych rzeczy, pytasz o przykłady z rzeczywistych projektów, nad którymi pracowali , a nie teorię. Akceptowanie odpowiedzi teoretycznych jest najprostszym sposobem na oszukanie przez kogoś, kto tak naprawdę tam nie był.

Więc prosisz o rozmowę z prawdziwymi programistami i pytasz o takie rzeczy jak:

• Opowiedz mi o swoim obecnym projekcie. Jaki był początkowy cel końcowy? Co zawierał pierwszy sprint i co oprogramowanie może zrobić na jego końcu?
• Czy możesz podać mi przykłady funkcjonalności lub projektu swojego ostatniego projektu, który Twoim zdaniem działał inaczej niż projekt wodospadu?
• Podaj mi przykład, w jaki sposób duża część funkcjonalności została rozbita na wiele sprintów? Do jakich nieefektywności / przeróbek doprowadziło to? I jakie ulepszenia lub zmiany w stosunku do pierwotnie przewidywanych.
• Kiedy zacząłeś pracować z agile, jakie rzeczy robiłeś podczas wczesnych sprintów, co zmieniłeś podczas późniejszych sprintów (lub projektów), kiedy opanowałeś metodologię?

Powracaj do nich z powrotem do rzeczywistych projektów - co starali się osiągnąć, przykłady tego, co było w każdym sprincie, przykłady rzeczy, które pojawiały się na spotkaniach, przykłady interakcji z użytkownikami.

Nie akceptuj teorii, nie akceptuj projektów innych ludzi, tylko rzeczy, nad którymi sami pracowali i o których mogą rozmawiać z pierwszej ręki.

Musieliby być oszałamiająco dobrym kłamcą, aby móc nadrobić 10-15 minutowe rzeczy, które ominie cię, jeśli znasz swoje rzeczy.

Jeśli nie chcesz, aby były defensywne, znalazłem następujące pytanie, które zainicjuje rozmowę, która powie ci wszystko, co musisz wiedzieć o tym, czy faktycznie używają podejścia zwinnego, czy po prostu płacą mu za usta:

Kto jest odpowiedzialny za pisanie wymagań / specyfikacji dla twoich projektów oprogramowania?

Widziałem wiele firm, które twierdziły, że są zwinne, a nawet chciały, aby certyfikat Scrum Master opisał klasyczny duży proces projektowania z góry, kiedy pytasz o proces zbierania wymagań.

To, co mnie wyróżnia, to to, że szukasz stażu, co prowadzi mnie do zastanowienia się, jaki jest twój cel zadawania tych pytań. Czy próbujesz zadać pytanie o zwinność, aby rozmowa przebiegła dobrze, czy może odrzuciłbyś ofertę firmy używającej zwinnego modnego hasła? Jeśli naprawdę szukasz zwinnego środowiska, wybierz pytanie (dlaczego używasz zwinnego, o której godzinie masz standup, jak długo trwają iteracje, cokolwiek) i zapytaj go przez telefon lub e-mail, nie marnując czasu na wywiad. Jeśli szukasz dochodu, poczekaj na rozmowę i zadaj pytania, które pokażą twoją wiedzę / ekscytację na temat zwinnych metodologii (powiedz mi o cyklu życia oprogramowania) bez zawstydzania ankietera, jeśli używają jakiejś na wpół zwinnej obrzydliwości.

Proszę ich o opisanie typowej prośby, od powstania do ostatecznej dostawy do klienta.

Pytam również, czy zazwyczaj obsługują długoterminowe wsparcie dla produktu, który zapewnia klientowi (ponieważ zespoły, które to robią, zazwyczaj tworzą lepszy produkt, wiedząc, że to one naprawią go o 1 w niedzielę w weekend w Święto Pracy).

Pytam również, jak zarząd widzi swoją rolę w trakcie tego procesu. Łatwo jest sprawdzić, czy mają postawę ognia i zapomnienia (wystrzeliwujemy, lecisz, pytamy, czy trafiłeś w cel) lub nastawienie „pomagamy ci wiosłować łodzią w górę rzeki”.

Zazwyczaj pokażą ci, jak naprawdę robią rzeczy, a nie jak mają to robić lub jak twierdzą, że to robią.

Najlepszym sposobem, w jaki znalazłem, aby zobaczyć, czy ktoś wie, co robią z perspektywy SDLC, jest zapytanie go, gdzie popełnił błąd w przeszłości i jak zrobiłby to inaczej. Ludzie, którzy przeszli przez ten proces kilka razy i w pełni przyznają się do tego, co spieprzyli, i ogólnie są dość szczegółowi. Otwartość na dyskusję pokazuje poziom pewności siebie, ponieważ przyznają, że nie są doskonali. Unikanie pytania przez powiedzenie „Prawie cały czas robią to OK” to prawdziwy znak ostrzegawczy.

Jak często trafiają do produkcji. Im dłuższy czas, tym mniej są zwinne. Jak często mają warsztaty refleksji. Jeśli wiedzą, o czym mówisz, to dobrze. Jak często odbywają się spotkania grupowe. Codziennie jest super, miesięcznie źle. Czy mają serwer ciągłej integracji? To nie musi być, ale da ci wyobrażenie o ich użyciu narzędzi. Jak często użytkownicy końcowi siedzą z programistami. Nigdy nie oznacza, że ​​nie są zwinne.

• Daj im sytuację i poproś, aby rozwiązali ją sprawnie;
• Zapytaj ich o ulubione praktyki zwinne (planowanie pokera, programowanie w parach, bdd / tdd, kanban);
• Zapytaj ich, dlaczego nie wybrali innych metodologii (wodospad, rup itp.)
• Kim są najbardziej znani ludzie w zwinnym świecie metodologii, którzy wymyślili ten termin i jakie najpopularniejsze książki o nim napisane.

Jeśli używają Scruma, możesz zapytać, czy możesz obejrzeć następny stand-up. Jeśli ich nie mają, zapytaj, dlaczego nie, ponieważ zwykle byłaby to część metodologii.

Warto wspomnieć o kilku aspektach Agile. Poproś, aby zobaczyć tablicę opowieści, jak duży jest tylny dziennik lub jakie były najważniejsze wydarzenia w ostatniej retrospektywie, aby uzyskać kilka innych pomysłów. Kluczem jest tutaj dojście do czegoś namacalnego, co pokazuje, co się dzieje, w porównaniu z tylko puszystymi słowami, które tak naprawdę niewiele znaczą.

Zapytaj ich, jak radzą sobie z projektem. Jeśli powiedzą ci, że nie ma zwinnego projektu, nie rozumieją go.

Zapytaj ich, jak radzą sobie ze zmieniającymi się wymaganiami. Jeśli wydaje się, że zmiana wymagań ma swój własny proces, prawdopodobnie nie rozumieją tego.

Jeśli twierdzą, że używają Scruma, zobacz, jak to piszą. Sklepy, które dobrze znają Scrum, zwykle dobrze wiedzą, jak to napisać. Wskazówka: to nie jest SCRUM.

To może wydawać się pedanterią, ale jestem głęboko przekonany, że aby z powodzeniem zastosować szablon procesu, taki jak Scrum, RUP, XP lub cokolwiek innego, musisz zrozumieć filozofię i „dlaczego”, aby wiedzieć, jak się dostosować „co” dla Twojej organizacji. W Scrumie większość ludzi, którzy odrabiają lekcje, natknie się na te odrobinę informacji. Ludzie, którzy szukają przepisów na książki kucharskie do zarządzania projektami, zwykle tęsknią za tym szczegółem.

Dla mnie sensowne jest poproszenie ich o opisanie, w jaki sposób obsługują część procesu Agile. W tej chwili mój ulubiony to początek iteracji, ale możesz opracować swój własny.

Zapytaj: „biorąc pod uwagę stos biletów na początku sprintu, opisz stąd swój przepływ pracy”

Najważniejsze punkty do słuchania tutaj:

• Czy deweloperzy oceniają bilety?
• Czy śledzisz prędkość?
• Co się stanie, gdy twoje oszacowania przekroczą prędkość?
• Co się stanie, gdy twoje prognozy przekroczą prędkość, gdy będziesz miał termin? (Uważaj na spin tutaj: czy zmniejszają złożoność, czy zmieniają priorytety, czy tylko wprowadzają deathmarch zespół programistów?)

Żadne z nich nie stanowi problemu same w sobie, ale jeśli ich odpowiedzi na wystarczającą liczbę pytań sprawiają, że zastanawiasz się, być może są zainteresowani zwinnymi rytuałami , a nie faktycznym zwinnym rozwojem .