« Rev
@agile_ru   369
Fwd »


Dmitry
А в остальном от других не отличается? Плюсы (точки) есть?
смотря что вы на стармэпе указываете. если только технические скиллы - то нет.
Ⓢⓔⓡⓖ
ЭЭЭ. внутри спринта можно хоть кадые 2 часа релизиться :)
Да я в курсе что можно по гайду. Нужно ли? А если нужно, то стоит ли этот процесс называть спринтом?
Anton
смотря что вы на стармэпе указываете. если только технические скиллы - то нет.
технологии + некоторые специализации (например: тестирование)
Денис
Подождите, попкорн закончился😣
Ⓢⓔⓡⓖ
ЭЭЭ. внутри спринта можно хоть кадые 2 часа релизиться :)
Если результат спринта - инкремент бизнес-ценности, то чем являются релизы внутри спринта? Инкремент внутри инкремента ?
Andrew
Привет, Антон! Мой совет обсудить эту тему с командой. Подумай, как можешь использовать встречу с командой, чтобы вернуть ее к правилам Скрама, но оставить им ответсвенность за принятие решения.
Anton
ну тестирование это тех.скил
Спасибо. Правильно понимаю, что он не может поставить задачи по тем скилам, которых у него самого совсем нет?
Anton
Привет, Антон! Мой совет обсудить эту тему с командой. Подумай, как можешь использовать встречу с командой, чтобы вернуть ее к правилам Скрама, но оставить им ответсвенность за принятие решения.
Да не, у меня самого такой проблемы нет. Но меня звали в несколько команд, помочь с самоорганизацией. И когда я там с ними заполнял стармапу, то было интересное наблюдение. Т.е. мой вопрос скорее не "что с этим делать" (что делать - мне понятно), а какая картинка наблюдается на скил стармапе, если её заполнить в такой команде, где до этого был тимлид?
⁣vladislav_gatsenko
зачем нужен скрам мастер?
Artem
Да я в курсе что можно по гайду. Нужно ли? А если нужно, то стоит ли этот процесс называть спринтом?
Частота релизов никак не регламентируется гайдом. Главное - это готовый к поставке продукт в конце спринта. Оунер решает релизить или нет. Если команда может выпускать релизы чаще - это ещё больше снижает риски выдать что-то не то или не выдать функционал вовремя. Конечно если выпуск версии- это не мучительный регресс, а разумное время и максимальная автоматизация
Ⓢⓔⓡⓖ
Может сделать табличку-справочник, что скрам: поощряет и должно быть обязательно; что не приветствуется и прямо запрещается; и что не запрещается но если очень нужно - то можно. В контексте этих 3х категорий лучше понять что кто имеет в виду.
Artem
Тогда это будет ограничивать гибкость имхо. Цель компании же не в 100% соответствии скраму. А в ускорении поставок, снижении рисков поставить что-то не то и так далее.
Artem
Хотя в учебных целях почему бы и нет))
Anton
Есть, но мне перевод не нравится.
Anton
http://agilerussia.ru/methodologies/%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0-%D0%BD%D0%BE%D0%B2%D0%BE%D0%B3%D0%BE-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%B0-%D0%BD%D0%BE%D0%B2%D1%8B%D0%B5-%D0%BF%D1%80%D0%B0/
Denis
Там надо за две недели проверить 20-30 экспериментов. Какой тут нафиг скрам
Мы щас с коллегами на тренинге по growth hacking, так тут автор обучает проводить 20 экспериментов за 2-недельный цикл именно используя фреймворк Scrum
Mikhail
Ребят подскажите мож есть у кого типовой договор.Сейчас впервые столкнулись с крупным таким проектом, биржа агентов недвижимости", хочется оставаться Agile и при этом защититься от проблем с клиентом.По идее в Agile должно быть какое-то гибкое тз,может у кого есть такой договор или контакты человека который проконсультирвоать в этом вопросе может. Так как не все юристы понимают что я хочу и зачем мне это))
Ⓢⓔⓡⓖ
Смотрите, здесь какая логика. Есть две команды; вторая делает продукт на основе продукта первой. Чтобы снизить время ожидания новой фичи, вторая команда может просить увеличить частоту релизов, например, раз в 3 дня. А первая может быть против, т.к. у них внутри спринта всё разворочено - фича как бы реализована, но тесты написаны с неполным покрытием, документация не синхронизирована, и вообще CI/CD может быть настроен в полуручном режиме, т.е. каждый релиз требует времени. Поэтому первая команда говорит: нам неудобно делать релиз внутри спринта, будем делать в конце. Это конфликт. Вторая команда наседает: вы же говорили, что работаете по скраму, а по скраму _можно_ делать релизы внутри! По идее первый SM должен ответить: можно, но не обязаны. Но иногда забывают о разнице. Я, в частности, забыл. Сорри.
Anton
Ребят подскажите мож есть у кого типовой договор.Сейчас впервые столкнулись с крупным таким проектом, биржа агентов недвижимости", хочется оставаться Agile и при этом защититься от проблем с клиентом.По идее в Agile должно быть какое-то гибкое тз,может у кого есть такой договор или контакты человека который проконсультирвоать в этом вопросе может. Так как не все юристы понимают что я хочу и зачем мне это))
Такой договор называется рамочным, т.к. при этом отношения строятся на доверии, и заказчик оплачивает разработку по спринтам. По сути это Time&Material. Если заказчик в принципе не воспринимает ничего кроме fix price, то можно оставить fix price с дедлайном, приложить туда ТЗ, которое там заказчик сочинил, и не париться. Дело в том, что если у вас Agile команда, то после нескольких спринтов с заказчиком он забудет про это ТЗ. Если на него там присядут юристы или бухгалтера, то он их успокоит парой допников. А если команда не Agile, то никакие договора не помогут и не защитят от проблем.
Dmitry
у меня было так: еще до договора был определен состав команды разработки (с подрядчиком работаем по другим активностям, поэтому проблем не было. В принципе, в рамках пресейла можно и в общем случае команду сформировать). Бюджетирование у нас годовое, поэтому прикинули, сколько будет стоить команда на год (с ВП получили коммит что продукт минимум год будет развиваться). т.е. в договоре указан fix price. актирование работ - раз в месяц. чтобы формализовать (настояли юристы и бухи) ВП с представителем подрядчика после планирования подписывают бэклог спринта (таблица с юзер стори). Результаты демо также подписываются с 2-х сторон. вся эта макулатура потом идет приложением к акту выполненных работ. бюрократия конечно, но на практике занимает не больше 30 минут на спринт
Artem
Смотрите, здесь какая логика. Есть две команды; вторая делает продукт на основе продукта первой. Чтобы снизить время ожидания новой фичи, вторая команда может просить увеличить частоту релизов, например, раз в 3 дня. А первая может быть против, т.к. у них внутри спринта всё разворочено - фича как бы реализована, но тесты написаны с неполным покрытием, документация не синхронизирована, и вообще CI/CD может быть настроен в полуручном режиме, т.е. каждый релиз требует времени. Поэтому первая команда говорит: нам неудобно делать релиз внутри спринта, будем делать в конце. Это конфликт. Вторая команда наседает: вы же говорили, что работаете по скраму, а по скраму _можно_ делать релизы внутри! По идее первый SM должен ответить: можно, но не обязаны. Но иногда забывают о разнице. Я, в частности, забыл. Сорри.
Выдерните разраба(ов) из первой команды и передайте его/их во вторую с правом коммитать в код первой. Зависимости от первой команды уменьшатся
Алекс
разраба из второй :)
Ⓢⓔⓡⓖ
Ну кстати вариант. Снизим скорость, но улучшим коммуникации и передачу знаний
Yuriy
у меня было так: еще до договора был определен состав команды разработки (с подрядчиком работаем по другим активностям, поэтому проблем не было. В принципе, в рамках пресейла можно и в общем случае команду сформировать). Бюджетирование у нас годовое, поэтому прикинули, сколько будет стоить команда на год (с ВП получили коммит что продукт минимум год будет развиваться). т.е. в договоре указан fix price. актирование работ - раз в месяц. чтобы формализовать (настояли юристы и бухи) ВП с представителем подрядчика после планирования подписывают бэклог спринта (таблица с юзер стори). Результаты демо также подписываются с 2-х сторон. вся эта макулатура потом идет приложением к акту выполненных работ. бюрократия конечно, но на практике занимает не больше 30 минут на спринт
по-моему, вполне подходящий вариант, и понятный заказчику)
Artem
Ну кстати вариант. Снизим скорость, но улучшим коммуникации и передачу знаний
Почему вы решили, что скорость снизится? Первая команда же что-то делает для второй. Перешедшие разрабы продолжат разработку продукта первой команды. Только в более тесном контакте со второй командой. И приоритетом для нужд второй команды
Andrew
Снизится, т.к. продукты разные
А код для продуктов одинаков?
Andrew
Язык имею ввидц
Artem
у нас подобная проблема долгое время сохранялась. Только на уровне бэк-мобилки. Ситуация стала меняться, когда мы стали делать объединенные команды из серверных и мобильных разработчиков/тестировщиков
Artem
от членов таких команд очень положительные отзывы идут насколько проще стало работать
Andrey
Всем привет. Кто использует у себя https://labs.spotify.com/2014/09/16/squad-health-check-model/ ?
Maxim
Всем привет. Максим Полищук. #whois ▫️Какой у вас проект или где работаете? текущий проект - автоматизированное тестирование приложения мвидео ▫️В чём вы специалист? тестировании ▫️Чем можете быть интересны или полезны сообществу? участвовал/ую в различной сложности проектах везде были свои сложности, “+” и “-“. Возможно небольшой опыт поможет кому-то из коллег. ▫️Чем интересно сообщество вам? Что вы ищете? Мнение экспертов, решение проблем, советы, best practice и т.д. ▫️Откуда вы? Воронеж ▫️Как узнали про группу? Из группы Atlassian User Group Moscow
HashTag
Подписка на #whois
Mikhail
Всем добрый день. ▫️Какой у вас проект или где работаете? Работаю в компании 65apps, разработка мобильных приложений ▫️В чём вы специалист? Бизнес-аналитик, пресейл, разработка ТЗ и проектной документации, сопровождение проектов, разработка концепции сервисов на основе идей заказчиков. ▫️Чем можете быть интересны или полезны сообществу? Могу рассказать про заказную разработку, сбор требований, работа с заказчиком на пресейле и на этапе разработки ТЗ и т.п. ▫️Чем интересно сообщество вам? Что вы ищете? Полезную информацию, ответы на вопросы. ▫️Откуда вы? Ижевск ▫️Как узнали про группу? Из канала Atlassian User Group Moscow #whois
Dmitry
Леди и джентльмены, такой бюрократический вопрос: а не завалялось ли у кого должностных инструкций на скрам-мастера? нужны для формализации должности в компании
Dmitry
У меня аж заболело :)
представьте как у меня болит. но что делать :(
Алекс
👍
Andrew
Никак
Dmitry
это понятно. но там умных слов надо страниц на 5 написать. не копипастить же весь скрам-гайд :)
Vlad
Вообще по закону нужны формальные должностные инструкции. Так что болеть должно у всех тут;)
Алекс
😁 5 страниц умных слов :)
Daria
Всем привет! Вопрос: сталкивался/используются ли у вас в командах грейды? Если да, то с чёт это едят, можно ли где то почитать об этом (как правильно составлять и каковы каноны)? И все все по этой теме интересует. Негативный опыт особенно👌🏻
Mikhail
В нескольких компаниях, где я работал использовались. Опыт сугубо положительный, хотя само внедрение требует времени и сил. Разбиваем всех сотрудников по видам деятельности, к примеру разработчики-андроид, разработчики-айос, разработчики-бэкенд и т.п. Для каждой группы описываются требования к знаниям и опыту которым должен обладать сотрудник для получения определенного грейда. Например: знание определенных технология, методик, теории и обязательные выполненные работы: например успешно выполненный проект как тим-лид и т.п. Раз в полгода аттестация. Плюсы - сотрудник знает, что ему изучать и к чему стремиться, чтобы получить новый грейд. Получение нового грейда должно сопровождаться повышением ЗП.
Dmitry
о, какие люди!
Mikhail
Негативный опыт был при первой аттестации - когда сотрудник считающий себя "крутым" и "опытным" по результатам получает минимальный грейд и по результатам ему срезают ЗП
Roman
Дима привет!
Андрей
«Разбиваем всех сотрудников по видам деятельности» -> про «команду» в понимании Скрама сразу можно забыть.
Remezov
Я бы к негативному ещё приписал один момент. У нас грейд можно повышать не больше раза в год. Бывают ситуации когда сотрудник растет быстрее, но искусственные ограничения не позволяют продвигать его
Daria
В нескольких компаниях, где я работал использовались. Опыт сугубо положительный, хотя само внедрение требует времени и сил. Разбиваем всех сотрудников по видам деятельности, к примеру разработчики-андроид, разработчики-айос, разработчики-бэкенд и т.п. Для каждой группы описываются требования к знаниям и опыту которым должен обладать сотрудник для получения определенного грейда. Например: знание определенных технология, методик, теории и обязательные выполненные работы: например успешно выполненный проект как тим-лид и т.п. Раз в полгода аттестация. Плюсы - сотрудник знает, что ему изучать и к чему стремиться, чтобы получить новый грейд. Получение нового грейда должно сопровождаться повышением ЗП.
1) кто определяет критерии прохождения грейда? Лид? 2) кто Лиду прописывает Грейд? 3) есть ли грейды у манагера? 4) кто составляет экзамен? 5) на сколько нужно повышать зп, чтобы было, к чему стремиться, но и волки сыты?
Remezov
Дополнительно не согласовывается? Строго по расписанию экзамены?
Есть возможность, но это согласование через 7 кругов ада и директора. Я слышал слухи что кто-то проворачивал подобное, но это очень конкретный гемор
Remezov
Вот поэтому и спрашиваю, а судьи кто?
У нас судья-твой руководитель. Тесты как правило не отображают реального положения вещей
Daria
есть
Ооооо и мне можно? Пожалуйста
SeWa
это понятно. но там умных слов надо страниц на 5 написать. не копипастить же весь скрам-гайд :)
Пять? Даже в госах обходился максимум тремя. Но вообще две можно наскрести из других - доблестно и честно работать работу и тп
Андрей
Ну это ж аттестация, около работы, штатка в итоге. Скраму разве мешает?
Мешает, так как разделение по направлениям создаёт предпосылки к поведению «я свою работу сделал, а дальше хоть трава не расти» вместо «если надо для успеха команды, мы все навалимся» :) И оценка извне команды тоже - важнее получается не на командную цель работать, а на свою личную (свой грейд поднять).
Remezov
Тогда это все фарс?(((
Ну это у Михаила по тестированию повышали. У нас есть тестирование, но оно не влияет на грейд.
Remezov
Абсолютно. Система грейдов разделяет команду а не укрепляет ее.
Тогда зп тоже мешает скраму. У меня зп 20 рублей, а у него 300, пусть он работает)))
Вова
Тогда зп тоже мешает скраму. У меня зп 20 рублей, а у него 300, пусть он работает)))
Вы сейчас с позиции того у которого 300 рассуждаете?система грейдов как правило не позволяет повышать грейд чаще чем раз в год и не более 30% к текущей. Поэтому текучка дай боже у разрабов получается
Андрей
Тогда зп тоже мешает скраму. У меня зп 20 рублей, а у него 300, пусть он работает)))
Мешает, но это привычный уровень «зла», и не надо его усугублять :) кроме того, передовые компании (есть примеры) двигаются в сторону открытых зарплатных формул, когда каждый член команды знает, почему у него и у коллег именно такая сумма; что нужно ему научиться делать, чтобы её увеличить и, самое главное, это всё решается внутри команды.
« Rev
@agile_ru   369
Fwd »