Artem
И это вполне нормально
Dmitry
чем чаще, тем лучше (12 принципов гибкой разработки программного обеспечения
1. Наш наивысший приоритет — это удовлетворение заказчика при помощи частых и непрерывных поставок ценного для него программного обеспечения...) , но если вы уверены в том, что релиз рабочий 😄
ну это уже упоминали про agile
Dmitry
CI / CD наше всё
Алекс
Коллеги, привет! Вопрос: как вы относитесь к внерелизной выкатке? Например, срочный багофикс скопом через несколько дней? Есть ли в этом что-то неадекватное? Просто возник спор в команде. Я поддерживаю идею того, что в релизе Х.1, допустим, ничего страшного нет.
А что Вам мешает релиться по требованию Владельца продукта?
Daria
А что Вам мешает релиться по требованию Владельца продукта?
ничего, у нас конец спринта = релиз
Yuriy
конец спринта = инкремент 😉, а релизы могут быть как договоритесь)
Алекс
конец спринта = инкремент 😉, а релизы могут быть как договоритесь)
Поддерживаю! Поговорите, что Вам нужно чтобы релизиться по требованию владельца продукта
Daria
конец спринта = инкремент 😉, а релизы могут быть как договоритесь)
ну читайте, что договариваемся так, да)
Yuriy
а кто что использует для CI/CD, раз пошла такая пьянка 😄
Daria
у нас флоу такой, что к концу спринта все на тестовую среду выливается, если все ок — релиз
Игорь
ну типо смотря что с чем сравнивать. У каждого же свое понимание крит не крит и что для аудитории ахтунг..
все верно, если для исправления инцидентов от пользователей достаточно будет помощи саппорта (в БД например поправить данные), то ХФ не обязателен и это терпимо до релиза, если кол-во таких инцидентов начнет расти лавинообразно, то целесообразно подумать о выводе ХФ, а то техподдержка-то нерезиновая
Olga
Yehor
спасибо, попробую:)
Но пне кажется, что должен быть более разумный способ, к примеру за уплату 25-ти долларов я не понимаю как мне выставят инвойс, если ключевые данные компании у меня не запрашивает
Vladimir
@Da_Nova Для вас выкатка внеплановая, похоже, оказалась индикатором проблем.
Почему команда не хочет выкатывать часто?
Могут быть чисто инженерные проблемы:
1) Релиз требует много ручной работы. Команда не хочет терять время на доп релиз. Надо настраивать CI/CD, как здесь уже верно написали.
2) Команда не может гарантировать качество релиза без масштабного ручного тестирования. Надо развивать внутреннее качество продукта: автоматизация тестирования, модульная/слоеная архитектура.
Либо есть вероятность для проблем бизнесового уровня:
1) Нет обоснованности действий. "Почему бы не приложить багу не особо критичную" это не обоснование для ее включения в работу. Видение продукта, цели, роадмап, понимание потребностей клиентов - это всё может решить проблему. Но на деле , конечно, всё значительно сложнее чем звучит )
Daria
@Da_Nova Для вас выкатка внеплановая, похоже, оказалась индикатором проблем.
Почему команда не хочет выкатывать часто?
Могут быть чисто инженерные проблемы:
1) Релиз требует много ручной работы. Команда не хочет терять время на доп релиз. Надо настраивать CI/CD, как здесь уже верно написали.
2) Команда не может гарантировать качество релиза без масштабного ручного тестирования. Надо развивать внутреннее качество продукта: автоматизация тестирования, модульная/слоеная архитектура.
Либо есть вероятность для проблем бизнесового уровня:
1) Нет обоснованности действий. "Почему бы не приложить багу не особо критичную" это не обоснование для ее включения в работу. Видение продукта, цели, роадмап, понимание потребностей клиентов - это всё может решить проблему. Но на деле , конечно, всё значительно сложнее чем звучит )
но разложено очень грамотно, спасибо. И я в кажом пункте знаю проблематику, но не сразу Москва строилась
Ivan
Я думаю сама культура выкатывать чаще уберет страхи и добавит подвижность, свойственную Agile. действие рождает мотивацию, а не наоборот
Vladimir
Я думаю сама культура выкатывать чаще уберет страхи и добавит подвижность, свойственную Agile. действие рождает мотивацию, а не наоборот
Ну почему, наоборот тоже бывает, может даже по-чаще )
А вобще-то это замкнутая система
Ivan
Вы про мотивацию или про частые обновления?
Vladimir
Вы про мотивацию или про частые обновления?
Я про взаимозависимость между мотивацией и действием.
Daria
Анекдот моего утра. Пишет мне коммент в джире разработчик подрядчика: а для чего ты требуешь декомпозицию задачи? (Чтоб вы понимали, это только 1\3 огромной таски = 30+ часов и это не точно)
Daria
Но это не смешно ведь...дожен ли разработчик знать, что декомпозиция — это благо?
Tanya
Ну так и ответь, для чего. Понимая, зачем именно тебе это нужно (учитывая что самому ему это не кажется необходимым), он сделает декомпозицию наилучшим образом
🦠
Но это не смешно ведь...дожен ли разработчик знать, что декомпозиция — это благо?
в чужой монастырь со своим усталым лучше не ходить)
Tanya
Как вариант можно сказать что эту задачу необходимо завершить за 18 часов, и после декомпозиции можно будет проанализиповать и гайти решение как уложиться в 18 часок (подключить другого разработчика, отказаться от тюнинга га данном этапе и тд...)
Daria
кстати, вопрос, все-таки, дискуссионный...до какого разумного предела нужно декомпозировать таски? В разрезе рабочих часов планируемых... не всегда нравилось 8часов, как стандарт, дальше сабтаски
🦠
зачем менеджить другой бизнес? у подрядчика есть свои обязательства по срокам
🦠
в СССР были трудодни, надо разбивать на майлстоуны "Социализм", "Коммунизм" и т.д.
Tanya
:)
Tanya
Я увидела в этом диалоге вопрос доверия между участниками проекта. И впринципе если он спрашивает, почему бы прямо не ответить? Очевидные вещи тоже можно и нужно проговаривать
Tanya
Может и правда ему не понятно зачем это делать в контексте вашего проекта
🦠
подрядчик подписал контракт, в нем есть сроки, есть обговоренные деньги - не попал в таймлайн - плати из своего кармана, все просто
Daria
прежде всего непонятно для всех ЧТО надо делать в задаче, поэтому и предлагаю декомпозировать, чтобы пончтней было
🦠
зарубежные коллеги именно так построили шведский социализм
Daria
Tanya
Ну это крайняя мера ждать пока подрядчик завалит твой проект
Daria
поэтому оценка времени для нас важна. И если я не понимаю, что входит в 30+ часов на задачу, я хочу, чтобы она была декомпозирована
🦠
ну аутстаффинг всегда дорого обходится)
Tanya
:)
🦠
идеально, когда внешняя команда имеет своего менеджера проектов)
🦠
но побеждать процессы чужого бизнеса - это мне кажется юношеский максимализм)
Tanya
поэтому оценка времени для нас важна. И если я не понимаю, что входит в 30+ часов на задачу, я хочу, чтобы она была декомпозирована
Вот именно это и есть ответ на его вопрос. Остается сделать копипаст из телеграмма в джиру :)
Tanya
Или какой там у вас более быстрый канал связи
🦠
у нас с такими ребятами все просто, менеджер снаружи, но и техлид снаружи, который следит, чтобы по срокам не проваливались)
🦠
и если разработчик подрядчика несет чушь, его вежливо останавливают и просят объяснить детали
Dmitry
agile же про доверие ...
🦠
у каждого своя карта ценностей, кто-то за размеренную работу без авралов, кто-то против микроменеджмента
🦠
скрам с внешней командой разработки - это проктология
Daria
идеально, когда внешняя команда имеет своего менеджера проектов)
Там менеджер — бывший разраб и у него очень плохо с менеджерством, к сожалению
Tanya
РазРАБ 😨 жуткое слово
Tanya
:)
Евгений Семашко
Всем привет!
Евгений Семашко
подскажите, пожалуйста, для jira решение, которое позволит планировать проекты, ресурсы, позволят планировать нагрузку и так далее. их что-то дофига рахных
Евгений Семашко
что лучше?
Denis
+1
Dmitry
Tanya
😄
Tanya
разработчик, developer, программист..., Вася, Петя, Оля...
Ivan
Мы обычно просто дэв называем))
Tanya
👍
Ivan
Ну и в теории скрама dev team, все на своих местах
Dmitry
Евгений Семашко
спасибо!
🦠
Дев (арм. դև) — в армянской мифологии добрый или злой дух[1]. Описывается в мифах, легендах и сказках как великан с огромной головой на плечах и глазами размером с глиняные горшки или тарелки (некоторые девы — одноглазые), сочетающий иногда в своём образе и черты животных[2]. Дев может быть как добрым, так и злым — все девы делятся на белых и чёрных, причём цвет не всегда соответствует характеру (т.е. белый может быть и злым, а чёрный — добрым). В легендах маги были способны заставить дева вселиться в тело человека[3].
Из добрых девов известны аралезы и урваканы, из злых — алы, айсы, чивалы и вишапы. Такие духи, как хадж, относятся к людям нейтрально в мифологии. Облик каждого дева отличается — например, пайрики принимают облик как прекрасных женщин, так и ослиц, живущих в развалинах[2].
============ FALCON ============
Внезапно в эджайл канале)
============ FALCON ============
Такие модели как бэлбина, такмана и т. д. на практике как применяете?
Anton
да
============ FALCON ============
Обновил вопрос
Sergey
Такие модели как бэлбина, такмана и т. д. на практике как применяете?
Я тетстирую команды по тестом Белбина через три-четыре спринта после начала. На ретро вместе обсуждаем. Очень хорошо заходит. Ну и этапы формирования команды по Тамену тоже рассказываю в самом начале. Главное это сделать до этапа бурления.
Глебка
Я тетстирую команды по тестом Белбина через три-четыре спринта после начала. На ретро вместе обсуждаем. Очень хорошо заходит. Ну и этапы формирования команды по Тамену тоже рассказываю в самом начале. Главное это сделать до этапа бурления.
Так и как реагируют на то что тест сказал?) тож думаю попробовать, с какой стороны б позитивной зайти
Yuriy
если "узаконить" бурление, то должно лучше пойти конечно
Sergey
если "узаконить" бурление, то должно лучше пойти конечно
Для многих это откровение. Они смотрят друг на друга и не понимают, как это может случиться. Но след остается. И они готовы когда это случится.
Tanya
Подскажите добротную литературу /ресурсы по 6sigma пожалуйста
PM
Подскажите добротную литературу /ресурсы по 6sigma пожалуйста
Добрый день! Коллеги из Pepsico посоветовали после семинара:
• Out of the Crisis – Edward Deming
• Creating a Lean Culture – David Mann
• Lean Six Sigma for Service - Michael George
• Leading Change – Kotter
Tanya
Спасибо, супер