Гибкая разработка — отличная идея, которая стала слишком сложной.
Agile Lite — это попытка упростить вещи.
Вам не нужны книги или семинары, чтобы объяснить Agile Lite. Все, что вам нужно, это небольшой текст в несколько абзацев.
Вот текст. Agile Lite довольно прост. Его можно применять к любому проекту, если работа разбита на более мелкие задачи.
Как и другие гибкие методологии, он использует короткие циклы разработки, называемые спринтами.
Но в отличие от них, Agile Lite открыто признает распространенность выгорания в индустрии разработки программного обеспечения и пытается смягчить его напрямую, внедряя цикл «три недели разработки и одну неделю отдыха».
Основные правила:
- В первую неделю каждого цикла менеджеры проектов, разработчики и другие заинтересованные стороны определяют предстоящий спринт. Хоть и выделена неделя, планирование спринта займет не более двух часов, а при правильной организации — около 45 минут. Это намеренно легкая неделя: многие могут просто взять отпуск, чтобы заняться серфингом, рисованием или чем-то еще.
- Спринт проводится в течение оставшихся трех недель.
В этот период инженеры работают над задачами, которые возложены на них при планировании.
Поскольку сотрудники могут находиться удаленно и находиться в разных часовых поясах, личные встречи проводятся нечасто, и большая часть общения происходит через трекер (который быстрее, чем электронная почта).
Обычная канбан-доска, такая как Trello, подойдет, но электронная таблица, вероятно, нет. Ежедневные планерки не приветствуются: общий пульс проекта вполне отслеживается обновлениями трекера.
- После начала спринта вы не можете добавлять задачи в спринт, но можете удалить их.
Это уменьшает переключение контекста, и это хорошо.
- Незавершенные задачи пересматриваются на следующем планировании спринта — и решается, перенести ли задачу на следующий спринт, вернуть ее в список желаний или переназначить другому разработчику.
- Каждая задача находится либо в списке желаний, либо в текущем спринте.
На выполнение каждой задачи должно уйти 4–8 часов.
- Как уже упоминалось, в течение недели планирования разработчикам рекомендуется отдыхать, чтобы их мозг мог восстановиться после предыдущего спринта.
Это не крестовый поход. Разработчики не работают по выходным.
Все это помогает избежать выгорания, что хорошо для всех.
Эти неожиданные проблемы называются проблемами поддержки.
Во время планирования спринта мы предлагаем выделить время для решения проблем поддержки, которые невозможно запланировать.
Например: «В ходе следующего спринта Дэйву выделяется 12 часов на выполнение задач поддержки (детали которых будут определены позже)».
Часто бывает полезно поддерживать ротацию, при которой каждый спринт меняет разработчика(ов), ответственного за проблемы поддержки.
Чтобы повысить точность прогноза, на каждом сеансе планирования спринта анализируется объем работы по поддержке, фактически выполненной в предыдущем спринте, и решается, потребуется ли больше или меньше времени для поддержки в следующем спринте.
На практике разные группы имеют разные определения задач поддержки.
Возможно, это означает поддержку клиента/клиентов.
Возможна поддержка других разработчиков.
Вам решать, какие элементы этой общей методологии лучше всего подходят для вашей команды.
Устраняя ненужную сложность, Agile Lite представляет собой лучший и более устойчивый способ разработки программного обеспечения.
Это помогает в развитии, обеспечивая при этом стабильно высокий уровень производительности.
Agile Lite для разработчиков Если вы не новичок в отрасли, вы, вероятно, испытали выгорание.
Причин много, но проще всего описать выгорание как результат слишком тяжелой работы в условиях слишком большого стресса и слишком долгого времени.
Все начинается с проекта.
Каждый проект имеет подробные спецификации и сроки выполнения.
При изменении спецификации срок не меняется.
В конце концов наступает крайний срок, и спецификация превратилась в нечто иное, чем то, с чего она началась.
Конечно, это рассматривается как ваша вина, и вас просят задержаться или выполнить «целевую растяжку».
В итоге вы работаете каждые выходные, но, как бы вы ни старались, менеджер всегда недоволен, а проект всегда отстает от графика.
Желание взять отпуск или отпуск заставит вас выглядеть бездельником, который не поддерживает команду.
Возможно, вы работаете в открытом офисе; все знают, когда все приходят и уходят, и каждый подписывает негласный договор не работать меньше других.
Вот почему людям хорошо удается выглядеть занятыми.
Когда кто-то спрашивает, как дела, вы просто отвечаете: «Занят! Я очень занят! Но в конце концов что-то происходит. Вы можете менять работу, но обычно это другие компании в индустрии программного обеспечения.
Может быть, вы отдаете все свои силы, пока не остаетесь полностью опустошенными, а затем компания отпускает вас, потому что вы больше не «соответствуете культуре».
Возможно, вы уйдете и начнете продавать автомобили, потому что программирование вас слишком утомляет. Как говорится, хочешь потерять удовольствие от хобби, попробуй заработать на нем.
Я предлагаю решение.
Это форма Agile, которая явно разработана для предотвращения выгорания: Agile Lite. Здесь нет сверхурочной работы.
Инженерные работы идут полным ходом, и у разработчиков есть достаточно времени, чтобы подзарядить мозги.
Накладные расходы на управление минимальны.
Практически вся система описана в шести пунктах выше.
Его можно изменить в соответствии с вашими целями.
Но хотелось бы выделить одну особенность Agile Lite. Здесь мы четко говорим: «О, гибкие команды выгорают так же, как и другие методологии разработки.
Возможно, стоит записать четкие правила, чтобы предотвратить перегрев двигателя, которым является команда инженеров».
Давайте прекратим перегревать двигатели.
Нам предстоит много работы.
По сути, это бездонная яма.
Но жизнь слишком коротка, чтобы тратить ее целиком на работу, стресс и, в конечном итоге, выгорание.
Agile Lite для менеджеров Были ли у вашей компании проблемы с разработчиками? Часто ли проекты срывают сроки? Работали ли вы с разработчиками, которые начинали хорошо, затем постепенно деградировали и исчезали? Возможно, это талантливый программист, испытавший выгорание.
Выгорание чрезвычайно распространено в индустрии программного обеспечения и является основной причиной неудач многих программных проектов.
Выгорание лучше всего можно охарактеризовать как симптомы посттравматического стрессового расстройства, связанного с конкретным проектом или организацией.
Например, кажется, что ваш мозг отключается, и вы чувствуете сильную тревогу при одном только упоминании определенного проекта.
Это выгорание.
Разработчик в таком состоянии, скорее всего, не сможет продолжать работу над этим проектом и не сможет работать на полную мощность в будущих проектах.
Выгорание может разрушить карьеру.
Это похоже на работу двигателя автомобиля на высоких оборотах в течение очень долгого времени без доливки масла или топлива.
Со временем этот двигатель сломается, и его будет трудно собрать обратно.
Основные принципы системы Agile Lite описаны выше и могут быть изменены в соответствии с вашими целями.
Часто задаваемые вопросы + типовые утверждения Единственное общее правило в мире гибкой разработки заключается в том, что все делают неправильно.
@fwip Значит, инженеры получают 12 недель отпуска в году для серфинга и рисования? Как это будет работать в мире, где работа с 9:00 до 21:00 шесть дней в неделю становится нормой? Я считаю, что ваши разработчики должны отдыхать столько, сколько им нужно.
Замечу, что 40-часовая рабочая неделя когда-то считалась радикальной идеей.
Google начинал с 80% рабочего времени на основные проекты, сейчас мы достигли 75%, я бы хотел снизить эту долю до 10% (метод Ферриса) к концу 2020-х годов.
Система 996 (с 9:00 до 21:00 6 дней в неделю) представляет собой противоположный подход, целью которого является продление 40-часовой рабочей недели до 72-часовой рабочей недели.
Я рассматриваю это как регресс и считаю, что нам следует перестать фетишизировать сверхурочную работу.
На самом деле это не увеличивает производительность.
Кроме того, вы сами решаете, чем заняться в «неделю отдыха»: уйти в отпуск, назначить более легкую нагрузку или что-то еще.
Ответ может зависеть от конкретной недели.
Возможно, «легкая неделя» дается людям легче, чем «неделя отдыха».
Используйте то, что наиболее удобно для вас.
Серфинг и рисование ни в коем случае не являются обязательными и являются лишь примерами.
Я даже не занимаюсь серфингом и не рисую сам.
Людям назначать задачи или себя предсказывать , что они получат? Они предсказывают. Ничего страшного, если ваши оценки неверны.
Это часть процесса, и все в одной команде.
Можем ли мы назвать это итерациями вместо спринтов? Конечно! «Спринт» лично меня устраивает. Можно ли провести скользящую итерацию в стиле Канбан, где даты начала и окончания различаются и зависят от обстоятельств? Мне очень нравится концепция рабочего цикла с конкретными датами начала и окончания, определяемого одним блоком задач.
Скользящие итерации, не синхронизированные с конкретным циклом, испортят его.
Почему именно три недели спринтов? Потому что развитие плюс восстановление укладывается в 13 слотов в год. Когда цикл завершается, начинается новый.
Неделя «отдыха» позволяет вам восстановить силы перед началом нового спринта.
Речь идет о достижении каденции и четких, последовательных интервалов.
Означает ли это, что даты начала и окончания спринта часто приходятся на середину календарного месяца? Да.
Участвуют ли разработчики в планировании спринта? Да.
Им не запрещено присутствовать на собрании.
В этом нет необходимости, особенно если трекер проблем работает хорошо и команда обсуждала некоторые задачи следующего спринта во время предыдущего.
Я за меньшее количество встреч.
Они мало кому нравятся.
Если вы один из таких, то не рассчитывайте на меня.
Действительно ли планирование спринта занимает неделю? Нет, в этом вся суть.
Это легкая неделя.
Действительно ли стендапы – это проблема? По моему опыту, да.
Обычно все стоят в кругу и слушают одного человека в течение 20 минут. Конечно, это «неправильный» подход, но я никогда не видел, чтобы кто-то выполнял их правильно, и я бы предпочел вообще отказаться от ежедневных занятий по планированию.
Еще сложнее (или как минимум неудобнее) их проводить, когда ваша команда распределена географически.
Но если они очень ценны для тебя, не позволяй мне останавливать тебя.
Должны ли мы делать все именно так? Нет. Никто не заставляет вас что-либо делать.
Это рекомендации, а не правила.
Это не религия.
Эти правила являются политическими только в том смысле, что продвижение 40-часовой рабочей недели было политическим.
То, что работает для вас, может не работать для других.
Знаете ли вы об этом?
Я в этом уверен!
Частые высказывания
Нет необходимости делать временные прогнозы, поскольку оценки невозможны.Прогнозы считаются прогнозами, а не контрактами, подписанными кровью.
Так что, если они не соблюдаются, ничего страшного.
Приложите все усилия и постарайтесь сделать прогноз с шагом в 4 часа.
Разработчикам нельзя доверять, и все их время нужно отслеживать, потому что именно так выполняется работа.
Я действительно не согласен, но не могу быстро объяснить почему.
У нас принципиальные различия в мировоззрении.
Это не Agile. Конечно Agile, это прямо в названии.
Это нереально.
И все же это работает. Вы неправильно делаете Agile. К сожалению, проблема Agile в том, что его невозможно сделать правильно.
Теги: #здоровье #Управление разработкой #Управление проектами #agile #burnout #agile lite
-
Вакуумное Напыление «На Коленке»
19 Oct, 24 -
Ссылка Из Pdf-Файла
19 Oct, 24 -
Два Номера На Одной Sim-Карте
19 Oct, 24
