Dmitry
YouTrack довольно удобный. https://www.jetbrains.com/youtrack/
Не бесплатный, но дешевле JIRA в разы
Oleg
Oleg
Но я очень уважаю JetBrains, хорошие русские ребята
Dmitriy
Марина, а сколько стоило обслуживание вот такой Jira yf 300 человек. Кто в этом случае настройками занимался?
Я сталкивался с Jira только как пользователь внутри большой компании 2к+ Соответственно у нас были специально обученные люди, которые настраивали инструмент
С пользовательской точки зрения меня напрягала пара вещей
- мы, как команда не могли самостоятельно поменять процесс (например, добавить колонку ревью).
- работало всё не очень быстро из-за огромного количества задач в базе
У нас занимаются админы, они справляются, как раз порядка 200 человек пользователей.
Можно сделать доступ к админ. ресурсу, чтобы сами меняли воркфлоу, поля и т.п. Нет проблемы здесь особой, если очень нужно.
Вопрос с огромным кол-вом задач и тормозами, скорее вопрос к тому, как обслуживается jira, если вообще обслуживается.
Vladimir
Dmitriy
Dmitriy
Да, я полагаю, что в рамках компании это было правильное решение. Но нашей команде создавало некоторые неудобства
Мы сейчас работаем по 2 воркфлоу, это плюс к тому, что одной из новых команд не пришлось перестраиваться и она не потеряла в скорости разработки - не путалась, не ошибалась. С другой стороны, мы работаем над общим воркфлоу, который должен будет включить в себя лучшее из каждого.
Тем не менее, пока каждый при своем и всех все устраивает, т.к. нет кардинальных различий, и все статусы похожи, за небольшими отклонениями, конечно.
Если вы можете обосновать необходимость нескольких воркфлоу для ускорения процесса, то и карты в руки, могут пойти навстречу, а если обоснований мало, уж как есть)
Vladimir
Мы сейчас работаем по 2 воркфлоу, это плюс к тому, что одной из новых команд не пришлось перестраиваться и она не потеряла в скорости разработки - не путалась, не ошибалась. С другой стороны, мы работаем над общим воркфлоу, который должен будет включить в себя лучшее из каждого.
Тем не менее, пока каждый при своем и всех все устраивает, т.к. нет кардинальных различий, и все статусы похожи, за небольшими отклонениями, конечно.
Если вы можете обосновать необходимость нескольких воркфлоу для ускорения процесса, то и карты в руки, могут пойти навстречу, а если обоснований мало, уж как есть)
Хм, это несколько странно слышать в чате по Agile. Ведь этот подход применим и к самому рабочему процессу.
Решила наша команда на ретро, что нам нужно дополнительное ревью и мы его может добавить. А через пару недель увидеть, что пользы от него нет никакой и опять выкинуть. При этом говоря о команде, я подразумеваю небольшую группу людей 5-7 человек. Сложно представить, что в рамках одной компании можно сделать один универсальный и удобный процесс для 200 человек.
Dmitry
+1
у команды должна быть возможность в любой момент поменять свой процесс
Dmitriy
Dmitry
ну тут вопрос не в джире, мне кажется, а в том, кто ее админит и как он относится к своим пользователям)
там не так уж сложно воркфлоу перенастроить
Dmitriy
Alexandr
единый и клевый вокфлоу для всех - мне чем то напоминает самообман водопада ) сейчас как мы опишем все требования сразу :)
Igor
не стоит добавлять дополнительные статусы в воркфлоу жиры - эти статусы станут парковочными.
Igor
чаще всего кроме to do - in progress - done
Dmitry
Вопрос: кто-то знает качественные каналы и чаты для сис/,биз аналитиков?
Igor
ничего не нужно.
✙ Ivan
я, например, сам администрирую джиру. В зависимости от проекта и задач. Потом это легко ассайнится на проекты и все хорошо.
Eduard
Всем доброго дня! Начинаем использовать методологию SCRUM для ведения образовательных и иных проектов на факультете. Подскажите, если кто знает, где приобрести доску, чтобы можно было вешать задачи по столбцам?
Иван
эммм METRO ))
Стас Щетинников
Иван
можно миллиметровку бумагу растянуть и фломастерами уже разлиновать и украсить
Стас Щетинников
Стас Щетинников
вот так выглядит ;)
Андрей
Зачем вам столько стикеров в done?)
Стас Щетинников
Историческое наследие, сейчас конечно, оно бесполезно, но все все-равно переклеивают)
Андрей
Выглядит эпично) Можно хвастаться мол вот как много мы сделали
Shamil ☘️
Shamil ☘️
а можно вот так на листах для флипчарта
Shamil ☘️
длительность спринта - 1 неделя
на доске один спринт
Shamil ☘️
малингвые стикеры - эпики
Shamil ☘️
но это было 2 года назад.. мы быстро перешли от реальной доски к JIRA так как реальную доск сложно поддерживать, если в команде много удаленных сотрудников
Eduard
Shamil, понял, спасибо!!!
Dmitry
Я скорее не про то, чтобы набрасываться всей командой, а про то, чтобы пулить из бэклога спринта верхнюю задачу, когда освобождаешься
Иначе можно попасть в ситуацию, когда одна задача окажется сложнее, чем предполагалось и вся очередь на этого человека застопорится
Не бывает таких проблем?
Shamil ☘️
регулярно(
Стас Щетинников
Такие проблемы мы решаем на стендапах. Если разработчик понял, что "встрял", команда приходит ему на помощь и какую часть оставшихся задач раскидывается на тех, у кого есть free capacity.
Dmitry
Shamil ☘️
а как быть в том случае, когда он встрял с проблемой, с которой может справиться только он, уникальный специалист?
Igor
устранять его уникальность надо
Dmitry
+1)
Стас Щетинников
Потому что вот у нас ситуации, когда приходиться помог - достаточно редки. А для тех, кто все успел - есть приоритизированный беклог с задачами, которые бы хотелось сделать.
Dmitry
bus-factor = 1 это плохо
Dmitry
Dmitry
то надо на стендапе решать
Dmitry
а так, это никак не повлияет на общую ситуацию
Shamil ☘️
Так это преопределение не вечное
Shamil ☘️
заболел - ушла таска на другого
Igor
вы создаете дисфункцию на ровном месте :) нельзя разделять таски по конкретным исполнителям
Igor
сразу все из команды становятся группой индивидуумов
Igor
каждый пилит что то свое
Dmitry
вот да, мне кажется это
1) лишняя трата времени на первоначальное распределение
2) проблемы при переназначении тасков, если надо
Igor
в каком то виде это долгосрочное планирование
Alexandr
интересная кстати тема, конечно в идеальном мире гибкой разработки все кроссфункциональны и почти любой из команды может взять любую таску, но на практике все равно есть люди, которые знают определенные части лучше других, и даже когда идет оценка спринта мы часто учитывали кто ориентировочно будет делать эту задачу, т.к. оценки могут варироваться значительно, интересно как у других: понятно что оценивать должна вся команда, но разве нет прикидки кто вероятнее будет делать задачу? или это уже не true agile? )
Dmitry
ну, мы специально боролись с тем, чтобы на планировании учитывать кто будет делать задачу
Dmitry
и еще старались, чтобы задачу брал тот, кто меньше знает про эту часть системы
Alexandr
интересный подход, на первый взгляд контринтуитивный, но возможно оч клевый :) и как результат? вся команда одинаково стала разбираться в системе?
Dmitry
ну в целом да
Dmitry
результат очень клевый получился
Dmitry
оценки почти всегда сходятся и реально никто не знает, кто займется задачей, но все успеваем)
Shamil ☘️
а если не секрет, что разрабатываете?
Dmitry
платформу для автоматизации интернет рекламы
Alexandr
но все равно в команде есть же разного уровня спецы? один ее сделает быстрее другой медленее, даже не зависимо от домена, получается оценка всегда будет ориентирована на самых слабых?
Alexandr
хотя если оценки в стори пойнтах, то наверное просто у более опытных будет большая производительность за спринт
Dmitry
да, оценки в стори поинтах
Igor
Стас Щетинников
> сразу все из команды становятся группой индивидуумов
Прям так чтобы сразу - нет, я такого не наблюдал. ;) Все-таки командный дух и групповая динамика не особо зависят от того, как распределяются задачи (по моему опыту). Тем более, что в планировании участвует вся команда и совместно решается кому, что достанется.
Victor
подскажите, пожалуйста. как показать на демо резульат задачи по бекенду? бывает же такое, что не продемонстрировать. как быть на демо?
Igor
Victor
здорова)))
Victor
Внешний клиент
Igor
ну как так что им не показать?
Igor
апи вызовы?
Victor
Задача:
В профиле пользователя указано имя и фамилия, но разделяются они уже в приложении (исходя из пробела, т.е. возможны ошибки). Необходимо изначально хранить имя фамилию раздельно
Что имеем в результате:
Имя фамилия хранятся отдельно, ошибок при отображении в профиле в будущем быть не должно.
Victor
например
Igor
покажите апи вызовы разработчикам которые делают фронтенд