Byndyusoft — это заказная разработка ПО с гарантией результата

Создаем IT-продукты для e-commerce, ритейла, банков и других бизнесов по всему миру. Одни из лучших в стране по реализации высоконагруженных систем и микросервисной архитектуре.

Помимо непосредственной реализации IT-решений, создаем стратегию развития IT-продуктов.

Посмотрите, что говорят о нас клиенты и как комфортно мы стартуем проекты.

Для обсуждения проекта пишите на ceo@byndyusoft.com или звоните +7 (904) 305 5263

пятница, 1 октября 2010 г.

Материалы конференции разработчиков. Доклад «Организация работы команды в Agile: разработка + тестирование»

Доклад от меня. Прозвучал на конференции разработчиков.

Я рассказал о том, как мы адаптировали практики экстремального программирования и Scrum для своих нужд, как распланировано время итерации, как команда разработчиков взаимодействует с командой тестировщиков и другие вопросы, касающиеся организации разработки.


Другие доклады с этой конференции http://blog.byndyu.ru/2010/10/blog-post.html

20 комментариев:

  1. А почему вконтакте плеер? :)

    ОтветитьУдалить
  2. @blog
    Я ждал этот вопрос :) Vimeo отказался третье подряд видео добавлять. Поэтому пока такое плеер, потом в Vimeo закачаю и заменю.

    ОтветитьУдалить
  3. опечатка - Я расскал о том

    ОтветитьУдалить
  4. Еще раз все одно и тоже рассказали...
    Хотя презентация с днями недели - хорошая задумка...

    Про технические долги смешно очень... Вы и правду не писали код, который будет только работать на Oracle на для MsSql сервер уже нет? Только не говорите, что универсальность важнее оптимизации?

    ОтветитьУдалить
  5. @Mik

    > Вы и правду не писали код, который будет только работать на Oracle на для MsSql сервер уже нет?

    Писали, но это код был обязательно локализован.

    > Только не говорите, что универсальность важнее оптимизации?

    Зависит от проекта.

    ОтветитьУдалить
  6. @Mik
    Я только поверхностно коснулся проблемы технических долгов. Развернуто написано здесь http://blog.byndyu.ru/2008/12/blog-post.html

    ОтветитьУдалить
  7. Спасибо за отличный доклад. Вы Алекасндр, отличный докладчик. После Вашего доклада я понял что у нас на работе совсем не Agile,от этого подхода только понятие итерации есть.

    ОтветитьУдалить
  8. @Кичук
    Итерации - это уже хорошо :) Если буду вопросы по применению других практик, то можете писать мне на почту или обращайтесь в гугл-группу.

    ОтветитьУдалить
  9. Хороший доклад, спасибо.

    У нас тоже не Скрам. :) Мы долго парились с временем, но в результате забили на него вовсе. Команда еще не достаточно зрелая.

    Я так понимаю вы никаких коэффициентов не вводите, как положили по 8 попугаев на человека так и работаете. Бурндаун чарты рисуете?

    Итерации у вас достаточно короткие. Видимо поэтому у вас не возникает необходимости в перепланировании, при досрочном завершении итерации и тд. :)

    Отдельные истории вы уже никак не фрагментируете?
    А тестировщик может вернуть историю обратно в разработку? или все недочеты устраняются в фазе тестирования?

    Я так понял, что у вас вебприложения?

    Сори за много вопросов. :) очень интересно.

    ОтветитьУдалить
  10. @Андрей Валяев

    > Я так понимаю вы никаких коэффициентов не вводите, как положили по 8 попугаев на человека так и работаете.

    Я думаю, что понятия "идеальный час" уже достаточно и коэффициенты лишние.

    > Бурндаун чарты рисуете?

    Раньше постоянно рисовали. Месяца 2 назад перестали и не даже этого не заметили. Возможно еще вернемся к этой практике.

    > Итерации у вас достаточно короткие

    Мы начинали с 3х недель, потом стало 2 недели и наконец поняли, что самое оптимальное для нашей команды - 1 неделя. Очень быстрая обратная связь ну и т.д., вы в курсе :)

    > Отдельные истории вы уже никак не фрагментируете?

    Если история оценена в 5 или тем более в 8 единиц, то разбиваем, иначе не разбиваем.

    > А тестировщик может вернуть историю обратно в разработку?

    Да, такое частенько бывает. Тестировщик тестирует раза в 2 быстрее, чем разработчик это карточку делает, поэтому разработка-тестирование-возврат-тестирование проходит в рамках одной итерации.

    > Я так понял, что у вас вебприложения?

    В основном да, через веб-интерфейс. Но так же есть WinForm, консольные приложения, сервисы.

    Любую тему могу еще развернуть.

    ОтветитьУдалить
  11. > Я думаю, что понятия "идеальный час" уже достаточно и коэффициенты лишние.

    А не бывает такого что разработчики оценивают работы с перекосом и это дело со временем компенсируется фокус фактором? :) Хотя сам уже вижу что сказал глупость... со временем разработчики просто начинают оценивать точнее и все.

    >> А тестировщик может вернуть историю обратно в разработку?
    > Да, такое частенько бывает.

    А он при этом ошибку обратно в кодинг перевешивает? или в Todo? Или вы ее как-то оперативно лечите?

    У нас в проекте немного своя специфика... серверное ПО на специально заточенной платформе. К тому же достаточно старое уже. Потихоньку пытаемся внедрять юниттесты. Интеграционное тестирование толком не проводится, достаточно сложно реализовать. Но думаем на эту тему...

    Ваш опыт с полным покрытием багов - это здорово, но у нас пока не получится... может быть когда нибудь... :)

    Пока что у нас обычная практика - разработчик с модулями идет на стенд, там их отлаживает и коммитит. Веток мы не юзаем почти, юзаем perforce (sic!), вот так и живем... :(

    ОтветитьУдалить
  12. @Андрей Валяев
    > со временем разработчики просто начинают оценивать точнее и все

    Да, я вот прям так и думаю :) По мне лучше придти к более точным оценкам.

    > А он при этом ошибку обратно в кодинг перевешивает?

    В презентации Вадима этот самый вопрос задавали http://blog.byndyu.ru/2010/10/web.html
    Суть в том, что мы пробовали различные варианты и пришли к следующей схеме. Если тестер нашел ошибку в карточке, которая разрабатывается в текущей итерации, то она сразу возвращается в Doing и передается обратно разработчику. Получается, что затраты на переключение между задачами не большие. Но если баг из предыдущих итераций вылез, то это уже пишется в отдельную карточку и исправляется в зависимости от критичности бага либо после завершения текущей карточки _любым_ из разработчиков (если критично), либо планируется в следующей итерации (если не критично).

    > Интеграционное тестирование толком не проводится, достаточно сложно реализовать

    А в чем сложность?

    ОтветитьУдалить
  13. >> Интеграционное тестирование толком не проводится
    > А в чем сложность?

    Мы разрабатываем межсетевой экран. VPN там, всякое такое. Теоретически нужно научиться без участия человека разворачивать стенд, несколько машин... Мало развернуть, нужно еще воздействовать на систему различными способами.

    Мы баловались со всякими виртуальностями, получается достаточно ненадежно. Пока находимся в процессе поиска.

    Кстати только что мне пришла идея. Нам же не обязательно разворачивать все с нуля! достаточно внедрить в систему свежие модули! :)

    ОтветитьУдалить
  14. @Андрей Валяев
    > Мы баловались со всякими виртуальностями

    Первая мысль, которую хотел посоветовать :)

    Возможно кто-то из читателей этого блога сталкивался с такой проблемой. Можете закинуть эту тему в гугл-группу http://groups.google.ru/group/dotnetconf

    ОтветитьУдалить
  15. А вот еще вопрос... как вы поступаете с багами. В презентации было, уточнить хочу. :)

    Вот баг - природа бага не ясна - может решиться быстро, а может занять неделю.

    Предположим что он признан некритичным и запланирован на следующую итерацию. Как его оценить в попугаях?

    А если признан критичным и сдвинул все работы текущей итерации - он же может сорвать итерацию практически. :)

    ОтветитьУдалить
  16. @Андрей Валяев

    > Вот баг - природа бага не ясна... Предположим что он признан некритичным и запланирован на следующую итерацию. Как его оценить в попугаях?

    Не помню случая, чтобы природа бага была не ясна. В любом случае сначала тестировщик пишет интеграционный тест, чтобы убедиться, что баг воспроизводится. Баг уходит в карточку и критерием завершения карточки является зеленый интеграционный тест.

    Я могу предположить, что "природа бага не ясна" может быть, когда есть какие-то проблемы с окружением на живом сервере или какие-то проблемы с железом. Если так, что оценка должна быть по обычному сценарию: 1) обсуждение проблемы 2) голосование за "стоимость" в единицах 3) если решаем сразу, то встраивание в текущие карточки с уведомлением заказчика о сдвиге; если на след. итерации, то в порядке очереди с другими карточками.

    > он же может сорвать итерацию практически

    Ну да, баги они такие, они все могут :)

    ОтветитьУдалить
  17. Хорошо вам... :) у нас весь девтрек набит всякими призраками...

    Хотя это скорее всего говорит о состоянии всей кодовой базы... тестов практически нету, интеграционных тестов совсем нету. Надо с этим что-то делать. :)

    ОтветитьУдалить
  18. @Андрей Валяев
    Без тестов вообще тяжело, я по себе помню.

    На сколько целесообразно в вашем проекте сейчас начинать писать модульные и/или интеграционные тесты?

    ОтветитьУдалить
  19. Ну поскольку жизненный цикл проекта, после более чем 10 лет разработки, успешно продолжается, я думаю, что в этом направлении стоит двигаться. Все не покроем, но жизнь наша, может быть, станет лучше. :)

    ОтветитьУдалить

Byndyusoft — это заказная разработка ПО с гарантией результата

Создаем IT-продукты для e-commerce, ритейла, банков и других бизнесов по всему миру. Одни из лучших в стране по реализации высоконагруженных систем и микросервисной архитектуре.

Помимо непосредственной реализации IT-решений, создаем стратегию развития IT-продуктов.

Посмотрите, что говорят о нас клиенты и как комфортно мы стартуем проекты.

Для обсуждения проекта пишите на ceo@byndyusoft.com или звоните +7 (904) 305 5263