Przedstawiamy nowe tematy współpracownikom

Próbowałem przedstawić takie tematy, jak testy jednostkowe, wstrzykiwanie zależności, odwrócenie kontroli itp. ... do współpracowników. Prowadziłem mini wykłady, pokazy i zasugerowałem te tematy podczas lunchu i nauki. Odbiór był ogólnie pozytywny i ludzie widzą wartość w takich tematach.

Choć wydaje się, że pociągają ich te tematy, poziom adopcji jest bardzo niski. Kiedy z nimi o tym rozmawiam, odpowiedź brzmi:

Spróbuję następnym razem. Chcę tylko wyciągnąć ten projekt za drzwi.

Mam wrażenie, że większość tego, co widzieli, to tylko pokazy typu wykładowego i nie mają oni praktycznego doświadczenia. Co mogę zrobić, aby popchnąć ich dalej? Nie chcę ich „zmuszać” do pisania kodu, jeśli nie chcą, ponieważ może to wydawać się „pracą domową” i może wywrzeć na nich złe wrażenie.

Nasze projekty na ogół nie pozostawiają czasu na eksperymenty, więc ludzie unikają nowych technologii. Nie pozostawia to miejsca dla programistów na próbę wprowadzenia nowych rzeczy na etapie programowania.

Czy są jakieś zabawne lub interesujące ćwiczenia (solo lub zespołowe), które pozwalają im mieć więcej praktycznych doświadczeń z tymi tematami? Mam nadzieję znaleźć coś, co wzbudziłoby wystarczające zainteresowanie, aby byli gotowi zaplanować godzinę swojego dnia na pracę nad czymś schludnym lub wzbudzić wystarczające zainteresowanie, aby mogli zbadać swój własny czas.

Aby „udowodnić”, a zatem naprawdę wszczepić pomysł w czyjąś głowę, teoria (mówienie) nigdy nie wystarczy.

Musisz użyć tych praktyk we własnym kodzie i sprawić, by „odkryli”, że rozwiązał problemy w przyjemny sposób.

To sugeruje, że twoje praktyki muszą być skuteczne i powinieneś to uczynić oczywistym.

W ten sposób czytanie kodu zainspiruje ich, ponieważ „zobaczą to w akcji”.

Nie zakładaj, że wystarczy samo powiedzenie, jak to działa.

Mówiąc z doświadczenia, jeśli nie chcą zastosować tego, czego próbujesz ich nauczyć, oznacza to, że ich to nie obchodzi. Jesteś prawdopodobnie tracić czas, starając się wprowadzać tematy do nich, bo jeśli oni rozumieć rzeczywiste korzyści z tych tematów, które oni chcą je stosować, nie dać wymówki, dlaczego nie mogą.

To tak, jakby próbować wprowadzić coś lepszego niż to, co jest obecnie używane i uzyskać puste spojrzenia lub natychmiastowe odpowiedzi, dlaczego nie jest to możliwe; wskazuje, że druga osoba tak naprawdę nie postrzega jej jako korzyści (ponieważ gdyby była w stanie dostrzec tę korzyść, nie usprawiedliwiałaby się).

Smutne ale prawdziwe. Może twoja sytuacja jest inna, ale wpadałem na to kilka razy w przeszłości i ostatecznie było boleśnie oczywiste, że nikt poza mną nie był zainteresowany tymi tematami; Ostatecznie podjąłem decyzję o odejściu i szukaniu współpracowników, którzy się tym przejmują; ludzie, którzy albo nie potrzebują mnie do przedstawiania tematów (ponieważ już je znają / używają), albo chętnie je akceptują, zamiast mówić, jak tego nie potrafią.

Widziałem wiele „najlepszych praktyk”, które wypadały z łask i nigdy się nie przyzwyczaiły. Istnieje wiele rodzajów projektów i takie techniki nie są odpowiednie dla wszystkich projektów. Upewnij się, że rzeczy, które naprawdę sprzedajesz, naprawdę pomogą.

Jeśli zaczniesz to robić, a ludzie zobaczą, że jesteś wyjątkowo produktywny lub produkujesz kod lepszej jakości, zobaczą później. Zastanów się jednak, czy wszystkie dodatkowe koszty naprawdę pomogą Twojemu projektowi? Nie każda aplikacja tego potrzebuje.

Jeśli możesz zmotywować swoich kolegów do wzięcia udziału, możesz zorganizować Coso Dojos . Są to wyzwania programistyczne, w których uczestnicy celowo koncentrują się na doskonaleniu praktyki. Może na przykład udział w testowanym dojo doprowadzi twoich kolegów do zobaczenia korzyści płynących z TDD.

Alternatywnie, czasami te rzeczy muszą być narzucone przez kulturę. Uderza mnie to, jakby kultura w twojej firmie ich nie potrzebowała.

Jeśli staną się one wymogiem zamknięcia projektu (prawdopodobnie decyzja kierownictwa), zobaczysz porywające, ale przynajmniej wtedy pewne zastosowanie tych narzędzi i kultura zaczną się zmieniać.

Najlepszą praktyką jest prawdziwy kod produkcyjny. Katas to miłe wprowadzenie, ale z mojego doświadczenia nie trzymaj tego samego „Eureka!” Chwile, kiedy się to robi naprawdę .

Wskazałeś jednak, że ramy czasowe „nie pozwalają na eksperymenty”. To naprawdę prosta poprawka. Już robisz te rzeczy, których próbujesz uczyć, więc zostaw otwarte zaproszenie, aby sparować się z tobą podczas wdrażania niesamowitej nowej funkcji X. Pozwól im usiąść przy klawiaturze i pisać na klawiaturze, pisząc „ tylne siedzenie ”. Pozwoli im to zbudować pamięć mięśni i pewność siebie.

Powodzenia w twoich staraniach.