Polecaj zasoby liderom zespołów programistycznych [zamknięte]

Niedawno zostałem kierownikiem zespołu programistów baz danych (95% MS SQL Server, 5% misc-Oracle, Sybase, Access), który zarządza i rozwija dużą liczbę baz danych w środowisku korporacyjnym. Szukam zasobów (list kontrolnych, narzędzi, najlepszych praktyk, procedur, stron internetowych, książek itp.), Które pomogą mi wdrożyć podstawy, których w przeszłości brakowało w tej grupie programistów, takie jak recenzje kodu, szkolenia przekrojowe, dokumentacja , egzekwowanie standardów, dzielenie się wiedzą, mentoring i tak dalej.

Większość tego, co znajduję, to ogólne zasoby umiejętności zarządzania, ale chciałbym znaleźć wszystko, co może być specyficzne dla kierowania zespołem programistów. Procesy korporacyjne są „standardowymi” SDLC typu wodospad, więc zasoby ukierunkowane na Agile nie są tak istotne.

Książki, które kupiłem i polecam dla kierowników technicznych i menedżerów, którzy dla mnie pracowali:

Rapid Development (S. McConnell) - wielka „biblia” odpowiedzi na typowe kwestie zarządzania / potencjalnych klientów (więcej zarządzania)

Zostań liderem technicznym (Gerald Weinberg) - gęsta lektura, ale świetna.

Zestaw narzędzi menedżera (Harvard Business Essentials) - ponownie, bardziej skupiony na zarządzaniu, ale dobry z niektórymi problemami interpersonalnymi

Wyjaśnienie współpracy (Jean Tabaka) - bardziej zwinny, ale kolejna dobra Biblia „jak robić X” bardzo praktyczna

Poza tym ... słuchaj. Ucz się od swojego zespołu. Ucz się od swoich rówieśników. Ucz się od swojego szefa. Znajdź mentora spoza łańcucha dowodzenia, ale kogoś, kogo szanujesz i do którego możesz uciec, gdy poczujesz frustrację lub utkniesz. Spotykaj się z nimi raz na dwa tygodnie na śniadanie.

Niedawno przeczytałem Peopleware i uważam to za bardzo pouczające. Z pewnością pomoże ci zrozumieć dynamikę zespołu programistów (i wiele błędów, które popełniamy w zarządzaniu nimi / kierowaniu nimi). Polecił mi go ktoś tutaj na programistach.

Spójrz na „ Debugowanie procesu rozwoju ” Steve'a Maguire'a.

Chociaż nie jest to już najnowsza książka (1994), wciąż zawiera wiele informacji, które powinny okazać się przydatne jako lider zespołu i można ją naprawdę tanio kupić. Uważam, że jest doskonały.

Warto również rozważyć „ Szybki rozwój ” Stevena McConnella. Ponownie, jest to oldie (1996), więc niejako poprzedza pracę metodologiczną Agile, więc znajdziesz podejścia „wodospad”, „spirala” i „timeboxed” omawiane na ich temat. Znajdziesz niektóre z prekursorów podejścia zwinnego (Rapid Prototyping i tak dalej). Ponadto w odniesieniu do „najlepszych praktyk” znajdziesz szeroki zakres streszczony na stronie 400 wraz z odpowiednio cytowanymi ocenami dotyczącymi ich skuteczności i szczegółowymi objaśnieniami.

Obie książki zostały wydane przez Microsoft Press, dlatego powinny zawierać wystarczające odniesienie do istniejących technologii.

Co najważniejsze, obie książki dotyczą zarządzania zespołami programistycznymi - motywacji, planowania, myślenia strategicznego, przywództwa i tak dalej.

Jestem w podobnej sytuacji. Pierwszą rzeczą jest określenie, jak powinien działać zespół, jakie procesy powinny być wdrożone, jaka jest rola zespołu. Utwórz stronę wiki (lub sharepoint lub cokolwiek), aby umieścić je wszystkie. Następnie przeprowadzaj wiele regularnych rozmów w zespole, aby szczegółowo zdefiniować każdą z nich. Najważniejsze jest ustalenie kultury i zachowania, które zespół chce mieć. Do wiedzy zespołu używamy tego. Rozpocznij regularną sesję dzielenia się wiedzą co dwa tygodnie lub co miesiąc, utwórz arkusz kalkulacyjny z różnymi obszarami wiedzy w wierszach i członkami zespołu w kolumnach. Następnie przypisz wynik od 1-5, aby poznać mocne strony i luki dla każdego członka. Przygotuj w planie przypisanie podstawowej, drugorzędnej i trzeciorzędnej odpowiedzialności za każdy obszar z docelowym wynikiem odpowiednio 5, 4 i 3.

Dokumentowanie wszystkich procesów jest bardzo ważne. np. Mamy proces przeglądu kodu i listę kontrolną. Jeśli w procesy zaangażowane są inne zespoły, podnieś to z zarządem i zgódź się na procesy na tym poziomie. np. proces wydania.

Nie mogę podkreślić znaczenia dokumentacji (może być lekka na wiki), ponieważ masz silną pozycję wyjściową, aby poprawić i zademonstrować zarządzanie. Wiele razy mój zespół wygrywał w oczach wyższej kadry kierowniczej, ponieważ mieliśmy solidne dokumenty i procesy.