Connect with us

Разработка

Григорий Петров: Управление разработкой. Тридцатая колонка

После каждых девяти статей я подвожу итог, кратко пересказывая, о чем писал предыдущие полгода. И, как это ни странно, за последние полгода я снова написал девять статей! О чем они?

Avatar photo

Опубликовано

/

     
     

После каждых девяти статей я подвожу итог, кратко пересказывая, о чем писал предыдущие полгода. И, как это ни странно, за последние полгода я снова написал девять статей! О чем они?

Колонка 21: Микроменеджмент

Микроменеджмент хорошо зарекомендовал себя там, где много ручного труда. Увы, это не про разработку. Молодость индустрии, отсутствие фундаментального образования и устоявшихся практик, проклятье нулевой цены копирования и кошелек Миллера — все это приводит к тому, что каждый программист пишет свой код. Поэтому попытка тим лида «вложить свои мозги» в головы разработчика чаще всего не работает. А работает метод «построения коридоров» и еще ряд вещей, о которых я рассказал в этой колонке.

Колонка 22: Scrum: как забивать гвозди микроскопом

Практика управления разработкой «SCRUM» появилась больше двадцати лет назад. Но только в последние годы, на волне популярности «Agile» методологий, «SCRUM» стали интересоваться все больше и больше разработчиков. О методологии написано огромное количество книг, на каждом углу предлагают тренинги и семинары. Но «SCRUM» — совсем не серебряная пуля. Двадцать лет назад эта практика была создана с одной целью: предотвращение срыва сроков любой ценой. Тогда это было очень важно. За прошедшие годы индустрия сильно поменялась, глобализация и интернет позволяют командам чутко реагировать на реалии рынка и делать «пивоты», меняя концепцию в течении считанных дней. Понимание, как и зачем была создана методология «SCRUM», позволяет использовать только нужные практики, не рискуя стать жертвой «карго культа».

Колонка 23: YAGNI: «Синдром Хомяка» у программистов

Принципы разработки — шутка хорошая. Но в отсутствии фундаментального образования часто становятся жертвами «карго культа»: разработчики не всегда понимают, почему более опытные коллеги рекомендуют делать те или иные вещи. Да и сами коллеги тоже это не всегда понимают. Первый из принципов, о котором я рассказываю, это YAGNI: «You Aren’t Gonna Need It». Этот принцип старается уберечь разработчика от одной из ловушек сложности: попыток писать код «про запас» в надежде побороть сложность. Использование данного принципа подразумевает знания о том, что такое сложность и как с ней бороться. Если разработчик точено понимает в чем проблема, то он не будет неделями «окапываться» и возводить в коде «оборонительные сооружения». А сможет принять взвешенное решение и обойтись минимумом кода. Проще — почти всегда лучше.

Колонка 24: Клетка из слов

Коммуникации — штука сложная. При разработке софта эта сложность еще больше вырастает. Отсутствие устоявшихся терминов, аналогий с физическим миром, простых и понятных неспециалистам процессов. Разработчики не смеются над шуткой что «ТЗ — это точка зрения и у нас их уже три». Сооружение клетки из слов является одним из самых простых способов что-либо объяснить. А чтобы этот способ хорошо работал в IT, нужно хорошо знать принцип его действия. Зная этот принцип, можно использовать специальные приемы для улучшения коммуникаций: возведение дополнительных «стен» клетки, пересказ понятного своими словами и наводящие вопросы.

Колонка 25: Стандарт оформления кода: и не стандарт, и не оформления, и не только кода

Проблема сложности является одной из основных при разработке программ. Кошелек Миллера не позволяет разработчикам держать в фокусе внимания программу целиком. Для борьбы с этим ограничением используется готовые библиотеки, фреймворки, разные языки программирования, приемы написания и комментирования кода, системы управления задачами и многое, многое другое. При этом каждый разработчик предпочитает «свой» набор инструментов и приемов. Чтобы лебедь, рак и щука все-таки договорились, придумана такая штука как «стандарт кодирования». Специальный документ, который описывает общие принципы написания кода в данной компании. Разработчики, придерживающиеся одного стандарта кодирования, через некоторое время привыкают к нему, так же как шахматисты привыкают распознавать постоянно используемые дебюты и гамбиты. Они уже не тратят фокус внимания на привычные вещи, и им становится намного проще работать не только со своим кодом, но и с кодом коллег. Которые придерживаются того же стандарта кодирования.

Колонка 26: Модель, которую построил мозг

Появление МРТ позволило психологам найти связи между устройством мозга и нашим поведением. Концепция «ментальных моделей» объясняет работу нашего сознания довольно просто: мозг постоянно строит и меняет модели окружающего мира. И через эти модели с окружающим миром взаимодействует. Из этой концепции следует множество практических рекомендаций. Стандарты кодирования, для синхронизации ментальных моделей в команде. Принудительный перебор нескольких вариантов решения, потому что мозг всегда «цепляется» за первую «подошедшую» модель. Определение проблем с архитектурой по сложным описаниям: мозг строит модели всегда, но чем меньше разработчик понимает задачу, тем сложнее будет его ментальная модель. Брейнштормы с бумагой и ручкой, потому что наше воображение не креативно. И много других интересных вещей, связанных с коммуникациями и организацией работы.

Колонка 27: Управление страхом с помощью Continuous Integration

«Continuous Integration», или «CI», решает не только технические задачи по сборке и тестированию кода. Автоматическая сборка и проверка задает для команды «правила игры», которые неявно, но очень сильно влияют на поведение участников. Знание о том, что push будет проверен автобилдом, заставляет разработчика внимательно проверять свой код. Просто потому, что он не хочет быть супергероем, сломавшим автобилд. Знание об этой роли CI позволит вам получить максимум пользы от минимума настроенной автоматизации — главное, чтобы команда понимала и принимала правила игры.

Колонка 28: Иллюзия визуального программирования

Иллюзия плохого инструмента — простая модель, с помощью которой мозг поддерживает в нас более-менее логичную картину окружающего мира. Психологически намного комфортнее объяснить неудачи внешними причинами, нежели признать, что тут надо учиться много лет и вообще все не так просто. Примерно раз в год очередная крупная компания анонсирует «создавайте игры сайты мобильные приложения, не умея программировать!». Сложность же разработки кроется не в инструменте, а в формулировке. Большинство людей без предварительного обучения не смогут создать в фотошопе красивую картинку, хотя фотошоп вполне себе «простой, визуальный» и не требует много лет изучать языки программирования. Только вот сложность рисования красивых картин — она в самих картинах, а не в используемых инструментах. Когда вы услышите «а вот давайте создадим универсальный инструмент, чтобы потом легче было!» или «это плохой язык программирования, давайте используем другой» — возможно, разработчики находятся под действием такой иллюзии и надо их спасать. Или не находятся, и спасать никого не надо. А вот проверить — стоит в любом случае.

Колонка 29: Менеджер, который сидит в засаде

В предыдущих колонках я рассказал про роль в разработке Заказчика (Product Owner) и Тим Лида (Team Lead). В этой колонке речь идет о третьей организационной роли. О менеджере. Зачем нужен менеджер? Затем, что наши модели поведения немного отстают от социума. Эволюция хорошо приспособила нас для выживания в небольшой стае охотников и собирателей. Наше существование кардинально поменялось, а вот выработанные модели поведения не успели. Эволюция штука не очень быстрая. И сейчас весь этот запас из каменного века очень мешает работе в коллективе, нещадно «глюча» и порождая множество неприятностей — от почти безобидной прокрастинации до опасных подковерных игрищ за звание альфа-самца. Борьба с инстинктами и когнитивными искажениями — самое, на мой взгляд, важное, что делает в команде менеджер. Он обеспечивает коммуникации между участниками разработки, решает социальные вопросы, рассказывает, как организовать работу — все то, что идеальная команда сделает и без него. А вот реальная — нет.

Что дальше?

В следующих колонках нас ожидают системы управления знаниями, code review и много других небезынтересных штук. Подписывайтесь на обновления и оставайтесь с нами!

Так как я пишу эти статьи для повышения собственной квалификации, то мне очень важно ваше мнение и те сложности, с которыми вы ежедневно сталкиваетесь при управлении разработкой. Пишите мне о ваших проблемах, и, возможно, в одной из следующих колонок я анонимно разберу именно ваш кейс.

Мой email: grigory.v.p@gmail.com
Facebook: http://facebook.com/grigoryvp

Также меня всегда можно найти и поспрашивать в Telegram канале @voximplant.

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Telegram

Популярное

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: