Как связаны человеческие привычки и ИТ-разработка? Мой опыт показывает, что напрямую.
В «Рексофт» мы каждый четверг проводим технологические митапы. Недавно на одном из них
я рассказал, как различные паттерны из повседневной жизни влияют на работу скрам-мастера, проектного и дев-менеджеров, да и на команду в целом. Тема коллегам зашла, поэтому решил написать об этом статью. Не претендую на истину в последней инстанции, скорее хочу поделиться личным опытом.
Синдром студента и закон Паркинсона
Как избыток времени играет против вас, и что с этим делать
Синдром студента
Он говорит о том, что у людей есть склонность не завершать задачи заранее. Иными словами, человек будет стремиться не приступать к задаче настолько долго, насколько это возможно.
Представим, что проект менеджеру приходит задача, он оценивает трудозатраты и накидывает 20% времени про запас. Менеджер со стороны заказчика накидывает еще 20%. Так, исходная оценка может вырасти в несколько раз. Казалось бы, все отлично, времени достаточно, чтобы реализовать необходимый функционал и даже сдать его заранее. Но синдром студента говорит об обратном.
Последствия Синдрома студента в Scrum:
Дополнительное время сгорает без толку.
Создается ложное впечатление, что времени в избытке и браться за задачу прямо сейчас необязательно. В результате время, которое заложено для подстраховки, просто сгорает.
Времени не остается совсем.
Когда остается мало времени — команда пытается ускорить разработку, упростить решение или избавиться от избыточного функционала. Но становится только хуже — драгоценное время уходит на то, чтобы пересогласовать решение, подготовить новые оценки и так далее. В итоге времени на задачу не остается вообще.
Закон Паркинсона
Он говорит о том, что работа заполнит любой предоставленный объем.
Как и с Синдромом студента, представим, что менеджеры со стороны заказчика и исполнителя заложили на задачу дополнительное время, чтобы перестраховаться. Казалось бы, если мы начнем работать вовремя, то точно успеем к сроку. Но, увы, по закону Паркинсона все не так гладко.
Последствия законы Паркинсона в Scrum:
Необоснованное усложнение проекта.
Когда у команды слишком много времени, то вместо того, чтобы решать задачу, она начинает думать, как реализовать дополнительную функциональность, использовать новые подходы к разработке и так далее. Это может потребовать пересогласований и вызовет риски, которые изначально не были предусмотрены. Результат все тот же — срыв сроков.
Избыточный код.
Погоня за улучшением или расширением заложенного функционала увеличивает объем кода. Это требует большего количества тестов и повышает число зависимостей. В результате опять же растут риски, которые могут сорвать сроки.
Как победить Синдром студента и Закон Паркинсона?
Используйте критическую цепь проектного менеджмента. Ее основные постулаты:
Избегать привязки к конкретным датам.
Вместо этого использовать короткие итерации. Их цель — не решить задачу к определенному сроку, а завершить ее как можно скорее.
Давать сотрудникам как можно меньше параллельных задач.
Каждое переключение требует времени — человеку нужно вспомнить, что он делал и снова погрузиться в контекст. Время уходит, а задача не делается. Поэтому в идеале один сотрудник должен работать над одной задачей. Это помогает четко видеть цель и избегать расфокусировки.
Заложить все запасное время в конец пути.
Буфер безопасности не должен быть размазан по всему времени работы. Его нужно заложить в самый конец, на случай, если что-то действительное пойдет не так. Это поможет избавиться от ощущения, что времени много и задачу можно без конца откладывать на потом.
Закон Вирта (закон Билла Гейтса)
Почему ПО становится медленнее
Закон Вирта говорит о том, что производительность программного обеспечения падает быстрее, чем растет производительность аппаратного. Билл Гейтс говорил о том, что скорость софта снижается на 50% каждые 18 месяцев. Давайте разберемся, почему ПО становится медленнее:
Избыточные функции
Даже если вам кажется, что скорость работы функций не снижается, то у вас может расти пользовательский workflow. То есть операция, которая ранее занимала у пользователя 1 час, после нового релиза может занимать 1,5 часа. Просто потому, что для части пользователей не нужны изменения, которые вы внесли в workflow. Таким образом, вы вынуждаете пользователей «бороться» с новым функционалом.
Неоптимальная работа с данными
По мере накопления данных, их становится слишком много, а взаимосвязи между ними могут меняться. Это требует пересмотреть методы обращения к данным. Зачастую встают вопросы не только переиндексации, но и вообще пересмотра архитектуры хранения.
Отсутствие рефакторинга
Если не проводить рефакторинг, то по мере развития продукта, вы получите «грязный» код, который сложно читать, понимать и поддерживать. Это усложняет рост продукта и снижает предсказуемость разработки. Чтобы сохранить производительность решения и обеспечить его развитие, нужно регулярно проводить рефакторинг.
Теория разбитых окон
Как разработчик становится худшим врагом своего проекта
Теория говорит о том, что если не заменить разбитое окно, то это спровоцирует вандалов побить и соседние окна. Давайте посмотрим, что играет роль разбитого окна в контексте ИТ-разработки.
Плохой код и временные решения
Бывает, что для того, чтобы быстро показать клиенту разработанный функционал, команда создает временные решения и ставит заглушки. Мол, сейчас покажем так, а потом уже доделаем по-человечьи. Но мифическое «потом» не наступает — работы много, временные, сделанные на коленке куски, становятся постоянными. Разработчики видят плохой код и не оптимальные решения, а потому считают вправе и дальше работать соответствующим образом. Зачем делать руль велосипеда удобным, если у него квадратные колеса?
Устаревшие технологии.
Что будет, если вовремя не переходить на новые технологии, не обновлять внешние модули и копить технические долги? На поддержку устаревших решений будет уходить все больше времени и сил, а чем дальше будет развиваться продукт, тем дороже и сложнее будет от них отказаться. Но самое плохое, что участникам проекта будет казаться, что это — норма. Так было всегда, зачем что-то менять?
Отсутствие владельца кода (code owner).
Когда никто не считает себя ответственным за код, он быстро превращается в помойку. Но что еще хуже, что, когда в проект приходит новый человек, он не стремится работать лучше. Какая разница, если никто не несет ответственности?
Но как найти время на рефакторинг, переработку неэффективных решений или переход на новые технологии? В самом начале необходимо вводить и согласовывать метрики качества, следить за плотностью дефектов и контролировать их на протяжении всего проекта. Само собой, необходимо заложить время на поддержание этих параметров на приемлемом уровне.
Бритва Оккама
Отсечь все лишнее
Методологический принцип, который утверждает, что чем проще — тем понятнее. В рамках ИТ-разработки Бритва Оккама отлично коррелирует с одним из столпов, на котором построен Scrum— Transparency:
Прозрачность и предсказуемость.
Мы понимаем, почему выбрали именно это решение, и понимаем, к чему оно приведет.
Еще 2 концепции, широко известные в IT-разработке и, фактически, являющиеся следствием Бритвы Оккама:
KISS
Принцип, который утверждает, что большинство систем работают лучше всего, если они остаются простыми, а не усложняются.
YAGNI
Принцип, который призывает отказаться от добавления функциональности, в которой нет непосредственной надобности.
Если обобщить, то принцип Бритвы Оккама призывает к тому, что задачу нужно реализовывать наиболее простыми и доступными методами в рамках текущих требований. Не нужно пытаться расширять функциональность или додумывать за заказчика, что бы ему хотелось получить, пусть это и продиктовано благими намерениями.
Приоритеты: матрица Эйзенхауэра и метод набегающей волны
Как правильно расставить приоритеты
Выбор тех задач, которые мы должны взять в спринт, может казаться тривиальной задачей. Однако регулярное ревью бэклога должно толкать нас на то, чтобы классифицировать, правильно оценить и осмысленно выбрать наиболее актуальные задачи. В этом может помочь, к примеру, матрица Эйзенхауэра, которая классифицирует задачи следующим образом.
Важные и срочные (Do)
Тут все просто. Это задачи, которые нужно в первую очередь класть в спринт.
Неважные и несрочные (Eliminate)
Выкиньте их из бэклога. Скорее всего вы никогда не возьмете эти задачи в спринт, а будете только тратить время на то, чтобы возвращаться и просматривать их. Если все-таки понадобится — заведете их снова, но сейчас просто выкиньте. Мой опыт говорит, что об этих задачах вы с вероятностью 90% больше не вспомните.
Важные, но несрочные (Schedule)
Если задачи действительно важные, то рано или поздно они точно станут срочными. Возьмите за правило брать небольшую часть этих задач в работу. Это облегчит ваши следующие итерации.
Неважные, но срочные (Delegate).
Делегируйте эти задачи заинтересованным сотрудникам.
Метод набегающей волны. Еще один метод, который помогает в приоритезации задачи в Scrum. Он говорит, что не надо пытаться грумить весь бэклог до состояния ready for development. Старайтесь понять, что наиболее важно, максимально детализируйте требования и оценки только для следующей итерации и, возможно, к одной за ней. Планирование далеко вперед отнимет у вас много времени, а любое изменение обрушит все ваши планы как карточный домик.
Инерция — главный враг Agile
Как привычки мешают проекту развиваться
Инерция — это сопротивление изменению скорости или направления. Здесь я бы хотел обсудить, как инерция мешает эффективной работе по Scrum.
Продолжаемые улучшения.
Важно после каждой итерации разобраться, что бы мы хотели улучшить в нашей работе. Затем заложить часть этих улучшений на следующую итерацию в качестве задач. И так из одной итерации в другую. При этом важно отслеживать ход улучшений, чтобы не ходить по кругу по одним и тем же граблям.
Привычки.
Мы привыкли к команде, менеджменту и нашим процессам. Здесь нужно уметь посмотреть на свою работу свежим взглядом — как мы работаем как команда, устраивает ли нас, как работает наш скрам-мастер, считаем ли мы текущие процессы разработки оптимальными. Желательно хотя бы раз в итерацию останавливаться и задавать себе такие вопросы — это важно и правильно.
Единичные специалисты.
Осознанно или неосознанно вы можете растить т.н. module specific developer, то есть человека, который в единственном лице способен решить проблемы определенного модуля.
Допустим, на прошлой итерации Ваня занимался задачей в определенном модуле, сейчас снова появилась, связанная с ним задача. Очевидно, имеет смысл снова назначить Ваню на эту работу. Это может быть хорошо с точки зрения скорости и качества разработки, но создает риски с точки зрения загрузки. Если вдруг Ваня заболеет или уволится, то кто подхватит задачи по этому модулю? Важно следить за тем, чтобы у вас не возникало узких специалистов в единственном числе.
Неготовность к изменениям.
Почему опытный разработчик боится чего-то нового и связанных с этим изменений?
Основных причин несколько:
— Для разработчика новые практики еще не доказали свою эффективность. Соответственно, есть страх, что «просядут» его личные результаты.
— В какой-то мере, мы предлагаем «выкинуть» опыт работы по текущим процессам и все члены команды должны будут стартовать с одинакового уровня знаний. Т.е. мы частично преимуществ сотрудников с большим опытом.
Вот как я рекомендую бороться с этими причинами:
— Убрать страх за плохой результат. Не делает ошибок в коде, тот кто его не пишет. Нельзя ругать и наказывать за ошибки (другой вопрос — повторяющиеся ошибки). Результаты могут не прийти сразу, поэтому очень важно отслеживать динамику изменений. Нужно поощрять право команды на эксперименты. Командой и конкретным разработчиком должно двигать любопытство — хотим попробовать и посмотреть на результат. Тем более что Agile и, в частности, Scrum предлагают самое честное соревнование — с самим собой из предыдущей итерации
— Накопленный ранее опыт не «выбрасывается» — он скорее девальвируется. Но, с другой стороны, приобретенный опыт работы по новым процессам существенно повышает ценность сотрудника и команды. А для более опытного сотрудника — это еще более ценно, т.к. его экспертиза становится более вариативной.
В современном IT мире, по большей части, процессы разработки не ортодоксальны относительно методологий и фреймворков — это очень часто микс из разных подходов, для конкретных этапов разработки ПО. И тут уже задача менеджеров правильно балансировать различные процессные практики в работе с командой.
Напоследок хочу сказать: чтобы быть успешным в ИТ-разработке нужно быть Agile, but not flexible. То есть нужно уметь подстроиться под реальность, а не прогибаться под нее. Мне кажется, что Agile и Scrum — именно про это. Буду рад, если вы поделитесь в комментариях своим опытом
