В репрессивной модели управления лидер будет, как правило, подбирать сотрудников либо глупее себя, либо таких, которых он может «загипнотизировать» или шантажировать тем или иным образом. Тут ищут «псов», которыми легко управлять и которыми легко травить. Спускаемые сверху идиотские указания будут без изменений проксироваться вниз и те, кто сможет проксировать их ниже — выживают, остальные лопаются. habr.com/post/124716Все ли так плохо с тим-лидерством? Навязывать ли скрам формально, когда его потребность никто не понимает, и она не особо ощущается, или вводить его элементы постепенно, чтобы команда почувствовала его эффективность.
Конфликты интересов частая ситуация в рабочих коллективах и не только в программистских. И зачастую нет правых и виноватых, есть столкновение опыта и видений. Как раскрыть потенциал всех сотрудников и получить синергию, когда 1+1 = 11, а не 2.
Навеяло после футбольного чемпионата мира по футболу. История вывода на колею скрама. Все события вымышлены, все совпадения случайны. Обобщенная и сильно упрощенная ситуация.
Итак, команда сформирована, аналитик, фронтендер, фуллстек-бекендер. Не скрам. Команда сформирована с достаточно грамотным и разносторонне развитым и опытным тимлидером, который имеет широкие полномочия. Руководство компании делегирует ему полную власть.
Для аналогии, представим, что проект — это лига по футболу. всей команды с фейлом, то есть неудавшимся или надолго затянувшимся проектом. Успехом считается качественно выполненный и вовремя сданный продукт, то есть верхнее положение команды в чемпионате по результатам всех игр. Игры — это спринты. Спринт — итерация в скраме, в ходе которой создается рост программного обеспечения. Жестко фиксирован по времени, как и матч в футболе. Обзор первого матча (спринта), ситуация вполне реальная.
Начало работы на проектом (Первый тайм, все идет хорошо, гол счет 1 — 0)
Итак свисток, и достаточно опытные в индивидуальном плане игроки, но не сыгранные вместе, очень хорошо делают свое дело. Аналитик ставит задачи, фронтендер делает приложение на моковом бекенде. По началу все идет хорошо, верстка, архитектура проекта, быстро создаются страницы, заказчик быстро получает результаты, команда получает от него обратный фидбек. Все довольны.
Бекенд развивается отдельно, строится архитектура, закладывается база данных, прокидываются примерные методы.
Неклиентоориентированный бекенд (Опасный момент, гол, передачи плохо проходят в среднюю зону, 1 — 1)
Аналитик проявляя очень хорошие индивидуальные качества, передает задачу команде, экран и описание.
Фронтендер, получает пас, верстает форму, пишет клиентский код, передает пас фулстеку-бекендеру. И ожидает что то вроде:
GET /some/method
Фуллстек-бекендер(капитан команды, он же тим-лид) принял пас и отдает:
Как правило, фуллстеки имеют неглубокие знания в областях (просто по причине того что физически не могут все охватить глубоко), но видят весь проект в целом. Они хороши на небольших проектах, где все делают сами, и в командной разработке неэффективны.
Возникла пауза и недоумение, на вопрос почему так, молчание и игнор, тим-лидер знает что делает. При повторных таких передачах и последующих вопросах, почему так. Ответ: «Доверся мне, я знаю, что делаю, у тебя нет видения системы в целом». Пока ничья 1-1. И ничего тут сделать нельзя, ни фронтендеру, ни руководству.
Слабое командное взаимодействие (Опасный момент, гол, 2-1 факап ведет)
Фронтендер думает и напрягается. Что нужно прокинуть на экран? Переспрашивает, но взаимодействие не клеится. Тим-лидер-фуллстек-бекендер нервничает, сыпяться ответы. «Думай!». «Мне проще самому сделать», «Пипец». Игра не клеится, команда пропускает второй гол.
Усиление средствами командной разработки (Время идет не в пользу команды, 2-1 счет прежний)
Фронтендер понемногу догадываться о параметрах, научился предугадывать направление паса, но все равно был брак в игре. Фронтендер плохо воспринимает все на слух, и просит средства командной разработки (Redmine, Jira, Trello). Руководство идет на встречу. Начали ставится задачи, типа:
Приветствие -> ??? (какое поле взять из данных)
Параметр1-> ??? (какое поле взять из данных)
Параметр2 -> ??? (какое поле взять из данных)
Данные для ясности чистятся прямо приходу из бекенда и в понятном виде прокидываются в html. Игра стабилизировалась, но уходит время, счет прежний в пользу факапа.
Травма, рефакторинг кода, (Команда отыгрывается, но и пропускает гол 3-2)
Фронтендер получает травму и покидает поле на некоторое время (запланированный отпуск), в это время бекендер, залезает в код фронта, тратит время на его рефакторинг, и героически распутывает данные из бекенда прямо в html. Быстрый гол, здорово! Но в ответ получает баги от аналитика и невыполненные задачи по текущему спринту. Да… команда быстро получила ответный гол. Бекендер попадает список лучших бомбардиров. Фронтендер быстро восстановился и снова в игре. Но так как пасы не идут, а тим лид сам справляется, то фронт пока не сильно задействован. Финальный свисток, матч окончен. 3-2 команда проиграла, но впереди следующие игры (спринты).
Ретроспектива спринта (Анализ первой игры, фронтендер на скамейке запасных)
В скраме для выявления проблем на ранних этапах и гибкой самонастройки команды, проводятся ретроспективы спринтов, которые проводит скрам-мастер (тренер команды), но так как его нет в клубе. Фронтендер инициирует ее. Собирает всех участников, и объясняет ошибочность от отказа игры в пас, так как один момент не может улучшить игру команды на протяжении всего чемпионата (окончания проекта), и просит высказаться всех членов команды. В ответ капитан команды — тимлид — фуллстек, предлагает перевести фронтендера на другой проект, так как мнения игроков никого не волнуют. Команда молчит — руководство клуба тоже. Трансфер пока затянулся, фронтендер завис на скамейке запасных.
Как действовать руководству клуба? Тим лидер или скрам мастер? Открытые обсуждения, высказывание мнений или единоличные приказы тим лида. На самом деле тут нет правильного ответа. Для прояснения ситуации нужно ввести тестировщика и посмотреть на игру в еще нескольких спринтах. Все зависит от размеров проекта.
Эпилог (прошло время):
Большое спасибо за комментарии!
Что наша жизнь? Игра…
Добрый вечер, в интеллектуальном клубе Что? Где? Когда? Единственном месте где каждый телезритель может заработать деньги своим собственным умом…
Итак, тишина в зале.
Уважаемые знатоки (скрама). Еще раз обращаю внимание, что в статье в самом начале было акцентировано четко, что то, что делала команда — это не скрам, а описана лишь попытка вывода на скрам.
Скрам как покер, у него очень простые, но очень жесткие правила. Но в тоже время покер и скрам — очень сложные игры.
Теперь, внимание правильный ответ.
В процессе работы было нарушено очень простое и базовое правило скрама. Ролей в скраме немного и они четко прописаны. Там нет роли под названием тимлид. Задача скрам-мастера четко следить за выполнением этого правила. И пресекать любые попытки его нарушить. Итог, хаос из бекенда перешел на фронт и проект зафакапился.
Scrum — фреймворк гибкой разработки ПО. Фреймворк основан на эмпирическом методе (основанном на опыте) и предназначен для разработки продуктов ВЫСОКОЙ ценности в ЗАПУТАННОЙ среде. ru.wikipedia.org/wiki/Scrum
Раунд. 1:0 — в пользу телезрителей. Знатоки уходят на музыкальную паузу… И готовятся к следующему раунду.
