что такое скрам доска
Разбираемся в Scrum и Kanban
Аспирант Нетологии Максим Пименов продолжает рассказ про гибкие методологии создания ПО. На этот раз Максим разбирает Kanban и Scrum — два подхода к работе над проектом, основанных на Agile.
Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile, о которых я писал в предыдущей статье.
Чистый Scrum — более директивная методология — больше предписаний. Kanban — демократичнее, поэтому его проще внедрить.
Обе технологии близки, потому их инструменты можно комбинировать.
Команды в Kanban и Scrum
Основа обеих методологий — Agile, поэтому и в Scrum, и в Kanban работают небольшие автономные команды из 5—9 человек. В командах нет формального руководителя, и никто извне не диктует, как организовывать работу над продуктом.
Поскольку команда автономная и самоорганизующаяся, за успех или неудачу она отвечает как единое целое. Провал не свалить на ленивого разработчика или невнимательного тестировщика.
Обе методологии подразумевают, что команда располагается в едином пространстве. Лучше, если это не кубиклы, а общая комната. Главный принцип — свободное общение между специалистами и общие обсуждения.
А вот дальше в Kanban и Scrum начинаются различия.
Kanban. Над задачей может работать несколько узкопрофильных команд. К примеру, сначала работают аналитики, потом дизайнеры рисуют прототип, а на третьем этапе включаются разработчики.
При этом универсальные команды не запрещены.
В Kanban внутри команды нет ролей.
Scrum. Над проектом работает одна универсальная команда. В ней столько разноплановых специалистов, сколько нужно для решения любой задачи проекта.
Поскольку команда самоорганизуется, у специалистов scrum-команды нет формальной компетенции. Когда необходимо, тестировщик помогает дизайнеру, а аналитик — разработчику.
В scrum-команде помимо собственно специалистов есть две роли.
Scrum-мастер — человек, который организует работу. Это не управленческая должность, и он не раздает указания. Его задачи:
В свободное от этих задач время скрам-мастер работает так же, как другие члены команды.
Владелец продукта — product owner — определяет ход проекта, он может представлять внешнего заказчика. Владелец знает все о рынке и целевой аудитории. Он ставит приоритеты задачам. Результат работы команда представляет владельцу продукта.
Как составляют список задач
Для начала команда берет проект и делит его на десятки, а то и сотни задач поменьше. Это часть философии Agile, поэтому так делают и в Kanban, и в Scrum.
Все задачи проекта, которые предстоит выполнить, складывают в общий список — бэклог. Бэклог — это банк задач проекта. Каждая задача должна быть актуальна. Если потребуется, их можно добавлять в бэклог или удалять из него «на лету».
Каждая задача имеет вес — обычно это время, которое нужно на решение. Команда сама оценивает вес всех задач, поэтому если проект не закончен в срок, виновата команда.
Также у каждой задачи есть приоритет. В Kanban приоритеты расставляет команда, в Scrum — владелец продукта. Приоритеты можно и даже нужно пересматривать по ходу проекта — это один из столпов гибких методологий.
Как работают над проектом
Когда начинается работа, Scrum становится понятно, почему его называют намного более директивной методологией.
Scrum-команда разбивает время работы над проектом на равные отрезки — спринты. Спринт может длиться и день, и месяц, а в последние годы стандартом стал спринт в 2 недели.
Поскольку все спринты одинаковы по длительности, в работе команды появляется ритм. Ритм — важный аспект методологии.
Спринт состоит из четырех последовательных этапов.
В Scrum категорически нельзя добавлять задачи в текущий спринт, поэтому Scrum менее гибок. Даже если появилась срочная и важная задача, она пойдет в работу только со следующего спринта.
В конце спринта недоделанные задачи уходят обратно в бэклог. Нужно ли их доделывать и когда, определяют на этапе планирования следующего спринта.
По сравнению со Scrum-директивами Kanban — это оплот либерализма и хаос.
Спринтов как таковых нет. Проект обычно делят на итерации, но они могут быть любой длины. Ритмичность Kanban не предписывает.
Вспомним этапы scrum-спринта:
В Kanban один этапы не завязаны на другие. Наступают они, когда решит команда. К примеру, релиз — по вторникам, планирование — когда закончились задачи, ретроспективы — каждый последний четверг месяца, а на фоне всего этого непрерывно идет разработка.
Поскольку выраженных спринтов нет, появляются особенности:
Что за доски используют Scrum и Kanban
Доска — это сердце kanban- и scrum-разработки, единственный визуальный атрибут методологий. Доски первым делом вешают на стену, когда хотят показать, что работают по Kanban или Scrum.
Доску используют, чтобы сделать проект прозрачнее, распланировать задачи и поставить ограничения.
Доску расчерчивают на столбцы. Каждый столбец — это состояние задачи («Разработка», «Тестирование», «Релиз»). Количество столбцов зависит от проекта, но чем их меньше, тем лучше.
Карточки — это задачи. На каждой описание, вес и приоритет. Когда задача проходит очередной этап, ее переклеивают в соответствующий столбец. При простом взгляде на доску понятно, как дела с проектом в целом и с каждой задачей.
Доски бывают физические и электронные.
Физическая доска. Часто доска — это действительно доска с клетками из малярного скотча. Задачи — липкие листочки, которые удобно двигать по доске.
Настоящая доска стоит в комнате и каждый в команде видит, как идут дела. Вокруг настоящей доски хорошо собираться во время совещаний.
Электронная доска. Электронная доска под рукой на пляже, на даче, в машине и в метро. Если у вас есть сотрудники, которые работают удаленно, электронная доска — единственный выход.
Я люблю настоящие доски, но без электронных иногда не обойтись.
Scrum — нюансы применения в распределенной команде
Наблюдая за применением Scrum в той или иной команде, я сделал вывод, что этот фреймворк, мягко говоря, не совсем правильно применяют. Несколько лет назад, впервые столкнувшись со Scrum (Скрам), я воспринял все происходящее как какой-то неведомый ранее бардак. Увидев очередной вариант бардака в другой компании, я решил прочитать пару книг по теме, а потом мне повезло попасть в стартап в качестве разработчика, где Скрам реально работал.
Важные книги по Скрам
Важные книги не про Скрам
Скрам не решит всех ваших проблем, полагаясь только на этот метод, можно потерпеть фиаско. Книги, которые помогут в управлении любой командой:
Особенности Скрам
Не буду описывать Скрам, это долго и я только все испорчу. Но отмечу наиболее важные, на мой взгляд, его особенности. Если вы начнете изучение Скрам с прочтения статей в интернете, первое, что вы найдете: в Скрам есть команда из семи человек, Скрам мастер, доска со стикерами и спринты. Да, это характерно Скрам, но не определяет его. Вы можете играть в эту ролевую игру, но Скрама у вас при этом может и не быть.
Первое, на что следует обратить внимание, есть ли у вас обратная связь с конечными пользователями и вносите ли вы изменения в создаваемый продукт с учетом этой информации. Если нет, то будьте уверены, у вас не Скрам.
Второй важной особенность Скрам является такая адаптация продукта к потребностям пользователей, которая позволяет в минимальные сроки выяснить и разработать наиболее востребованный функционал. Известно, что пользователи MS Word в среднем владеют не более чем пятью процентами общего функционала этой программы. Если бы MS Word разрабатывался по Скрам, то этот функционал был бы разработан в первую очередь, в кратчайшие сроки и за гораздо меньшие деньги. Кроме того, финальный продукт довольно часто совершенно не похож на задуманный изначально, и это совершенно нормально.
Третьей важной особенностью Скрам является учет инноваций против показателей тщеславия. Если говорить упрощенно, то показатели тщеславия — это такие, например, как количество новых пользователей, зарегистрированных в единицу времени, или позиция продукта на рынке по объемам продаж, и т.п. Учет инноваций — это оценка эффективности новых фич с точки зрения поддержки этих нововведений конечными пользователями, позитивных либо негативных реакций конечных пользователей. В истории есть множество примеров падения крупных компаний из-за чрезмерного увлечения показателями тщеславия, в то время как их конкуренты вели правильный учет инноваций.
Четвертой особенностью Скрам, является его способность предоставления возможности самореализации членам команды, исключения бесполезной работы, простоев, прожигания жизни.
Еще одной важной особенностью Скрам является его плохая применимость в проектах государственного заказчика. Скрам приводит к многократному сокращению бюджета и сроков выполнения работ, а это неинтересно госзаказчику. Скрам несовместим с коррупцией, свойственной любой власти и любому государству, не совместим с жестким планированием, водопадным подходом, строгим техническим заданием, подробной технической документацией, точными прогнозами по затратам и времени.
Насколько точно надо придерживаться правил Скрам?
Думайте своей головой, не доверяйте слепо людям, каким бы авторитетом они ни обладали. Например, Джефф Сазерленд в своей книге призывает публиковать размеры зарплат членов команды. Серьезно? Публикация зарплат приведет к зависти, обиде, ненависти одних сотрудников по отношению к другим, демотивации и даже увольнению некоторых ценных сотрудников. Большинство компаний запрещают сотрудникам публиковать свою зарплату под страхом увольнения и правильно делают.
Скрам требует открытости всех членов команды перед всеми, которая нужна для непрерывного обмена информацией, кооперации всех членов команды и обмена опытом, взаимопомощи, оперативного устранения проблем совместными усилиями, повышения эффективности команды. Джефф Сазерленд призывает избавляться от сотрудников, не желающих делиться информацией, например, из-за боязни потерять ценность как эксклюзивного носителя знаний, а также избавляться от “токсичных” сотрудников. Слепое руководство этим правилом может привести к потере ценного сотрудника. Надо помнить о том, что гениальные идеи не приходят в голову ко всем сотрудникам, даже если их много и они дружные, но идея выбирает кого-то одного, который был мотивирован конкуренцией за лучшее место под солнцем. Людей много, но чемпионов мира и нобелевских лауреатов единицы. Кто вам нужен в вашей команде, очередной рядовой сотрудник, который ни с кем не конфликтует или чемпион, обеспечивающий конкурентные преимущества вашей компании, пускай даже со сложным характером — решать вам. Простой совет: если у вас есть толковый сотрудник, держите дураков от него подальше и у вас не будет конфликтных ситуаций. Кроме того, обязанностью работать открыто злоупотребляют лодыри и бездельники, которые стараются сесть на шею работягам.
Скрам призывает уничтожать иерархии. Надо понимать, что иерархии неизбежны из-за неравенства людей в образовании, опыте, аналитических способностях, лидерских качествах и пр. Любая стабильная система в природе имеет иерархическую структуру. Даже если компания разрушает иерархии, они будут образовываться самопроизвольно. См. книги о власти, указанные в начале статьи.
Не забывайте о том, что многое, что является вполне естественным и не требующим объяснения для американского читателя, не является таковым для российского. Многие практики, эффективные на западе, совершенно не работают у нас. Это может быть обусловлено, помимо различий в культуре и законодательстве, например, довольно большой властью американского работодателя над работником. Работодатель в США может очень быстро уволить сотрудника, а увольнение там может означать потерю страховки, способности платить по счетам, потери собственности, даже нищите. У нас же увольнение иногда ничего не меняет, да и уволить иногда не удается. Отсюда и разное отношение к работе, компании, начальнику, конкуренции, саморазвитию, корпоративной культуре. Отсюда возникают разное понимание одного и того же текста, разное применение одних и тех же методов.
Доски со стикерами
Не могу пройти мимо этого явления. Если команда находится в одном офисе, может быть это и неплохое решение, поскольку позволяет общаться всем членам команды лицом к лицу. Кроме того, митинги у доски проходят стоя, что должно помогать избегать длинных собраний. Однако, информация, написанная на стикерах от руки плохо читаема и непонятна новым членам команды. К стикеру нельзя приаттачить файл, добавить описание или ссылку. Непонятно на кого назначена та или иная задача. Да, на стикерах можно указать идентификаторы тикетов Jira, но это не решает проблему. Часто можно заметить, что возле доски собирается более 20 человек, при том, что классическая Скрам команда должна иметь в своем составе не более 9 человек. Во время проведения таких собраний образуются небольшие группы сотрудников по интересам или специализации, которые начинают независимые совещания, мешая друг другу. И такие совещания, как показывает практика, не проходят быстро, несмотря на то, что проводятся на ногах. На доске часто можно увидеть вместо трех — пяти столбцов целый десяток и больше. Но самое неприятное в наличии доски — это отсутствие единого источника правды, т.е. существуют одновременно как доска так и dashboard в Jira. Пора прекратить пользоваться досками. Ниже я приведу описание митинга, который подойдет как для офисной, так и для распределенной команд.
Роли членов команды
Роли членов команды могут быть, например:
Вариант команды в реальных условиях
Предположим, у нас небольшой стартап с ограниченным бюджетом, и мы не можем себе позволить по одному или более человеку на каждую роль. Вакансии опубликованы на upwork, собеседования проводят SM и SA. Для найма членов команды вы можете воспользоваться рекомендациями из моей статьи «Онлайн тестирование — вы серьезно?». Сформированная команда состоит из следующих удаленных сотрудников (взято из реального проекта):
Процесс
Каждый день проводится стендап (короткий митинг на 15 минут не более), на котором присутствуют все члены команды. Каждый из членов команды кратко отвечает на два вопроса “над каким тикетом работаю” и “что меня блокирует”. Все митинги проводятся по возможности через Zoom или другую систему, позволяющую видеоконференции с демонстрацией экрана. Для митингов, тренингов и деловых встреч создаются специальные тикеты. Это мотивирует SM к сокращению длительности митингов. Если митинги длятся дольше чем 15 минут, значит SM что-то делает неправильно.
Колонки в проекте в Jira (вариант):
Предположим, что члены команды живут в разных часовых поясах от Екатеринбурга до Чикаго. Оптимальным временем для митинга может быть, например 15:00. SM запускает трансляцию своего экрана через Zoom, открывает dashboard проекта в Jira. Затем SM включает фильтр тикетов како-го либо из членов команды, при этом становятся видны тикеты только этого члена команды.
Этот сотрудник кратко рассказывает о своих тикетах в колонке In Progress и о трудностях, с которыми он сталкивается, о том, что его блокирует. Далее SM переключает фильтр на другого сотрудника. SM следит за тем, чтобы выступления членов команды были короткими. В моем случае я настоял на отдельном тикете для списания времени, потраченного на митинги, и спустя 2 недели SM сильно сократил длительность митингов, посчитав их стоимость. Если у кого-либо возникают вопросы, требующие дополнительного обсуждения, то они обсуждаются на отдельном митинге, время которого определяет SM. Создание любого митинга сопровождается рассылкой приглашения в персональный календарь каждому из участников. Использование календаря избавляет участников от необходимости пересчета времени проведения митинга в локальное время. Выявив и обсудив все проблемы, возникшие на данный момент, SM принимает меры по их устранению, координируя действия всех членов команды.
Разработка ведется поэтапно спринтами по 1 или 2 недели. Результатом каждого спринта является промежуточная версия системы с некоторым новым функционалом (фичами). SM создает, запускает и закрывает спринты.
SA конфигурирует билд и деплой на тестовый стенд из какой-либо ветки Git, которую можно условно назвать dev. Ветка dev заблокирована для прямых коммитов, возможен только Merge request (MR). Разработчик делает MR, если уверен, что качество и завершенность фичи достаточны для использования конечными пользователями. Недоделанные фичи в dev не попадают, MR не создается.
PO и SM согласуют требования, собирают все необходимые материалы в Confluence, создают спецификацию. Гибкие методы отодвигают документацию на второй план. Я сталкивался как с системами, где нет никакой документации, так и с системами, где ее настолько много, что в этом океане информации ничего невозможно найти. Ситуация с обилием документации усугубляется примитивностью поискового движка Confluence. Оптимальным решением является компактная спецификация. Она представляет собою страницу в Confluence, в которой есть схематичное изображение интерфейса (mockup) с отметками и выносками. Под изображением находится описание функционала и поведения каждого элемента, отмеченного на схеме. В тексте есть ссылки на релизы и тикеты в Jira. В нижней части страницы идет обсуждение в комментариях.
Перед началом спринта SA формирует бэклог, создает новые стори и добавляет их в будущий спринт, назначает разработчиков на каждую стори. Разработчики разбивают стори на подзадачи, определяют Estimate (приблизительное прогнозируемое время разработки) в часах и минутах. Полученное суммарное время подзадач определяет количество Story points из расчета 1 Story point = 6 часов. Далее тимлид распределяет стори по разработчикам исходя из расчета 8-12 Story points на разработчика на спринт. SM запускает спринт.
SM следит за тем, чтобы тикеты, имеющие взаимную зависимость, выполнялись своевременно. Например, для того, чтобы запрограммировать фронт, необходимо, чтобы верстальщик предварительно подготовил шаблоны в HTML и CSS, а перед этим дизайнер сделал макет страницы. Таким образом, тикеты должны попадать в работу в такой последовательности, которая позволила бы всем членам команды работать без простоев и взаимных ожиданий.
Перед тем как приступить к разработке новой фичи или исправлению бага разработчик убеждается, что изменения есть в спецификации, если тикет противоречит спецификации, то либо дорабатывается спецификация, либо дорабатывается или отменяется тикет.
Разработчик создает ветку в Git по имени тикета стори, например MVP-123. По завершении каждой подзадачи разработчик записывает в Jira фактическое затраченное время на каждую из подзадач. В качестве TimeSheet рекомендую Tempo. По окончании отчетного периода (2 недели или 1 месяц), разработчик запрашивает утверждение отработанных часов у SM, формирует счет на оплату, отправляет его SM. Когда все задачи в стори готовы, разработчик перемещает все тикеты (стори и подзадачи) в столбец Code review. При этом разработчик создает MR своей ветки в dev, копирует ссылку на него и помещает в комментарии к тикету стори, назначает тикет на ревьювера (сеньора или тимлида). Изменение исполнителя сопровождается его оповещением по электронной почте.
Когда тимлид заметил новые тикеты в Code review он изучает MR и, если находит недостатки, пишет их в комментариях в GitLab, перемещает тикеты назад в столбец In Progress. Разработчик дорабатывает код, добавляет комментарий в GitLab (или в другой системе), нажимает Resolve discussion в комментариях, переносит тикеты в Code review. Особенностью GitLab является невозможность добавления нескольких ревьюверов. Это часто бывает необходимым, если изменения затрагивают, например, как фронт, бек, так и базу данных. В BitBucket такая возможность есть.
Иногда возникают ситуации, когда принимаются несколько MR и они конфликтуют. Разрешать конфликт должен разработчик, создавший MR последним. Он объединяет ветку dev со своей текущей и устраняет конфликты, делает дополнительный коммит.
В некоторых ситуациях, многочисленные MR, даже в случае удачного слияния, приводят к невозможности сборки или невыполнимости части unit тестов. Иногда это становится известно после того, как одна из сред перестала работать, что блокирует, например, QA. То есть тимлид может провести ревью и принять MR, но это не гарантирует успешность сборки или выполнения unit тестов. Для решения этой проблемы, например, в GitLab есть возможность настройки Development Pipeline. По сути это автоматическая сборка и тестирование коммита, который указан в MR. Код ревью выполняется только после успешного выполнения Development Pipeline. Если Development Pipeline “падает” с ошибкой, разработчик, сделавший MR, устраняет ошибку и делает дополнительный коммит.
Тимлид принимает код и принимает MR, при этом происходит автоматическая сборка и деплой на тестовый сервер. Тимлид переносит код в столбец QA.
QA приступает к тестированию новых изменений в соответствии со спецификацией. QA создает программы ручного тестирования. В случае неудачного тестирования, тикет переводится в столбец In Progress — возвращается на доработку, либо создается баг-тикет в Jira, который SM назначает на какого-либо из разработчиков. После того, как тестирование завершено успешно, тикеты переводятся в Demo ready и, впоследствии, фича демонстрируется на еженедельном Demo митинге. Если фича принимается, тикет переводится в Done.
В случае, если задачи не завершены к окончанию спринта, они переносятся на следующий спринт.
PO и SM определяют набор фич (стори), которые попадут в тот или иной релиз, планируют дату релиза. Перед релизом QA осуществляют регрессионное тестирование. В момент релиза создается специальная ветка в Git и замораживается для изменений. Изменения релизов возможны в исключительных случаях и производятся через бэкпорты. Бэкпорт — специальный процесс внесения изменений в релизные ветки. В некоторых компаниях для бэкпортов создаются специальные команды.
По окончании каждого спринта проводится Retrospective митинг, на котором обсуждается все проблемы, накопившиеся за спринт, определяются проблемы и препятствия, которые задерживают процесс разработки, принимаются решения о способах устранения препятствий. Для ретро заводится специальная страница в Confluence, в которой записывается: что мы делаем, что мы начинаем делать и что мы прекращаем делать.
Что необходимо для работы (вариант)
Учет времени
Хороший разработчик любит свое дело, стремится повысить свои скилы, выкладывается полностью. Мозг молодого человека можно сравнить со свежим ивовым прутом. Со временем прут, который вплели в корзину, теряет свою эластичность и способность принять прежнюю форму или любую другую. Мозг тоже гибок и эластичен пока молод. Немногим людям удается поддерживать гибкость своего мозга на протяжении всей жизни и практически у всех период наибольшей активности, восприимчивости приходится на молодые годы. Именно по этой причине важно подвергать свой разум наибольшим нагрузкам в раннем возрасте, поскольку развиваться в зрелом возрасте будет сложнее. Именно по этой причине в первой половине своей карьеры надо пахать практически на износ, независимо от размера вознаграждения.
Хороший разработчик Self motivated (самомотивирован), стремится сделать больше в единицу времени, опережая estimate сроки, повышать свой авторитет, увеличивать шансы стать сеньором, тимлидом, иногда шансы на получение опциона. Он активен, генерирует идеи, непрерывно изучает новые технологии, дорожит своим временем. Если в команде не отлажены процессы и разработчик простаивает без задач, если разработчик выполняет работу, которая никому не приносит пользы, если работа никак его не развивает, то он начинает ощущать, что тратит драгоценное время своей жизни впустую. Как результат, он уходит на другой проект. Скрам позволяет разработчику избежать прожигания жизни, помогает самореализоваться, ощутить свою причастность к важному делу.
В некоторых командах учет времени не ведется и разработчики не списывают часы, получая фиксированную зарплату. В некоторых компаниях часы учитываются, но как обоснование фиксированной зарплаты, т.е. разработчик должен отработать и списать, например, не меньше 40 часов в неделю. Бывают компании (или проекты), в которых оплата почасовая, и разработчик получает ровно столько сколько заработал в соответствии со стоимостью его часа. Некоторые компании практикуют почасовую оплату, но требуют использования трекера времени на компьютере удаленного разработчика, который не просто считает время, но и отсылает скриншоты, скринкасты и различные параметры активности разработчика.
Какой способ лучше? В каждом конкретном случае лучшим может быть любой из перечисленных или какой-то еще. Но я отдаю предпочтение почасовой оплате без использования трекера времени и далее я объясню почему. Отсутствие учета времени считаю вредным, поскольку может привести к ощущению ненужности вклада в общее дело, даже бесполезности участия в проекте. Учет времени, наоборот, добавляет ощущение важности и востребованности выполняемой разработчиком работы, помогает определить собственный темп, мотивирует к повышению собственной эффективности. Хочу обратить внимание на то, что разработчику важно, чтобы его труд оценивали не только по скорости выполнения задач, но и по качеству. Обязательно нужен человек, руководитель, который может оценить вклад разработчика. К сожалению, на многих проектах никого не интересует ни что делает разработчик, ни как он это делает, ни насколько быстро.
Иногда бывает, что скорость разработчика оценивается путем сравнения предварительно оцененного времени и фактически затраченного. То есть если разработчик опережает оценки, то его поощряют и наоборот. Считаю, что такая оценка должна использоваться как неточная, ориентировочная, второстепенная. Предварительная оценка времени (estimate) может быть сделана только приблизительно. Более точная оценка может быть сделана только в том случае, если подобные задачи решались многократно, однако повторяющиеся задачи встречаются нечасто. Даже обладая большим опытом и высокой точностью прогнозирования времени выполнения, вы не будете застрахованы от неожиданностей. Например, применение многократно использованной в других проектах библиотеки, оказало непредсказуемое влияние на систему, причем баг проявляется во время выполнения, и логи ни о чем не говорят. Если нет готового решения на StackOverflow, можно превысить Estimate в несколько раз. Надо понимать, что Estimate — это грубая оценка, которая может использоваться как ориентир. Превышение разработчиком Estimate, и если оно не является систематическим, не должно приводить к критике со стороны руководства.
Как правило, фактически затраченное время всегда меньше Estimate. Если задачи сложные и разработчик видит, что для решения потребуется провести небольшое исследование, он может указать Estimate с запасом, но он не должен злоупотреблять этим.
SM или тимлид, или кто-либо еще в команде должен оценивать реалистичность Estimate. Это может сделать только опытный разработчик, обладающий, к тому же, доверием руководства.
Пусть удаленный разработчик оценил задачу в 2 часа, а выполнил ее за 1 ч 33 мин и записал это фактическое затраченное время в Tempo, перевел тикет в Code review и взял в работу следующий. Возникает вопрос, можем ли мы доверять разработчику, ведь он мог сделать эту задачу за 15 минут, а остальное время уделить онлайн играм или даже другим проектам? Ответ — да, можем доверять. Самое главное, на что должен обращать внимание SM, являются ли сотрудник эффективным, являются финансовые затраты на сотрудника приемлемыми в единицу времени. Обеспечивается ли такая скорость команды, которая позволит запустить MVP до окончания взлетной полосы стартапа. Во-первых, точные временные затраты на выполнение той или иной задачи да еще и при заданном уровне качества просто физически невозможно определить. У одного разработчика уйдет на это 2 часа, а у другого 15 минут, поскольку многое зависит от опыта и способностей. Кроме того, в любом проекте есть старожилы и новички. Старожил найдет решение за считанные минуты, в то время как новичок может потратить несколько дней на исследования. Во-вторых, разработчик может искать решение не только в момент написания кода, но и в любое нерабочее время. Идея может посетить человека совершенно неожиданно и в любой момент. Оценивать качество полученной идеи и ее реализации простым учетом времени, потраченного на кодирование, неэффективно. Это одна из причин низкой эффективности применения трекеров времени — разработчик работает не только в момент непосредственного написания кода. Ко всему, трекеры времени вносят элемент недоверия, превращают творческий процесс в каторгу.
Если SM не уверен в правдоподобности фактически списанного на задачу времени, он может заглянуть в GitLab и сопоставить изменения кода, сделанные по этой задаче, со списанным временем. Разработчик не может списать 2 часа за 2 строчки кода. Если SM не разбирается в программировании, он может пригласить эксперта для оценки реалистичности списанного времени, например SA. Как бы тами ни было, адекватный разработчик не будет списывать лишнее время, поскольку понимает, что реалистичность может быть проверена, а испорченную репутацию и доверие потом не восстановить.
Вернемся к разработчику, который выполнил задачу за 1 ч 33 мин и приступил к следующей. При этом, он списал за первую задачу 2 ч как было в Estimate. SM сможет легко определить, что интервал времени между переводом задачи в статус In Progress и Code review существенно меньше, чем списанное время. То есть факт приписки может быть легко установлен, обращать внимание разработчика на этот факт или нет, SM определяет сам. Конечно, разработчик может переводить задачи в те или иные статусы в точном соответствии со списанным временем, несмотря на то, что он не работал так много. Или он может переводить в In Progress сразу несколько тикетов, чтобы время начала работ было как можно более ранним — надо договориться о последовательном переводе тикетов в работу. В любом случае, не стоит беспокоиться! Напомню, для SM намного важнее польза, которую этот человек приносит за потраченные на него деньги в единицу времени. SM в любой момент может исключить любого члена команды из проекта, но это может привести к непредвиденным затратам на поиск и адаптацию нового члена команды, взятого взамен уволенному.
SM также может обратить внимание на то, что затраченное время всегда или почти всегда совпадает с Estimate. Для SM это звоночек, закрывать на это глаза или нет, решать ему в зависимости от ситуации.
В некоторых случаях, стремясь поддержать разработчика, руководство повышает ему стоимость часа. Это необходимо делать очень осторожно, поскольку может возыметь обратный эффект, когда разработчик начнет работать меньше. Он увидит, что те же деньги можно заработать с меньшими усилиями, а освободившееся время потратить на что-либо другое. Следите за стоимостью услуг на рынке труда, оставаясь конкурентоспособным работодателем, подходите индивидуально, будьте внимательны.
Финансовые отношения
Оплата труда должна быть как можно более справедливой и должна мотивировать сотрудников к повышению производительности. Почасовая оплата является наиболее подходящей для этого. Работодатель должен оплачивать любые трудозатраты сотрудников. Даже если сотрудник проработал всего один день и результаты его труда оказались бесполезными, необходимо оплатить его время. Репутация работодателя является одним из важнейших активов. Если работодатель не выплачивает зарплату или выплачивает ее с большими задержками, это может привести к большим репутационным издержкам, а в некоторых случаях парализовать найм новых сотрудников.
Некоторые работодатели задерживают зарплату до тех пор пока тикеты, выполненные разработчиком, например, не пройдут тестирование. В некоторых случаях разработчику предлагается исправить баг новой фичи за свой счет. Все это происходит по той причине, что работодатели не понимают применимость того или иного способа оплаты услуг в разных ситуациях. Задержка оплаты и устранение недостатков за свой счет допустима при сдельных работах, услугах, оказываемых юридическими лицами по контракту, когда есть техническое задание и сроки. Но и бюджет при этом намного больше. Если вы нанимаете сотрудников в свою команду на полный день или даже на неполный, никогда не задерживайте зарплату. Если сотрудник не устраивает, то увольте его, но не пытайтесь воспитывать или наказывать человека задержками зарплаты за некачественно выполненную работу. Платите сотруднику с момента приема на работу до момента увольнения и без малейших задержек. Это должно быть золотым правилом компании, поскольку его невыполнение неизбежно приводит к тяжелым для компании последствиям.