Компания попросила меня провести презентацию и рассказать о методологии, по которой мы работаем и разрабатываем наше приложение.
Я сразу сказал: «У нас Scrum» — и сел оформлять презентацию.
Но я остановился на самом первом слайде, и вот почему.
Agile содержит множество методологий — XP, Scrum, Lean, Kanban, ScrumBut (ScrumNO).
Сев за анализ методов, я понял, что не могу сказать, что моя команда работает по какому-то одному из них.
В целом наш рабочий процесс можно изобразить следующим образом: 
Как видите, мы используем множество пунктов из разных методологий, многие — но не все.
Мы адаптировали методологии под наш процесс разработки и нашу команду.
Мы используем множество рекомендаций из практики XP, что-то похожее мы нашли в процессе разработки в методологии Канбан, некоторые моменты были взяты из методологии Scrum. Также я решил выделить отдельную ось и назвал ее «Конференции».
Потому что с конференций было взято много полезных идей.
Могу сказать, что начинающий Project Manager(y), Team Lead(y) должен начинать с конференций, но не просто приходить и слушать, а подходить к спикеру после выступления и пытаться задавать вопросы, которые вас интересуют. Так в моей команде появилась страница релиза, командная и личная цель, мои QA специалисты привезли с конференции такую полезную вещь, как импакт-анализ и понятие «тестировщик-аналитик».
Но не будем отвлекаться от основной темы и вернемся к методологиям разработки программного обеспечения.
Управление проектами основано на концепции спринта и бэклога продукта; любой, кто знаком со Scrum, сразу скажет, что это его основные артефакты.
Но в нашей команде нет владельцев продукта, пользовательская история не имеет приоритета и нет точек истории.
У нас нет Scrum-карт для игры в Planning Poker, и мы не рисуем диаграммы Burndown, но вместо Scrum-доски мы ведем страницу релиза.
И мы всем этим не пользуемся не потому, что нам лень или мы не понимаем как это делать, просто в процессе разработки приложения пропали некоторые артефакты.
Заказчик не хотел расставлять приоритеты, потому что.
для него важны все задачи, мы не заморачивались с Story Point(ами), т.к.
новые задачи можно было запихнуть в спринт. А схему мы не строили, поэтому она оказалась не понятной.
Когда во время разработки нас спрашивают, как идут дела, мы показываем страницу релиза, которая выглядит примерно так: 
Алексей Лупан однажды посоветовал мне запустить его; он выступал на конференции и показал нечто подобное для своего проекта.
Я внедрил это в свой проект и это оказалось удобно.
На этой странице вы можете увидеть, сколько функций мы включили в релиз, кто отвечает за каждую функцию и в каком состоянии она находится.
Также указан срок подачи на тестирование и производство.
Самое главное здесь — это список всех критических и очень важных ошибок, на которые нужно обратить внимание перед выпуском новой версии продукта.
Мне нравится эта страница тем, что если в проекте больше одного тестировщика, то я всем говорю — «Тестируйте важные ошибки, и не важно, что они зарегистрированы на кого-то другого, лучше пройтись свежим взглядом.
Так вы сможете найти что-то новое».
И это работает. Сколько раз у меня были такие ситуации, когда один тестировщик находил ошибки у другого тестера.
Это действительно помогает. Конечно, не всегда возможно провести двойное тестирование, но я стараюсь практиковать это при любой возможности.
Здесь хорошо работает поговорка, что одна голова хорошо, а две лучше.
Итак, я рассказал вам, что мы не используем в Scrum. Ах да, чуть не забыл, мы не проводим ежедневные стендапы.
Мы сидим рядом, на расстоянии вытянутой руки, все, что обсуждается, обсуждается рядом с командой, а значит, все слышат. Поэтому митинги проводятся по мере необходимости.
В основном, когда этого требует клиент. Затем распечатываем страницу релиза, и распечатываем задачи, разделенные на подзадачи, со статусом напротив каждой подзадачи и с комментариями в графе «Проблемы», если они есть.
В общем, в процессе работы я усвоил две истины: 1. заказчику все равно, какую методологию вы используете; на самом деле его интересует конечный результат; 2. если дать клиенту больше, чем он ожидает, он станет счастливее.
Это тоже проверено не раз, особенно первая правда, потому что при обнаружении ошибок в конце релиза заказчик забывает, что вы работаете, например, по Scrum. В голове крутятся вопросы: «Когда это исправятЭ», «Кто виноватЭ», «Почему это произошлоЭ» И заметьте, именно в таком порядке.
Вряд ли в этот момент клиент ожидает, что вы начнете играть в Planning Poker, назначать Story Points и планировать спринт. И его не интересует скорость, даже если она выросла вдвое по сравнению с предыдущим спринтом.
И на графики он тоже смотреть не будет. Поэтому, если какие-то артефакты в Scrum вас беспокоят или вы считаете их не очень полезными в своем проекте, не бойтесь их выбрасывать, в этом нет ничего страшного.
Главное, чтобы ваша команда продолжала двигаться вперед и была гибкой к изменениям.
Scrum — это своего рода фреймворк, состоящий из отдельных частей.
Вы можете использовать все его части, можете соединять постепенно, а можете что-то менять под свои нужды.
В этом, мне кажется, и есть смысл гибкой методологии, когда не ты подчиняешься методологии, а методология подчиняется тебе.
Еще одна истина, которая мне нравится и которая окупается — давать тестировщикам как можно больше времени на тестирование готового продукта, а также позволять тестировщикам проверять промежуточные результаты вашей работы.
Вероятно, вторая часть предыдущего предложения является основной.
Я всегда позволяю своим тестировщикам опробовать сырую версию приложения.
За что? Для того, чтобы они начали критиковать, сказали, что что-то не удобно, внесли идеи, начали писать тесты, чтобы проверить, что будет, начали продумывать узкие места в логике и интерфейсе.
Это немного раздражает, но все равно приносит свои плоды.
Главное – не совершить ни одной ошибки, о которой я слышал во многих проектах.
Ошибка в том, что тестировщики и программисты сидят отдельно, а главное, не общаются напрямую.
Те.
образуются два вражеских лагеря.
Это не правильно, помните, вы — команда, вы работаете над одним продуктом, ваши цели одни и те же.
Помогайте друг другу, сидите вместе, задавайте вопросы, общайтесь.
Теги: #Методика Scrum ИТ-программное обеспечение XP #Управление проектами
-
Кишечнополостные
19 Oct, 24 -
После Взлома Tp-Link
19 Oct, 24 -
Вы Используете Цифровую Клавиатуру?
19 Oct, 24
