«Жалуются, что университеты отстали от индустрии». Венкат Субраманьям про разработку, процессы и образование
Венкат Субраманьям, основатель компании Agile Developer, сотрудничает как разработчик и Agile-коуч со многими компаниями: «Я одновременно работаю в семи местах». А ещё занимает профессорскую кафедру в Хьюстонском университете, пишет книги и выступает на конференциях по всему миру без обуви, но в белых носках («это очень удобно, ведь покупает их моя жена»). Человек-оркестр рассказывает о философии Agile, видах корпоративной культуры, ИТ-образовании и фитнесе для ума и тела.
Журналист dev.by встречается с профессором после его выступления на Voxxed Days Minsk. Сабраманьям делится впечатлениями о Минске, в который приезжает уже третий год подряд:
«Минск прекрасен. Последние два дня я бегал утром вдоль Свислочи и снова удивлялся, насколько это просторный и дружелюбный город. Очень много молодежи, а местные разработчики, с которыми я встречался, стремятся к обучению и полны энтузиазма».
15 лет назад Agile был интересным подходом, с которым с любопытством и, возможно, не без опаски экспериментировали многие компании. Какое место Agile занимает сегодня?
Последние плюс-минус пятнадцать лет были успешны для Agile-разработки. Но проблемы остаются. Многие компании и команды до сих пор стремятся вести разработку в наиболее предсказуемом русле — они уделяют ключевое внимание самому процессу. В то время как в духе Agile фокусироваться на результате. И пока мы не перестанем ставить во главу угла процесс разработки, проблема будет существовать. Здесь уже неважно, как мы называем методику работы: Agile, Waterfall или как-то иначе — нам нужно фокусироваться на результате.
До сих пор можно услышать мнение, что Agile — это философия, оторванная от практики, внедрение новых методик ради самого внедрения. Что вы ответите на это?
Я написал книгу «Приёмы работы Agile-разработчика» (Practices of an Agile Developer)! Поэтому, конечно, я верю в практическую сторону Agile. Да, Agile — это философия, но не только. Важно понять, что мы имеем в виду под практической стороной? Не процесс разработки, а набор практик. Я очень хочу, чтобы Agile был гибким подходом. Для меня существенны три ключевые характеристики подхода: Agile получает фидбэк, Agile адаптивен, Agile реалистичен.
Соответственно, правильные вопросы к разработке: насколько мы готовы адаптироваться, насколько мы реалистично подходим к задачам, насколько хорошо прислушиваемся к фидбэку. Это те практики, которые мы можем внедрить в команду, чтобы получить максимальную отдачу.
Так что, да: на каком-то уровне Agile — это философия, но существуют совершенно конкретные задачи, к которым стоит стремиться. В то же время необходимо осознать факт, что эти практики сильно зависят от контекста и ситуации. Одна крайность — процесс без концепции, другая крайность — отсутствие всякой практики. Мне кажется, что обе крайности очень опасны и нам нужно сконцентрироваться на практиках, приносящих результат.
Как практикующему коучу, вам наверняка приходится сталкиваться со стереотипным отношением клиентов к Agile.
Конечно! Я прихожу в ту или иную компанию и часто слышу, как разработчики и другие сотрудники говорят:
«Мы нуждаемся в Scrum-мастере». Обычно я отвечаю: «Мне жаль это слышать!».
Почему-то они поверили, что появление Scrum-мастера решит их проблемы. Не могу согласиться с этим. Для достижения результата в нашей работе нужно научиться адаптироваться под текущие задачи. Если же кто-то считает, что приход Scrum-мастера автоматически решит их проблемы, значит, они ставят во главу угла не результат, а процессы разработки. Такие организации игнорируют преимущества адаптивного подхода. Приходя в компанию, я пытаюсь бороться с этим и приносить вещи, направленные на результат. Иногда это очень сложно, потому что многие команды слишком привязаны к своим подходам и не готовы принять многообразие путей для достижения цели. И это еще одна проблема.
Как следует поступать Agile-разработчику, который разрабатывает ПО для традиционной компании, требующей классические строгие отчеты о каждом пройденном шаге?
Первое, что нужно сделать — понять, почему заказчик требует такие вещи. Второе, и самое важное, — завоевать доверие менеджмента. Невозможно добиться результата там, где тебе не доверяют. Я хочу донести до разработчиков простую истину: «Не пытайтесь сражаться с менеджментом, пытайтесь завоевать его доверие». Безусловно, завоевать доверие можно лишь добившись определенного результата, и если у меня не было времени на это, то не важно, что я буду говорить заказчику — отклика не будет. Но в большинстве случаев стоит спросить себя: «Что сделал я для получения доверия?». Итак, особенно важно при работе с заказчиком: завоевывать его доверие и выстраивать хорошие взаимоотношения.
За последние 30 лет я работал с самыми разными компаниями. И часто люди говорили мне: «Нет, ты не сможешь выполнить задачу, потому что ты никогда не работал с этими ребятами». Но я все равно справлялся с «невыполнимым» заданием. Так происходило, не потому что я столь умён — всё совсем наоборот. Я справлялся, потому что выстраивал отношения и завоевывал доверие.
Насколько часто американские разработчики сталкиваются с бюрократией, царящей в компаниях-заказчиках?
Каждый божий день! Я часто говорю о культуре. Своя культура присуща не только отдельным странам или отдельным регионам — культура присуща и каждой отдельной команде.
Мне приходилось работать в больших компаниях, и на одном этаже я мог встретить до десятка разных культур. Поэтому крайне важно фокусироваться не только на проекте, над которым работаешь, но и на культуре, в которой работаешь.
Когда я берусь за тот или иной проект, я пытаюсь разузнать, какую культуру исповедует компания-заказчик. Одно дело, когда корпоративная культура позволяет свободно обмениваться мнениями, быть открытым к критике, не соглашаться с решениями руководства. Но мне приходилось сотрудничать с компаниями и с жестким командным стилем управления.
И я думаю, что такая культура замечательна… если вы работаете в военной сфере. Но большинство из нас всё же занимаются другими вещами.
На самом деле, крайне важно найти подходящий тип корпоративной культуры. Компании с разными видами культуры существуют в каждой стране мира, включая США. Возможно, для некоторых стран командный стиль управления более свойственен в силу более жесткой структуры общества, но это не значит, что в США нет подобных компаний. На самом деле, встречаются они довольно часто.
В Беларуси часто говорят, что наше техническое образование не поспевает за развитием индустрии. Насколько актуальна подобная проблема для американских университетов?
То же самое можно сказать почти о всех странах, где я бывал. Все знают, что технические университеты с опозданием передают знания и практические навыки будущим разработчикам. Это хорошо известный факт. Но когда очередной разработчик жалуется мне, что университеты отстали от индустрии, я спрашиваю его: «А что лично ты собираешься с этим делать?».
Я пытаюсь изменить эту ситуацию уже тридцать лет, с тех пор как окончил колледж. Именно поэтому еще тогда я решил быть не только практикующим разработчиком, но и преподавать на факультете. Обычно я говорю, что у меня семь работ. Но на самом деле их всего две: разработчик и университетский профессор. И они взаимосвязаны: в университете я делюсь выводами, полученными на практике, а в качестве разработчика пытаюсь применить идеи, рожденные в академической среде.
Мне очень хочется больше воодушевлять разработчиков идеей преподавания в университетах. Даже несколько часов в месяц, потраченных на такую работу практикующим разработчиком, могут значительно повлиять и на студентов, и на учебные программы технических факультетов. Так что думаю, что это обязанность каждого в индустрии — быть мостиком между ней и Университетом.
Вообще я считаю, что лучший способ помогать людям — это помогать им в получении образования. Если я дам деньги кому-то… Что ж, это всего лишь деньги. Но если я воодушевлю кого-то получить образование, то помогу сразу нескольким поколениям людей.
Вы написали много книг, посвященных программированию и компьютерным наукам. Наверняка, это долго. Можете объяснить, зачем вам это?
Поделюсь с вами историей. Это было давным-давно, когда я только начинал выступать на конференциях. У меня был товарищ, мой учитель, весьма уважаемый мной. И вот я обратился к нему с вопросом:
— Не написать ли мне книгу? Я никогда не делал ничего подобного.
— Как у тебя идут дела?
— Отлично.
— В таком случае, не трать время зря. Книга — это лучшая визитная карточка, и с помощью неё можно найти работу. Но если с бизнесом всё в порядке, не трать время.
Я прислушался к совету и решил не писать книгу. Но прошло несколько месяцев, и я сказал себе: «Мой товарищ был прав, и я уважаю его. Но у меня есть одна причина написать книгу. Я хочу рассказать историю!».
Это звучит очень по-американски.
Не знаю, насколько это в американском стиле, но в моем уж точно (Смеется). И каждую книгу я писал только потому, что мне хотелось рассказать ту или иную историю.
Люди часто спрашивают, сколько времени мне приходится тратить на написание книг. Отвечаю я так: написание книги занимает две недели, но на подготовку уходит два года. И для меня каждый раз это сродни путешествию, цель которого — рассказать разработчикам новую историю.
Вы постоянно в пути, посещаете какое-то невероятное количество мероприятий по всему миру. Как держите себя в тонусе с таким графиком?
Существует два типа фитнеса, которые очень важны для меня: физический и психологический.
Пристально слежу за своим питанием. Лишь раз в год могу позволить себе банку колы. Я каждое утро бегаю, и это великолепный способ не только поддерживать физическую форму, но и бороться со стрессом.
Что касается психологического фитнеса, то у меня уже 35 лет существует правило: мыслить только в позитивном ключе. Конечно, все мы люди, и получается не всегда, но пытаться стоит. В нашей семье даже не принято говорить негативно о других. Это настраивает ум на нужный позитивный лад.
В работе у меня существует два правила: браться только за то, что действительно сможешь сделать, и уметь сказать «нет». Я мыслю следующим образом: чем больше ты говоришь «да», тем меньше ты сделаешь, чем больше ты говоришь «нет», тем ты сделаешь больше.
И еще одно — делать работу как можно раньше. Если у тебя запланировано дело на декабрь, а сейчас июнь, зачем ждать полгода, чтобы взяться за него?
Карго-культ вокруг DevOps: как навредить проекту из лучших побуждений
DevOps родился для того, чтобы команды разработки и поддержки работали эффективно и слаженно. Но иногда использование его практик может привести к реальным провалам. Как с помощью DevOps-практик не только не помочь, но и навредить проекту, рассказывает Александр Селезнёв, релиз-менеджер в Luxoft.
Коллективное воображение в ИТ: как менялись методологии разработки и кому они нужны
Лид-архитектор OpenShift из британского Barclays Айэн Милл опубликовал свои рассуждения о развитии методологий программирования, свидетелем которому он стал в ходе 20-летней карьеры в программировании. Его описание основано на концепции коллективного воображения из книги «Sapiens: Краткая история человечества» Юваля Ноя Харари. Она объясняет существование религий, демократии и многих других вещей, в основе которых лежат взаимоотношения мужду людьми. Публикуем сокращённый перевод.
Продолжаем знакомить с популярными курсами по Agile&Scrum. Предлагаем вам новую подборку курсов по Agile&Scrum, где мы собрали еще 20 интересных и разнообразных программ обучения по управлению проектами, которые подойдут как для руководителей, так и для рядовых сотрудников компаний.
Хотите сообщить важную новость? Пишите в Telegram-бот
Главные события и полезные ссылки в нашем Telegram-канале
Обсуждение
Комментируйте без ограничений
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.