Size: a a a

2018 May 17

DU

Denis Ulitkin in DevOps Moscow
ого, какое оживление канала =)
источник

OS

Oleg Soroka in DevOps Moscow
на простые вопросы - конечно есть, всё-таки стаж, опыт и всё такое :)
источник

P

Pavel in DevOps Moscow
допустим тим решил, что в тим будет 50 человек, они все умеют все?
источник

H

Hopf in DevOps Moscow
Oleg Soroka
вот такая картинка в-подсказку
Спасибо. Тогда следующий вопрос.


Что делать, если коллега что-то от тебя хочет (является заказчиком фичи или нашёл баг), а сам, по каким-либо причинам выполнить эту фичу или починить баг не может

Без таск трекинга
источник

P

Pavel in DevOps Moscow
утром я версткой занимался, но теперь мне нужно чтобы мои css-ки компилировались не полчаса а 5 минут и деплоились на 1к серверов - я это сам сяду писать или отдам задачу другому более умному?
источник

OS

Oleg Soroka in DevOps Moscow
Pavel
допустим тим решил, что в тим будет 50 человек, они все умеют все?
странный вопрос, я его вообще не понял 🙂
источник

P

Pavel in DevOps Moscow
Pavel
утром я версткой занимался, но теперь мне нужно чтобы мои css-ки компилировались не полчаса а 5 минут и деплоились на 1к серверов - я это сам сяду писать или отдам задачу другому более умному?
а если тот умный занят?
источник

P

Pavel in DevOps Moscow
я пишу задачу на стикере и клею ему на монитор? =)
источник

P

Pavel in DevOps Moscow
а если эта задача не выполняется полгода?
источник

As

Anton spaceinvaderz in DevOps Moscow
я так понял, что главная идея, что нужно уйти от модели «заказчик-исполнитель», но главный вопрос - как?
источник

P

Pavel in DevOps Moscow
или я допустим взялся и пишу это полгода, а версткой занимается тот кто умеет в деплой, и теперь мы оба работаем на 10% мощности
источник

NK

ID:427332755 in DevOps Moscow
Pavel
готовьте доклад
+1
источник

OS

Oleg Soroka in DevOps Moscow
Anton spaceinvaderz
я так понял, что главная идея, что нужно уйти от модели «заказчик-исполнитель», но главный вопрос - как?
не совсем так, как раз ЗАКАЗЧИК-ИСПОЛНИТЕЛЬ - это идеальная сервисная модель, к ней надо стремиться. джира - симтом ровно противоположной модели ТОЛПА НАКИДЫВАТЕЛЕЙ ТАСКОВ - КУЧКА РАЗГРЕБАТЕЛЕЙ ТАСКОВ
источник

LG

Lev Galaktionov in DevOps Moscow
ID:427332755
+1
+1
источник

P

Pavel in DevOps Moscow
только если можно с цифрами, сколько у вас людей по такой схеме работает без jira
какие задачи делаете, как делаете сложные задачи
я понимаю, что это не так красиво будет как просто сказать “у нас вообще все круто, а jira это отстой“, но людям нужны доказательства что это работает =)
источник

P

Pavel in DevOps Moscow
хочется очень верить, честно
источник

P

Pavel in DevOps Moscow
что где-то там, есть супер инженеры, которые делают задачи в 10 раз быстрее, раз они не копятся
и общаются они очень эффективно и никто никогда не забивает на свои обязанности
источник

OS

Oleg Soroka in DevOps Moscow
если заказчик и исполнитель - это разные команды, работающие в конечном итоге на один большой общий проект, то хорошим описанием модели взаимодействия между ними будет - архитектра проекта (с учётом закона Конвея), описание разных API (тот же swagger), набор тестов (тесты как ТЗ) - ну всякие такие модные практики, о которых по соусом "девопс, клауднейтив, микросервис" вы и сами слушали много раз
источник

OS

Oleg Soroka in DevOps Moscow
при таком подходе, никого не надо КОНТРОЛИРОВАТЬ - задача или реализована или нет, индикатром реализации является прохождение тестов, означающих полноту реализации API (в старой модели - аналог сответсвия ТЗ)
источник

PK

Pavel Klyuev in DevOps Moscow
Я и без Jira и без команды использую как записи, так и документацию. В рамках команды хочется видеть все структуировано и в одном месте, какие инструменты, кроме стикеров на монитор и общения у стола вы предлагаете на проекте с 250+ инженерами?
источник