Гибкий подход разработки ПО — Scrum
И как всё это касается меня — разработчика?
Вам нравится разрабатывать фичи, которые никто не будет использовать?
Вам нравится работать по проектному плану, в который вы не верили с самого начала?
Вам нравится кодировать архитектуру, которую кто-то продумал до вас, и в которой вы видите множество недостатков?
Вам нравится работать в группе людей, где вы чувствуете себя одиночкой?
Я пишу это для тех, кто отрицательно ответил на перечисленные вопросы.
В Рунете вы можете найти множество статей и обзоров гибкой разработки, в частности XP и Scrum. Это ещё одна. Чем же она отличается?
Отличается она тем, что нацелена на аудиторию разработчиков, которым как мне подсказывает мой опыт объяснить выгоды от применения гибких подходов (или agile software development) намного сложнее, чем менеджерам проектов или представителям стороны заказчиков.
Ещё она отличается тем, что написана по просьбе моих друзей специально для developers.org.ua.
Так, хватит воды. Перехожу к сути.
Кстати, на счёт воды... Подходы ведения проектов, которые ставят в сравнение с гибкими подходами называют водопадными (или каскадными). Их так называют потому, что артефакты таких проектов перетекают от отдела к отделу как вода на каскадах водопада. Очевидно, что пересогласование требований или перерисовка архитектуры в таком проекте тем сложнее, тем больше утекло воды с момента написания такого документа. Признаками такого проекта являются горы документов, функциональная разбивка компании (отдел разработки, отдел тестирования...), заранее принятые решения и далеко идущие (и уже возможно устаревшие) планы.
Всё это не так плохо, если помогает эффективной работе. Часто же ей это вредит. Лучшее враг хорошего?
Давайте теперь разберёмся с аджайлом и в частности Скрамом.
Скрам — это подход управления проектами (при чём не только по разработке ПО), который предлагает каркас, в рамках которого вы можете строить свой agile процесс, адаптирую его части по ваши нужды. Это не конструктор, но цельный набор хороших практик, с которого часто легче начать, нежели с нуля.
Приходилось ли вам учить новый язык программирования или какой-то API, начиная с примера в мануале и переделывая его по ходу под ваши нужды? В итоге в конечном коде возможно не останется ни одной строки, которая была в начальном примере. Тем не менее использовать за основу простой работающий пример было удобно. То же самое и со Скрамом. Примените, отладьте, поломайте, почините, потом смело меняйте на ваш вкус.
Итак, Скрам — это термин из регби, означающий так называемую «свалку», когда все члены команды собираются в кучу.
Гибкая разработка ПО по принципу свалки...
Давайте лучше называть это Скрамом или «командным подходом».
Правила просты для озвучивания (но зачастую не так просты в реализации):
1. У вас должен быть один человек в проекте, который уполномочен принимать решения о том, какую фичу стоит разрабатывать раньше, какую позже.
«Кто платит, тот и музыку заказывает».
Обычно этот человек работает на стороне заказчика. Или является бизнес аналитиком. Или быть может синхронизирует взгляды различных заинтересованных в разрабатываемом продукте заказчиков.
В любом случае разработчикам проще, если такой человек есть, он доступен, и он такой один на проект (во избежание конфликтов).
Его называют «Product Owner» (оставим без перевода)
2. Product Owner поддерживает список требований-пожеланий к продукту. Этот список он сортирует (приоритезирует) по принципу «ценное сверху, менее ценное снизу».
Такой список называется «Product Backlog» (без перевода).
3. Собираясь на планирование короткой фазы проекта (итерации или «спринта» — дословно забега на короткую дистанцию), команда (а это все те, кто влияют на разрабатываемый продукт — архитекторы, дизайнеры, разработчики, тестировщики) выбирают из Product Backlog ту верхнюю часть, которую они считают, что реально начать и закончить (!) за этот короткий выделенный период.
Так как часто для принятия подобных решений требуется пожертвовать детализацией фич, Product Owner принимает активное участие в подобном планировании.
Таким образом заказчик и команда принимают удовлетворяющие всех решения: заказчик ожидает получить некий ценнейший набор функционала за довольно короткое время, команда же получает план, в который верит.
4. По истечению оговоренного срока команда и заказчик встречаются для просмотра и обсуждения результатов. Это называется демонстрацией («де-монстрация» — изгонение монстров из софта).
На выходе такого митинга мы имеем а) уменьшенные риски, за счёт доказательства работоспособности команды, технологий и требований; б) новые идеи по развитию нашего продукта (вряд ли он готов к продаже после двухнедельной работы); в) доверие заказчика и команды к друг другу.
5. После всей перечисленной тяжёлой работы команда собирается и обсуждает серию экспериментов и задач, которые она думает ей помогут более эффективно работать в течение следующей итерации (спринта).
Это называется ретроспектива (дословно «просмотр прошедшего»; или что-то в этом роде — лингвисты поправят).
6. Забыл сказать — во время спринта членам команды скорее всего придётся синхронизировать свои усилия и помогать друг другу для более слаженной работы и достижения общего результата. Говорят, что хорошо это делать раз в день в течение 10–15 минут в присутствии всех членов команды. Это и называется Скрамом.
7. Во время подобного обсуждения члены команды могут пожаловаться на проблемы, которые они не в силах устранить (падает сервер, пропадает интернет, слишком тёплое пиво...) Эти проблемы помогает устранить так называемый ScrumMaster — человек, который понимает принципы и тонкости Скрама, командной работы и «нежного лидерства». Он делает всё, чтобы команда максимально эффективно общалась с заказчиком, между собой и достигла своих обещаний и целей.
Такие вот правила. Или скорее хорошие практики, которые, работая вместе, помогают достичь отличных результатов, построить хорошие и честные отношения с заказчиками и в команде, получить удовольствие и удовлетворение от работы. Они, как мне кажется, дают шанс каждому разработчику подняться на ещё одну ступеньку профессионализма.
Вам нравится разрабатывать фичи, которые никто не будет использовать?
У нас нет такой проблемы. В Скраме мы разрабатываем только наиболее важные с точки зрения заказчиков и конечных пользователей фичи. Очень вероятно, что наш проект успешно завершится до того момента, когда в беклоге останутся только низкоприоритетные фичи. Тем лучше!
Вам нравится работать по проектному плану, в который вы не верили с самого начала?
У нас нет такой проблемы. В Скраме мы работаем по плану, который мы сами обговорили с заказчиками и в который сами верим. К тому же, мы строим наши планы на довольно короткие интервалы. Так что если что-то и пойдёт не так, как мы думали, то у нас будет возможность внести коррективы и успешно сдать проект. Да, кстати, разработчики у нас на проекте сами выбирают задачи, над которыми им работать.
Вам нравится кодировать архитектуру, которую кто-то продумал до вас, и в которой вы видите множество недостатков?
У нас нет такой проблемы. В нашем Scrum-проекте наш архитектор постоянно доступен и сидит с нами в одной комнате, так что у нас всегда есть возможность повлиять на принятие решений. К тому же, благодаря таким практикам как refactoring и unit-testing, нам не приходится продумывать все архитектурные решения наперёд — мы знаем, что сможем ввести в код практически любые изменения без поломок продукта и существенных задержек в отладке.
Вам нравится работать в группе людей, где вы чувствуете себя одиночкой?
У меня нет такой проблемы. Мне всегда готовы прийти на помощь, как в прочем и я. Мы все ежедневно обсуждаем чем друг другу помочь. У нас же общая цель! Какие там одиночки.