Игрофикация багфикса. Кейс одной компании (Максим Коробцев, AgileDays-2014) — различия между версиями
Материал из 0x1.tv
StasFomin (обсуждение | вклад) (Batch edit: replace PCRE \[([^\s]+) Страничка доклада на сайте конференции\] with {{ConferencePage|$1}}) |
StasFomin (обсуждение | вклад) |
||
* [http://habrahabr.ru/company/odnoklassniki/blog/220329/ Статья по теме доклада на хабре]
[[File:Dilbert-Bugfix-Gamification.gif|center]]
<!-- <blockquote>[©]</blockquote> -->
<references/>
[[Category:AgileDays-2014]]
[[Category:Геймификация]]
[[Category:Agile process]]
[[Category:История из практики]]
<!-- topub -->
{{stats|youtube_plays=63|refresh_time=2017-06-12T01:30:46.046932|vimeo_plays=41}} |
Версия 22:00, 11 июня 2017
Содержание
Аннотация
- Докладчик
- Максим Коробцев
У любой компании, занимающейся разработкой ПО, всегда есть определённое количество накопившихся ошибок. Не важных багов, которые всегда исправляются перед выходом в релиз, а скорее недоделок, представляющих собой этакий технический долг, который копится и копится, но который в конечном счёте нужно выплачивать.
Проект с большим количеством багов всегда тяжело поддерживать, он вызывает негатив у пользователей. И нет такой софтверной компании, в которой это было бы не так. Если вы откроете у себя JIRA и посмотрите фильтр Created vs Resolved, т. е. соотношение созданных и исправленных багов, вы увидите непрерывно возрастающий график. Это означает, что неисправленных багов с течением времени становится только больше. Исправлять старые баги большая головная боль. Их приоритет всегда ниже, чем у новых проектов, и нередко бывает так, что они остаются ничьи сотрудник уже в компании не работает, а баг остался.
Цель у этого доклада рассказать, как можно исправить ситуацию. Причём рассказать не просто на пальцах, а на конкретном примере того, что мы сделали в одной компании.
Видео
Слайды
Примечания и отзывы
Plays:104 Comments:0