Положение интернета вещей, в отличии к примеру от некоторых веб-приложений, не может быть сделано по принципу: "скажите что надо, мы сделаем". Разработка не исполняет желания заказчика, а решает его проблему. И к началу разработки обязательно должно быть понимание способа решения и хотя бы общее представление об архитектуре. И да, для приложений интернета вещей на современной платформе, такая прикидка может быть сделана очень быстро, ведь самоорганизация приложения такова, что очень быстро и с минимальными ресурсами, может быть выстроена ядро приложения, вокруг которого может наращиваться дальнейший функционал. Тут важно определить, что требуется от ядра предложения, ну вот например, для человека ориентированной интерактивной системы, такой основой может стать сам веб-интерфейс, а приложение будет, по сути обслуживать взаимодействие с ним пользователя. Для системы ориентированной на управление из облака взаимодействия вещей, основой будет виртуальная модель этих вещей и взаимодействия в ней, а для систем ориентированной на работу с данными, к примеру, на предиктивную аналитику, обнаружение аномалий в рядах данных, выявление паттернов и так далее. Основой становится, структура данных и средство их хранения анализа, ну и так далее. Если принять, что условием выполнения разработки является четкое понимание задачи, способа и концепции ее решения, то может быть выбрана любая подходящая ситуация методологии работы над проектом. Если архитектура понятна, а необходимый опыт есть, то гибкие методологии разработки являются мощным инструментом, позволяющим быстро предоставить заказчику необходимые ему решения. И Scrum тут дает возможность получить результат достаточно быстро, поскольку в Scrum задача может дробиться на sprint-ы, соответствующая реализация отдельных элементов архитектуры, ну и даже их частей. Поэтому такой подход очень широко используется в стартапах, при желании быстрее вывести продукт на рынок. Но плохо подходит для заказных работ, поскольку не дает заказчику представление о сроках и затратах. А вот небольшой типовой заказной проект, как раз может быть быстро сделан, по классической каскадной модели. И вашим плюсом может стать то, что вы точно сможете обозначить заказчику сроки, стоимость и другие параметры проекта. Для более крупного проекта, так может быть реализовано ядро системы, становящееся минимально жизнеспособным продуктом или прототипом. И может далее обрастать инкрементами и наращивать функциональность. Получаем таким образом, инкрементную или прототипную модель и обращаться к гибким методологиям на этом этапе нет никакой необходимости. Однако на этапе ввода в эксплуатацию или сопровождения, именно гибкий подход может оказаться очень полезным, ведь приложения интернета вещей, хотя и выполняет часто функции, внешне выглядящие, как работа автоматизированной системы, но в основе его присутствует облачное или иным образом организованная серверная структура. И это позволяет иметь непрерывный доступ к системе, одновременно пользователю и разработчикам и, соответственно, немедленно получать обратную связь и новые требования. Особенно хорошо подходит для этого методология канбан, которая наименее директивна, не требует кросс-функциональной команды и позволяет организовать непрерывный итерационный процесс. Поэтому канбан удобно использовать для развития проекта, от ядра до текущих требований пользователя, в том числе и в случае, если его требования у пользователя возникают уже в ходе эксплуатации готовой системы. С другой стороны, расширяются и возможности удовлетворения этих требований, от простоты внесения изменений в систему, до простой интеграции с другими продуктами с целью расширения функционала. Это важная тенденция и мы обсуждали ее когда говорили о коммерциализации приложения интернета вещей. По мере того, как интернета вещей становится все более широко используя технологии, потребители начинают все больше ожидать от технологических решений. А поскольку для большинства людей умным подключенным устройством уже является их смартфон, они ожидают, что другие подключенные устройства будут столь же эффективны во взаимодействии с другими устройствами и эта связь может быть так же легко организована. Для многих компаний становится проблемой, что они не поспевают за этими ожиданиями. Старый подход сделал и забыл, перестает быть актуальным. Ему на смену приходят новый, сделал и потом все время совершенствуешь. Гибкая методология хорошо подходит для того, чтобы работать с этими постоянно меняющемся требованиям и ожиданиям пользователя в среде, где все, совсем взаимосвязано. Гибкая методология позволяет получить приложения, практически непрерывно обновляемое, всегда соответствующие требованиям пользователя. При этом давая возможность и разработчикам строить свою работу в удобном им режиме. Но, чтобы это сработало, форматы требований, должны быть адаптированы именно под такой бесконечный формат жизненного цикла. Аналитик, должен быть вовлечен в управление проектом в широком смысле, а не только на этапе формирования первоначальных требований. Правильная концепция и ее реализация в продукте, становятся еще более важной. Подведем итоги! Современная платформа позволяет очень легко и быстро создавать легко масштабируемые и наращиваемые приложения, в которых просто менять и добавлять необходимые функции, и развивать в соответствии с пожеланиями пользователей. Именно поэтому, понимание того, что и для чего делается, следования единой концепции и подходов становится критически важным, поскольку в противном случае, система очень быстро становится неуправляемой. Возрастает, соответственно, и требования к архитектуре, предлагаемые решения качество проекта. С другой стороны, простота технической реализации приложений на современных платформах, резко снижает требования квалификации исполнителей. Таким образом, за счет проработки архитектуры и качества подготовки документации, существенно могут быть снижены сроки и стоимость реализации проекта. Это делает возможным разработку даже крупных проектов, небольшими командами, куда входят аналитик возможно даже на аутсорсе, 1, 2 квалифицированных разработчика в качестве архитекторов, дизайнер пользовательских взаимодействий графических интерфейсов и несколько линейных программистов. Работа над проектом начинается с четкой фиксации требований и тщательной разработки архитектуры, а для человека ориентированных приложений, с архитектуры, пользовательских взаимодействий и интерфейсов, на основе которых, выстраивается модель данных и формируется ядро приложения. Дальнейшее развитие системы до базовой функциональности, согласованной заказчиком, может идти по инкрементной или прототипной моделям, а дальнейшее сопровождение, и дальнейшее расширение функциональности, на основе гибких методологий, в том числе канбан. Несколько слов напоследок, программа Engineering Elementary, разработанная Бостонским музеем науки, описывает 5-этапный процесс инженерного проектирования для детей, состоящих из следующих шагов: ASK - спроси, imagine - представь, вообрази, plan - спланируй, create - создай и improve - улучши. Для каждого шага, приводятся примеры направляющих вопросов. Спроси! В чем проблема? Что сделали другие? Каковы ограничения? Представь! Каковы варианты решений? Что еще можно продумать? Какой вариант решения лучший? Спланируй! Ход процесса. Какие материалы и ресурсы тебе понадобятся? Создай! Следуй своему плану и создай то, что хотел и проверь это. Улучшай! Что работает, что не работает, что можно сделать лучше? Измени свой дизайн, чтобы сделать его лучше. Проверь это. Вы видите, что общие подходы и этапы совершенно те же, что мы рассматривали. Просто сформулированы немножко по-другому. Так что если вам будет сложно на первых порах запомнить логику работая над проектом, вы всегда можете ориентироваться на этот простой набор шагов.
