Менеджмент цифрового мира. Максим Цепков

Чтение книги онлайн.

СКАЧАТЬ style="font-size:15px;">      Важная разница: пригодный для потребителя или в принципе работающий. Пригодность для использования означает выполнение некоторого полного цикла задач. С этим многие сталкивались при ремонте в квартире или строительстве загородного дома: для жизни требуются некоторый набор функций: место, где спать, место для еды с возможностью ее минимально приготовить, места для личной гигиены и для хранения личных вещей. И последовательность ремонта существенно отличается в зависимости от того, надо ли в доме жить. Когда не надо – сильно проще, делаем последовательно. В общем-то с софтом тоже самое. Зачем же делать сложнее? Засада в том, что когда мы потом приходим в построенный дом, то могут выясниться очень неприятные вещи, например, с отсутствием розеток в нужных местах. И в софте они тоже выясняются. И если в случае дома это обеспечивается грамотным проектированием и представлением проекта, то, как показывает опыт разработки софта, адекватно оценить это по проекту – почти невозможно. Пользователям нужен работающий софт – приложение, которое можно запустить, понажимать на кнопки, попробовать решить в нем свои задачи, и только в этом случае они могут дать адекватную обратную связь о пригодности приложения.

      Переход к инкрементальному созданию приложения в IT потребовало кардинального пересмотра способов работы с требованиями и проектирования приложения. Появились новые форматы, такие как user story, каждая из которых описывала ценную для пользователя функциональность и была относительно мала, так, что можно было легко ими маневрировать при планировании, в отличие от цельных проектов большого функционала, с которым работали в прошлом. И первая версия Scrum Guide (можно скачать здесь) рекомендовала использовать именно их в качестве элементов бэклога. По мере распространения Scrum другие форматы ведения требований и проектирования тоже адаптировались, например, появился Use Case 2.0, пригодный для инкрементальной реализации, и сейчас могут применяться разные варианты.

      Отметим, что далеко не в любых проектах можно перейти к инкрементальной реализации с поставкой ценности. Понятным примером являются строительные проекты: мост или здание надо построить целиком и запустить в эксплуатацию. Другим примером является организация конференции или другого мероприятия – тут есть финальный релиз и нет промежуточных этапов, приносящих ценность. Однако, есть большая зона, где преобразование возможно в том или ином объеме. И надо отметить, что хорошо поддаются преобразованию проекты НИОКР. Например, концерн Калашникова на одной из встреч, что они применяют Scrum для разработки новых видов оружия. При этом за две недели получается сделать в железе некоторый очередной прототип, демонстрация которого позволяет увидеть ошибки проектирования и неверные пути, которые при традиционном способе были бы проявлены только через полгода, и это дает большую экономию и средств и времени. На AgileBusiness-2018 применении Scrum для разработки СКАЧАТЬ