Sasha
?
Anton
безусловно вариант - но не особо приемлем
Anton
это рабочий момент
Anton
замечания тестировщика
Anton
и если замечания критичные, типо заказывали велосипед, а накодили кастрюлю - вопросов нет, возвращаем в туду
Anton
а если все готово и работает, однако нужно "поменять иконки местами" - возвращать задачу на начало цепочки и ждать пока она дождется своей очереди крайне не целесообразно
Anton
тем более если таких итераций будет несколько (каждый раз будут выявляться минорные баги)
Sasha
ну у тестировщика есть только "задача выполнена" и "задача не выполнена"
Sasha
в случае если есть замечания - обговаривается с менеджером, отправляется в туду или задача переводится далее по статусу, а замечания выносятся отдельной задачей, линкуется к базовой
Sasha
а если все готово и работает, однако нужно "поменять иконки местами" - возвращать задачу на начало цепочки и ждать пока она дождется своей очереди крайне не целесообразно
тут не соглашусь. у разработчика появится уведомление о том что его задача была возвращена. у тестировщика в это время появится одно место для новой задачи
Sasha
таким образом, разработчик отдает на тестирование следующую задачу (у него соответственно освобождается лимит), и берет ту которую вернули
Sasha
у вас кстати два статуса done одинаковые получается? не путаетесь?
Anton
в каждой рабочей колонке есть 2 подстатуса (в работе, выполнил)
Andrey
вооот
а по идее в скраме не так)
в скраме Scrum Team (это и PO в том числе) на Sprint Review показывает и обсуждает инкремент с пользователями/стейкхолдерами и тд
это очень даже помогает понять, что никому не интересно, чтобы ты тупо кодил. Пользователи будут смотреть на результат и спрашивать у тебя "а как это работает", но не про код)
у нас такой продукт, где в явном виде этот процесс не применить, это как если вы пишете драйвер - промежуточные шаги особо не посмотреть
Anton
проектировщики перемещают свои "в работе" на стадию "выполнено" (выполнено имеется ввиду этим отделом)
Anton
тем самым сигнализирую следующему отделу что можно брать новые
Anton
тут не соглашусь. у разработчика появится уведомление о том что его задача была возвращена. у тестировщика в это время появится одно место для новой задачи
если на практике доска немного сложнее чем todo | wip | done ?
Anton
если например
todo | анализ | проектировка | ковыряние в носу | еще стопитсот колонок | кодинг | тестинг
Anton
и тестер по Вашему сценарию для изменения иконок местами - возвращает задачу в todo
Anton
и вся компания должна эскалировать задачу и разбираться что же там такое
Sasha
как то по схеме статусов которую вы описали казалось что статусов как раз таки мало
Anton
статусы - это дело такое
Anton
сегодня 3
Anton
завтро 10
Sasha
в таком случае возвращать не в ту ду а в статус "qa failed", да, это добавит новую колонку в ваши стопитсот, но вопрос с лимитом будет решен
Anton
и хотелось бы бест практис решения такого распространенного явления как возврат задачи
Anton
есть у кого-нибудь практический опыт такой штуки?
Sasha
на прошлой работе у меня такое было. кстати сказать, довольно успешно применялось) могу в лс описать
Igor
а зачем вам статусы?
Igor
обычно 100500 статусов - говорит о том что команда делит ответственность за задачи
Dmitry
у нас такой продукт, где в явном виде этот процесс не применить, это как если вы пишете драйвер - промежуточные шаги особо не посмотреть
всмысле такой продукт? пользователи у продукта есть какие-то?
Dmitry
@levinotti го в личку, если хочешь, а то тут уже другая тема, а мы мешаемся)
Andrey
иду, ага
Denis
Запутали людям все ноги
Andrey
мне?)
Denis
А они хотели бежать проворно
Denis
Как заяц
Dmitry
вопрос по формированию юзер стори: у нас сейчас тоже сложилась ситуация, когда анализика и дизайн идут на 1 спринт вперед, и вот почему: представитель заказчика не может быстро отвечать на вопросы, а так же не может воспринимать информацию фрагментами. Когда мы делали аналитику и дизайн в спринте, то на выходе всегда получали: а это почему так? а это почему так? а тут я бы хотел так... когда мы им стали показывать готовый дизайн - они на него смотрят, обдумывают. и часть требований корректируют. но на это надо им время. в итоге, именно разрабы бегут ровно более-менее, а на этапе согласования дизайна - тут бурление.
Dmitry
вот как "правильно" исправить ситуацию?
Dmitry
вопрос по формированию юзер стори: у нас сейчас тоже сложилась ситуация, когда анализика и дизайн идут на 1 спринт вперед, и вот почему: представитель заказчика не может быстро отвечать на вопросы, а так же не может воспринимать информацию фрагментами. Когда мы делали аналитику и дизайн в спринте, то на выходе всегда получали: а это почему так? а это почему так? а тут я бы хотел так... когда мы им стали показывать готовый дизайн - они на него смотрят, обдумывают. и часть требований корректируют. но на это надо им время. в итоге, именно разрабы бегут ровно более-менее, а на этапе согласования дизайна - тут бурление.
заказная разработка, увы, всегда подстраивается под заказчика
если у заказчик работает только так и никак иначе – наверно это правильный подход.
Можно попробовать его переубедить, потому что этот подход менее эффективный, но стоит ли – мне кажется, это вы должны понимать, потому что знаете весь контекст
Denis
Кто сказал, что дизайн — это легко?
Dmitry
ну тут только что было бурное обсуждение: аналитика и дизайнера в спринт и вперед
Dmitry
ну там не заказная разработка жж
Denis
Да и в продуктовой норм
Dmitry
и нету проблем с коммуникациями
там проблема, что программисты не знают, зачем код пишут )
Dmitry
да. и еще вопрос, туда же. пусть даже не заказная. бывает так, что дизайн ооооочень долго создается.
Dmitry
что в этом случае?
Dmitry
ну объективно, много работы бывает надо сделать.
Dmitry
я писал об этом, в этом же бурном обсуждении
Dmitry
ща
Dmitry
примитив, потом красоту?
Dmitry
дизайн прототип, который на Sprint Review показывается пользователям и тестируется – это инкремент.
Dmitry
но это, например, если мы хотим сделать несколько вариантов, потестить и потом чего-то решать.
Dmitry
а в ситуации, где, допустим, фича более очевидна и тестирование отдельно дизайна не оправдано, логичнее будет включить работы по дизайну в US самой фичи. И делать их в том же спринте, и инкрементом будет вся фича целиком
Dmitry
фактически, если у нас 1 аналитик и 2 дизайнера, их можно завернуть в отдельную команду и смотреть их инкремент?
Dmitry
инкремент можно, зачем в отдельную команду?
Dmitry
у нас 2 команды. посадить в одну - будет слишком большая. раскидать по разным - тогда как один дизайнер без аналитика?
Dmitry
по пол анлитика в команду?
Andrey
у нас не заказная разработка, но реально изза желания некоторых иметь на вход рафинированные истории, это выглядит как внутренняя заказная разработка
Dmitry
🤔
ну если хотить делить (или решить делить или нет), то есть отличный способ)
соберите всех в одной комнате и пусть поделятся
скорее всего, они поделятся хорошо
Dmitry
у нас не заказная разработка, но реально изза желания некоторых иметь на вход рафинированные истории, это выглядит как внутренняя заказная разработка
вопрос в том, чья это зона влияния
на заказчика мы влиять обычно не особо можем
на команду свою – вполне
надо или нет – обсуждаемый вопрос
Dmitry
ну у нас была раньше одна команда. когда она начала расти - мы поделились
Dmitry
размер: по 7 человек
Dmitry
сделать одну 10 чел - это нереально. мы разделились как раз на цифре 11. стало гораздо легче
Dmitry
ну, больше 10 человек, это плохо, да
я имею в виду "как" разделиться – может решить сама команда
Andrey
а где хорошие видосы и выступления на тему аджайл смотреть? - в архивах прошлых agile days?
Andrey
https://www.youtube.com/playlist?list=PLk8AWaxHcq7sJz5h0A30LbhNlxppMPONL да, так сходу и не поймешь в каком из видео может быть ответ
Slava
это как совет про n / 2
Anton
я еще ничего не вводил
Anton
это теория
Slava
лимиты нужны чтобы выровнять поток, а правильные они или нет можно увидеть на CFD
Anton
=)
Slava
ну в теории правильных лимитов не существует, а теоритическое ненарушение их вообще пустой разговор
Anton
да нет же
Anton
какие бы лимиты не были
Anton
рано или поздно
Anton
возникнет ситуация