Dmitry
Behavior
Dmitry
блин, там o или ou, не помню)
Anonymous
давай с начала, тут вопрос про метрики именно?
Иван
Нет, как пример. Вопрос про смену майндсета с планово-контрольного на коллаборативно-агильно.
Anonymous
процесс внедрения занял полтора года, из них первые полгода я тупила и пыталась по-хорошему :)
Anonymous
потом мы начали пилот, ткнув пальцем в группу, которая была "самая плохая" по мнению московского офиса у нас в Питере
Dmitry
с командами надо по-хорошему, а с менеджментом можно жестко)
Anonymous
и когда эта "самая плохая" стала крутой - на их примере мотивировали еще 12 групп
Anonymous
причем уровень разработчиков и тестировщиков не поменялся
Anonymous
просто на лиде разработки висело 400 задач и коллеги из москвы были все уверены что именно их задача - самая главная
Anonymous
мы начали с канбан-доски и плазменного экрана на котором она в реальном времени менялась
Anonymous
блокеры стали делаться оперативно без звонков из москвы
Anonymous
потом мы убедили начальника группы сделать стендапы - показав стендапы другой группы разработки, в мобильном браузере уже был "скрамно" своеобразный, а потом он САМ ПРИШЕЛ ПРОСИТЬ СПРИНТЫ чтобы отгородиться от очереди из 400 тикетов набором того что можно сделать за спринт
Anonymous
примерно также менялось мышление у всех остальных
Anonymous
мы ввели правило, что есть встреча между всеми заказчиками разработки и руководителем группы разработки, на которой из уже оценненных(планнинг покер) задач выставляются сквозные приоритеты
Anonymous
причем кто ушел со встречи - свои задачи в спринте потерял
Anonymous
и разработчики тогда из минска сказали мне главное: продавать спринты разработчикам можно просто: если они сделают в срок все тикеты/стори из спринта, новые они смогут выбрать из бэклога сами или даже не выбирать ничего а заняться рефакторингом или исследованиями
Anonymous
после этого у меня спринты внедрялись 1 совещанием и клонированием доски :)
Anonymous
а последние 2 группы пришлось сломить через главного прожект менеджера, они пошли к руководителю всей разработки и тот им разрешил быть последними кто не перейдет очень долго на новую систему, и когда я пришла к ним внедрять, гордо об этом сообщили, я тогда сказала "к вам придет начальство и вы "захотите" и сами обратно ко мне прибежите" ну почти дословно от раздражения незавершенности :) потом написала начальству, и через полдня они сами меня позвали и даже переговорку забронировали не только в мск но и в питере с видео(необычайно предусмотрительно для москвичей)
Иван
Кулстори, зачет!
Anonymous
статью чтоли теперь оформить из этого текста :) можете посмотреть видео с аджайл дейз 15 пошаговая инструкция по переходу на спринты, там будет инструкция, основанная на этом опыте
Ruslan Kuzminov
прекрасная мысль! =)
Ruslan Kuzminov
давай
Ruslan Kuzminov
как кейс
Ruslan Kuzminov
с результатами =)
Alexander
статью чтоли теперь оформить из этого текста :) можете посмотреть видео с аджайл дейз 15 пошаговая инструкция по переходу на спринты, там будет инструкция, основанная на этом опыте
Для ленивых: http://msk15.agiledays.ru/members/profile/1116/
Anonymous
спасибо!
Alexander
Вам спасибо за подсказки) эх, должны же руки дойти запилить базу знаний по agile
Fedor
Ну вы поинтересуйтесь сколько у них, и код пускай покажут :]
Слава, т е лучше вообще без тестов?
Anton
поржал тут над TDD хейтерами :)
Anton
когда у разработчиков не пишущих тесты, начнутся проблемы - приходите к нам ))
Иван
Антон, мочИ!
Иван
Культуру в массы!
Anton
я имею опыт работы и с тестами и без. могу сравнивать. вообще решение о том, надо писать тесты или нет - это бизнес решение, тут Слава прав. если у вас стартап и вам важна скорость в ущерб поддерживаемости кода - тесты будут вас замедлять. но надо понимать, что такой код долго не живет. но это вплоне себе жизненный кейс. если для бизнеса тесты не выгодны - их не надо писать.
Anton
но если уж решили что тесты на проекте нужны, то лучше уж писать по TDD, чем Test Last.
Anton
по опыту скажу что мне лично гораздо комфортнее писать новый код одновременно с тестами - либо по TDD, либо по Test First
Иван
Иван
Иван
А я бы вот такую тему вбросил
Anton
TDD тоже не серебряная пуля, он помогает там где домен сложный и сразу не поймешь откуда начинать. TDD организует процесс работы так, что ты двигаешься маленькими шагами, имеешь постоянно работающий код, в случае ошибки мгновенно видишь что сломано, и главное - после каждого 10-15 минутного цикла ты получаешь новый работающий инкремент функционала, который можно закоммитить
Иван
Кто-нить рэнкинг по cost of delay делает?
Anton
если хотите узнать сколько времени экономит TDD - посчитайте сколько времени вы тратите на дебаг
Иван
Или более сложным штукам типа WSJF. "Бизнес" участвует в оценках?
Oleg
А если 50% времени разработки это исправление ошибок, это о чем говорит?)) Стоит внедрять TDD?)
Anton
не знаю )) если домен сложный то да, если простой то нет. если в основном поддержка старого кода, то внедрять TDD уже поздно . но тесты писать никогда не поздно
Anton
а вообще если у вас 50% времени - исправление ошибок, то у вас явные проблемы с качеством. тут уже TDD не поможет. здравствуй рефакторинг, юнит тестирование, код ревью или парное программирование.
Oleg
Юнит или автотесты селениумные?) То есть что лучше на многолетнем продукте внедрять - тестовое покрытие методов или же автотестами покрыть, чтобы смоук тесты и интеграционка не позволяла ещё больше увеличивать процент?
Oleg
Кстати, парное программирование был опыт внедрения на распределенной команде?
Anonymous
это как? через тимвьюер?
Oleg
Ага, я делал через тимвьювер или VNC
Anton
да, есть такой опыт
Oleg
Один прогает, другой на хенгаусте висит и является навигатором собственно
Anonymous
юниттесты внедрять дешевле, вторые по стоимости интеграционные, ну вы поняли
Anton
селениум тесты не люблю. их писать легко, но на поддержке сдохнете
Anonymous
начинать с самого дорогого - ваш выбор
Anton
юнит + интеграционные
Anonymous
ага
Anonymous
как говорит мой хороший друг: нет юнитов - нет тестов :)
Oleg
юниттесты внедрять дешевле, вторые по стоимости интеграционные, ну вы поняли
юнит тесты продать тяжело разработчикам, код же уже выпущен - нафига тесты. Покрытие тестами кода процентов 5, команда не очень любила тесты, с чего полюбит?))
Anonymous
сначала правильная многослойная архитектура
Anonymous
уволить нафиг такую команду, как по мне или перевести в девопсы
Oleg
сначала правильная многослойная архитектура
Типа давайте менять архитектуру, а в процесе рефакторинга не забывайте писать тесты?
Anonymous
ну да
Petr
Можно начать с того что юнит тестами покрывать новый функционал
Oleg
уволить нафиг такую команду, как по мне или перевести в девопсы
перевести в девопсы)))) без любви к качеству? опасненько.
А так, уволить анрил же, имея продукт без тестов почти и комментов. Только тихонечько, аккуратненько
Petr
Через пару месяцев предложить рефакторинг, когда понравится тесты писать
Anton
когда код написан и не поддерживается, то действительно романтический момент упущен, юнит тесты писать без толку. пишите интеграционные. но тут есть проблема. если код написан без тестабельного дизайна в уме, то вы не сможете написать интеграционные тесты. вам сначала придется распилить код на горизонтальные слои хотя бы, чтобы можно было мокать тяжелые зависимости (сервисы, БД, файловая система, …). а рефакторить код без тестов страшно. вот вам и и смертельная спираль. нет тестов - страшно рефакторить. не рефакторим - код загнивает - еще тяжелее писать тесты
Иван
Anton
тады ой :)
Anton
в смысле ок. но все равно, скорее всего интеграционные тесты вам будут более полезны
Anonymous
на опыте переписать продукт дешевле чем бороться с зашоренностью мышления, как-то после ухода одного программера в его коде нашли "магию" замешанную на 4 параметрах, один из которых всегда равен 1
Anton
если есть критические модули, которые часто меняются или от которых много чего зависит с плане рисков, то лучше их дополнительно покрыть юнит тестами. но все покрывать не надо…
Anonymous
еще помогает код ревью
Oleg
Я пока на слоенку перевожу четко разделяя front (react), back (rest), bi (services), db (ну понятно). Помодульно
Oleg
Плюс прошу их покрывать тестами и некоторых программистов способных по TDD прошу
Anonymous
и требование покрытия тестами нового проверяемое на ревью