Попросили меня на фирме выступить с докладом и рассказать о методологии по которой мы работаем, разрабатываем наше приложение. Я сразу же сказал — «У нас Scrum», и сел составлять презентацию. Но я остановился на первом же слайде, и вот почему.
Agile содержит в себе множество методологий — XP, Scrum, Lean, Kanban, ScrumBut (СкрамНО). Сев разбирать методики, я понял, что не могу сказать, что моя команда работает по какой-то одной из них. В целом наш рабочий процесс можно изобразить так:
Как видите, мы используем, множество пунктов из разных методологий, множество — но не все. Мы адаптировали методологии под свой процесс разработки, под свою команду.
Мы используем множество рекомендаций из XP практики, что-то схожее в нашем процессе разработки нашли в методологии Kanban, часть пунктов взяли из Scrum-методологии.Еще, я решил выделить отдельную ось и назвал ее Conferences. Потому, что много полезных идей было взято именно из конференций. Могу сказать, что начинающему Project Manager(y), Team Lead(y) стоит начать с конференций, но не просто прийти и послушать, а подойти к докладчику после выступления и постараться задать интересующие тебя вопросы. Именно так в моей команде появилась страница релиза, командная и личная цель, мои QA-специалисты привезли с конференции такую полезную вещь как импакт-анализ и понятие «тестировщик-аналитик». Но не будем отвлекаться от главной темы и вернемся к методологиям разработки програмного обеспечения.
В основе ведения проекта лежит понятие Sprint и Product backlog, кто знаком со Scrum(ом), тот сразу скажет, что это его главные артефакты. Но в нашей команде нет Product Owner(a), у User Story нет приоритета и нет Story Point(ов). У нас нет Scrum карт для игры в Planning Poker и мы не рисуем Burn down диаграммы, а вместо Scrum-доски мы ведем страницу релиза.
И все это мы не используем не потому, что нам лень или мы не понимаем как это делать, просто в процессе разработки приложения некоторые артефакты отпали. Заказчик не захотел выставлять приоритеты, т.к. для него все задачи важные, мы не стали «заморачиваться» со Story Point(ами), т.к. в спринт могли впихнуть новые задачи. И диаграмму мы не строили, потому, она оказалась не наглядной. Когда нас спрашивают, в процессе разработки, как обстоят дела, мы показываем страницу релиза, которая выглядит примерно так:
Когда-то мне посоветовал ее вести Алексей Лупан, он выступал на конференции и показывал, что-то подобное для своего проекта. Я внедрил это в свой проект и это оказалось удобно. На этой странице видно сколько фич мы включили в релиз, кто отвечает за каждую фичу, в каком она состоянии. Также указывается срок сдачи в тестирование и в продакшин. Самое важное тут виден список всех критических и очень важных ошибок, на которые нужно обратить внимание перед сдачей новой версии продукта. Такая страница мне нравится тем, что если в проекте больше одного тестировщика, то я говорю всем — «Тестируйте важные ошибки, и не важно, что они оформлены на кого-то друго-го, лучше пройтись свежим взглядом. Так можно найти что-то новое». И это работает. Сколько раз у меня были такие ситуации, когда один тестеровщик находил ошибки у другого тестировщика. Это реально спасает. Конечно, не всегда получается делать двойное тестирование, но по возможности старюсь это практиковать. Тут хорошо срабатывает поговорка одна голова хорошо, а две лучше.
И так, я рассказал, чем мы не пользуемся в скраме.Ах да, чуть не забыл, мы не проводим каждодневные стендап митинги. Мы силим рядом, на расстоянии вытянутой руки, все что обсуждается — обсуждается рядом с командой, а значит — слышат все. Поэтому митинги проводятся по необходимости. В основном когда этого требует заказчик. Тогда мы печатем страницу релиза, и печатаем разбитые на подзадачи задачи со статусом напротив каждой подзадачи и с комментариями в колонке Problems, если таковые имеются.
Вообще, в процессе работы я усвоил для себя две истины:
1. заказчику все равно по какой методологии Вы работаете, на самом деле его интересует конечный результат;
2. если давать заказчику больше, чем он ожидает, он становится счастливие.
Это тоже проверялось не однократно, особенно первая истина, ведь когда в конце релиза обнаруживаются ошибки, то заказчик забывает, что вы работаете, например, по Scrum(у). У него в голове крутятся такие вопросы: «Когда будет исправлено?», «Кто виноват?», «Почему так получилось?». И заметте, именно в таком порядке. Врядли в этот момент заказчик ждет от вас, что вы начнете играть в Planning Poker, расставлять Story Point(ы) и планировать спринт. И velocity его не интересует, даже если оно выросло в два раза по сравнению с предыдущим спринтом. И на графики он тоже не будет смотреть. Поэтому если Вам мешают некоторые артефакты в Scrum(е) или Вы считаете их не очень полезными именно в вашем проекте, не бойтесь их выкинуть, ничего в этом страшного нет. Главное, чтобы Ваша команда продолжала двигаться вперед и была гибкой в плане изменений. Scrum — это своего рода фреймворк, состоящий из отдельных частей. Можно использовать все его части, можно подключать постепенно, а можно и изменить что-то под ваши нужды. В этом мне кажется и есть смысл гибкой (agile) методологии, когда не Вы прогибаетесь под методологию, а методология прогибается под Вас.
Еще одна истина, которая мне нравится, и которая приносит свои плоды — это выделяйте тестировщикам как можно больше времени на тестирование готового продукта, а также давайте тестеровщикам тестрировать промежуточные результаты Ваших трудов. Наверное вторая часть предыдущего предложения является главной. Я всегда даю своим тестеровщикам пощупать сырую версию приложения. Зачем? Для того, чтобы они начали критиковать, сказали, что что-то не удобно, внесли идеи, начали писать тесты для тестирования того, что будет, начали продумывать узкие места в логике, интерфейсе. Это немного достает, но тем не менее приносит свои плоды. Главное не допускайте одной ошибки, о которой я слышал во многих проектах. Ошибка заключается в том, что тестировщики и программисты сидят отдельно, а самое главное не общаются на прямую. Т.е. образовывается два вражеских лагеря. Это не правильно, помните, Вы — команда, Вы работаете над одним продуктам, Ваши цели совпадают. Помогайте друг другу, сидите вместе, задавайте вопросы, общайтесь.
Автор: AndreyPM
