Polonium Arts

Российская компания, специализирующаяся на разработке мобильных приложений и комплексных IT-решений для бизнеса. Мы создаем программные продукты, которые достигают поставленных бизнес-целей. Расска...
Страна: Россия
Город: Москва
Год основания: 2010
Количество сотрудников: 21-50
Специализация:
Количество приложений: 20
PR/Медиа:
Не по годам: сколько нужно времени, чтобы бизнес заработал
http://www.the-village.ru/village/business/case/157861-skolko-nado-vremeni-chtoby-raskachat-biznes
Polonium Arts о мобильных приложениях и зеленых ограх
http://www.computerra.ru/45758/pavel-abdurahimov-polonium-arts-o-mobilnyih-pril/
Связной запустил мобильное приложение для iOS и андроид
http://android-robot.com/svyaznoy-zapustil-mobilnoe-prilozhenie-dlya-ios-i-android/
Карту «Тройка» теперь можно пополнить через мобильное приложение «Моя Тройка»
http://corp.cnews.ru/news/line/kartu_trojka_teper_mozhno_popolnit
Показаны записи 1-12 из 20.
Образ жизни
Free
Развлечения
Free
Развлечения
Free
Фото и видео
Free
Финансы
Free
Музыка
Free
Путешествия
Free
Образ жизни
Free
Развлечения
Free
Бизнес
Free
 
 
09-11-2017, 12:41
Polonium Arts

Мобильная разработка изнутри. Это модное слово — agile

Работать по agile — это модно. Когда заказчик заказывает мобильное приложение, он хочет, чтобы оно разрабатывалось непременно по гибкой методологии. Но мало кто знает, что сам по себе agile — это не совсем методология.

Химия — это естественная наука. Но естественная наука — это никакая не наука. Представьте себе такой диалог между условной парой заказчик-исполнитель:
— Я хочу заниматься естественной наукой.
— Отлично! Мы как раз занимаемся естественными науками. Химия, физика, география — чем займемся?
— Естественной наукой.
Несложно догадаться, что с таким подходом человек, скорее всего, будет заниматься какой-нибудь беспросветной дребеденью.

В разработке ровно такая же картина: agile — это общее название для многих методов и подходов к разработке, иначе называемых “фреймворки”.

Каким бывает agile в идеальном мире

Agile — это общее название принципа разработки, в котором есть несколько методологий, или фреймворков. Самые известные — SCRUM и Kanban, самая свежая и прогрессивная — Шесть Точек. Но обо всем по порядку.

Обе методологии — SCRUM и Kanban — предполагают формирование продуктового бэклога до начала разработки. Но, если в SCRUM вместе с продуктовым бэклогом формируются все спринт-бэклоги с прописанными датами выхода каждой фичи, то в Kanban спринт-бэклог формируется проектной командой каждую неделю (или каждые две недели, если спринт сдвоенный).

Команда — очень важное слово для понимания гибких методологий. В идеальном мире именно команда формирует и продуктовый бэклог, и спринт-бэклоги. Под командой мы понимаем не только команду заказчика, но и project-менеджера, и разработчиков.

SCRUM позволяет создать запланированный продукт в жесткие сроки, не отходя от бэклога. Kanban же оставляет пространство для маневра и позволяет корректировать план действий на ходу, меняя приоритетность задач в зависимости от ситуации.

Обе методологии малореалистичны в работе студии и заказчика: SCRUM требует жесточайшей дисциплины и не допускает “это же несложно” и “мы подумали, что будет логично сделать это сейчас”, а Kanban может увести разработку далеко от изначально запланированного продукта.

На их фоне выгодно отличается методология, придуманная Toyota — Шесть Точек. Её отличие в том, что в этой методологии нет изначального видения конечного продукта — он рождается в процессе разработки. С первого взгляда может показаться, что методология предлагает разрабатывать то, не знаю что и так, не знаю как. Но это только с первого взгляда. Например, мы делаем интернет-магазин. Средний срок разработки стандартного приложения в области онлайн-торговли — полтора года. Но ведь за полтора года тренды в индустрии могут измениться в корне, и почти невозможно предугадать, что будет актуально. Шесть Точек позволяют не тратить время на переносы спринтов и перекраивание бэклога, а постоянно держать руку на пульсе рынка.

В самых утопичных утопиях, за соблюдением методологии следит специальный человек — agile-мастер. Не путайте его с project-менеджером: agile-мастер отвечает за сам процесс разработки, он хранит методологию и помогает команде не сойти с ума от всех этих ролей, артефактов и препятствий. Agile-мастер проводит митинги, помогает команде увидеть происходящее «сверху» и указывает на проблемные места в процессе взаимодействия. В реальной жизни роль agile-мастера частично играет project-менеджер.

Все методологии хороши в теории, но в нашей практике не было еще ни одного заказчика, который смог бы выдержать методологию и не сойти на Waterfall.

Что происходит на самом деле


На самом деле желание заказчика работать по agile меркнет на фоне “это же несложно” и “мы подумали, что это логично”. За время разработки бэклог может измениться до неузнаваемости, а в размеренное течение спринта обязательно врываются неотложные доработки по перекрашиванию иконок.

Это называется Waterfall — методология без методологии, когда задачи хаотично сыпятся на команду разработки. В отличие от гибких методологий, о которых мы говорили выше, в Waterfall проектная команда не имеет ценности — что, как и когда делать решает заказчик. Но это — такая же крайность, как идеально выдержанная гибкая методология. Чаще всего у заказчика все же есть план, которого он не слишком придерживается.

В условиях отсутствия однозначной методологии, очень многое зависит от компании-разработчика. Надо понимать, когда можно уступить и внести бесполезную правку, а когда нужно стоять на своем и идти по плану так, как запланировали. Надо понимать, что заказчик и его команда — это просто люди, у которых и без разработки много работы. Они могут не отвечать, а потом ругаться на сдвинувшиеся сроки сдачи задачи, могут менять точку зрения, могут вводить в команду новых, не погруженных в проект, людей — к этому просто нужно быть готовыми.

Позиция компании-разработчика может варьироваться от безграничной услужливости до жесткой бескомпромиссности, но мы придерживаемся открытого диалога без лишних эмоций. Если заказчик три дня не отвечал на письма в почте с просьбой дать уточнение по задаче — срок сдачи спринта будет сдвинут на три дня; если полюбовно общаться не выходит, мы формализуем отношения и полностью переезжаем в Jira — чтобы любой участник команды всегда видел, кто, когда и что сделал или написал.

Мы — разработчики, и мы хотим сделать хороший продукт. Если подумать, больше мы ничего не хотим — не хотим казаться пушистыми, не хотим становиться закадычными друзьями с заказчиком. Поэтому в спорных ситуациях мы можем проявить настойчивость, которую даже могут счесть за грубость, лишь бы не прерывать спринт на полпути ради самодурства даже самого большого босса. Бывает нервно, но зато продукт выходит в срок и приносит заказчику деньги.

 
0 0 0

Чтобы оставлять комментарии вам необходимо зарегистрироваться