Накопилось у меня немножко мыслей на этот счет, и возникло дикое желание выплеснуть их на бумагу.
Что хочется сказать в первую очередь? Я не считаю, что существуют плохие или хорошие методологии разработки. У всех свои задачи, своя специфика работы, свои требования и фактически хорошей может быть та методология, которая дает результат в команде конкретно или в компании в целом. В конце концов, до изобретения Agile и Scrum, как ни странно, тоже писали софт. Писали по разному - и хорошо, и плохо. Даже какой-нибудь археологический waterfall давал результат (да и сейчас, скорее всего, даёт где-то). На мой взгляд, проблемы начинаются, когда методологии начинают боготворить и проецировать на всё и вся. Или применять их из мысли «у нас есть проблемы в разработке, сейчас мы применим какую-нибудь гибкую методологию, и они решатся». Ага, сейчас.
Поскольку я являюсь участником только процесса разработки, я буду касаться исключительно его. Может быть, залезу на смежные какие-то области, но следует понимать, что я не имею доступа к маркетингу и менеджерам. Я, как рядовой разработчик, могу не знать, чего хочет компания, и какие приоритеты у нее. В какую сторону поведут продукт. Это кстати одна из проблемок – я могу неделями заниматься работой, которая полетит в стол или никому не будет нужна.
Ну, давайте попробую начать. Поскольку заранее требований к продукту никто в серьез не собирает и цель вывести на рынок, то, что называется MVP(Минимально жизнеспособный продукт), возникает смешная ситуация. Под жизнеспособностью можно понимать очень разные вещи. Я даже имею некоторую циничную аналогию. Представьте, что вы молодая семья и хотите завести ребенка. Вы можете тщательно к этому процессу готовиться, сдавать анализы и принимать сложные решения при возникновении сложных ситуаций. Как это касается, на мой взгляд, MVP? Некоторые продукты похожи на ребенка без рук, без ножек, с плохим зрением и проблемами в органах. Но он дышит, и сердце бьется, значит «жизнеспособен», поборемся. А потом будем собирать деньги всем миром на лечение.
Одной из основ scrum-методологии является понятие спринта или итерации. По определению это очень небольшой промежуток времени. Как правило - встречается спринт продолжительностью в неделю. Многие мобильные приложения, как раз, обновляются раз в недельку, что выдает в них пользователей подобного подхода. Встает вопрос – «что можно успеть за неделю?». Давайте подумаем что нужно сделать – разработка, ревью, тестирование нового функционала, разработка тестов всех слоёв(Unit,Integration,Behavior и еще каких-нибудь на вкус команды) + опционально комплексное тестирование продукта перед релизом (зависит от того кто осуществляет обновление продукта, иногда этим занимаются другие команды тестировщиков, в моем случае этим занимается команда (команды), осуществляющие поддержку продукта) + попутно, еще и хочется старые баги исправить. Те, которые критичные. Да и практика показывает, что внезапно от клиентов можно получить информацию о жутком баге, который запилили программисты и проглядели тестировщики. Надеюсь, ничего не забыл. Теперь давайте считать. У нас есть 5 рабочих дней. Один выкидываем сразу на исправление блокеров обновления и тестирования релизной версии. Остальные 4 делим пополам, так как разработка тестов, как правило, удваивает время разработки функционала и имеем честные 2 рабочих дня на то чтобы сделать для клиента что-то полезное. Что за это время можно успеть – можете написать в комментариях. Ну, можно конечно тесты не писать и мы имеем 4 дня на разработку, только парадокс в том, что из выигранных двух дней – полтора, скорее всего, уйдет на исправление увеличившегося количества багов или увеличение времени на тестирование, так как надо помимо нового функционала – проверить еще и что-нибудь рядом. Как итог – обновление содержит только багфиксы, а продукт забагован по ноздри. Знакомая картина?
Другой, часто используемой фишкой гибкой методологии, является доска. Про доску в принципе ничего плохого сказать нельзя, это отличный инструмент визуализации процесса. Проблема может быть в том, что на ней есть. Самая веселая доска, что я видел – 3 колонки. «Надо сделать», «Делаем», «Сделано». Т.е. тестирование функционала делается через создание задачи на тестирование другой задачи. Вопрос – при провале тестирования надо переоткрывать старую задачу или заводить новую на исправление? А как дальше тестировать? Хотя имеет место быть, если в команде отработана данная схема. Просто, я думаю, применять ее с нуля трудно. Для своей работы мы используем следующие колонки: ожидание, работа, требуется ревью, ревью, ожидание тестирования, тестирование, протестировано, готово к деплою, задеплоено. На мой взгляд, самым узким местом тут является «ревью». Все знают, что ревью надо делать, мало, кто знает, как его надо делать. Для качественного ревью нужны, как мне кажется, следующие соглашения:
1) Количество и размер коммитов. Данная проблема может быть решена ограничением времени на разработку задачи. Если задача требует больше одного дня – разбивай. Однако это не меняет того, что на ревью может попасть солидная портянка кода, в которой не сразу понятно, откуда начинать читать.
2) Общекомандные требования к ревью. Смысла в ревью нет никакого если один член команды въедливо ищет опечатки и анализирует решение, а другой пропускает код только потому что не нашел очевидных испражнений.
3) Корпоративные требования к ревью. Вот вроде одно и тоже с пунктом 2, но есть нюансы. В команде мы можем строить друг друга как хотим. Требовать идеальных решений и давать их. Но если соседи творят ерунду, то вы тоже будете с этой ерундой работать. С другой стороны – если есть хотя бы п.2, вы можете профессионально расти внутри команды и давать пример другим, может и получится.
4) Общий средний уровень профессиональности программистов – вот самый скользкий пункт. Предположим в команде есть 1 стажер, 2 мидла и 1 сеньор. Получается, что один сеньор может затравить стажера ревью, так что тот бросит желание программировать, а кто будет ревьювить сеньора вообще непонятно, так как его приемы могут быть банально неясны другим.
Последней важной вехой, которой хочется упомянуть, являются митинги. Ежедневное собрание с ответом всех участников группы на 3 вопроса: «Что я делал вчера?», «Чем я буду заниматься сегодня?», «Какие возникают проблемы?». Очень полезная практика, особенно если такие собрания посещает кто-то выше руководителя группы. Если не посещает никто, то, скорее всего, встреча проходит в формате «я работал вчера, буду работать сегодня, проблем нет». Или «Вчера работал по багам, а сегодня по задачам». Руководство для себя может помечать скорость разработки функционала. Но команда, скорее всего, не сидит молча целый день. Если разработчик испытывает проблему и не задает вопросы коллегам до митинга – это проблема серьезней, чем кривой и скучный митинг.
На этом у меня, наверное, всё. Вышло несколько более многословно, чем обычно, но и боли накипело тут больше чем по ранее описанным ситуациям. Может кому-то кажется, что я просто не разбираюсь в методологии? Ну, может быть, я не отрицаю. Только дело в том, что вряд ли я один такой во всем мире. И разработчиков, которые работают по методологии, не разбираясь в ней, не мало. И это приводит к проблемам.