маленькие баг фиксы на планировании спринта?
Pavel Aksonov
действительно небольшие, но их надо
читать, разбираться. репродьюсить -
делать это на планировании, значит
фактически включать баг-фиксирование
в планирование (чтобы понять во
сколько это оценить). То есть проблемы
две:
1. Затягивается планирование. Для того
чтобы прочитать, объяснить всем,
разобраться и проголосовать-
согласовать уходит минимум 10-15 мин.
Получается если будет 20 маленьких баг
фиксов, то
это 200-300 минут только на фиксы, не
говоря о новой функциональности!
2. Мин. оценка - 1/2, а у нас сейчас один
"попугай" - это около 3 человеко-дней.
Даже если считать в "половино-попугаях"
все равно получится 0.75 человеко дня -
минимум. Понятно, что есть еще оценка 0 -
но это ведь не отобразит 2-3 часа работы?
А на самом деле все эти фиксы могут
взять 40 человеко часов без всякого
планирования. У меня есть один человек
который работает удаленно, без скрама,
я просто даю ему задачи. И часто
выходит так, что то что планируется и
оценивается командой в 0.5 - 1 попугая,
занимает у него несколько часов
работы. Конечно, может у него опыта
больше, а у команды - меньше, но ведь не
настолько
Каким Вы видите решение - не включать в
планирование? изменить "попугая"? что-
то другое?
Павел.
Artjom Serdyuk
Мы боролись с этим так:
1) набирали задач только на часть спринта, а оставщуюся часть отводили
под багфиксинг.
2) поскольку багом было много и они были мелкие, мы решили что один
баг примерно равень 6 часам, и набирали их просто по количеству. Если
баги сильно отличаются, предлагаю T-shirt sizes: S, M, L, XL, XXL -
для маленьких, средних, больших и очень больших багов (у вас такие
есть?? ;).
3) иногда, когда продакт оунер сознательно отказывался от фикса багов,
приходилось делать "стабилизацию". Т.е. один спринт мы фиксили только
баги, опять-таки не делая их оценку. Команда просто набирала столько,
сколько считала возможным сделать в спринте. Если был недобор -
добирали. Если был перебор, то как правило небольшой (2-3 бага с
невысоким приоритетом из 30), что было вполне приемлимо.
Tim Yevgrashyn
по поводу оценок:
мы в какой-то момент провели "инфляцию" наших оценок, когда поняли, что у нас много таких "мелких" фиксов или просто фич на пару часов работы.
Сначала мы тоже думали, что 1 поинт это на 2 дня работы и т.п. После того, как мы взяли выборку сделанных Issue и попробовали оценить их заново, то у нас получилось 1 день ~3 поинта. Т.е. 2 - это явно меньше дня, а 3 можем быть чуть больше. Опять же, мы используем сравнение при оценке в SP, а про дни я говорю исходя из усредненной статистики ;-)
Может это вам поможет по другому взглянуть на оценки и тем самым получить простор "быстрой" оценки багов, что позволит их планировать.
Однозначно на планировании (или еще до него?!) вам нужно дать быструю оценку "размера" бага и тогда при планировании спринта вы можете уже думать сколько и чего взять. Дальше уже баланс между багами и фичами на совести Владельца Продукта или фиксированный резерв, как предложил Артем.
Еще отдельный коммент по поводу "пожарника" (т.е. отдельно выделенного человека) - это хорошо, если он один из команды и вы его меняете время от времени. Тогда знания по прежнему шарятся между членами команды и даже иногда возникает вдохновение о том как избавиться от багов.
Если же человек сидит "где-то там" и его никто не видит, то это может иметь обратный эффект. Команда не осознает своих проблем и не делает багов меньше. Более того, быстрые фиксы, которые делает этот мифически удаленный человек, потом могут вылиться в полную переделку командой (под новую фичу, например). Как результат не зная о причине бага, они опять его породят новыми фичами или как минимум потратят дополнительное время на разработку новой фичи путем переделки старого бага....
В общем, это нужно очень внимательно продумать и не в коем случае не "аутсорсить".
Tim Yevgrashyn,
Web: http://tim.com.ua
Skype: spidertim
Phone: +380 67 408 53 30
Artjom Serdyuk
Павел, расскажите про удаленного гуру! Зачем он вам нужен и почему так
далеко? И как вы его в свой процесс включили?
> 2009/6/30 Pavel Aksonov <akso...@gmail.com>
Pavel Aksonov
Из этой затеи ничего не вышло, я предложил разработку в офисе полгода назад используюя скрам. В итоге компания открыла офис в Киеве, я набрал команду, дело пошло. Постепенно удаленные разработчики уходят из проекта, сейчас осталось два (один проводит около 20 часов в месяц, а второй "пожарник" - до 170 часов).
Пожарник живёт в Китае, имеет огромный опыт в JSF, GWT и над этим работает. Баги фиксит свои, команда - свои :) Стараюсь давать ему автономные задания (компоненты). Также комнда изучает эти компоненты, чтобы небыло "незаменимых".
Пока я не нашёл нужного человека в Киеве, без китайца проект будет двигаться медленнее.
Tim Yevgrashyn
> Баги фиксит свои, команда - свои :)
Команда в Киеве работает по списку новых фич + своих багов + ничейных багов, которые они могут пофиксить - я правильно понял?
Китаец работает по списку своих багов + ничейных багов, которые он может пофиксить.
Вы можете свести все это в один Product Backlog и каждая команда планирует свой спринт, а время от времени синхронизируется. В идеале это Scrum of Scrums или просто некая синхронизация.
Наличие единого списка может помочь сделать видимым общее состояние дел. Плюс Киевская команда все-таки будет иметь возможность увидеть что же делается "за стеной" и со временем научиться делать не хуже. Т.е. возможно даже заберет себе все доработки.
P.S.
От себя лично, я бы предложил по разному называть Баги и Дефекты.
Лично я считаю, что Баги - это то, что нашли в ходе разработки нового и что не дает нам сказать "мы сделали эту фичу". Т.е. мы их поймали в ходе спринта до демо или даже баги помешали демонстрации фичи и мы их доделали и сдали фичу в следующем спринте.
Дефекты - это то, что нам приходит от реальных пользователей или заказчиков. Система работает, живет, и тут они решают, что она работает не так как им хочется. Даже если они заявляют, что это ошибка, то не факт, что это примитивная опечатка в коде - чаще всего это не правильная реализация их ожиданий или просто ожидания поменялись.
В первом случае, Баги - это таски (саб-таски) в рамках одной истории. Команда их сама создает
Во втором случае, Дефекты - это такие же элементы Продукт Бэклога и будут приоритезированы соответственно их критичности. Может они вообще будут ждать годами, так как вероятность нахождения этой проблемы реальным пользователем стремится к нулю ;-)
Alimenkou Nikolay
такой, когда и баг и дефект находятся в бэклоге как полноправные
элементы. Так же приоритезируются и планируются. Только на
планировании не стоит копать в каждый баг чтобы сделать более точную
оценку. Просто набрали пучок в порядке очереди на столько, сколько
готовы выделить и работаете над ними. Опять таки как над полноценными
задачами. Теперь 2 более сложных случая:
1. Баги очень мелкие и получается много задач и вроде как все на 0, а
в сумме куча времени. Для решения проблемы баги объединять в пучки по
0.5 и выставлять как единую задачу.
2. Баг "хер знает сколько займет, но сука очень критичный".
Разбивается на две стадии: анализ и написание тестов (оценивается
сначала в 0.5) и исправление, которое может и не понадобиться если в
результате анализа все оказалось легко. Исправление оценивается
отдельно по результатам анализа. Это и есть критерий DONE для задачи
анализа. Если за 0.5 не справились, то собираетесь и решаете что
важнее продолжать или отложить.
И в любой стратегии починки багов есть свои минусы, особенно в
"пожарнике". Мне кажется что если работать с багами как с задачами, то
их может и фиксить не придется (функциональность приоритетнее :)).
И на последок главное: надо разрабатывать так чтобы вся команда была
QA, а только ПО являлся QC. Тогда все что вам грозит - это не баги а
ченж реквесты.
On Jul 1, 5:44 pm, Tim Yevgrashyn <yevgras...@gmail.com> wrote:
> Павел,
>
> 2009/7/1 Pavel Aksonov <akso...@gmail.com>
>
>
>
> > Краткая история проекта - его делали удаленно без скрама, в основном
> > бла-бла-бла по емейлу о разных архитектурах и т.д. и так почти два года. Я
> > был простым исполнителем, так как оказался от роли тим-лида, считая это
> > невозможным - все сидели отдельно, почти не пересекались в онлайне и т.д.
>
> > Из этой затеи ничего не вышло, я предложил разработку в офисе полгода назад
> > используюя скрам. В итоге компания открыла офис в Киеве, я набрал команду,
> > дело пошло. Постепенно удаленные разработчики уходят из проекта, сейчас
> > осталось два (один проводит около 20 часов в месяц, а второй "пожарник" - до
> > 170 часов).
>
> > Пожарник живёт в Китае, имеет огромный опыт в JSF, GWT и над этим работает.
> > Баги фиксит свои, команда - свои :) Стараюсь давать ему автономные задания
> > (компоненты). Также комнда изучает эти компоненты, чтобы небыло
> > "незаменимых".
>
> > Пока я не нашёл нужного человека в Киеве, без китайца проект будет
> > двигаться медленнее.
>
> > 2009/7/1 Artjom Serdyuk <artem.serd...@gmail.com>
> ...
>
> read more >>
Alexey Maslov
Regards,
Alexey Maslov