Как стать автором
Обновить
34.96
Рейтинг

Эмпирические законы человеческого поведения в Scrum

ReksoftУправление разработкойУправление проектамиAgileУправление персоналом

Как связаны человеческие привычки и ИТ-разработка? Мой опыт показывает, что напрямую.
В «Рексофт» мы каждый четверг проводим технологические митапы. Недавно на одном из них
я рассказал, как различные паттерны из повседневной жизни влияют на работу скрам-мастера, проектного и дев-менеджеров, да и на команду в целом. Тема коллегам зашла, поэтому решил написать об этом статью. Не претендую на истину в последней инстанции, скорее хочу поделиться личным опытом.

Синдром студента и закон Паркинсона

Как избыток времени играет против вас, и что с этим делать

Синдром студента

Он говорит о том, что у людей есть склонность не завершать задачи заранее. Иными словами, человек будет стремиться не приступать к задаче настолько долго, насколько это возможно.

Представим, что проект менеджеру приходит задача, он оценивает трудозатраты и накидывает 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 — именно про это. Буду рад, если вы поделитесь в комментариях своим опытом

Теги:управление людьмиуправление проектамиуправление командойуправление разработкойуправление временемagilescrumscrum-мастерagile developmentуправление проектами и командой
Хабы: Reksoft Управление разработкой Управление проектами Agile Управление персоналом
Всего голосов 3: ↑2 и ↓1 +1
Просмотры4.5K

Похожие публикации

Лучшие публикации за сутки

Информация

Дата основания
Местоположение
Россия
Сайт
www.reksoft.ru
Численность
201–500 человек
Дата регистрации

Блог на Хабре