Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Т.е. нет такого человека, без которого рабочий процесс может остановиться.
А как же вариант форсмажора/болезни человека? Рабочий процесс не может быть остановлен по определению, а только заторможен. Болезнь того же тимлида автоматически сдвигает все работы, разве нет?
Нет, его обязанности автоматически принимают другие.
ПМ — распределяет задачи и советуется с другими программистами — для оценки сроков.
Ревизию кода выполняет либо другой квалифицированный программист, либо вообще любой программист (джуниоров у нас нет, а увидеть чужой гуанокод способен любой).
Так что процесс затормаживается только условно. Критических работ, которые просто не делаются потому что ждут тимлида — нет.
ПМ — распределяет задачи и советуется с другими программистами — для оценки сроков.
Ревизию кода выполняет либо другой квалифицированный программист, либо вообще любой программист (джуниоров у нас нет, а увидеть чужой гуанокод способен любой).
Так что процесс затормаживается только условно. Критических работ, которые просто не делаются потому что ждут тимлида — нет.
Очень интересная статья. По ходу прочтения возникли вопросы:
1) Сколько по времени обычно занимает задача в работе(шаг 4)?
2) Как много шагов проходит задача до завершения? (всего их 10, но с учетом повторений 50?)
1) Сколько по времени обычно занимает задача в работе(шаг 4)?
2) Как много шагов проходит задача до завершения? (всего их 10, но с учетом повторений 50?)
1) мы стараемся формировать задачи так, чтобы её разработка не превышала раб дня.
2) вот по этому критерию мы и определяем качество работы программиста. Чем больше раз тестировщики возвращают задачу, тем хуже её реализовал программист. Хороший программист все делает чётко с первого раза. Конечно это не учитывая дополнительные возвраты из-за хотелок тестировщиков или ПМ-а. А вот различать типы возвратом Jira, увы, не умеет.
Наша средняя статистика показывает около 5-и возвратов. Но это так… Средняя температура по палате…
2) вот по этому критерию мы и определяем качество работы программиста. Чем больше раз тестировщики возвращают задачу, тем хуже её реализовал программист. Хороший программист все делает чётко с первого раза. Конечно это не учитывая дополнительные возвраты из-за хотелок тестировщиков или ПМ-а. А вот различать типы возвратом Jira, увы, не умеет.
Наша средняя статистика показывает около 5-и возвратов. Но это так… Средняя температура по палате…
как техпису было бы интересно почитать про автоматизацию процесса документирования. но чето у вас эта тема не раскрыта. но опять же, как техпис, скажу, что вам нужно что-то делать с рисованием схем\диаграмм, хотя бы разъединять входящие\исходящие стрелки, а то вообще ниче не понятно. или все связи двунаправленные или все данные для процессов только входящие, а исходящих нету. такие процессы-кадавры, all in :)
Это картинка из Jira. Живой воркфлоу. Она такая, какая есть :)
Да, схема показана средствами Jira.
Ну на самом деле у нас есть ещё один тип задач — документация. Для него у нас настроен стандартный workflow. Когда техпис видит задачу с типом «новая функциональность» или «изменение функциональности», он создаёт задачу типа «документация» и по ней отражает эту задачу во всех документах.
А документация тестируется тем же тестировщиков, который тестировал основную задачу.
Ну на самом деле у нас есть ещё один тип задач — документация. Для него у нас настроен стандартный workflow. Когда техпис видит задачу с типом «новая функциональность» или «изменение функциональности», он создаёт задачу типа «документация» и по ней отражает эту задачу во всех документах.
А документация тестируется тем же тестировщиков, который тестировал основную задачу.
Насколько детально вы описываете требования? Если задача идет сразу без этапа постановки в Jira, не возникает ли проблем у тестировщиков типа «как это тестировать, требований нет»?
Стараемся детально. Потому что при разночтениях сильно затягиваются сроки разработки из-за возвратов.
Часто мы создаём задачи без постановки в Confluence, но постановка в Jira — обязательна. Правда бывает так, у меня не хватает времени на ревизию постановки, приходится верить, что все все правильно поняли на словах.
Ну а у тестировщиков даже с нормальной постановкой вопросов хватает.
Часто мы создаём задачи без постановки в Confluence, но постановка в Jira — обязательна. Правда бывает так, у меня не хватает времени на ревизию постановки, приходится верить, что все все правильно поняли на словах.
Ну а у тестировщиков даже с нормальной постановкой вопросов хватает.
Если описание задачи «годное», то это и есть требования :)
благодаря плагину “Automated Log Work for JIRA” автоматически запускается счетчик логирования времени, который останавливается и сохраняет набежавшее значение при переводе задачи в другие статусы
Время логируется так, как-будто программист работает над задачей 24 часа в сутки или есть какие-то условия, что из суток логировать только 8 часов (или что-то подобное)?
Я натыкался на специализированные плагины, где можно настраивать рабочие часы, но сразу же их отмел т.к. часть программистов у нас ходит на одно время, а часть на другое.
А еще, ко всему прочему, кто-то может в какой-то день задержаться и поработать дольше.
Так что нет. Кнопку «В работе» надо отжимать всегда когда уходишь домой и утром опять нажимать.
А еще, ко всему прочему, кто-то может в какой-то день задержаться и поработать дольше.
Так что нет. Кнопку «В работе» надо отжимать всегда когда уходишь домой и утром опять нажимать.
В JIRA одной из картинок видно, что с таском связано 17 комитов? За счёт чего достигнуто? Интеграция с crucible?
У нас интеграция со Stash, комиты отражены в JIRA только если в тексте комита есть названия таска (AGILE-33, BUG-123).
У вас просто принято за основу писать в каждый комит таск или это достигнуто за счёт других фич? Или так работает интеграция с crucible (учитываются все комиты в ветке, которая была создана из таска)?
У нас интеграция со Stash, комиты отражены в JIRA только если в тексте комита есть названия таска (AGILE-33, BUG-123).
У вас просто принято за основу писать в каждый комит таск или это достигнуто за счёт других фич? Или так работает интеграция с crucible (учитываются все комиты в ветке, которая была создана из таска)?
А как у вас с регрессионным тестированием?
Регрессионное тестирование обычно производится, когда все задачи версии закрыты. Программисты ответвляются в Git вновую ветку и начинают работы над следующей версией, а тестировщики проводят регресс.
У нас в Confluence есть статьи с чек-листами. Тестировщики обычно закреплены за определенными сферами проетка и проходят по этим чек-листам.
При найденных косяках обычно лид сразу же определяет по какой задаче это было сломано и задача переоткрывается.
После выпуска версии программисты начинают работы над следующей, а тестировщики тем временем актуализируют чек-листы.
У нас в Confluence есть статьи с чек-листами. Тестировщики обычно закреплены за определенными сферами проетка и проходят по этим чек-листам.
При найденных косяках обычно лид сразу же определяет по какой задаче это было сломано и задача переоткрывается.
После выпуска версии программисты начинают работы над следующей, а тестировщики тем временем актуализируют чек-листы.
У вас все проекты в Git помещаются?
Что делаете с тяжелыми фалами, если это фотошоп-дизайн, например?
Что делаете с тяжелыми фалами, если это фотошоп-дизайн, например?
Ну да. На текущий момент у нас 15 живых проектов. Все в гите.
Ну так как у нас контора не дизайнерская, а софтверная, то продуктом нашей работы обычно не бывают большие файлы.
Если это не продукт нашей разработки, а какой-то материал необходимый для разработки, то выкладываем мы его на наш внутренний ФТП, а в Jira даем на него ссылку.
Ну так как у нас контора не дизайнерская, а софтверная, то продуктом нашей работы обычно не бывают большие файлы.
Если это не продукт нашей разработки, а какой-то материал необходимый для разработки, то выкладываем мы его на наш внутренний ФТП, а в Jira даем на него ссылку.
Я правильно понял, что задача, проходя по workflow, периодически меняет исполнителя, и кто на каком этапе что делал можно понятьтолько по логу?
Является ли это проблемой? Нет ли желания видеть, чья задача? В каком виде в Jira видно, кто чем и насколько был загружен за какой-то период времени?
У закрытых на любом предыдущем этапе задач исполнителем назначается диспетер? Автоматически? На исполнителях-диспетчерах висят задачи пачками, те их раскидывают по исполнителям очередных этапов, и задачи возвращаются обратно исполнителям-диспетчерам?
Является ли это проблемой? Нет ли желания видеть, чья задача? В каком виде в Jira видно, кто чем и насколько был загружен за какой-то период времени?
У закрытых на любом предыдущем этапе задач исполнителем назначается диспетер? Автоматически? На исполнителях-диспетчерах висят задачи пачками, те их раскидывают по исполнителям очередных этапов, и задачи возвращаются обратно исполнителям-диспетчерам?
1. Да.
2. Нет не является. Чья задача на текущий момент? Потому что тим лид хочет видеть какого программиста задача (кто указан в поле программист), а QA лид хочет видеть какой тестировщик за нее отвечал (кто указан в поле тестировщик). На дашборд выводили для каждого список задач, ассигнованых сейчас на него. Плюс для ПМ-а список всех членов комманды с кол-вом задач на текущий момент на них назначенных. Если надо было проанализировать прошлое, использовали доп плагин.
3. Выше в статье писал, Диспетчерами являются только ПМ, тимлид и QA-лид (последний только если тестировщик на задачу еще не определен). Потом все уже знают всех кто с этой задачей связан и переводят на них напрямую.
2. Нет не является. Чья задача на текущий момент? Потому что тим лид хочет видеть какого программиста задача (кто указан в поле программист), а QA лид хочет видеть какой тестировщик за нее отвечал (кто указан в поле тестировщик). На дашборд выводили для каждого список задач, ассигнованых сейчас на него. Плюс для ПМ-а список всех членов комманды с кол-вом задач на текущий момент на них назначенных. Если надо было проанализировать прошлое, использовали доп плагин.
3. Выше в статье писал, Диспетчерами являются только ПМ, тимлид и QA-лид (последний только если тестировщик на задачу еще не определен). Потом все уже знают всех кто с этой задачей связан и переводят на них напрямую.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматизация workflow небольшой команды разработки (Часть 2)