Jak stworzyć „kult jakości” [zamknięte]


21

DeMarco i Lister (Peopleware) sugerują stworzenie „kultu jakości” w zespole programistycznym. Frustrujące jest to, że nie sugerują, jak to zrobić!

Czy ktoś zastanawiał się, jak to osiągnąć?


1
Twój „kult jakości” będzie tak skuteczny, na ile pozwala na to czas. Kiedy szef mówi: „Musi to być zrobione do piątku” , oznacza to, że musisz obniżyć jakość ze względu na szybkość. Oczywiście nie jest to preferowane przez programistów. Idealnie wolimy czas, aby zapewnić jakość!
inwertowanie

1
@WesleyWerner: Dobra uwaga. Uważam jednak, że „kult jakości” powinien obejmować także zadłużenie techniczne, które (ostatecznie) rozwiąże problem szefa, o którym wspominasz.
talonx,

@invert: Zazwyczaj odpowiadam w takich przypadkach, że mamy tutaj sytuację analogiczną do twierdzenia CAP. Mamy jakość, szybkość i siłę roboczą, a on może wybrać dwa.
JensG

Odpowiedzi:


37

Z mojego doświadczenia wynika, że ​​zespoły programistów (ale ogólnie każdy zespół) składają się z 3 rodzajów osób:

  • te z wbudowanym napędem jakości,
  • tych, którzy są w nim tylko dla pieniędzy (piwo / dziewczyny / cokolwiek innego) i nie obchodzi ich to mniej, jakkolwiek starasz się ich motywować,
  • te „przeciętne” (z braku lepszego słowa).

Ostatnia grupa jest największa i zwykle podążają za partią rządzącą. Jeśli w zespole jest wystarczająco dużo ludzi wysokiej jakości, mogą pociągnąć większość ze sobą, tworząc silną spiralę w górę ducha zespołu i motywacji. Jeśli jednak jest zbyt wielu zwolenników, mogą łatwo stworzyć odwrotny efekt, spiralę śmierci.

Dlatego głównym zadaniem menedżera jest wybór i utrzymanie odpowiednich ludzi oraz pozbycie się złych jak najszybciej . Jednak nie te „przeciętne” - można na nich wpłynąć, aby zacząć się poprawiać, wspierać dobre pomysły innych, a niektórzy z nich mogą nawet samodzielnie stać się pozytywnymi trendami.

[Update2] zastanawiając się nad odpowiedzią Alb : IMO nie ma potrzeby, aby programiści ds. Jakości stanowili zdecydowaną większość w zespole (chociaż to nie boli :-). Istnieje „próg wyznaczania trendów” , powyżej którego poglądy i zachowanie podgrupy mogą szybko stać się „głównym nurtem” w społeczności , więc inni zauważają ją i zaczynają podążać. Widać to przez cały czas w pracy w większym społeczeństwie (np. (Nie) nawyki palenia, zdrowie i diety, moda pop, żywność ekologiczna). Moje bardzo przybliżone oszacowanie jest takie, że może wynosić około 25-30%, ale zależy to od wielu czynników. Tutaj źli ludzie mogą bardzo zranić. Nawet kilka złych osób w twoim zespole może znacznie podnieść ten próg. [/ Update2]

Oczywiście nie zawsze jest możliwe zatrudnienie wystarczającej liczby najlepszych ludzi. Kiedy więc pierwsza frakcja nie jest wystarczająco silna, by prowadzić własne rzeczy, zarząd musi im pomóc. Kilka przemyśleń na ten temat:

  • Myślę, że Scrum ma na to dobry pomysł, prezentując produkty. Demonstracja funkcji, którą wdrożyłeś przed publicznością składającą się nie tylko z twoich kolegów z drużyny, ale być może deweloperów z innych zespołów, zarządzanie, a nawet użytkownicy aplikacji mogą być ogromnym źródłem dumy, a także silnym czynnikiem, który pomaga zespołowi galaretowemu.

  • Inną sprawą jest, aby kierownictwo poważnie wysłuchało zespołu deweloperów na temat jakości. DeMarco i Lister wspominają nawet, że istnieją firmy / działy, w których zespoły deweloperów mają weto co do tego, co może trafić do produkcji. Jeśli uważają, że aplikacja nie jest jeszcze gotowa na najwyższy czas, mogą odłożyć wydanie bez względu na to, co chciałby zarząd. Teraz jest to trudne do zarządzania, ale mogę sobie wyobrazić, że buduje ducha zespołu i silnie przekazuje przesłanie, że jakość jest tutaj naprawdę ważna, nie tylko na poziomie słów.

  • Prowadzi to do następnego punktu: aby stworzyć „kult jakości”, kierownictwo musi dokładnie zrozumieć to, co wiedzą już najbardziej doświadczeni programiści: ta jakość nie jest kwestią późniejszą - musi być wbudowana w produkt od samego początku. Dlatego należy zachęcać ludzi do (i nagradzanych za!) Myślenia o długoterminowej łatwości konserwacji, dążeniu do dobrych rozwiązań zamiast szybkich .

Aktualizacja

@Machado w swoim komentarzu zmienił pytanie (przynajmniej dla mnie):

Co, jako członek zespołu, a nie menedżer, mogę zrobić, aby poprawić jakość kodu mojego zespołu?

Kilka myśli:

  • Ucz się i rozpowszechniaj wiedzę wśród wszystkich, którzy słuchają. Dowiedz się i korzystaj z najlepszych praktyk w swoich obszarach wiedzy.
  • Bądź dumny ze swojej pracy .
  • Te dwie rzeczy prawie naturalnie pozwolą ci stać się pozytywnym wzorem do naśladowania dla innych - zwłaszcza nowicjuszy i juniorów -; bądź tego świadomy i wykorzystaj swoją rolę z korzyścią dla całego zespołu. Najlepszym sposobem wpływania na innych jest pozytywny przykład.
  • Spójrz nie tylko na kod, ale na cały proces tworzenia oprogramowania; zadawaj pytania i przesyłaj opinie, aby zoptymalizować proces rozwoju .

I na koniec: znajdź miejsce, w którym możesz być „najlepszym facetem” . Jeśli jesteś teraz w grupie „przeciętnej”, staraj się rozwijać - mam nadzieję, że powyższe pomysły w tym pomogą. Ale jeśli zdarzyło Ci się być w „niższych warstwach” w obecnym zespole, zalecamy przeanalizowanie przyczyn. Co cię motywuje? Złe warunki pracy? Koledzy z drużyny? Zarządzanie? Rodzaj pracy? Co cię podnieca i interesuje? Być może będziesz musiał porozmawiać o tym ze swoimi współpracownikami i / lub szefem. Możesz też poszukać lepszej pracy - a nawet nowego zawodu - w którym możesz zacząć lśnić. Naprawdę nie warto spędzać znacznej części życia na czynnościach niezadowalających lub przygnębiających.

Może się zdarzyć, że będziesz zmuszony kontynuować swoją obecną, nieoptymalną pracę z powodu czynników zewnętrznych (brak lepszych możliwości pracy, konieczność płacenia rachunków itp.) - zdarza się to od czasu do czasu. Nawet w tym przypadku postaraj się z tego jak najlepiej wykorzystać. Wykonywanie wysokiej jakości pracy (na ile pozwalają na to okoliczności) jest nagrodą samą w sobie, która pomaga utrzymać poczucie własnej wartości oraz zachować rozsądek i otwartość na dłuższą metę. Kiedy więc pojawia się okazja na coś lepszego, jesteś lepiej przygotowany na to.


4
Niebezpieczna rada. Co jeśli PO należy do 2. / 3. grupy? ;)

1
świetna odpowiedź, nigdy nie myślałem o tym w ten sposób, ale ma to tyle sensu.
Alb

9
@ Gdyby byli deweloperami, nie czytaliby DeMarco i Listera ani nie zadawali tutaj pytania.
Alb

Myślałem, że pytanie jest bardziej ukierunkowane z punktu widzenia członka zespołu. Jeśli kierownictwo naprawdę chce jakości, wysłucha swoich najlepszych / kluczowych programistów. Co, jako członek zespołu, a nie menedżer, mogę zrobić, aby poprawić jakość kodu mojego zespołu?
Machado

1
@ Thorbjørn, doskonałe pytanie! Przyznaję, że do tej pory mi tego brakowało w większości moich miejsc pracy. Mając nadzieję, że nie zabrzmiałoby to zbyt pochlebnie, zawsze szukałem członków drużyny, którzy mogliby się tym zająć i uczyć, ale rzadko ich znajdowałem. Zwróciłem się więc do książek i Internetu. W miarę możliwości znalazłem wzory do naśladowania u Martina Fowlera, wuja Boba Martina i in. A ostatnio w społeczności SO! To wspaniałe miejsce do nauki. Również silny „dostawca kontroli rzeczywistości”. Upokarzające doświadczenia ujawniające granice i luki w wiedzy mogą być trudne do zniesienia, ale są dla mnie bardzo zdrowe.
Péter Török

2

Świetna odpowiedź Pétera Töröka, aby podkreślić, że poradzisz sobie z tym tylko z większością dobrych ludzi. Gdy masz dobrych ludzi, musisz bardziej celować w marchewkę niż w kij. Wzmocnij pozycję programistów, pozwól im przejąć na własność projekty / zadania i zachęcaj do konkurencji pod względem jakości, być może poproszę ludzi o krótkie prezentacje na temat tego, jak poprawili jakość projektów. Dobrzy programiści będą motywowani do wywarcia wrażenia na swoich rówieśnikach.


+1 Dobre punkty za motywację. Byłem najwyraźniej niezrozumiały w odniesieniu do większości; Zaktualizowałem swoją odpowiedź, aby wyjaśnić.
Péter Török

2

Oprócz komentarzy Petera (które są naprawdę głównym problemem), musisz upewnić się, że jakość nie jest funkcją dodaną później.

Dokładniej:

  • Usuń wszelkie ślady myślenia „Oczyścimy to później”. Zamiast tego włóż wysiłek na początku, aby zrobić to poprawnie.
  • Wymagaj, aby zmiany zostały przejrzane i przeszły przez proces kontroli jakości z udziałem osoby innej niż programista.
  • Wymuszaj przemyślenia na temat jakości we wczesnych fazach projektów. Skup się na tym, aby „jak łatwo utrzymać to dla innych” podczas projektowania.
  • Śledź i zgłaszaj występujące błędy. Jeśli istnieją trendy, spójrz na sposoby walki z podstawową przyczyną błędów.
  • Przedstaw myśl o oprogramowaniu jako rzemiośle, które można ulepszyć i czymś, z czego twórcy mogą być dumni.

1

Powiedziałbym, że najlepszym sposobem jest zwiększenie jakości zamiast wydajności. Jest to jedna z przesłanek ruchu Lean Software (opartego na Lean Manufacturing). Napisałem długi post na blogu omawiający, o co chodzi w Lean . Mówię ci, jak stworzyć kult jakości. Zainwestuj w swoich pracowników i pozwól im zainwestować w Twoją firmę (nie inwestycja pieniężna, ale inwestycja osobista).

Dan Pink wygłosił świetną rozmowę na TED o tym, co nas motywuje. Chociaż nie odnosi się to konkretnie. Hierarchia potrzeb Maslowa doskonale wyjaśnia obserwowane zjawisko. Tak długo, jak pracodawca zaspokoi pierwsze dwie potrzeby (tj. Zapłać wystarczającą ilość pieniędzy, aby pieniądze nie stanowiły problemu), wszystko, co pozostaje, to Należenie, Szacunek i Samoaktualizacja.

  • Zapewnij solidną społeczność dla przynależności.
  • Zapewnij środowisko, w którym pracownik może popełniać błędy, aby mógł zyskać szacunek podczas osiągnięć.
  • Przekaż programistom wodze, aby mogli podejmować ważne decyzje dotyczące samorealizacji

Jakość nie jest czymś, co można dyktować ... raczej jest włączona. Zaufaj swoim pracownikom, aby robili to, co najlepsze, i zejdź im z drogi. W końcu będziesz musiał powiedzieć im, że muszą odejść. Zamiast prosić ich o poświęcenie większej liczby godzin

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.