Попросили меня на фирме выступить с докладом и рассказать о методологии по которой мы работаем, разрабатываем наше приложение. Я сразу же сказал — «У нас Scrum», и сел составлять презентацию. Но я остановился на первом же слайде, и вот почему.
Agile содержит в себе множество методологий — XP, Scrum, Lean, Kanban, ScrumBut (СкрамНО). Сев разбирать методики, я понял, что не могу сказать, что моя команда работает по какой-то одной из них. В целом наш рабочий процесс можно изобразить так:
![image](http://a3.sphotos.ak.fbcdn.net/hphotos-ak-ash3/535814_360503470678544_100001566810464_1007938_2013580064_n.jpg)
Как видите, мы используем, множество пунктов из разных методологий, множество — но не все. Мы адаптировали методологии под свой процесс разработки, под свою команду.
Мы используем множество рекомендаций из 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(ами), т.к. в спринт могли впихнуть новые задачи. И диаграмму мы не строили, потому, она оказалась не наглядной. Когда нас спрашивают, в процессе разработки, как обстоят дела, мы показываем страницу релиза, которая выглядит примерно так:
![image](http://a4.sphotos.ak.fbcdn.net/hphotos-ak-ash3/576317_360503297345228_100001566810464_1007937_2062108228_n.jpg)
Когда-то мне посоветовал ее вести Алексей Лупан, он выступал на конференции и показывал, что-то подобное для своего проекта. Я внедрил это в свой проект и это оказалось удобно. На этой странице видно сколько features мы включили в релиз, кто отвечает за каждую feature, в каком она состоянии. Также указывается срок сдачи в тестирование и в Production. Самое важное тут виден список всех критических и очень важных ошибок, на которые нужно обратить внимание перед сдачей новой версии продукта. Такая страница мне нравится тем, что если в проекте больше одного тестера, то я говорю всем — «Тестируйте важные ошибки, и не важно, что они оформлены на кого-то другого, лучше пройтись свежим взглядом. Так можно найти что-то новое». И это работает. Сколько раз у меня были такие ситуации, когда один тестер находил ошибки у другого тестера. Это реально спасает. Конечно, не всегда получается делать двойное тестирование, но по возможности старюсь это практиковать. Тут хорошо срабатывает поговорка одна голова хорошо, а две лучше.
И так, я рассказал, чем мы не пользуемся в Scrum. Ах да, чуть не забыл, мы не проводим каждодневные standup митинги. Мы сидим рядом, на расстоянии вытянутой руки, все что обсуждается — обсуждается рядом с командой, а значит — слышат все. Поэтому митинги проводятся по необходимости. В основном когда этого требует заказчик. Тогда мы печатаем страницу релиза, и печатаем разбитые на подзадачи задачи, со статусом напротив каждой подзадачи и с комментариями в колонке Problems, если таковые имеются.
Вообще, в процессе работы я усвоил для себя две истины:
1. заказчику все равно по какой методологии Вы работаете, на самом деле его интересует конечный результат;
2. если давать заказчику больше, чем он ожидает, он становится счастливее.
Это тоже проверялось не однократно, особенно первая истина, ведь когда в конце релиза обнаруживаются ошибки, то заказчик забывает, что вы работаете, например, по Scrum. У него в голове крутятся такие вопросы: «Когда будет исправлено?», «Кто виноват?», «Почему так получилось?». И заметьте, именно в таком порядке. Вряд ли в этот момент заказчик ждет от вас, что вы начнете играть в Planning Poker, расставлять Story Point и планировать спринт. И velocity его не интересует, даже если оно выросло в два раза по сравнению с предыдущим спринтом. И на графики он тоже не будет смотреть. Поэтому если Вам мешают некоторые артефакты в Scrum или Вы считаете их не очень полезными именно в вашем проекте, не бойтесь их выкинуть, ничего в этом страшного нет. Главное, чтобы Ваша команда продолжала двигаться вперед и была гибкой в плане изменений. Scrum — это своего рода framework, состоящий из отдельных частей. Можно использовать все его части, можно подключать постепенно, а можно и изменить что-то под ваши нужды. В этом мне кажется и есть смысл гибкой (agile) методологии, когда не Вы прогибаетесь под методологию, а методология прогибается под Вас.
Еще одна истина, которая мне нравится, и которая приносит свои плоды — это выделяйте тестерам как можно больше времени на тестирование готового продукта, а также давайте тестерам тестировать промежуточные результаты Ваших трудов. Наверное вторая часть предыдущего предложения является главной. Я всегда даю своим тестерам пощупать сырую версию приложения. Зачем? Для того, чтобы они начали критиковать, сказали, что что-то не удобно, внесли идеи, начали писать тесты для тестирования того, что будет, начали продумывать узкие места в логике, интерфейсе. Это немного достает, но тем не менее приносит свои плоды. Главное не допускайте одной ошибки, о которой я слышал во многих проектах. Ошибка заключается в том, что тестеры и программисты сидят отдельно, а самое главное не общаются на прямую. Т.е. образовывается два вражеских лагеря. Это не правильно, помните, Вы — команда, Вы работаете над одним продуктам, Ваши цели совпадают. Помогайте друг другу, сидите вместе, задавайте вопросы, общайтесь.
Agile содержит в себе множество методологий — XP, Scrum, Lean, Kanban, ScrumBut (СкрамНО). Сев разбирать методики, я понял, что не могу сказать, что моя команда работает по какой-то одной из них. В целом наш рабочий процесс можно изобразить так:
![image](http://a3.sphotos.ak.fbcdn.net/hphotos-ak-ash3/535814_360503470678544_100001566810464_1007938_2013580064_n.jpg)
Как видите, мы используем, множество пунктов из разных методологий, множество — но не все. Мы адаптировали методологии под свой процесс разработки, под свою команду.
Мы используем множество рекомендаций из 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(ами), т.к. в спринт могли впихнуть новые задачи. И диаграмму мы не строили, потому, она оказалась не наглядной. Когда нас спрашивают, в процессе разработки, как обстоят дела, мы показываем страницу релиза, которая выглядит примерно так:
![image](http://a4.sphotos.ak.fbcdn.net/hphotos-ak-ash3/576317_360503297345228_100001566810464_1007937_2062108228_n.jpg)
Когда-то мне посоветовал ее вести Алексей Лупан, он выступал на конференции и показывал, что-то подобное для своего проекта. Я внедрил это в свой проект и это оказалось удобно. На этой странице видно сколько features мы включили в релиз, кто отвечает за каждую feature, в каком она состоянии. Также указывается срок сдачи в тестирование и в Production. Самое важное тут виден список всех критических и очень важных ошибок, на которые нужно обратить внимание перед сдачей новой версии продукта. Такая страница мне нравится тем, что если в проекте больше одного тестера, то я говорю всем — «Тестируйте важные ошибки, и не важно, что они оформлены на кого-то другого, лучше пройтись свежим взглядом. Так можно найти что-то новое». И это работает. Сколько раз у меня были такие ситуации, когда один тестер находил ошибки у другого тестера. Это реально спасает. Конечно, не всегда получается делать двойное тестирование, но по возможности старюсь это практиковать. Тут хорошо срабатывает поговорка одна голова хорошо, а две лучше.
И так, я рассказал, чем мы не пользуемся в Scrum. Ах да, чуть не забыл, мы не проводим каждодневные standup митинги. Мы сидим рядом, на расстоянии вытянутой руки, все что обсуждается — обсуждается рядом с командой, а значит — слышат все. Поэтому митинги проводятся по необходимости. В основном когда этого требует заказчик. Тогда мы печатаем страницу релиза, и печатаем разбитые на подзадачи задачи, со статусом напротив каждой подзадачи и с комментариями в колонке Problems, если таковые имеются.
Вообще, в процессе работы я усвоил для себя две истины:
1. заказчику все равно по какой методологии Вы работаете, на самом деле его интересует конечный результат;
2. если давать заказчику больше, чем он ожидает, он становится счастливее.
Это тоже проверялось не однократно, особенно первая истина, ведь когда в конце релиза обнаруживаются ошибки, то заказчик забывает, что вы работаете, например, по Scrum. У него в голове крутятся такие вопросы: «Когда будет исправлено?», «Кто виноват?», «Почему так получилось?». И заметьте, именно в таком порядке. Вряд ли в этот момент заказчик ждет от вас, что вы начнете играть в Planning Poker, расставлять Story Point и планировать спринт. И velocity его не интересует, даже если оно выросло в два раза по сравнению с предыдущим спринтом. И на графики он тоже не будет смотреть. Поэтому если Вам мешают некоторые артефакты в Scrum или Вы считаете их не очень полезными именно в вашем проекте, не бойтесь их выкинуть, ничего в этом страшного нет. Главное, чтобы Ваша команда продолжала двигаться вперед и была гибкой в плане изменений. Scrum — это своего рода framework, состоящий из отдельных частей. Можно использовать все его части, можно подключать постепенно, а можно и изменить что-то под ваши нужды. В этом мне кажется и есть смысл гибкой (agile) методологии, когда не Вы прогибаетесь под методологию, а методология прогибается под Вас.
Еще одна истина, которая мне нравится, и которая приносит свои плоды — это выделяйте тестерам как можно больше времени на тестирование готового продукта, а также давайте тестерам тестировать промежуточные результаты Ваших трудов. Наверное вторая часть предыдущего предложения является главной. Я всегда даю своим тестерам пощупать сырую версию приложения. Зачем? Для того, чтобы они начали критиковать, сказали, что что-то не удобно, внесли идеи, начали писать тесты для тестирования того, что будет, начали продумывать узкие места в логике, интерфейсе. Это немного достает, но тем не менее приносит свои плоды. Главное не допускайте одной ошибки, о которой я слышал во многих проектах. Ошибка заключается в том, что тестеры и программисты сидят отдельно, а самое главное не общаются на прямую. Т.е. образовывается два вражеских лагеря. Это не правильно, помните, Вы — команда, Вы работаете над одним продуктам, Ваши цели совпадают. Помогайте друг другу, сидите вместе, задавайте вопросы, общайтесь.