Да. Я уже писал в 1й части — это из-за интеграции с FishEye и Bitbucket. И что в тексте комита должно быть название таска.
Вот так выглядит всплывающая форма при нажатии «3 commits»
(Данные из FishEye)
(Данные из Bitbucket)
А вот так, при нажатии на «2 reviews» (Данные из crucible )
Я натыкался на специализированные плагины, где можно настраивать рабочие часы, но сразу же их отмел т.к. часть программистов у нас ходит на одно время, а часть на другое.
А еще, ко всему прочему, кто-то может в какой-то день задержаться и поработать дольше.
Так что нет. Кнопку «В работе» надо отжимать всегда когда уходишь домой и утром опять нажимать.
Ну да. На текущий момент у нас 15 живых проектов. Все в гите.
Ну так как у нас контора не дизайнерская, а софтверная, то продуктом нашей работы обычно не бывают большие файлы.
Если это не продукт нашей разработки, а какой-то материал необходимый для разработки, то выкладываем мы его на наш внутренний ФТП, а в Jira даем на него ссылку.
Регрессионное тестирование обычно производится, когда все задачи версии закрыты. Программисты ответвляются в Git вновую ветку и начинают работы над следующей версией, а тестировщики проводят регресс.
У нас в Confluence есть статьи с чек-листами. Тестировщики обычно закреплены за определенными сферами проетка и проходят по этим чек-листам.
При найденных косяках обычно лид сразу же определяет по какой задаче это было сломано и задача переоткрывается.
После выпуска версии программисты начинают работы над следующей, а тестировщики тем временем актуализируют чек-листы.
Вот и получается, что тестить приходится дважды. А для качественных тестов порой времени тратится в несколько раз больше чем на разработку.
Наши тестировщики проводят всевозможные виды тестирования, которые отнимают ну очень много времени, но за то покрывают всё. Потому тратить время на два таких тестирования не целесообразно. Либо надо иметь тестировщиков в два раза больше чем программистов. Ну или тестировать только позитивным тестированием.
Возможно из-за перехода с svn, но мне кажется, что наш флоу удобнее.
1. У программиста не бывает задач дольше дня — нет смысла делать много комитов по одной задаче.
2. они так или иначе влияют на правки другого программиста — как тестировать? Опишите, пожалуйста, как тестируют у вас. И вообще есть тестировщики?
3. очень часто исправляются одни и те же файлы одновременно несколькими программистами — мержи и в нашем случаи неизбежны, но в случае с ветками 100% будут конфликты.
4. Работа всего коллектива не останавливается в случае отсутствия мастера.
Как я уже писал в части 2, любой программист может срочно исправить багу, и любой тестировщик может срочно собрать исправления и протестировать.
Пул реквест мы пробовали внедрять несколько раз, но ниразу не взлетел.
Ну повторюсь, что я не админ. Не исключено, что оно жрёт ресурсы сверх моих выделенных.
Но по графикам видно, что тяжелее всех именно Confluence.
Jira как то вообще замечательно себя ведёт.
Все немного не так. Про стеш я рыл много, но толкового описания не нашёл. Он и сейчас есть на сайте атласиана для скачивания, но только под Винду. У меня не было желания его ставить, чтобы удовлетворить любопытство. Когда я установил Bitbucket, я подумал, что стеш был просто репозиторием, а тут ещё и понятие проектов появилось…
Так как при подключении репозиториев к Fisheye, они светились именно как стеш репозитории, то я и сделал вывод, что стеш просто обернули в новую обертку.
Стараемся детально. Потому что при разночтениях сильно затягиваются сроки разработки из-за возвратов.
Часто мы создаём задачи без постановки в Confluence, но постановка в Jira — обязательна. Правда бывает так, у меня не хватает времени на ревизию постановки, приходится верить, что все все правильно поняли на словах.
Ну а у тестировщиков даже с нормальной постановкой вопросов хватает.
Да, схема показана средствами Jira.
Ну на самом деле у нас есть ещё один тип задач — документация. Для него у нас настроен стандартный workflow. Когда техпис видит задачу с типом «новая функциональность» или «изменение функциональности», он создаёт задачу типа «документация» и по ней отражает эту задачу во всех документах.
А документация тестируется тем же тестировщиков, который тестировал основную задачу.
1) мы стараемся формировать задачи так, чтобы её разработка не превышала раб дня.
2) вот по этому критерию мы и определяем качество работы программиста. Чем больше раз тестировщики возвращают задачу, тем хуже её реализовал программист. Хороший программист все делает чётко с первого раза. Конечно это не учитывая дополнительные возвраты из-за хотелок тестировщиков или ПМ-а. А вот различать типы возвратом Jira, увы, не умеет.
Наша средняя статистика показывает около 5-и возвратов. Но это так… Средняя температура по палате…
В вашем workflow используется пулл реквест. У нас — нет. У нас все программисты работают в dev ветке и тимлид раз на версию это все сливает в мастер ветку.
Честно говоря я так и не понял до сих пор как быть с тестированием в модели пулл реквеста.
GitLab как бы имеет и трекер и вики… но в функциональности они вообще рядом с Jira и Confluence не стоят. Читайте ЧАСТЬ 2. Такое на GitLabe не настроить.
Нет, его обязанности автоматически принимают другие.
ПМ — распределяет задачи и советуется с другими программистами — для оценки сроков.
Ревизию кода выполняет либо другой квалифицированный программист, либо вообще любой программист (джуниоров у нас нет, а увидеть чужой гуанокод способен любой).
Так что процесс затормаживается только условно. Критических работ, которые просто не делаются потому что ждут тимлида — нет.
1. Ну это к делу не относится. Но это и не секрет. Разрабатываем всевозможные web-системы. Соц сети, онлайн торги, платежные системы, почтовые системы и т.д. и т.п.
2. Пишем в основном на PHP+Postgresql, но бывают и исключения.
3. Правильно построенный workflow здорово облегчает жизнь всем участникам процесса разработки. И вот один из способов автоматизировать этот процесс по максимуму.
Пробовали разные системы, но пришли к выводу, что всем удобнее группы в скайпе: весь проект, программисты, тестировщики и лиды.
Jira благодаря «Automated Log Work for JIRA» автоматом логирует время. А у «WorkLog» отличные визуальные отчеты. Вот-вот опубликую вторую часть, там об этом есть.
TeamCity — не изучал. Но спасибо за наводку, посмотрю.
Вот так выглядит всплывающая форма при нажатии «3 commits»
(Данные из FishEye)
(Данные из Bitbucket)
А вот так, при нажатии на «2 reviews» (Данные из crucible )
А еще, ко всему прочему, кто-то может в какой-то день задержаться и поработать дольше.
Так что нет. Кнопку «В работе» надо отжимать всегда когда уходишь домой и утром опять нажимать.
Ну так как у нас контора не дизайнерская, а софтверная, то продуктом нашей работы обычно не бывают большие файлы.
Если это не продукт нашей разработки, а какой-то материал необходимый для разработки, то выкладываем мы его на наш внутренний ФТП, а в Jira даем на него ссылку.
У нас в Confluence есть статьи с чек-листами. Тестировщики обычно закреплены за определенными сферами проетка и проходят по этим чек-листам.
При найденных косяках обычно лид сразу же определяет по какой задаче это было сломано и задача переоткрывается.
После выпуска версии программисты начинают работы над следующей, а тестировщики тем временем актуализируют чек-листы.
Наши тестировщики проводят всевозможные виды тестирования, которые отнимают ну очень много времени, но за то покрывают всё. Потому тратить время на два таких тестирования не целесообразно. Либо надо иметь тестировщиков в два раза больше чем программистов. Ну или тестировать только позитивным тестированием.
1. У программиста не бывает задач дольше дня — нет смысла делать много комитов по одной задаче.
2. они так или иначе влияют на правки другого программиста — как тестировать? Опишите, пожалуйста, как тестируют у вас. И вообще есть тестировщики?
3. очень часто исправляются одни и те же файлы одновременно несколькими программистами — мержи и в нашем случаи неизбежны, но в случае с ветками 100% будут конфликты.
4. Работа всего коллектива не останавливается в случае отсутствия мастера.
Как я уже писал в части 2, любой программист может срочно исправить багу, и любой тестировщик может срочно собрать исправления и протестировать.
Пул реквест мы пробовали внедрять несколько раз, но ниразу не взлетел.
Юзеров тоже бекапить надо.
Но по графикам видно, что тяжелее всех именно Confluence.
Jira как то вообще замечательно себя ведёт.
Так как при подключении репозиториев к Fisheye, они светились именно как стеш репозитории, то я и сделал вывод, что стеш просто обернули в новую обертку.
Часто мы создаём задачи без постановки в Confluence, но постановка в Jira — обязательна. Правда бывает так, у меня не хватает времени на ревизию постановки, приходится верить, что все все правильно поняли на словах.
Ну а у тестировщиков даже с нормальной постановкой вопросов хватает.
Ну на самом деле у нас есть ещё один тип задач — документация. Для него у нас настроен стандартный workflow. Когда техпис видит задачу с типом «новая функциональность» или «изменение функциональности», он создаёт задачу типа «документация» и по ней отражает эту задачу во всех документах.
А документация тестируется тем же тестировщиков, который тестировал основную задачу.
2) вот по этому критерию мы и определяем качество работы программиста. Чем больше раз тестировщики возвращают задачу, тем хуже её реализовал программист. Хороший программист все делает чётко с первого раза. Конечно это не учитывая дополнительные возвраты из-за хотелок тестировщиков или ПМ-а. А вот различать типы возвратом Jira, увы, не умеет.
Наша средняя статистика показывает около 5-и возвратов. Но это так… Средняя температура по палате…
Честно говоря я так и не понял до сих пор как быть с тестированием в модели пулл реквеста.
GitLab как бы имеет и трекер и вики… но в функциональности они вообще рядом с Jira и Confluence не стоят. Читайте ЧАСТЬ 2. Такое на GitLabe не настроить.
ПМ — распределяет задачи и советуется с другими программистами — для оценки сроков.
Ревизию кода выполняет либо другой квалифицированный программист, либо вообще любой программист (джуниоров у нас нет, а увидеть чужой гуанокод способен любой).
Так что процесс затормаживается только условно. Критических работ, которые просто не делаются потому что ждут тимлида — нет.
2. Пишем в основном на PHP+Postgresql, но бывают и исключения.
3. Правильно построенный workflow здорово облегчает жизнь всем участникам процесса разработки. И вот один из способов автоматизировать этот процесс по максимуму.
Jira благодаря «Automated Log Work for JIRA» автоматом логирует время. А у «WorkLog» отличные визуальные отчеты. Вот-вот опубликую вторую часть, там об этом есть.
TeamCity — не изучал. Но спасибо за наводку, посмотрю.