Пример: бот для учебного расписания

Введение

В данной статье описано, как правильно подходить к разработке IT проектов, их оценке и сопровождению. Давайте рассмотрим на примере простого проекта для университета, как реализуются все шаги, описанные в материалах курса.

Ну, давайте по порядку.

Выбор идеи

Рассмотрим ситуацию.

Вы поступили в университет, начали учебу и столкнулись с тем, что расписание часто меняется и это приносит множество неудобств:

• расписание хранится на сайте вуза в виде таблицы, которую неудобно просматривать (много лишней информации, мобильные устройства плохо отображают большие таблицы, каждый раз нужно масштабировать)
• невозможно отследить момент, когда расписание изменилось
• лень - двигатель прогресса

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

Идея, конечно, хорошая, но как это реализовать?

На этом моменте и запускается беспощадный конвейер…

Предварительная оценка

Вы поискали в интернете и не нашли ничего, что полностью удовлетворило бы вашим требованиям. Либо это стоит денег, либо просто не работает так, как вам бы того хотелось.

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

Выход один - написать самостоятельно.

Первым делом Вы узнали, что в ближайшее время способ доставки расписания для студентов не изменится, и Вы не слышали, чтобы кто-то начал разрабатывать продукт, подобный Вашему. То есть рынок пуст и можно спокойно занять в нём свою нишу.

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

В данном случае проект простой, но и тут есть несколько ролей.

• В данный момент, Вы как автор идеи являетесь владельцем проекта. С этой стороны ваша задача оценить возможности и риски проекта. Делать это не обязательно именно Вам, но ответственность за развитие однозначно лежит именно на Вас.

• Всегда существует потребитель товаров и услуг, иначе не было бы смысла что-либо создавать и производить. Эту роль мы назовем просто - Клиент. Вы также в данном случае являетесь клиентом, так как в первую очередь проект задуман облегчить жизнь именно Вам, но не стоит забывать, что в такой же ситуации и все остальные студенты вашего учебного заведения. Они также являются потенциальными клиентами (пользователями Вашей программы).

• Есть люди, которые будут непосредственно разрабатывать - это как ни странно разработчики. И у Вас как раз на примете есть парочка друзей-прогульщиков, которые только рады будут подписаться под Вашу идею, если правильно попросить.

Есть и другие роли, но нам хватит пока и этих.

Снова обратившись к талмудам, которые пишут бородатые дядьки в интернете, вы решили наладить коннект со вселенной и четко прописать, как же должна работать эта программа и что вообще она из себя представляет. Первым делом вы придумали название, на что ушла примерно вечность… Назвали просто и без прекрас “Скайнет”, как в Терминаторе, размах будет примерно такой же (ну или Вам так показалось).

Вы поспрашивали друзей, собрали фокус-группу (точнее просто вкинули мысль в общий чат курса и получили обратную связь от ничего не подозревающих будущих потребителей топ контента), прибавили к этому супер популярный подход “Пользовательских историй” и накидали несколько мыслей:

1. Я КАК пользователь ХОЧУ иметь возможность получать более простой вариант расписания именно моей группы, ЧТОБЫ не тратить время на поиск нужной мне информации в общей таблице с расписанием.

Неплохо, но этого мало, чтобы обрисовать проект в деталях. Поехали дальше.

2. Я КАК пользователь ХОЧУ иметь возможность получать уведомления в виде письма на электронную почту, когда изменится расписание, ЧТОБЫ не пропустить актуальных изменений.

Хорошо, уже похоже на что-то адекватное. Вы решили, что этого вполне достаточно для старта.

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

После подтянулись потенциальные разработчики, неравнодушные к ситуации, но очень ленивые, чтобы самим замутить подобный проект. Вы выдали первым делом им задание узнать, как сделать всё то, что требуют пользователи и помочь оценить сроки разработки.

ТЗ, конечно, как такового нет, но вместе вы смогли накидать примерную архитектуру проекта:

• Вы зашли на app.diagrams.net и сотворили нечто.

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

• Как получить расписание с сайта вуза и переделать его так, чтобы не стыдно было отправить клиенту?

• Как запихнуть всё это в электронное письмо и отправить?

• Наконец, как общаться с пользователями?

Нехилые такие вопросы, правда? Ну, это не всегда проблема на самом деле. Гугл в помощь.

Спустя море литров кофе и бессонную ночь, миллион статей в интернете и пару видосиков на ютубе, всё слегка стало проясняться.

Вы узнали, что каждый из этих вопросов описывает эпик. Каждый эпик нужно уточнить и разбить на более мелкие задачи. Тут мы пришли к такому понятию как декомпозиция. Снова придётся лезть за советом к крутым бородатым дядькам.

Похоже, что это вопрос к разработчикам, не всё же делать Вам, правильно? Эти задачи Вы скинули на них (делегировали по-научному), а Вам нужно прикинуть сроки и помониторить рынок. Вдруг параллельная группа прознала про Ваш план и решила погубить Скайнет? Итак, ваши разрабы декомпозировали вдоль и поперёк, вникли в проблему и выдали новую архитектуру:

Со своей стороны программисты тоже написали User stories:

1. Как разработчик я хочу программную прослойку, которая будет способна получать данные от сервера университета, чтобы мы могли автоматически доставать расписание.

2. Как разработчик я хочу метод, который будет выбирать из полученного расписания нужный фрагмент, чтобы мы могли выделить нужную клиенту часть продукта.

3. Как разработчик я хочу метод, который будет сохранять в базу данных обработанные расписания, чтобы ими могли пользоваться другие части сервиса.

4. Как разработчик я хочу метод, который будет формировать текст сообщения для каждого клиента, чтобы предоставлять продукт клиенту через почтовый сервер.

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

6. Как разработчик я хочу настроить CRON, чтобы иметь возможность запускать процесс рассылки по расписанию.

7. Как разработчик я хочу настроить брокер сообщений, чтобы иметь возможность быстро сформировать очередь сообщений для клиентов.

По идее, этого достаточно чтобы описать архитектуру проекта.

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

Тут вы решили, что вам нужны уже проверенные, простые, и хорошо задокументированные решения, но всё равно выбрали java script.

Сервер вы решили написать на node.js, а остальные части проекта, как оказалось, уже давно придуманы теми самыми бородатыми дядьками и нужно лишь связать это всё воедино. Отлично!

Разработка

Дальше встал вопрос: как разрабатывать проект, если собираться вместе все могут лишь раз в неделю, а времени нужно затратить по вашим общим оценкам 100 часов? Бизнесу это не нужно…

Помедитировав над нулями и единичками, Вы выяснили, что существуют системы контроля версий (git например), и давно уже крутятся такие сервисы как Github и ему подобные. Очень неплохо, там можно хранить наработки и соединять всё воедино, плюс всегда можно откатиться в случае чьего-нибудь затупа.

С этим всё Окей, разобрались. Делаем репозиторий и прикидываем, что делать дальше.

По какой схеме мы будем работать? Нужно максимально эффективно прикладывать усилия и думать о будущем, ведь конкуренты спят и видят, как можно разорить Вашу контору.

Тут Вы вспоминаете, что кто-то там что-то говорил про мессенджеры и ботов, кому-то сайтик был бы в самый раз и прочие уникальные запросы. Хотим ли мы развиваться дальше? А почему бы и нет?

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

Старый дедовский метод, видимо, не катит, хоть и звучит красиво - водопад.

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

• Зарегистирируемся на Github. И зайдем на страницу репозиториев

• Далее ищем, где можно намутить новый репозиторий.

• Тыкаем на зелёную кнопку с надписью “New”, на ней ещё книжечка нарисована. И делаем новый репозиторий.

• Отлично! Теперь у нас есть репозиторий, в котором мы будем хранить код и всю историю изменений. Все взаимодействия с репозиторием в основном сводятся к системе контроля версий git.

• Теперь вспоминаем про все пользовательские истории, которые написали наши клиенты и разработчики. И создаем задачи. Для этого находим на странице репозитория вкладку Issues.

• Тыкаем по вкладке и переходим на нужную нам страницу.

• Находим кнопку “New issue” и, очевидно, не просто так. Тыкаем и на неё тоже.

• Интерфейс понятен, пишем заголовок и описание. В правом меню выбираем лейблы и назначаем ответственного за выполнение. Когда все шаги выполнены, нажимает “Submit new issue”.

• Отлично! Теперь давайте перейдем во вкладу “Проекты” и зафигачим канбан доску.

• Ловкость рук и никакого мошенничества!

• Формируем беклог и запускаем в работу. Настраиваем расписание скрам митингов, рулим процессом и решаем проблемы по мере их поступления.

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

Чем детальней получится декомпозировать задачи, тем быстрее пойдёт разработка. Вы посчитали, что на проект уйдёт 100 человекочасов. Если выставить сроки, например в 4 недели, то на одну неделю получится всего по 25 часов. Это реально? В принципе, да, реально. Вы подумали, что 4 недели потерпеть без Вашей супер программы можно и решили сделать 4 итерации по 1 неделе, на каждую из которых набросали задачи. Получится быстрее, хорошо, нет - ничего страшного, на следующий спринт нужно будет уменьшить нагрузку.

На этом моменте можно уже начинать реализовывать продукт. Для тестовых запусков вы взяли для начала свой личный ноут. Допилили? Шикарно. Прикрутили swagger, попинали сервер - работает.

Теперь нужно решить вопрос, а где крутить сервис и сколько это стоит? По идее, такой проект может спокойно жить и на вашем компьютере, но это не надёжно. Для него хорошо бы арендовать сервер. Но это стоит денег.

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

И тут колесо спринта дало оборот…