Наверх ▲

Путь самурая. От скрама до канбана

Александр Кудымов Александр Кудымов Проектировщик интерфейсов, канбан-мастер. Евгений Кобзев Евгений Кобзев Руководитель проекта в СКБ "Контур".

 Евгений Кобзев: Мы вдвоем будем делать доклад. Меня зовут Евгений Кобзев. Я работаю в компании СКБ "Контур" и руковожу проектом "Электронный бухгалтер "Эльба". Мой коллега Александр Кудымов – специалист по интерфейсам.

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

О чем мы собираемся говорить?

Мы будем рассказывать, каким образом мы настраиваем процесс разработки в нашем проекте. Мы объясним, какой мы прошли путь и куда пришли.

Тут есть вот какая особенность. В нашей команде довольно веселые и молодые люди. Вместе мы делаем "Эльбу". Это онлайн-бухгалтерия. Онлайн-бухгалтерия – дело серьезное.

Один из наших клиентов в отзывах написал, что бухгалтерия для него темный лес, и лезть туда ему до нашего проекта не хотелось.

Когда мы начинали работу, мы испытывали примерно такие же ощущения. Это, конечно, на наш процесс очень сильно повлияло.

У нас в проекте есть разные группы сотрудников. Прежде всего, есть разработчики, как и у всех IT-компаний. Кроме того, очень важную роль у нас играют аналитики, которые лезут в темные глубины и создают какое-то описание на понятном человеческом языке. Есть у нас специалисты по интерфейсам (в частности, Саша), которые обеспечивают удобство всем остальным нормальным людям.

Таким образом, продукт "передается по цепочке" и приходит к пользователям. Как он передается и зачем, мы и будем рассказывать.

Начали мы с традиционной ошибки: предположили, что у нас все получится сразу. Мы поймем, что нужно делать, потом посчитаем ресурсы (в частности, сколько нам нужно денег) и создадим прекрасный продукт.

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

Мы в результате мы даже стали называть ТЗ не ТЗ, а ХЗ. Это всегда вызывает определенные восторги. Правда, слово ХЗ мы даже не стали писать на слайде.

Мы решили немного измениться. Что мы сделали?

Мы в общих чертах зафиксировали небольшой прототип и начали применять гибкие методологии в группе разработки. Сначала у нас было 2, а потом 4 разработчика. Я тоже был разработчиком проекта в этот момент, поэтому могу говорить ответственно. Мы начали использовать различные инженерные практики: Planning Poker, парное программирование, что-то еще.

У нас что-то стало получаться. Мы стали очень хорошо работать. Делали нашу систему очень хорошо с инженерной точки зрения, но получалось примерно как на картинке внизу. Остальные части команды не были к нам близки: была команда продвижения, были аналитики, но мы очень мало с ними общались. Они не влияли на процесс, а это, конечно, очень важно.

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

Мы называли эту реализацию "экстремальный agile".

Почему "экстремальный"?

Мы взяли agile, который был у разработчиков, и распространили его на все основные роли нашего проекта.  

У нас был такой инструмент, как планирование. Раз в две недели мы собирались и, по сути, планировали 4 итерации. Мы работали двухнедельными итерациями. Предположим, у нас была цель – сделать какую-нибудь отчетность в Пенсионный фонд, которую нужно реализовать обязательно к такой-то дате, без вариантов.

Это должны сделать разработчики. До этого, очевидно, должны быть протестированы инженерные интерфейсы. Этим занимаются наши психологи – так мы называем специалистов по юзабилити, user experience. До этого должны сами интерфейсы появиться, до этого должны сделать свою работу аналитики.

Тут у нас есть легенда: цвет бумажек отвечает за определенную функциональность. Если бы мы тут делали еще что-то в блоке "Бизнес", у нас на плане появились бы красные бумажки. У каждой клеточки есть емкость: больше 4-х бумажек мы туда не можем повесить.  

Раз в две недели мы начали собираться по понедельникам. Проводили планирование сразу 4-х согласованных итераций. Сначала мы проводили презентацию того, что будем делать, перед всей командой. Мы все к тому моменту уже сидели в одной комнате (нас было 20 с небольшим человек). Это было очень классно! Мы до сих пор продолжаем это делать.

Потом все расходились по своим углам. Разработчики играли в Planning Poker, потом специалисты по интерфейсам начали играть в Planning Poker. Даже аналитики у нас играли в Planning Poker. Потом специалист по интерфейсам один остался, и ему не с кем стало играть.

Стали появляться проблемы. Мы развивали нашу систему, было реализовано много функциональности, пришло больше пользователей. В какой-то момент наши стройные картинки начали разваливаться.

Причем это не значит, что мы жалеем об этом этапе работы: мы об этом рассказывали в статьях на "Хабре" и где-то еще. Сейчас мы говорим: "Мы начали отказываться от этого процесса". Многие из тех, кто следил за нашей работой изначально, включают режим троллинга: "Ну, вот! Мы же вам говорили, что у вас ничего не получится!"

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

Именно там мы и видим, что происходит. Мы получили ситуацию, аналогичную той, которая имеет место в Калифорнии с мостом "Золотые ворота". Мост "Золотые ворота" красят круглогодично. Когда маляры доходят до другой стороны залива, опять надо начинать красить предыдущую сторону.

Почему так получилось?

Появилась какая-то функциональность, которую нужно поддерживать. Появились десятки тысяч пользователей. У нас 200 тысяч регистраций.

Конечно, докладчики из "Badoo" вчера рассказывали, что у них за день столько регистраций бывает. У нас серьезная система, и в такой системе получить много регистраций тяжело. Это не развлекательный сервис.

Мы "красили мост". Мы, по сути, имели 10 рабочих дней. Из них 1 день полностью тратился на планирование. 2 дня мы тратили на исправление ошибок, вернее, сначала был 1 день, потом тестировщик попросил 2 дня, потому что одного оказалось мало.

Еще один день у нас – это день свободного творчества разработчиков, потому что им хочется делать не только унылые бизнес-задачи делать, но и что-то интересное. К тому же разработчикам надо было развивать систему, чтобы она могла адекватно реагировать на вызовы и справляться с нагрузками. 

Итак, мы постоянно "красили". У нас начались потери и проблемы. Требовалось что-то изменить. Передаю слово Александру.

Александр Кудымов: Всем привет! Я – дизайнер интерфейсов Александр Кудымов.

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

Допустим, разработчики часто спрашивали у дизайнеров нечто вроде: "Где текст для подсказки?".

Или: "Где детали в прототипе?"

Или: "Где вообще прототип?"

Все это "всплывало", когда разработка брала новую задачу в итерацию.

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

Почему так происходило?

Дизайнеров интерфейсов тоже демотивировала такая ситуация: разработка режет прототипы. 

Допустим, существовал некий исходный прототип. Разработка: "Давайте мы в эту итерацию уберем вот это. Наверное, чтобы вся задача влезла в итерацию, уберем еще вот это. Ну, и давайте так оставим".

Дизайнерам интерфейсов, конечно, это не очень нравилось. Хотелось, чтобы задача, которую они полностью нарисовали и сделали, так и шла. Но сделать это было невозможно.

Как сделать из минуса плюс?

Соответственно, получился минус. Мы подумали и решили, что из любого минуса как-то можно сделать плюс.

Как это сделать? Достаточно палочку добавить. В принципе, это вполне очевидная вещь.

Мы решили, что процесс у нас не очень хороший, и надо от него избавляться. Так как мы все-таки agile-команда, мы решили это делать в несколько итераций.  

Первая итерация канбаном решила проблемы с планированием. Выглядело это так. У нас были какие-то цели, которые мы ставили к определенной дате. Был список ToDo: с waterline поднимались задачи, которые мы помещали сюда… Их у нас обычно было не больше 3. Дальше они шли по процессу.

Причем процесс, естественно, здесь ограничен просто посредством points – на каждой стадии их может быть 4. Допустим, у аналитиков 4, у интерфейсологов – 3, у разработчиков 3-4. Все это зависит, конечно же, от количества членов в конкретной команде. 

Чуть позже обсудим, какие здесь появились проблемы.

Начну с плюсов. Мы добились того, что перестало уходить время на постоянное планирование. Мы планировали только тогда, когда у нас заканчивался список ToDo. Сам процесс стал более явным, более зримым стал переход задач. Можно было что-то измерять. По самому циклу задачи стало можно оценивать, когда мы сможем задачу выпустить в продакшн.

Но потом мы поняли, что люди важнее. 

Извините, кое-что я забыл сказать. У нас на той доске были отображены роли  – инженерный психолог и графический дизайнер. Сейчас мы их убрали, потому что в канбане далеко не все задачи проходили через эти две роли. Были прототипы, которые не нуждались в юзабилити-тестировании, например, какие-то достаточно мелкие вещи. Занимать ими две колонки было глупо.

С графическим дизайнером была такая ситуация: основные элементы системы он давно уже нарисовал. Проектировщики уже могли составлять что-то из них. Часть прототипов просто не нуждалась в графическом дизайне, потому что он уже был сделан когда-то давно.

Вот эти люди начали слегка возмущаться и говорить: "Мы никак не можем контролировать процесс, потому что задачи вообще проходят мимо нас. Даже те, которые нужны!" Мы решили это исправить. 

Еще у нас был такой момент. Мы всегда считали: если задача попала сюда, а потом оказалось, что там что-то не доработано и мы ее возвращаем обратно, это плохо. На самом деле у нас гибкая разработка. Зачем делать из этого трагедию?

Мы решили, что люди важнее, и сделали такую штуку. Сейчас доска канбана у нас выглядит примерно так.

Что это такое?

Здесь ToDo. Мы оставили всего лишь три роли: аналитика, интерфейс и разработка. Причем мы разделили колонки на "сделано" и "проверено", чтобы мы могли сразу получить обратную связь, отзывы. Когда аналитики делают какую-то задачу, они вешают бумажку в "сделано". Это означает, что прямо сейчас дизайнерам интерфейсов надо посмотреть эту задачу и оценить, насколько она хорошо проработана для интерфейсов.

Эта задача не будет сразу браться в работу. Она может быть взята в работу через неделю, когда слот дизайнеров интерфейсов освободится. Но дизайнер уже сейчас может оценить эту задачу – на этом этапе выявить какие-то проблемы в аналитике и сказать, что чего-то не хватает, и лучше бы сейчас это исправить.

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

Такая же ситуация с интерфейсами и разработкой. Это и было наше слабое место.

Как мы из этой ситуации вышли?

Мы на раннем этапе показываем интерфейсы разработчикам – просто обсуждаем их с отделом разработки. Разработка говорит: "Это мы вырежем, потому что будет слишком долго".  Соответственно, функциональность отрезается на самом раннем этапе, чтобы мы ничего ненужного не рисовали и не делали лишнюю работу.

Конечно, нам бы хотелось процесс отрезания сделать еще более быстрым, чтобы аналитики тоже не делали лишнюю работу и говорили: "Здесь мы все отрезаем и сразу валяем так".

Что мы еще ввели?

Мы ввели вот такие персонажи.

Персонажи добавили веселья команде. У каждого человека есть какой-то персонаж: два значка (у нас по 2 значка на человека). Они здесь висят, когда какой-нибудь человек делает задачу.

Во-первых, персонажи очень хорошо иллюстрируют весь процесс – видно, кто какой задачей занимается на данный момент. Во-вторых, это просто весело. Также это ограничивает количество задач на сотрудника, потому что у нас только по 2 значка на человека – это означает, что человек не может заниматься более чем двумя задачами одновременно.       

Это, в принципе, нормально. Одна задача может "подвиснуть": например, надо дожидаться чего-то еще. Человек в это время будет выполнять вторую задачу.

Теперь нет проблемы с тем, что мы считали перенос провалом. Допустим, если на этапе разработки понадобится делать интерфейс и что-то дорабатывать, просто берется значок дизайнера интерфейсов и вешается на эту задачу. Это означает, что человек сейчас работает над этой задачей, хоть она и находится в стадии разработки. Это нормально. Какие-то доработки всегда появляются.

Соответственно, все эти значки могут путешествовать по всей доске. Разработчики могут принимать участие на этапах аналитики и дизайна интерфейсов. Все полностью заменяемо.

Здесь уже вступают тестировщики…

Я забыл сказать, что из "сделано" в "проверено" задачи переносит другая команда (это следующая роль). Если аналитики повесили задачу в "сделано", но я это не посмотрел, они не могут ее повесить в "проверено", а я не могу взять задачу из "сделано". Я обязательно должен взять задачу из "проверено".

На последнем этапе "сделано" и "проверено" – это уже барьер-фильтр тестировщика, когда он все протестировал и сказал: "Да, я проверил. Это все готово к релизу". Мы включаем это в релиз.

Какие scrum-практики у нас все-таки остались?   

Планирование у команды разработки. Все равно задачи там оцениваются каждый раз. Они берут задачу после того, как было сделано основное, первичное планирование (они просто смотрят, сделали ли дизайнеры интерфейсов все, что надо). Второе – когда они уже берут к себе задачу, они просто ее оценивают, чтобы самим понимать сроки.

Скрам-встречи каждый день. Да, у нас каждый день проходят скрам-встречи. Там все роли рассказывают, чем они занимались.

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

Например, у команды продвижения вообще только такие задачи, а у остальных задачи могут быть как в сфере разработки, так и вне ее. Допустим, подготовка к РИТ. Задача в процесс разработки никак не входит, но ее все равно надо как-нибудь отследить и посмотреть.

У нас каждые две недели проходит ретроспектива и презентация. Причем презентацию сейчас показывают все роли в команде: и разработка (что она сделала), и дизайнеры интерфейсов (что они сделали). Иногда дизайнер показывает, что она нарисовала.

Не так давно у нас появилась и презентация от команды продвижения. Это очень круто, потому что до этого остальные не всегда понимали, чем занимается команда продвижения, и какие результаты она приносит.

Евгений Кобзев: Не все знали, что есть блог. 

Александр Кудымов: Да, не все знали, что есть блог. Вообще не знали, где что у нас есть. Презентация команды продвижения рассказывает, на каких площадках мы опубликовались, какие результаты посещений на сайте, как они выросли. Вот такие вещи.

Это очень круто, потому что теперь вся команда знает, чем занимаются люди, которые чего-то продвигают.

Мы понимаем, что у нас процесс все еще не совсем налажен: все равно есть какие-то проблемы.

Что мы хотим сделать в будущем?

Сейчас очень плохо стало с бэклогом. Для этого мы хотим сделать стори мап: просто взять задачи и расписать их на месяц вперед. Посмотреть, сделать нормальный бэклог и выделить "скелет" основных задач.

Еще хочется ввести такую штуку, как таймлайн. Это для ретроспективы. Она будет существовать в течение двух недель… Итерация между ретроспективами как таковая есть. Там будут бумажки с эмоционально окрашенными фразами, которые можно повесить, допустим, на стенку. Например: "Я счастлив, что у нас все хорошо".

Для ретроспективы это хорошо, потому что мы на ней обычно обсуждаем плюсы и минусы. У нас раз в 2 недели это проходит, и довольно сложно вспоминать, какие были плюсы и минусы. Иногда что-то забывается, и нельзя нормально управлять всем этим.

Это все. Конец. У кого есть вопросы, задаем сейчас. Потом можно тоже задавать.

Вопросы и ответы

Реплика из зала: Добрый день, коллеги. Меня зовут Илья. На доске и в задачах не увидел ничего про оценки, хотя вы про них упоминали. Как вы сейчас отвечаете на вопрос отдела бизнеса о том, когда это будет готово?

Александр Кудымов: У нас на бумажках с обратной стороны пишется дата – когда она сюда попала. Здесь мы смотрим, какой цикл был. Зная средний цикл задачи, мы можем прогнозировать, когда она будет выпущена, если мы эту задачу поднимем. ToDo-лист можно составлять (он приоритетен) по приоритетам, по тому самому, когда должна выйти задача и какой средний цикл.

Евгений Кобзев: Вопросы от бизнеса у нас в проекте как раз я задаю. На это всегда есть очень хороший ответ: очень сильно влияет, что все стремятся сделать свою работу хорошо. На каждом этапе люди думают, как же сделать так, чтобы к нужной дате это действительно произошло.

У нас бывают релизы, которые необязательно выпускать к какой-то дате. Бывают и релизы, которые связаны с законодательством и изменениями в нем. У нас там вариантов нет!

Тут еще важно добавить не по этому вопросу, а вообще.

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

Тут может возникнуть вопрос: чем же им тогда заняться? Ну, люди всегда находят, чем заняться. Причем именно с точки зрения проекта. Можно законы почитать или что-нибудь классное придумать совместно с дизайнерами интерфейсов. Разработчики всегда могут заняться рефакторингом, но обычно они заняты другими вещами.

Реплика из зала: Где висит доска физически?

Александр Кудымов: На стене.

Реплика из зала: Кто ее видит? Она в той же комнате, где все сидят?

Александр Кудымов: Она не висит. У нас open space – она просто катается на колесиках. Она стоит – ее все видят. Мы каждый день всей командой у доски собираемся. Когда задача сделана, она не перевешивается в середине дня, а торжественно перевешивается в конце дня.

Реплика из зала: Что за проблемы с бэклогом? Вы сказали, что они появились, но не сказали, какие именно, какого типа.

Евгений Кобзев: Бэклог – это количество задач здесь. Вы видите, тут нет ни одной задачи. Это проблема. Мы не знаем, что дальше делать. У нас очень много идей, но в каком порядке их реализовывать, мы пока четко не представляем.

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

С другой стороны доски еще больше таких бумажек, но как мы их будем делать? Это и есть проблема.   

Реплика из зала: Здравствуйте. У вас помимо этой доски есть какая-то автоматическая система отслеживания задач? Например, какая-то интеграция с JIRA, что-то такое? Или только доска с бумажками?

Александр Кудымов: Сейчас у нас только доска с бумажками. Мы хотим сейчас сделать такую штуку – всю доску перенести в программу дополнительно. Это даже не для того, чтобы посмотреть откуда-то. Просто будет удобно там добавлять какие-то штуки к задачам: ссылку на прототип, ТЗ, которое от аналитиков пришло. И чтобы у всей команды был туда доступ.

Реплика из зала: Сколько у вас сейчас команд?

Александр Кудымов: У нас одна команда – 20 человек.

Евгений Кобзев: Я бы по поводу JIRA хотел сказать. Я бы хотел пропиарить наш багтрекер – мы пользуемся YouTrack. Это очень классная вещь. JIRA, по-моему, полная фигня по сравнению с YouTrack. В принципе, мы никогда не интегрировали наше планирование с какими-то автоматическими вещами. Когда нас просили в электронный вид его перевести, мы просто присылали фотографию.

Реплика из зала: У вас есть такая роль как аналитик-интерфейсолог? Хотелось бы понять, что является результатом деятельности аналитика в вашем случае.

Евгений Кобзев: Результатом деятельности аналитика раньше являлось ТЗ, а сейчас, по сути, у дизайнера интерфейсов и аналитика один результат – прототип. Они совместно работают над прототипом. Аналитик объясняет дизайнеру интерфейсов, какая проблема стоит с точки зрения законодательства, например. Дизайнер интерфейсов создает прототип и комментарии к нему.

Реплика из зала: Они работают в связке все-таки?

Евгений Кобзев: Сначала аналитик что-то сам "копает". Он что-то может записать, если ему нужно. Это его дело. А результатом, который всем презентуется, является прототип.

Реплика из зала: Но дизайнер интерфейсов же не просто рисованием занимается...

Евгений Кобзев: Давайте я специалисту слово дам…

Александр Кудымов: Да, он занимается не просто рисованием, а всякими проблемами взаимодействия пользователя с системой. Аналитик изучает достаточно сложную предметную область – бухгалтерию. Задача аналитика: сказать, как правильно это будет по закону. 

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

Реплика из зала: Понял. У вас просто специфика такая.

Реплика из зала: Добрый день. Спасибо за презентацию. Я абсолютно не понимаю, как вы умудряетесь выпускать релизы.

Александр Кудымов: Мы сами не понимаем.

Реплика из зала: Просто я вижу нижнюю часть доски, где маленькие задачи, и верхнюю часть доски, где большие задачи. Как тестировщик понимает, в какой ветке он тестирует? В общем, как вы его обновляете, выпускаете и все это собираете?

Евгений Кобзев: На нижнюю часть доски смотреть вообще не надо! Она на релизы не влияет. Она влияет на пиар релизов – продвижение. Тут творится какой-то ахтунг, но это, к счастью, не влияет на релизы. На релизы влияет только верхняя часть.

По сути, тестировщику очень легко. Смотрите, тут сейчас 4 бумажки. Разработчики сделают что-то – повесят бумажки вот сюда. Причем тестировщик об этом быстро узнает: не дольше, чем за день. Мы вечером соберемся – тестировщик говорит: "Ага, это сделано". Об этом узнает не только тестировщик, но и вся команда. Тестировщик протестирует и перевесит сюда.

Вся команда поймет: ок, можно пойти на тестовый сервер, кому интересно, и посмотреть, что получилось. После этого происходит релиз.

Реплика из зала: А если у вас в это же время ошибка исправится?

Евгений Кобзев: Ну, исправится и исправится. 

Реплика из зала: Не видно, протестирована она или нет. 

Евгений Кобзев: Ошибки – это вещь, которая недостойна того, чтобы здесь появлялись какие-то бумажки. Бумажки – это функциональные возможности, которые чувствует пользователь.

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

Если нам нужно выпустить релиз только с багфиксами, тут все ок. Просто тестировщики общаются с разработчиками как-то вне этой доски, если выясняется что-то очень серьезное. Кстати, есть механизмы (мы ими довольно редко пользуемся), чтобы протащить что-то внепланово. Иногда можно.

Реплика из зала: Кто принимает решение? Вы по скраму, я так понимаю, раньше работали: план сделали, собрали все, выпустили релиз. А здесь кто принимает решение, что пора выпускать релиз? Задача сделана, - и релиз?

Евгений Кобзев: У нас решения принимаются совместно. Мы стараемся формировать общую ответственность. Все люди разумные. Разработчики и тестировщики в состоянии принять любое решение – в том числе о ценовой политике, например.

Если возникает какой-то очень сложный вопрос, тогда он выносится общее обсуждение. Иногда мне нужно проявить деспотические наклонности и сказать: "Нет, так будет". Но так очень редко бывает. Все хотят, чтобы релиз появился, и он появляется. Это нормально.

Реплика из зала: Спасибо.  

Реплика из зала: Добрый день. Подскажите, пожалуйста, каким образом у вас происходит вмешательство… Вы упомянули, что разработчик может вмешаться в процесс постановки задачи аналитикам, потому что с его точки зрения чего-то не хватает, что-то сложно реализовать. В общем, процесс вмешательства бывает необходим – задача "сырая". Как это происходит?

Александр Кудымов: Мы показываем разработчикам какую-то конкретную задачу. У нее есть срок (дедлайн). Разработчик говорит: "Блин, давайте половину из этого выкинем, потому что мы тогда не успеем к дедлайну". Это обсуждается с аналитиком.

Мы принимаем общее совместное решение от трех ролей (аналитики, разработки, дизайна интерфейсов): если мы это выкинем, насколько пострадают пользователи, насколько это будет по законодательству правильно или неправильно. Если нас все устраивает, мы на это идем и просто отрезаем часть функциональности.  

Реплика из зала: Я хочу уточнить вопрос. Когда это происходит, когда они понимают, что разработчик не успеет сделать задачу?

Александр Кудымов: Обычно это происходит на стадии, когда интерфейс сделан. Мы показываем его разработчикам. Они еще заняты, получается…

Это здесь происходит: разработчики еще заняты, а здесь уже есть какая-то задача. Разработчики тогда сразу на нее смотрят и оценивает более поверхностно. Они все равно понимают, насколько сложно сделано все с точки зрения интерфейсов, какие могут быть проблемы в реализации. Если есть какие-то проблемы, мы отрезаем часть функционала.

 Евгений Кобзев: Я хочу добавить. Цель всего этого процесса – дать всем обратную связь как можно раньше. В идеале прекрасно, когда аналитик что-то сделал, а ему уже здесь разработчики сказали "ок". Так не всегда получается.

Но мы к этому стремимся. Мы не только в момент перевешивания бумажек что-то можем посмотреть: мы для этого, в частности, проводим презентации. Когда дизайнеры интерфейсов показывают прототипы, аналитики их комментируют. Это попадет в разработку в течение каких-то дней, недель. В этот момент разработчики могут сразу высказаться. По результатам этого люди соберутся и обсудят.

Реплика из зала: Демо и предпланирование – такие вещи? 

Евгений Кобзев: Да.

Реплика из зала: Я понял. Спасибо.  

Реплика из зала: Здравствуйте. У меня вопрос по поводу ваших тестировщиков. У вас какие-то тест-кейсы есть, они где-то хранятся, или это тоже все на бумажках?

Евгений Кобзев: У нас есть один тестировщик. Он очень большой молодец – стал у нас "Человеком года". Поскольку он один, то что-то делает, и все хорошо. Ему этим ни с кем не нужно делиться: он фактически тестирует вручную. Если хочет, то как-то свой труд автоматизирует: пишет различные сценарии с использованием "Selenium" на "C-Sharp", чтобы кнопки кликались. 

Эти сценарии являются тест-кейсами. Исходный код очень понятный. Можно посмотреть код теста, и все ясно.

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

На бумажках или какие-то регламенты тестирования мы не делаем, потому что у нас потребности в этом нет. У нас нет какой-то группы тестировщиков в другой стране или комнате, которым все время нужно сообщать, что что-то изменилось: "Измените свои тест-кейсы".

Мы боремся за то, чтобы информация расходилась в результате беседы между людьми. Люди поговорили, что-то узнали, учли.

Реплика из зала: Что будете делать, если возникнет необходимость передачи опыта?

Евгений Кобзев: Мы решаем задачи по мере их поступления. Всегда стараемся делать самую важную задачу. Глупо было бы нам начать писать тест-кейсы: мы два года уже их не пишем. До сих пор не возникла необходимость передачи опыта. Мы бы уже два года этим занимались совершенно напрасно.

Как только необходимость передачи опыта возникнет, люди что-нибудь придумают.

Реплика из зала: Спасибо.   

Реплика из зала: Скажите, пожалуйста, почетче, какой трекер вы используете?

Евгений Кобзев: YouTrack. Это трекер от компании "JetBrains".

Реплика из зала: Спасибо. 

Реплика из зала: Прототип – это что у вас?

Александр Кудымов: У нас есть веб-сервер, на который выкладываются прототипы – конкретные сценарии поведения пользователя. То есть отрисованные картинки, пошагово иллюстрирующие, как и что пользователь делает. Это, по сути, является ТЗ для разработчика.

Они бывают кликабельными или нет. Для тестирования мы делаем кликабельные прототипы, чтобы на пользователях протестировать. Для разработки файлы там лежат – они могут посмотреть их, и все.

Реплика из зала: Здравствуйте. Меня зовут Александр. Возможно, я пропустил информацию, которая была в самом начале: сколько лет ваша компания живет?

Евгений Кобзев: Вообще компания живет 22 года. Это одна из самых старых IT-компаний в России. Проект наш стартовал 19-го января 2010-го года: это дата его выхода в продакшн. Активную работу мы начали в сентябре 2009-го года.

Реплика из зала: Как проект называется?    

Евгений Кобзев: "Эльба". "Электронный бухгалтер "Эльба". Введите в строке поиска Google слово "Эльба" (как река). Мы на первом месте.

Реплика из зала: Я понял. Спасибо.

Реплика из зала: Очень интересный доклад. Скажите, пожалуйста, сколько человек в команде?

Евгений Кобзев: 20 с небольшим. У нас есть еще группа в call-центре, которую мы тоже хотим объединить с командой. Мы пока сидим отдельно, но скоро переедем и будем рядом сидеть. У нас меньше 30 человек, на самом деле.

Реплика из зала: Сколько человек участвует в скраме?

Евгений Кобзев: Участвуют все, кроме call-центра. Все, кто был нарисован на картинке со стрелочками, участвуют. Call‑центр приходит на презентации и ретроспективы.

Реплика из зала: Можете сказать, сколько человек на каждой роли?

Евгений Кобзев: 2 аналитика. По-моему, 8 разработчиков. Дизайнеров интерфейсов то 1, то 2. Верстальщик. Дизайнер.

Реплика из зала: Спасибо.  

Евгений Кобзев: Время кончилось. Спасибо! Если вы что-то хотите спросить, можете к нам подойти. К сожалению, время кончилось.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Павел Шинкаренко

Павел Шинкаренко

Генеральный директор юридической компании «Сенешаль Нейман».

Рассказ о том, как правильно выстроить правовую часть работы по разработке программ для иностранных заказчиков (для нерезидентов).

Павел Уваров

Павел Уваров

Работает в команде Google SRE в Дублине (Ирландия).

Доклад от Google о принципах и процессах, полезных при создании программных систем.

Андрей Юношев

Андрей Юношев

Глава мобильной разработки Game Insight.

Андрей Юношев (Game Insight) освещает проблему удержания игроков в мобильных играх и делится интересными психологическими приемами.