Еще со времени моего выступления на SQA Days в Казани мне хотелось поднять эту тему. Ну вот совсем не ожидала я, что в большинстве айтишных фирм одни и те же проблемы. Притом, вне зависимости от размера этих фирм: 20 в ней человек или 120, или 320. Иногда мне даже кажется, что у нас проблемы не в конкретной компании, а в отрасли в целом, но я гоню от себя эту шальную мысль.
Итак.
О чем это я? А я о процессах. Таких модных сейчас и актуально-гибких. А еще конкретнее: о процессе разработки фичи.
На той же конференции услышала замечательное слово "скрамнецо" от докладчика по Канбану. И как человек, который познал и скрам, и канбан во всякой степени распределенности командах, решилась это слово опровергнуть. Ибо если вы не любите скрам, значит, вы не умеете его готовить. Т.е. во всех собственных ошибках обвиняется процесс, хотя он-то тут не при чем :)
Итак, возьмем в качестве примера процесс разработки простейшей фичи на 2 стори-поинта
(для простоты определим их равными 16 человеко/часам) по скраму.
Предположим, что процесс разработки у нас выглядит так:
Из имеющихся 16 часов на разработку 2 у нас занимает анализ, 2 - проектирование, 8 - разработка и 4 - тестирование. Допустим, что написание контента, работа дизайнеров, верстальщиков и пр. включены в разработку.
Предположим, что тестировщики нашли баг. Или даже баги. Наш процесс разработки сразу же перестает быть идеальным и начинает выглядеть так:
Фича возвращается на доработку программистам и сразу же оказывается на доске на шаг назад, т.е. снова в стадии Разработка. И вот тут начинается самое интересное. Допустим, что баги у нас не очень большие и критичные. И еще допустим, что программист еще не успел переключиться на контекст другой задачи, и тихо-мирно пьет чай или ничего не подозревая играет в какой-нибудь теннис. Или все по очереди - 4 часа все-таки тестирование занимало.
В общем, нам повезло, мы словили программиста с незанятыми мозгами и посадили его править баги. Допустим, он смог их исправить за 2 часа. И еще час нам нужен на регрессию.
Итого общее время разработки фичи получается уже не 16 часов, а 19. Казалось бы: ну и что? Подумаешь, 3 лишних часа!
Но ведь у нас - идеальная фича! Мы еще не учли, что из стадии разработки фича может вернуться, например, на стадию проектирования. Или что у программиста прорвало трубу и он срочно убежал домой улыбаться сантехникам. Или даже вот такую ситуацию (взято из реальной жизни, кстати):
Как такое происходит? Все очень просто. Релиз здесь равняется показу заказчика (или ПМу). И он (заказчико-ПМ) сообщает, что вообще все себе не так представлял! И что дизайн надо поправить в 20 местах, тексты переписать, а вот тут не покупка должна быть, а продажа. Ну и мало ли что еще бывает в головах у ПМов :)
Несложно подсчитать, что на разработку фичи у нас уходит уже 19+19 = 36 часов (потому что возвраты на тестирование никто не отменял). 36 часов на простейшую 2-поинтовую фичу.
Что делали в свое время мы.
Сначала мы постарались избавиться от этих "возвратов".
Чтобы не было возвратов в этап анализа, мы стали проводить его только при участии всех заинтересованных лиц (ПМа, разработчика, тестировщика и пр.).
Чтобы не было возвратов на этап проектирования, оно проводилось при участии как минимум 2 разработчиков.
Чтобы снизить количество возвратов на этап разработки активнее использовались unit-тесты, парное программирование и даже (!!!) TDD.
А сколько часов на возвратах теряете вы? ;)
Итак.
О чем это я? А я о процессах. Таких модных сейчас и актуально-гибких. А еще конкретнее: о процессе разработки фичи.
На той же конференции услышала замечательное слово "скрамнецо" от докладчика по Канбану. И как человек, который познал и скрам, и канбан во всякой степени распределенности командах, решилась это слово опровергнуть. Ибо если вы не любите скрам, значит, вы не умеете его готовить. Т.е. во всех собственных ошибках обвиняется процесс, хотя он-то тут не при чем :)
Итак, возьмем в качестве примера процесс разработки простейшей фичи на 2 стори-поинта
(для простоты определим их равными 16 человеко/часам) по скраму.
Предположим, что процесс разработки у нас выглядит так:
Предположим, что тестировщики нашли баг. Или даже баги. Наш процесс разработки сразу же перестает быть идеальным и начинает выглядеть так:
В общем, нам повезло, мы словили программиста с незанятыми мозгами и посадили его править баги. Допустим, он смог их исправить за 2 часа. И еще час нам нужен на регрессию.
Итого общее время разработки фичи получается уже не 16 часов, а 19. Казалось бы: ну и что? Подумаешь, 3 лишних часа!
Но ведь у нас - идеальная фича! Мы еще не учли, что из стадии разработки фича может вернуться, например, на стадию проектирования. Или что у программиста прорвало трубу и он срочно убежал домой улыбаться сантехникам. Или даже вот такую ситуацию (взято из реальной жизни, кстати):
Как такое происходит? Все очень просто. Релиз здесь равняется показу заказчика (или ПМу). И он (заказчико-ПМ) сообщает, что вообще все себе не так представлял! И что дизайн надо поправить в 20 местах, тексты переписать, а вот тут не покупка должна быть, а продажа. Ну и мало ли что еще бывает в головах у ПМов :)
Несложно подсчитать, что на разработку фичи у нас уходит уже 19+19 = 36 часов (потому что возвраты на тестирование никто не отменял). 36 часов на простейшую 2-поинтовую фичу.
Что делали в свое время мы.
Сначала мы постарались избавиться от этих "возвратов".
Чтобы не было возвратов в этап анализа, мы стали проводить его только при участии всех заинтересованных лиц (ПМа, разработчика, тестировщика и пр.).
Чтобы не было возвратов на этап проектирования, оно проводилось при участии как минимум 2 разработчиков.
Чтобы снизить количество возвратов на этап разработки активнее использовались unit-тесты, парное программирование и даже (!!!) TDD.
А сколько часов на возвратах теряете вы? ;)
А в обновленном процессе разработка этой гипотетической двухпойнтовой фичи сколько человекочасов занимает?
ОтветитьУдалитьВидно же, что затрат на анализ стало больше, - участвуют все заинтересованные лица. Проектируют двое - опять же человекочасов больше, чем исходные 2.
Я это не к тому, что "то на то и выходит". Выходит как раз лучше - ведь даже если потратятся 36 человекочасов, но мы уложимся запланированный срок, то мы уже круче, чем в исходном варианте. Опять же, самообманом не занимаемся.
Просто интересно, есть ли выигрыш только в астрономических часах на полную разработку или в человекочасах тоже.
Получается лучше, да.
ОтветитьУдалитьВо-первых, мы даем оценку лучше (максимально приближенную к реальности), т.е. уже избавляем себя от "горим по срокам" и "как объяснить заказчику?"
Во-вторых, мы стараемся избавиться от так любимого многими: "Нет времени разрабатывать нормально, зато есть время переделывать и рефакторить".
В-третьих, .... ну, стыдно признаться, но когда мы подсчитали все затрато-возвраты и прочие ожидания при производстве простейшей 2-поинтовой фичи, то у нас вышло, что одна такая фича у нас около месяца разрабатывается... Что уж говорить про более крупные.
В общем, на достаточно крупных фичах (от 5 стори-поинтов и более) у нас получилось ускорение в три раза. При этом, оценка фич бралась старая (т.е. нельзя сказать, что мы просто переоценили фичи на "побольше", а теперь понтуемся ))). При этом качество разработки повысилось настолько, что багов практически не было. У тестировщиков появилось "свободное" время, в которое они могли заниматься всяким нагрузочным тестированием, безопасностью, автоматизацией... В общем, всем тем, чем в обычное время заниматься некогда, особенно если на проекте тестировщик только один.