[Управление разработкой, Agile] Мой опыт в самоорганизующейся команде
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет! Я хочу рассказать про свой опыт в самоорганизующейся команде. За полтора года в ней было от 3 до 5 разработчиков, я не занимался их наймом, но все процессы и разработку построил с нуля. Расскажу, что такое самоорганизующаяся команда, какую пользу она приносит для компании, команды, и ее участников.Самоорганизующаяся командаВ команде нет разделения на специализации, роли и кого-либо кроме разработчиков. Нет отдельных людей на клиент (front-end), сервер (back-end), инфраструктуру, тестирование, управление проектами. Каждый разработчик участвует в каждой итерации цикла разработки программного обеспечения: получение задачи, прояснение требований, написание кода, тестирование, развертывание, мониторинг, поддержка.Команда сама выбирает технологии, занимается их исследованием (насчет релевантности, например), внедрением и поддержкой — Go или Python, Jenkins или Github Actions, нужен ли Kubernetes. Составление бэклога, приоритизация задач и подзадач, распределение задач между участниками команды, митинги, ретроспективы — ответственность команды.В задачи руководителя команды входит: мотивировать и заботиться об участниках, убирать препятствия на пути команды, улучшать процессы. Еще о процессахХочу описать процессы, которые не относятся напрямую к самоорганизующимся командам, но относятся к командам вообще. Но их было в разы быстрее, эффективнее и приятнее настраивать и соблюдать именно в самоорганизующейся команде.В команде не было ежедневных митингов по рабочим моментам и ретроспектив. Я стремился сделать разработку прозрачной и документированной, как будто мы на удаленной работе без возможности созвониться, даже находясь в офисе. Описание пулл реквестов с объяснениями и примерами, документация процессов, инструментов, технологий и гайдов.Не было 1-to-1 митингов, хотелось иметь мгновенную обратную связь. О том, что кому-то что-то не нравится или нравится — было правило сообщать сразу, не только руководителю команды, а и всем ее участникам.Тоже самое с дедлайнами и эстимейтами — только когда это действительно необходимо, ведь работа делается за весь отведенный на нее срок.Для постановки задач нет отдельного человека, либо это звонок с командой, либо сообщение в соответствующий канал связи (почта, чат) на всех участников команды.Классно иметь модель ветвления по типу Trunk-based, когда код сразу попадает на сервера, нет отдельных веток для пред-master (develop) и релизов как это предусматривает GitFlow Workflow. У нас была одна ветка master, если пулл реквест смерджился, значит, тесты написаны, функциональность проверена на deploy preview (feature branch, review app) — ничего не затягивается. Один пулл реквест — один коммит в master — один релиз.ПлюсыДля разработчика быть в такой команде значит:
- заниматься разными задачами, используя разные технологии в разных областях, а это не скучно и развитие в ширину,
- приобретается понимание всего цикла разработки программного обеспечения,
- растет ответственность за проделанную работу, так как работа не «скидывается» на других людей на промежуточных этапах (тестирование, развертывание, мониторинг).
Для команды и компании:
- каждый может поучаствовать в прояснении требований к задачам, технических и архитектурных решениях, что привносит видение ситуации с разных сторон,
- нет проблем с отпуском, больничным, увольнением и уходом, так как нет задач или участков программного обеспечения, в котором разбирается только один разработчик,
- нет проблем с переходом на удаленную работу команды, если это необходимо.
МинусыНе всем разработчикам комфортно в самоорганизующейся команде, кому-то не интересно развиваться в ширину, кто-то привык к меньшей ответственности на работе. Ценности при разработке, от банального стиля кодирования, до инструментов и технологий. Чем больше зона ответственности у разработчика, тем больше у него убеждений на тот или иной счет. Ценности конфликтуют в любых командах, особенно в начале разработки. А в самоорганизующихся и подавно, ведь спектр задач и технологий у каждого из разработчиков шире. Конфликты и недопонимания неизбежны, важно находить win-win решения (либо компромиссы), открыто решать проблему, чтобы ни у кого не оставалось обиды за спиной. Непривычно для менеджмента и бизнес-людей — они привыкли к общению по задачам и прогрессу только с руководителем команды. ВыводЯ сделал следующий вывод для себя:
- мне комфортно так работать,
- мне нравится когда участники команды разносторонне развиваются и получают удовольствие от процессов и работы,
- мне нравится когда на каждом участнике команды лежит одинаковая ответственность, это сплачивает и приносит результат.
Спасибо за внимание, буду обновлять статью, если что-то забыл упомянуть. Если у вас есть вопросы или вы хотите что-то обсудить, жду в комментариях или личных сообщениях.
===========
Источник:
habr.com
===========
Похожие новости:
- [Управление разработкой, Управление персоналом, Интервью] Профессия СТО часть 2
- [Управление разработкой, Развитие стартапа, Управление продуктом, Управление персоналом] Расширение технической команды в растущем стартапе: проблемы и решения
- [Профессиональная литература, Agile] Книга «Еще более эффективный Agile»
- [Интерфейсы, Управление проектами, Agile, Дизайн] Эстимирование дизайна
- [Управление продуктом, Управление персоналом, Карьера в IT-индустрии] Маленькие задачи, а доверия ещё меньше (перевод)
- [IT-инфраструктура, Git, Управление разработкой, DevOps] Как в MGA в 5 раз быстрее реализуют проекты при помощи GitLab
- [Agile] Кристиан Вервейс: О сложности или зачем вам Скрам? (перевод)
- [Программирование, Венчурные инвестиции, Развитие стартапа, Управление продуктом, Карьера в IT-индустрии] Software Engineer + Product Manager = Product Engineer?
- [PHP, Symfony, Управление разработкой, Управление проектами] У Вас проблемы с legacy — значит, Вам повезло! Распил монолита на PHP
- [Управление разработкой, Карьера в IT-индустрии] Профессионализм разработчика — на шаг ближе к счастью
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_agile, #_agile, #_samoorganizujuschiesja_komandy (самоорганизующиеся команды), #_upravlenie_razrabotkoj (управление разработкой), #_upravlenie_razrabotkoj (
Управление разработкой
), #_agile
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 20:26
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Привет! Я хочу рассказать про свой опыт в самоорганизующейся команде. За полтора года в ней было от 3 до 5 разработчиков, я не занимался их наймом, но все процессы и разработку построил с нуля. Расскажу, что такое самоорганизующаяся команда, какую пользу она приносит для компании, команды, и ее участников.Самоорганизующаяся командаВ команде нет разделения на специализации, роли и кого-либо кроме разработчиков. Нет отдельных людей на клиент (front-end), сервер (back-end), инфраструктуру, тестирование, управление проектами. Каждый разработчик участвует в каждой итерации цикла разработки программного обеспечения: получение задачи, прояснение требований, написание кода, тестирование, развертывание, мониторинг, поддержка.Команда сама выбирает технологии, занимается их исследованием (насчет релевантности, например), внедрением и поддержкой — Go или Python, Jenkins или Github Actions, нужен ли Kubernetes. Составление бэклога, приоритизация задач и подзадач, распределение задач между участниками команды, митинги, ретроспективы — ответственность команды.В задачи руководителя команды входит: мотивировать и заботиться об участниках, убирать препятствия на пути команды, улучшать процессы. Еще о процессахХочу описать процессы, которые не относятся напрямую к самоорганизующимся командам, но относятся к командам вообще. Но их было в разы быстрее, эффективнее и приятнее настраивать и соблюдать именно в самоорганизующейся команде.В команде не было ежедневных митингов по рабочим моментам и ретроспектив. Я стремился сделать разработку прозрачной и документированной, как будто мы на удаленной работе без возможности созвониться, даже находясь в офисе. Описание пулл реквестов с объяснениями и примерами, документация процессов, инструментов, технологий и гайдов.Не было 1-to-1 митингов, хотелось иметь мгновенную обратную связь. О том, что кому-то что-то не нравится или нравится — было правило сообщать сразу, не только руководителю команды, а и всем ее участникам.Тоже самое с дедлайнами и эстимейтами — только когда это действительно необходимо, ведь работа делается за весь отведенный на нее срок.Для постановки задач нет отдельного человека, либо это звонок с командой, либо сообщение в соответствующий канал связи (почта, чат) на всех участников команды.Классно иметь модель ветвления по типу Trunk-based, когда код сразу попадает на сервера, нет отдельных веток для пред-master (develop) и релизов как это предусматривает GitFlow Workflow. У нас была одна ветка master, если пулл реквест смерджился, значит, тесты написаны, функциональность проверена на deploy preview (feature branch, review app) — ничего не затягивается. Один пулл реквест — один коммит в master — один релиз.ПлюсыДля разработчика быть в такой команде значит:
=========== Источник: habr.com =========== Похожие новости:
Управление разработкой ), #_agile |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 20:26
Часовой пояс: UTC + 5