wisdom of wombats » from archive
#FriendFeedExodusFest offline mode. как организовать разработку, чтоб люди не поубивали друг друга.
Я технофашист и верю в то, что good structure follows the great architecture. Если ваша архитектура -- гигантский ball of mud, as in python django апп которая делает все (ходит в базу, показывает интерфейс, посылает письма и факсы), то разработчиков придется менять раз в полгода. ‎- wisdom of wombats
С другой стороны, правильная архитектура на пустом месте тоже не растет. Очень редко когда удается остановить разработку на год, пока пишется новая платформа, а потом всех переучить на новый прекрасный путь всех вещей. Ну, то есть, бизнес-владельцы должны обладать ангельским характером, чтобы ждать, пока продукт улучшается технически, но денег больше не приносит. ‎- wisdom of wombats
Поэтому самые большие победы лежат в эволюционных переходах. Модуль за модулем, страница за страницей, вызов за вызовом. На фронт-энде это традиционно проще, чем в тех частях, которые касаются system state, то есть попросту базы данных или что там ее заменяет. "Вот мы этот вызов перепишем, сделаем для него отдельный микросервис и у него будет свей маленькое хранилище" работает, если больше никто на эти данные не претендует. Поэтому важный вопрос -- "кто владеет данными". При построении структуры на него надо отвечать. ‎- wisdom of wombats
Agile/scrum это хорошая идея сама по себе, но в современных компаниях больше смахивает на карго-культ. "Мы слышали, что все успешные компании делали scrum, мы позовем scrum masters и мы будем успешными." Нет, не будете. ‎- wisdom of wombats
Успешные компании стали успешными потому, что на них работали крутые люди и у них была крутая идея. Все остальное -- это следствие. По моему опыту, скрам работает только в случае 1. понятной и известной технологии 2. сработавшейся команды 3. вменяемых требованиях к продукту. То есть что-то типа разработки новых фич для уже существующего хорошо документированного продукта. ‎- wisdom of wombats
Для прототипирования, исследований, даже починки багов канбан работает лучше на порядок. ‎- wisdom of wombats
Горизонтальная структура, holarchy vs hierarchy, "we have no managers". Наверное, это работает для каких-то компаний. Чтобы понять, насколько они плоские, спросите, кто распоряжается бюджетом и кто нанимает людей. Это и есть менеджеры, все остальное ерунда. Реальный бизнес требует простых понятных вещей, в частности, single point of contact and responsibility. Можно сколько угодно говорить, что наличие лида снижает мотивацию команды, но при этом остается в стороне тот факт, что он или она берет на себя ответственность и тем самым снижает стресс для той же самой команды. Короче, лид нужен. И да, без политики не обойтись. ‎- wisdom of wombats
(Я говорю, кстати, о командах от тридцати инженеров примерно, меньшее количество можно организовать в стиле "мы все друзья". Потом начинается боль.) ‎- wisdom of wombats
To be continued. ‎- wisdom of wombats
На самом деле решение всех проблем, конечно, лежит в найме правильных людей. Дроны не нужны. Ну, то есть, у каждого проекта есть этап, на котором достаточно дронов, чтобы его поддерживать (без развития), но это неинтересно. Good engineers are troublemakers. ‎- wisdom of wombats
Если у инженера нет идей, как улучшить код, продукт, процесс, людей или хотя бы комнату где он сидит, то потыкайте его палочкой. ‎- wisdom of wombats
Как найти правильных людей? ‎- wisdom of wombats
Hiring is dating, с поправкой на полигамию. Вы перебираете десятки кандидатур, ходите на конференции и в бары, встречаетесь, разговариваете и наконец находите кого-то, с кем готовы провести месяцы в одной комнате. Все строго индивидуально, но есть одна максима, которая необходима для правильной структуры. ‎- wisdom of wombats
Нанимать надо людей умнее себя. В теории все с этим согласны, на практике много кто опасается, что умник его со временем подсидит. Да, это возможно. Но альтернатива -- окружить себя посредственностями -- в конечном счете губительна и для данного нанимателя в частности и для бизнеса в целом. ‎- wisdom of wombats
Еще немного про архитектуру. Мне кажется, она начинается со storage. То, как организован ваш интерфейс в базу данных или любое другое хранилище, определит вашу дальнейшую архитектуру. Микросервисы это прекрасно, но если они ходят в одни и те же таблицы, то все ваши микроразработчики будут все равно встречаться на одном пятачке, то есть, вам понадобятся общие процессы определения схем и структур данных, миграции и так далее. То есть одна такая большая зависимость на всех. И сколько бы ни было прекрасных абстракций вокруг нее, понадобятся интеграционные тесты (а это больно). ‎- wisdom of wombats
Если ваша архитектура позволяет держать разные хранилища для разных данных, то вы победили. Вы можете разделять компоненты, раздавать их разным командам и они могут разрабатывать с разной скоростью, ориентируясь только на свои цели. На нашем проекте меньше чем за год была сделана прекрасная декомпозиция фронтэнда от всего остального, но декомпозиция бэкенда уже заняла больше двух лет and counting. ‎- wisdom of wombats
Инфраструктура, девопсы, опсы. Это тоже боль. Большой проект под сколько-то серьезной нагрузкой требует серьезных людей, которые умеют настраивать системы (как вообще переводится provisioning?), индексировать базы, делать fail safe установки всего на свете, настраивать балансировку на сервере и так далее. Проблема в том, что эти люди по натуре антагонисты хакерского подхода, предпочитают проверенные технологии и слово "сертификация". Их можно понять, потому что в традиционной структуре именно они первыми получают звонок в субботу вечером, если все падает. Их работа все чинить, откатывать и перезапускать. И это неправильно. ‎- wisdom of wombats
Когда я говорю с людьми из других компаний, я первым делом спрашиваю, how often you deploy. Это хороший показатель. Мы пришли от одного деплоя в неделю (и меньше), к ежедневному. И все равно это мало. Почему люди бояться деплоя? Потому что бизнес требует предсказуемости. Если вы что-то ломаете, вы должны знать, как это быстро починить. Move fast and break things подразумевает, что вы можете откатить версию за секунды или что у вас есть тесты, которые не дадут вам сломать production. ‎- wisdom of wombats
В реальности, конечно, это куда сложнее. Инфраструктура это не код, развернуть ее предсказуемым, повторяемым и проверяемым образом очень сложно. Инструменты типа docker это шаг в правильном направлении, но 1) они накладывают ограничения на вашу архитектуру, проистекающие от концепции process per container 2) они недостаточно зрелые, чтобы сисадмин с седой бородой согласился пустить их на живой сервер. ‎- wisdom of wombats
Поэтому необходим компромисс. Хорошо, если в команде есть человек, глубоко понимающий в системах. Еще лучше, если ваша архитектура и культура компании позволяют docker + aws. В реальности -- любой разговор о новых функциях продукта должен вестись с людьми воот с такими бородами. У меня на глазах был прибит полугодовой проект, который использовал couch db, просто потому, что он не был сертифицирован. ‎- wisdom of wombats
QA. Глубоко убежден в том, что тестеры должны уметь писать код. Это следует тупо из математики -- продукт растет, функции и сценарии добавляются, руками тестить все дольше и дольше. Поэтому нужна автоматизация, без кода не обойтись. Не бывает автоматизации в вакууме, все специфично. Лучшие автотесты пишутся на языке, на котором написана система. DSLs are overrated. ‎- wisdom of wombats
Идеальный product manager это половина успеха проекта, врать не буду, с такими никогда не работал. Мне кажется, что чем более технический продукт, тем более техническими должны быть люди, которые его придумывают. Соответственно, чем ближе он к юзеру-пользователю-посетителю, тем больше от должен уметь в области интерфейсов и дизайна. Продукт и разработка должны жить параллельно, не сливаясь, бо цели у них все-таки довольно разные. ‎- wisdom of wombats