[Управление разработкой, Управление проектами, Agile, Управление персоналом] Эмпирические законы человеческого поведения в Scrum

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
02-Мар-2021 12:31

Цитировать

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

Синдром студента и закон ПаркинсонаКак избыток времени играет против вас, и что с этим делатьСиндром студентаОн говорит о том, что у людей есть склонность не завершать задачи заранее. Иными словами, человек будет стремиться не приступать к задаче настолько долго, насколько это возможно.Представим, что проект менеджеру приходит задача, он оценивает трудозатраты и накидывает 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 — именно про это. Буду рад, если вы поделитесь в комментариях своим опытом
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_proektami (Управление проектами), #_agile, #_upravlenie_personalom (Управление персоналом), #_upravlenie_ljudmi (управление людьми), #_upravlenie_proektami (управление проектами), #_upravlenie_komandoj (управление командой), #_upravlenie_razrabotkoj (управление разработкой), #_upravlenie_vremenem (управление временем), #_agile, #_scrum, #_scrummaster (scrum-мастер), #_agile_development, #_upravlenie_proektami_i_komandoj (управление проектами и командой), #_blog_kompanii_reksoft (
Блог компании Reksoft
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_proektami (
Управление проектами
), #_agile, #_upravlenie_personalom (
Управление персоналом
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 13:47
Часовой пояс: UTC + 5