Доклад от меня. Прозвучал на конференции разработчиков.
Я рассказал о том, как мы адаптировали практики экстремального программирования и Scrum для своих нужд, как распланировано время итерации, как команда разработчиков взаимодействует с командой тестировщиков и другие вопросы, касающиеся организации разработки.
Другие доклады с этой конференции http://blog.byndyu.ru/2010/10/blog-post.html
А почему вконтакте плеер? :)
ОтветитьУдалить@blog
ОтветитьУдалитьЯ ждал этот вопрос :) Vimeo отказался третье подряд видео добавлять. Поэтому пока такое плеер, потом в Vimeo закачаю и заменю.
опечатка - Я расскал о том
ОтветитьУдалить@neodim
ОтветитьУдалитьИсправил, спасибо.
Еще раз все одно и тоже рассказали...
ОтветитьУдалитьХотя презентация с днями недели - хорошая задумка...
Про технические долги смешно очень... Вы и правду не писали код, который будет только работать на Oracle на для MsSql сервер уже нет? Только не говорите, что универсальность важнее оптимизации?
@Mik
ОтветитьУдалить> Вы и правду не писали код, который будет только работать на Oracle на для MsSql сервер уже нет?
Писали, но это код был обязательно локализован.
> Только не говорите, что универсальность важнее оптимизации?
Зависит от проекта.
@Mik
ОтветитьУдалитьЯ только поверхностно коснулся проблемы технических долгов. Развернуто написано здесь http://blog.byndyu.ru/2008/12/blog-post.html
Спасибо за отличный доклад. Вы Алекасндр, отличный докладчик. После Вашего доклада я понял что у нас на работе совсем не Agile,от этого подхода только понятие итерации есть.
ОтветитьУдалить@Кичук
ОтветитьУдалитьИтерации - это уже хорошо :) Если буду вопросы по применению других практик, то можете писать мне на почту или обращайтесь в гугл-группу.
Хороший доклад, спасибо.
ОтветитьУдалитьУ нас тоже не Скрам. :) Мы долго парились с временем, но в результате забили на него вовсе. Команда еще не достаточно зрелая.
Я так понимаю вы никаких коэффициентов не вводите, как положили по 8 попугаев на человека так и работаете. Бурндаун чарты рисуете?
Итерации у вас достаточно короткие. Видимо поэтому у вас не возникает необходимости в перепланировании, при досрочном завершении итерации и тд. :)
Отдельные истории вы уже никак не фрагментируете?
А тестировщик может вернуть историю обратно в разработку? или все недочеты устраняются в фазе тестирования?
Я так понял, что у вас вебприложения?
Сори за много вопросов. :) очень интересно.
@Андрей Валяев
ОтветитьУдалить> Я так понимаю вы никаких коэффициентов не вводите, как положили по 8 попугаев на человека так и работаете.
Я думаю, что понятия "идеальный час" уже достаточно и коэффициенты лишние.
> Бурндаун чарты рисуете?
Раньше постоянно рисовали. Месяца 2 назад перестали и не даже этого не заметили. Возможно еще вернемся к этой практике.
> Итерации у вас достаточно короткие
Мы начинали с 3х недель, потом стало 2 недели и наконец поняли, что самое оптимальное для нашей команды - 1 неделя. Очень быстрая обратная связь ну и т.д., вы в курсе :)
> Отдельные истории вы уже никак не фрагментируете?
Если история оценена в 5 или тем более в 8 единиц, то разбиваем, иначе не разбиваем.
> А тестировщик может вернуть историю обратно в разработку?
Да, такое частенько бывает. Тестировщик тестирует раза в 2 быстрее, чем разработчик это карточку делает, поэтому разработка-тестирование-возврат-тестирование проходит в рамках одной итерации.
> Я так понял, что у вас вебприложения?
В основном да, через веб-интерфейс. Но так же есть WinForm, консольные приложения, сервисы.
Любую тему могу еще развернуть.
> Я думаю, что понятия "идеальный час" уже достаточно и коэффициенты лишние.
ОтветитьУдалитьА не бывает такого что разработчики оценивают работы с перекосом и это дело со временем компенсируется фокус фактором? :) Хотя сам уже вижу что сказал глупость... со временем разработчики просто начинают оценивать точнее и все.
>> А тестировщик может вернуть историю обратно в разработку?
> Да, такое частенько бывает.
А он при этом ошибку обратно в кодинг перевешивает? или в Todo? Или вы ее как-то оперативно лечите?
У нас в проекте немного своя специфика... серверное ПО на специально заточенной платформе. К тому же достаточно старое уже. Потихоньку пытаемся внедрять юниттесты. Интеграционное тестирование толком не проводится, достаточно сложно реализовать. Но думаем на эту тему...
Ваш опыт с полным покрытием багов - это здорово, но у нас пока не получится... может быть когда нибудь... :)
Пока что у нас обычная практика - разработчик с модулями идет на стенд, там их отлаживает и коммитит. Веток мы не юзаем почти, юзаем perforce (sic!), вот так и живем... :(
@Андрей Валяев
ОтветитьУдалить> со временем разработчики просто начинают оценивать точнее и все
Да, я вот прям так и думаю :) По мне лучше придти к более точным оценкам.
> А он при этом ошибку обратно в кодинг перевешивает?
В презентации Вадима этот самый вопрос задавали http://blog.byndyu.ru/2010/10/web.html
Суть в том, что мы пробовали различные варианты и пришли к следующей схеме. Если тестер нашел ошибку в карточке, которая разрабатывается в текущей итерации, то она сразу возвращается в Doing и передается обратно разработчику. Получается, что затраты на переключение между задачами не большие. Но если баг из предыдущих итераций вылез, то это уже пишется в отдельную карточку и исправляется в зависимости от критичности бага либо после завершения текущей карточки _любым_ из разработчиков (если критично), либо планируется в следующей итерации (если не критично).
> Интеграционное тестирование толком не проводится, достаточно сложно реализовать
А в чем сложность?
>> Интеграционное тестирование толком не проводится
ОтветитьУдалить> А в чем сложность?
Мы разрабатываем межсетевой экран. VPN там, всякое такое. Теоретически нужно научиться без участия человека разворачивать стенд, несколько машин... Мало развернуть, нужно еще воздействовать на систему различными способами.
Мы баловались со всякими виртуальностями, получается достаточно ненадежно. Пока находимся в процессе поиска.
Кстати только что мне пришла идея. Нам же не обязательно разворачивать все с нуля! достаточно внедрить в систему свежие модули! :)
@Андрей Валяев
ОтветитьУдалить> Мы баловались со всякими виртуальностями
Первая мысль, которую хотел посоветовать :)
Возможно кто-то из читателей этого блога сталкивался с такой проблемой. Можете закинуть эту тему в гугл-группу http://groups.google.ru/group/dotnetconf
А вот еще вопрос... как вы поступаете с багами. В презентации было, уточнить хочу. :)
ОтветитьУдалитьВот баг - природа бага не ясна - может решиться быстро, а может занять неделю.
Предположим что он признан некритичным и запланирован на следующую итерацию. Как его оценить в попугаях?
А если признан критичным и сдвинул все работы текущей итерации - он же может сорвать итерацию практически. :)
@Андрей Валяев
ОтветитьУдалить> Вот баг - природа бага не ясна... Предположим что он признан некритичным и запланирован на следующую итерацию. Как его оценить в попугаях?
Не помню случая, чтобы природа бага была не ясна. В любом случае сначала тестировщик пишет интеграционный тест, чтобы убедиться, что баг воспроизводится. Баг уходит в карточку и критерием завершения карточки является зеленый интеграционный тест.
Я могу предположить, что "природа бага не ясна" может быть, когда есть какие-то проблемы с окружением на живом сервере или какие-то проблемы с железом. Если так, что оценка должна быть по обычному сценарию: 1) обсуждение проблемы 2) голосование за "стоимость" в единицах 3) если решаем сразу, то встраивание в текущие карточки с уведомлением заказчика о сдвиге; если на след. итерации, то в порядке очереди с другими карточками.
> он же может сорвать итерацию практически
Ну да, баги они такие, они все могут :)
Хорошо вам... :) у нас весь девтрек набит всякими призраками...
ОтветитьУдалитьХотя это скорее всего говорит о состоянии всей кодовой базы... тестов практически нету, интеграционных тестов совсем нету. Надо с этим что-то делать. :)
@Андрей Валяев
ОтветитьУдалитьБез тестов вообще тяжело, я по себе помню.
На сколько целесообразно в вашем проекте сейчас начинать писать модульные и/или интеграционные тесты?
Ну поскольку жизненный цикл проекта, после более чем 10 лет разработки, успешно продолжается, я думаю, что в этом направлении стоит двигаться. Все не покроем, но жизнь наша, может быть, станет лучше. :)
ОтветитьУдалить