Comments 22
А какие этапы проходят задачи, чья реализация займет очевидно меньше времени, чем весь описанный выше процесс?
Например, мобильный разработчик попросил добавить +1 поле в возврате api-метода.
Например, мобильный разработчик попросил добавить +1 поле в возврате api-метода.
0
Александр, спасибо, что поделились реальным опытом!
Особенно понравилось описание инструментария при планировании: просто о майках и покере на примерах из жизни :-)
Вы упомянули, что:
Речь о совокупности описанных и доступных для команды регламентов и процедур или же это, например, знание опытного сотрудника? А как тогда ваша команда избегает бас-фактора в таких ценных знаниях?
Особенно понравилось описание инструментария при планировании: просто о майках и покере на примерах из жизни :-)
Вы упомянули, что:
Декомпозиция — это трудоёмкий процесс. Именно он определяет этапы работы над новой фичей. Он требует знания архитектуры дорабатываемой системы и понимания протекающих процессов.
Речь о совокупности описанных и доступных для команды регламентов и процедур или же это, например, знание опытного сотрудника? А как тогда ваша команда избегает бас-фактора в таких ценных знаниях?
0
Это скорее про знания опытного сотрудника. В нашем случае не так много мест, где нужны сакральные знания. Во всех процессах можно разобраться. Кроссфункциональность в команде, техналоги, ревью, культура обмена знаниями между командами, помогают увеличить автобусное число. Обычно опыта остальных членов команды достаточно, чтобы передать знания новому сотруднику. Конечно, что-то всегда приходится делать в первый раз и требуется время, чтобы разобраться
+1
Интересно, а бывало такое, что на пятом этапе заказчику не нравится работа и фича возвращается на этап разработки? Должны же быть демонстрации каких-то промежуточных вариантов.
PS: Футболки очень классные :). Немного юмора никогда не повредит
PS: Футболки очень классные :). Немного юмора никогда не повредит
0
Я такого не припомню. Предже, чем задача пойдет в разработку, она тщательно прорабатывается и на выходе у всех есть картина того, что будет. Бывает, что что-то было упущено из виду и нужно доработать. Если новый продукт имеет большой объем, то он обычно делится на этапы, которые можно выпускать отдельно и каждый из них может демонстрироваться
+1
В разных командах разные заказчики, иногда риск непонимания задачи действительно есть. Случаев полного несовпадения ожидания и реальности я не припоминаю, обычно фичей все же можно пользоваться. Чтоб избежать таких ситуаций — делаем демо до выхода на прод (при помощи тех же тестовых стендов). Если есть возможность — делаем прототипы «на коленке» чтоб показать свое понимание решения заказчику как можно раньше.
Стараемся чаще встречаться с заказчиком, обсуждать возникающие вопросы.
Стараемся чаще встречаться с заказчиком, обсуждать возникающие вопросы.
+2
Менеджер проектов как интерфейс, забавное сравнение )). Если команд 17, то и МП тоже 17? Бывшие технари в основном?
0
А чем отличается фича от бага?
+1
Как много лишних шагов! Всегда старался избегать компаний, использующих kanban/agile/etc
-3
В компании, где много кода, много сотрудников, поддерживающих его и высокие требования к отказоустойчивости без «лишних шагов» никак не обойтись. Иначе в итоге получится кривой, неподдерживаемый монстр, в котором в итоге время на работу с наделанными косяками превысит время, затраченное на «лишние шаги».
+5
Спасибо за интересную статью.
Появилось несколько вопросов.
1. Как накатаываете изменения по базы данных? Миграции есть?
2. Как откатываете изменения в базе если что-то пошло не так?
3. Где почитать про ваш технологический стек?
4. Статья по релиз без вмешательства человека будет? Особенно интересен момент с изменениями в базе.
Появилось несколько вопросов.
1. Как накатаываете изменения по базы данных? Миграции есть?
2. Как откатываете изменения в базе если что-то пошло не так?
3. Где почитать про ваш технологический стек?
4. Статья по релиз без вмешательства человека будет? Особенно интересен момент с изменениями в базе.
+2
1. Если меняются только данные, то скрипт прицепляется к задаче в jira и выполняется, в которой, например, меняется связанный с этими данными код. А если нужно поменять структуру таблиц, то заводится задача в отдельном репозитории для бд. Обязательно пищется rollback-скрипт. Важное правило изменений в БД — они должны быть обратно совместимы и изменение происходит поэтапно. Например, если мы хотим использовать новую колонку в БД вместо старой:
— создаем в базе новую колонку, код пока работает на старой
— обеспечиваем, чтобы данные совпадали в обеих колонках
— переключаем код на новую колонку
— дропаем старую колонку
2. Если в базе что-то пошло не так, то выполняется rollback-скрипт
3. Я не нашел статей на эту тему. Надеюсь, что в скором времени это будет исправлено
4. Мне бы тоже хотелось видеть такую статью. Надеюсь, коллеги обратят на это внимание и напишут
— создаем в базе новую колонку, код пока работает на старой
— обеспечиваем, чтобы данные совпадали в обеих колонках
— переключаем код на новую колонку
— дропаем старую колонку
2. Если в базе что-то пошло не так, то выполняется rollback-скрипт
3. Я не нашел статей на эту тему. Надеюсь, что в скором времени это будет исправлено
4. Мне бы тоже хотелось видеть такую статью. Надеюсь, коллеги обратят на это внимание и напишут
+2
картинка «hh — и в продакшн» — это очень круто!
+2
UFO just landed and posted this here
Приглашаются заказчик, другие заинтересованные лица и опционально все желающие и проводится небольшая презентация по проделанной работе и даются ответы на вопросы. После портфель в джире переводится на заказчика, чтобы тот оставил фидбэк о проделанной работе. На этом жизненный цикл портфеля заканчивается.
Как добились активного участия бизнес заказчика?
Как правило, им до фени ваш канбан, дайте фичу и лучше вчера
0
Sign up to leave a comment.
hh и в продакшн: как выпустить новую фичу