Это херня

Извините

А как же девопс?!! О_о )))

а какой девопс при ватерфолах?)

Если деплоят одмины то какая у чорту команда?

А, мы про это

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

Наверняка есть много ещё чего

обычно чтобы такой зрелости достигнуть надо оч по многим граблям пройти.

Наверное

Зачем давать команду на деплой если тестирование ещё не завершилось

Но даже если так

Всего лишь надо откатиться на пред версию

Обычно это просто

Зачем давать команду на деплой если тестирование ещё не завершилось

ну как завершилось. нашли багу уже после того как завершилось

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

Корпоративный пинг-понг. Меня один из моих руководителей (когда работал в очень большой компании) учил этому искусству :)

Ну ничего страшного вернуть предыдущие версии

У меня одни раз в одной команде было что тестировщики деплой делали

Нужно было инструкцию готовить и скрипты

Вот это было занятно

Ну ничего страшного вернуть предыдущие версии

Обычно в таких организациях нельзя. Учитывая что даже деплоить просто это боль

Да по этому админы нужны

Просто надо им настроить все

Мы когда деплоили 1с на 300 гиговую базу это была боль просто потому что идёт простой примерно в полчаса просто потому что медленно применяются изменения по базе

А потом это надо ещё откатывать

Да 1с это свой мир

И час просто фирма стоит ибо без 1с работа стоит

У меня знакомые по 1с вообще без выходных на новый год работают

Ну и каждый квартал это тоже геморрой

Там мир такой же как у всех можно любой проект так запороть если накосячить с миграциями.

Ага

Знакомый хорошо так один раз денег поднял, фирма его уволила и наняла аутсорс

Месяца через 3 они им удалённо кладут базу

Ни одного бекапа за 3 месяца не сделали)

Последние свежие у него остались

Вот оно. В команде о таких рисках вспомнить легче. Кто-то обязательно спросит - а что если база свалится. Но это только в том случае если нет установки "мое дело маленькое. Вот нанали аутсорсеров на 1с, вот пусть они этим и занимаются". Может забыть манагер, потому что он не шарит, может забыть админ, потому что он перегружен, но вот чтобы вся команда, которая работает на ПРОДУКТ, а не на бэкенд, фронтенд или инфраструктуру, это гораздо более невероятно.

Также в кроссфункциональной команде значительно меньше проблем МЕЖДУ компетенциями, потому что все отвечают за ПРОДУКТ, а не завою часть. Футбол проходит, когда дрюкают и хвалят всех.

компетенций очень много не боитесь

если есть админы которые хорошо знаю что делать с 1С

наприрер снять дамп тупо проверить миграцию до выкладки в прод

зачем команде думать что может что-то свалиться

Если умер, то надо после ретро делать PBI на постмортем.

👍

Друзья, не могу найти статью на фейсбуке про http://www.scrum.ua/blog/articles/squad-health-check-model Помню, что кто-то переводил эти карты на русский и публиковал на FB. Помоги пож.

компетенций очень много не боитесь

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

зачем команде думать что может что-то свалиться

Чтобы не свалилось!

Вместе легче и приятнее обнаруживать риски чем одному.

ну я сомневаюсь что они пишут в надежде что-то свалить

часто это проверятся только рутиной

ну я сомневаюсь что они пишут в надежде что-то свалить

Риски != навемерние свалить.

накатить прод на RC накатить скрипты дать еще раз все проверить кактить в прод

в моем идеальном мире надо стараться риски снимать с команды

а не добавлять им

там и так обычно непонятно что надо делать и куда бежать

еще и риски что выйдет новая версия 1С и все сломается

бррр

Рисками надо управлять. Кто это будет делать - вопрос отдельный. Вы пример привели про аутсорсеров и проблему с базой. Кроссфункциональная команда с большой долей вероятности этого бы не позволила.

это тупо было кроилово директора фирмы

он не хотел платить зп в 40 тыщ а нашел за 15

Т.к. никто не лез к аутсорсерам, вот так и получлось. Ведь каждый отвечал только за свою маленькую область.

он не хотел платить зп в 40 тыщ а нашел за 15

Полно таких проблем со своими сотрудниками.

Риски убирать с команд означает не давать им принимать решение, не посвящать их в какие-то аспекты. Это и приводит к незаинтересованностью работой, к "моя хата с краю", к футболу, к недовольству разработки и бизнеса друг другом.

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

погоди - но есть риски по продукту

как что делать там что бы работало

зачем им знать про сложности деплоя

чтобы сократить риски

чтобы потом не говорили - это виноваты админы или директор

Чтобы вовремя заметили и исправили

хорошо - а закупкку сервером и их настройка тоже на команду положить ?

выбор датацентров

сетевые конфиругации

?

у команды есть свой CI - где они достаточно погружены в проблемы деплоя нафига им все остально знать то

Зачем - я уже ответил. Почему это может не получиться - отдельная тема.

риски не сокращают - а управляют

или забивают на них

имхо

напишите все риски за которые отвечает команда и повесьте у них на доске - если места хватит

управляют рисками зачем? - забить - изменить вероятность возникновения - изменить степень влияния

будет отличная мотивация

Советы плохого папы? :)