hh и в продакшн: как выпустить новую фичу

[shamyyl]

А какие этапы проходят задачи, чья реализация займет очевидно меньше времени, чем весь описанный выше процесс?
Например, мобильный разработчик попросил добавить +1 поле в возврате api-метода.

[shurik2533]

Для небольшого изменения иногда достаточно завести отдельную задачу. Ревью и прогон автотестов обязательны.

Хотя конкретно в случае с " +1 поле в возврате api-метода" это уже как минимум 3 задачи: документация, задача в API, доработка автотестов

[Aleksei_Mikhailov]

Александр, спасибо, что поделились реальным опытом!
Особенно понравилось описание инструментария при планировании: просто о майках и покере на примерах из жизни :-)

Вы упомянули, что:

Декомпозиция — это трудоёмкий процесс. Именно он определяет этапы работы над новой фичей. Он требует знания архитектуры дорабатываемой системы и понимания протекающих процессов.

Речь о совокупности описанных и доступных для команды регламентов и процедур или же это, например, знание опытного сотрудника? А как тогда ваша команда избегает бас-фактора в таких ценных знаниях?

[shurik2533]

Это скорее про знания опытного сотрудника. В нашем случае не так много мест, где нужны сакральные знания. Во всех процессах можно разобраться. Кроссфункциональность в команде, техналоги, ревью, культура обмена знаниями между командами, помогают увеличить автобусное число. Обычно опыта остальных членов команды достаточно, чтобы передать знания новому сотруднику. Конечно, что-то всегда приходится делать в первый раз и требуется время, чтобы разобраться

[Tirex]

Ну т.е. декомпозицию задачи чаще всего делает один и тот же самый опытный сотрудник (тим лид)? Или эта обязанность ротируется между членами команды?

[shurik2533]

Тимлид делает это чаще. В последнее время мы стараемся, чтобы остальных членов команды тоже не обделяли

[ArVaganov]

Интересно, а бывало такое, что на пятом этапе заказчику не нравится работа и фича возвращается на этап разработки? Должны же быть демонстрации каких-то промежуточных вариантов.
PS: Футболки очень классные :). Немного юмора никогда не повредит

[shurik2533]

Я такого не припомню. Предже, чем задача пойдет в разработку, она тщательно прорабатывается и на выходе у всех есть картина того, что будет. Бывает, что что-то было упущено из виду и нужно доработать. Если новый продукт имеет большой объем, то он обычно делится на этапы, которые можно выпускать отдельно и каждый из них может демонстрироваться

[serpinar]

В разных командах разные заказчики, иногда риск непонимания задачи действительно есть. Случаев полного несовпадения ожидания и реальности я не припоминаю, обычно фичей все же можно пользоваться. Чтоб избежать таких ситуаций — делаем демо до выхода на прод (при помощи тех же тестовых стендов). Если есть возможность — делаем прототипы «на коленке» чтоб показать свое понимание решения заказчику как можно раньше.

Стараемся чаще встречаться с заказчиком, обсуждать возникающие вопросы.

[feligz]

Менеджер проектов как интерфейс, забавное сравнение )). Если команд 17, то и МП тоже 17? Бывшие технари в основном?

[shurik2533]

У одного МП несколько команд. В моей команде бывший технарь, да. За остальных не знаю.

[nefone]

А чем отличается фича от бага?

[shurik2533]

Баг — это нежелательное поведение или отсутсвие поведения вообще

[Matisumi]

Как много лишних шагов! Всегда старался избегать компаний, использующих kanban/agile/etc

[shurik2533]

В компании, где много кода, много сотрудников, поддерживающих его и высокие требования к отказоустойчивости без «лишних шагов» никак не обойтись. Иначе в итоге получится кривой, неподдерживаемый монстр, в котором в итоге время на работу с наделанными косяками превысит время, затраченное на «лишние шаги».

[Tirex]

Спасибо за интересную статью.
Появилось несколько вопросов.
1. Как накатаываете изменения по базы данных? Миграции есть?
2. Как откатываете изменения в базе если что-то пошло не так?
3. Где почитать про ваш технологический стек?
4. Статья по релиз без вмешательства человека будет? Особенно интересен момент с изменениями в базе.

[shurik2533]

1. Если меняются только данные, то скрипт прицепляется к задаче в jira и выполняется, в которой, например, меняется связанный с этими данными код. А если нужно поменять структуру таблиц, то заводится задача в отдельном репозитории для бд. Обязательно пищется rollback-скрипт. Важное правило изменений в БД — они должны быть обратно совместимы и изменение происходит поэтапно. Например, если мы хотим использовать новую колонку в БД вместо старой:
— создаем в базе новую колонку, код пока работает на старой
— обеспечиваем, чтобы данные совпадали в обеих колонках
— переключаем код на новую колонку
— дропаем старую колонку
2. Если в базе что-то пошло не так, то выполняется rollback-скрипт
3. Я не нашел статей на эту тему. Надеюсь, что в скором времени это будет исправлено
4. Мне бы тоже хотелось видеть такую статью. Надеюсь, коллеги обратят на это внимание и напишут

[hardtop]

картинка «hh — и в продакшн» — это очень круто!

[shurik2533]

В нашей команде проводит и модерирует планирование чаще всего тимлид. А рассказывает о задачах тот, кто проводил декомпозицию

[baskins]

Приглашаются заказчик, другие заинтересованные лица и опционально все желающие и проводится небольшая презентация по проделанной работе и даются ответы на вопросы. После портфель в джире переводится на заказчика, чтобы тот оставил фидбэк о проделанной работе. На этом жизненный цикл портфеля заканчивается.

Как добились активного участия бизнес заказчика?
Как правило, им до фени ваш канбан, дайте фичу и лучше вчера

[shurik2533]

Например, у нас заказчик — команда мобильной разработки. Они заинтересованы в фиче. Им это потом использовать и делать заказы у нас ещё. Мне кажется этого достаточно, чтобы принимать участие.