Chociaż DevOps jest powszechnie uznawany za rozwiązanie usprawniające dostarczanie oprogramowania i podnoszące jego jakość, stworzenie naprawdę skutecznego zespołu wykracza poza wdrożenie pojedynczego narzędzia. To strategiczne połączenie odpowiednich elementów: kultury, procesów, współpracy i technologii. W tym artykule omówiono kluczowe elementy wysoko wydajnego zespołu DevOps oraz przedstawiono wskazówki dotyczące ich integracji przez organizacje w celu osiągnięcia optymalnych rezultatów.
Na potrzeby tego wywiadu w formacie pytań i odpowiedzi rozmawialiśmy z Davidem Brooksem, starszym wiceprezesem ds. ewangelizacji w firmie Copado. Z 35-letnim doświadczeniem w Dolinie Krzemowej dołączył do Copado w 2018 roku, aby stworzyć dział zarządzania produktem, którym kierował przez cztery lata. Brooks dołączył do Salesforce.com w 2005 roku, aby uruchomić AppExchange. Jako wiceprezes ds. produktu kierował zespołami, które w czasie jego dziewięcioletniej pracy w Salesforce stworzyły platformę Force.com.
Bardzo dziękujemy za rozmowę! Zanim przejdziemy do szczegółów, czy opowie nam Pan o swojej drodze zawodowej?
W 1984 roku uzyskałem tytuł magistra inżyniera elektrotechniki na Auburn University. Tematem mojej pracy dyplomowej był odporny na awarie wieloprocesorowy system operacyjny do obrony przeciwrakietowej.
Przeniosłem się do Doliny Krzemowej, gdzie pracowałem w ośmiu startupach, z których trzy odniosły dotąd udane wyjścia z inwestycji. Dołączyłem również do Salesforce tuż po wejściu firmy na giełdę w 2005 roku. Kierowałem zespołami, które uruchomiły AppExchange, a następnie platformę Salesforce. Najczęściej zajmowałem stanowiska kierownicze wyższego szczebla w obszarze inżynierii i zarządzania produktem, choć byłem także założycielem i dyrektorem generalnym dwóch firm.
Nikt z nas nie może osiągnąć sukcesu bez pomocy po drodze. Czy jest jakaś konkretna osoba, która pomogła Panu dotrzeć do miejsca, w którym się Pan znajduje?
Są dwie takie osoby. Chuck Comiso był dyrektorem generalnym Link Technologies, gdzie kierowałem rozwojem produktu. Był menedżerem starej szkoły HP. Chuck nauczył mnie bardzo wiele o zarządzaniu ludźmi. Ted Elliott był dyrektorem generalnym JobScience, a dziś jest dyrektorem generalnym Copado. Ted nauczył mnie koncentrować się na najważniejszych rzeczach oraz pokazał, czego potrzeba, aby rozwijać startup.
Jakie trzy mocne strony, umiejętności lub cechy pomogły Panu dotrzeć do obecnego miejsca w karierze? Jak inni mogą aktywnie rozwijać te obszary?
Ciekawość, komunikacja i kreatywność. Z natury jestem ciekawy świata i uczę się przez całe życie — to dar, który najbardziej doceniam. Potrafię również komunikować się z ludźmi w sposób dla nich zrozumiały. Mówię po chińsku i nauczyłem się cierpliwości wobec osób, dla których angielski jest drugim językiem. Przekłada się to również na wyjaśnianie kwestii technicznych osobom nietechnicznym.
Ludzie często są tak zajęci planowaniem tego, co powiedzą za chwilę, że pomijają sedno rozmowy. Wreszcie, ponieważ interesuje mnie bardzo wiele dziedzin, potrafię łączyć pomysły w nowatorski sposób. Moja kreatywność polega więc bardziej na umiejętności syntezy dużej ilości informacji i przekształcania jej w nowe zastosowanie.
Jakie umiejętności nadal próbuje Pan rozwijać?
Z pewnością umiejętności komunikacyjne. Niedawno objąłem nowe stanowisko ewangelisty technicznego, co wymaga ode mnie podniesienia poziomu komunikacji kluczowych idei, które wyróżniają Copado. Kieruję również naszymi działaniami w Chinach, więc mój chiński zostanie wystawiony na próbę.
Porozmawiajmy o tym, jak stworzyć skuteczny zespół DevOps. Jakie kluczowe cele może wyznaczyć zespół DevOps na drodze transformacji cyfrowej?
Uważam, że najważniejsze są jasność i szacunek. Jasne określenie tego, co należy zrobić, jest kwestią priorytetów i pozwala precyzyjnie zdefiniować poszczególne historyjki użytkownika oraz funkcje. Dobry menedżer produktu powinien umieć komunikować „co” i „dlaczego”.
Wszystko zaczyna się od dogłębnego zrozumienia „dlaczego”, a następnie upewnienia się, że rozumieją je również zespoły programistyczne i testowe. Między członkami zespołu musi panować wzajemny szacunek, a każdy z nich powinien mieć poczucie, że jego opinie są cenione, a obawy wysłuchiwane. Jednocześnie każdy członek zespołu musi wywiązywać się ze swoich obowiązków i zdobywać to zaufanie w każdym sprincie.
Czy istnieją jakieś wyzwania lub typowe pułapki, które zespoły DevOps powinny brać pod uwagę?
Zbyt często właściciel produktu nie radzi sobie z właściwym zrozumieniem potrzeb użytkowników — nie tego, o co poprosili, ale tego, czego rzeczywiście potrzebują. Zawsze uczono mnie, aby pięć razy pytać „dlaczego?”. Wtedy można zrozumieć, co jest naprawdę potrzebne, i przekazać tę wiedzę reszcie zespołu.
Drugim wyzwaniem jest sytuacja, gdy członkowie zespołu nie wyrażają otwarcie swoich niezgodności. Widziałem, jak programiści mówili menedżerowi produktu, że czegoś nie da się zrealizować od strony technicznej, tylko dlatego, że nie uważali tego za właściwe rozwiązanie. Każdy członek zespołu powinien czuć, że jego opinia jest ceniona, i zabierać głos, gdy się z czymś nie zgadza. Ostatecznie lider zespołu musi podjąć decyzję, a reszta zespołu powinna ją poprzeć.
W jaki sposób skuteczna współpraca i komunikacja między członkami zespołu mogą zwiększyć produktywność i szanse na sukces zespołu DevOps oraz jakie praktyki mogą to ułatwić?
Tak ważna jest szczera, otwarta komunikacja, w której ceniona jest opinia każdego, a każdy ma możliwość zabrania głosu. Ważne jest również zrozumienie „dlaczego”. Jeśli członek zespołu dostrzega lepszy sposób spełnienia wymagania, zespół powinien być otwarty na ten pomysł. Często prowadzi to do uzyskania lepszego rozwiązania w krótszym czasie.
Jaką rolę odgrywa CI/CD w DevOps i jakie są najlepsze praktyki wdrażania potoków CI/CD, aby zapewnić płynny i niezawodny proces wydawania oprogramowania?
CI/CD polega na wydawaniu wielu niewielkich zmian. Zaczyna się od definiowania historyjek użytkownika w taki sposób, aby można je było zrealizować w ciągu godzin, a nie dni, i przekazać do kolejnego etapu bez powodowania problemów. Zautomatyzowane testy funkcjonalne i bezpieczeństwa również mają kluczowe znaczenie.
Zespoły powinny stosować programowanie sterowane testami, aby funkcjonalność mogła szybko przechodzić przez potok. Na każdym etapie należy ustanowić bramki jakości, aby zapewnić, że zmiana nie będzie mogła przejść dalej, dopóki nie zostanie ukończona. Prawdziwe CI/CD do środowiska produkcyjnego nie jest praktyczne w niektórych silnie regulowanych branżach, ale nie powinno to uniemożliwiać stosowania tej praktyki na wszystkich etapach poprzedzających produkcję.
W jaki sposób rozwijanie kultury i sposobu myślenia DevOps przyczynia się do ogólnego sukcesu zespołu oraz jakie strategie mogą stosować organizacje, aby promować tę kulturę wśród zespołów programistycznych i operacyjnych?
Sposób myślenia DevOps oznacza, że wszyscy członkowie zespołu mają wspólny cel: dostarczanie wysokiej jakości pracy aż do środowiska produkcyjnego. Programiści nie mogą uważać, że ich praca kończy się w momencie przesłania zmian do repozytorium. Jakość nie jest zadaniem jednej osoby — odpowiada za nią każdy członek zespołu. To, w połączeniu z zaufaniem i otwartością na ciągłe doskonalenie, sprawia, że zespół odnosi sukces.
Jakie są niezbędne elementy skutecznego zespołu DevOps?
1 . Wzajemne zaufanie —Na początku mojej kariery pracowałem w zespole, w którym członkowie nie ufali sobie w pełni. Nieustannie podważali decyzje innych i potajemnie wprowadzali zmiany, aby „naprawiać” problemy. Spowalniało to rozwój i sprawiało, że praca w zespole była bardzo nieprzyjemna.
2 . Zaangażowanie w realizację celów zespołu — Skuteczna praca zespołowa opiera się na wspólnych celach. Z mojego doświadczenia wynika, że odnoszące największe sukcesy zespoły wykraczają poza indywidualne osiągnięcia. Obserwowałem głównych programistów, którzy po szybkim ukończeniu swoich zadań oferowali wskazówki i wsparcie młodszym programistom. Ten duch współpracy sięgał dalej — programiści pomagali inżynierom ds. testów w ukończeniu automatyzacji testów. W rezultacie zespół ten konsekwentnie wywiązywał się ze swoich zobowiązań i utrzymywał pozytywne środowisko pracy
3 . Jasna komunikacja — Gdy zespół nie komunikuje się dobrze, może dochodzić do marnowania dużej ilości czasu i energii. Zaczyna się to od właściwego zrozumienia celów. Kiedy w 2006 roku rozpocząłem pracę z metodyką zwinną, uważałem, że spotkania dotyczące planowania sprintu trwają zbyt długo, a codzienne spotkania na stojąco są absurdalne. Nie pomagało również to, że podczas spotkania musiałem nosić zdjęcie koguta, aby przypominało mi, że jestem obserwatorem i nie mogę zabierać głosu.
Z perspektywy czasu rozumiem znaczenie krótkich spotkań, ale straciliśmy okazje do wyjaśnienia pewnych kwestii. Później w mojej karierze wykorzystywaliśmy codzienne spotkania na stojąco do wyjaśniania pytań. Nie chcesz dotrzeć do końca sprintu tylko po to, by odkryć, że stworzyłeś coś niepoprawnego.
4 . Ciągłe doskonalenie — Nie ma dwóch takich samych zespołów i żaden pojedynczy proces nie sprawdzi się w każdym zespole. Ruch Lean Manufacturing umożliwił pracownikom linii montażowej zmianę procesu w celu zwiększenia jego efektywności. Przeprowadzali eksperymenty i określali, czy zmiany przyniosły poprawę, czy pogorszenie. To samo dotyczy procesów tworzenia oprogramowania. Zespół powinien mierzyć wyniki za pomocą narzędzi takich jak mapowanie strumienia wartości, aby zrozumieć rzeczywiste problemy, a następnie być gotowym do zmiany procesu na taki, który ma sens i nadal jest zgodny z zasadami zgodności obowiązującymi w firmie.
5 . Bezpieczna przestrzeń dla nowych pomysłów — Jedynym sposobem na skłonienie wszystkich członków zespołu do dzielenia się pomysłami jest zapewnienie im poczucia bezpieczeństwa. Nie ma czegoś takiego jak głupie pytanie lub pomysł. Często pomysł może wydawać się niemożliwy do wdrożenia, ale jeśli zakwestionujesz utrwalone praktyki, odkryjesz, że nikt nie wie, dlaczego zostały wprowadzone. Najgorsza odpowiedź, jaką kiedykolwiek usłyszałem, brzmiała: „Bo zawsze robimy to w ten sposób”. Potrzeba ciągłego doskonalenia oznacza, że musisz być otwarty na nowe sposoby myślenia. Możesz odrzucić 90% nowych pomysłów, ale te 10% może mieć znaczący wpływ.
Jakie pojawiające się trendy przewidujesz w obszarze DevOps, które mogą w przyszłości znacząco wpłynąć na strategie transformacji cyfrowej?
Generatywna AI, bez wątpienia. Wykorzystanie produktów Copilot do generowania kodu i skryptów testowych znacząco zwiększy produktywność. Trzeba jednak zacząć od dobrego zestawu wymagań, dlatego zobaczymy znaczne ulepszenia narzędzi wspierających planowanie.
Większość naszych przyszłych działań będzie koncentrować się na upewnieniu się, że robimy właściwe rzeczy, oraz na zrozumieniu ich wpływu i zależności. GenAI ułatwi dokumentowanie wydania i zwiększy nasze możliwości wspierania użytkowników końcowych poprzez generowanie usług pomocy, które działają w czasie rzeczywistym i są aktualne względem bieżącego stanu aplikacji.
Gdybyś mógł zainspirować ruch, który przyniósłby najwięcej dobra największej liczbie osób, jaki byłby to ruch?
Wow! Myślę, że wszystko sprowadza się do kilku dość podstawowych zasad. Traktuj innych tak, jak chcesz, aby traktowano ciebie, czyli okazujcie sobie wzajemny szacunek. Bierz odpowiedzialność za swoje zobowiązania i dostarczaj to, co obiecujesz, czyli postępuj uczciwie. Skup się na sukcesie swoich interesariuszy — pomóż im odnieść sukces i zdobądź ich zaufanie.
Najważniejsze wnioski
Budowanie wysokowydajnego zespołu DevOps wymaga przemyślanych i nieustających działań. Stawiając na pierwszym miejscu kluczowe elementy — kulturę, procesy, współpracę i technologię — organizacje mogą w pełni wykorzystać potencjał DevOps.
- Oceń obecny stan i zidentyfikuj obszary wymagające poprawy.
- Zainwestuj w szkolenia i warsztaty, aby wspierać kulturę współpracy DevOps.
- Wdrażaj narzędzia i automatyzuj procesy, aby usprawnić przepływy pracy.
- Nieustannie mierz postępy i dostosowuj swoje podejście na podstawie wyników.
Aby uzyskać więcej wywiadów i informacji na temat DevOps, zasubskrybuj newsletter The CTO Club.
