О том, как мы Scrum внедряли (Часть 1)

Началось всё ровно год назад. Тогда сотрудники нашей компании узнали о том, что есть scrum. Это методология разработки ПО, которая ломала сложившиеся стереотипы в 1С:Підприємство-автоматизации, и буквально взрывала мозг людям, привыкшим работать по стандартной схеме. Методология гласит, что не нужно иметь законченное техническое задание до начала разработки, новые задачи появляются в любое время, ещё задолго до завершения существующих. При этом новые задачи могут изменять и отменять существующие, независимо от того, выполнены те или нет.

Тогда это казалось чем-то абсолютно нереальным. Большинство коллектива было настроено скептически. Но попробовать все же решили.

Немного о методологиях. По каскадной (waterfall) схеме, стандартной, разработка выглядит приблизительно так: определение требований и документирование, потом проектирование и разработка, потом интеграция, тестирование и финальная инсталляция, потом поддержка. Основой здесь является то, что каждый этап выполняется только после завершения предыдущего, в строго определенном порядке. Разработка не может начаться, пока не определены и не утверждены все требования. После утверждения требования нельзя изменить, даже если по каким-то причинам они потеряли актуальность.

Основной критерий выполнения и завершенности проекта – точное соответствие конечного продукта требованиям, определенным в самом начале. С одной стороны, это помогает легко разрешать разногласия с точки зрения формальных деловых отношений, но с другой – это не способствует получению удовлетворения командой от процесса разработки и заказчиком от конечного продукта.

Здесь есть проблема – на начальном этапе, заказчик зачастую не знает, что ему нужно на самом деле (и даже не осознаёт того, что он на самом деле не знает, чего хочет), он не представляет, как будет выглядеть система, и какие идеи, каким образом можно в ней воплотить. А разработчики и аналитики, какой бы огромный опыт не имели, не могут предугадать реакцию отдельного заказчика на конечный продукт, который с их точки зрения может быть идеальным и совершенным.

Вернёмся к scrum. Scrum относится к гибким методологиям разработки (agile). Это означает, что здесь нет жёсткого документирования и следования документации, наоборот – приветствуются изменения в требованиях, т.к. это способствует улучшению и развитию продукта. Главное – удовлетворение заказчика с помощью частых и непрерывных поставок версий продукта, которые заказчик может самостоятельно «прощупать» и понять, чего ему хочется.

Вот основные принципы:

Личности и их взаимодействие важнее, чем процессы и инструменты. Работающее программное обеспечение важнее, чем полная документация. Сотрудничество с заказчиком важнее, чем контрактные обязательства. Реакция на изменения важнее, чем следование плану. Итак, мы решили внедрять scrum. Пора было начинать что-то делать. Первое, с чего мы начали – это решение вопроса, как вписать эту методологию в мир 1С:Підприємство. Нужно было определить, в каком виде scrum будет входить в привычные будни наших разработчиков, аналитиков, руководителей проектов, менеджеров и компании вцелом. Мы начали с принятия решений о том, какие положения и процессы методологии нам точно подходят, а какие нужно трансформировать под наши реалии. Продумывали трансформацию.

Прежде чем пробовать методологию на практике, нам нужно было её переосмыслить в контексте именно нашей компании, нужно было определить точки, от которых мы будем отталкиваться. Мы составили документ, в котором по пунктам описали, как scrum будет выглядеть в исполнении TQM systems. Следующим этапом было использование методологи во внутреннем проекте по переработке нашей собственной учетной системы.

Продолжение следует…

• 
• Контент-маркетолог TQM systems Nataliya Raevskaya
• 6/2/2020 10:50:06 PM
• news