😈 Работа кипит даже в выходные! ☄️

Наши разработчики работают с любого уголка земли, с любого положения и в любом месте.

И все это ради Ваших успешных проектов. 🔼

Всем хороших выходных! 🔥
Для сотрудничества и предложений пишите на почту cooperation@martinscode.tech или в Telegram: @geggggr.

☺️ Agile - как философия разработки 🤩

Agile — это не методология, а целая философия гибкой разработки программного обеспечения.

Её суть — отказаться от всего лишнего и сосредоточиться на самом важном для бизнеса.
Agile помогает создавать ценность быстро, качественно и с фокусом на реальную потребность клиента.

💬 Вот четыре ключевых принципа Agile-манифеста:

— Люди и взаимодействие важнее процессов и инструментов
— Работающий продукт важнее исчерпывающей документации
— Сотрудничество с заказчиком важнее согласования условий контракта
— Готовность к изменениям важнее следования первоначальному плану

«Я не разрабатываю программное обеспечение. Я меняю поведение людей через программное обеспечение.»
— Кент Бек, один из авторов Agile-манифеста

💻 Наша команда следует философии Agile, которая включает в себя множество эффективных подходов — Scrum, Kanban и другие. О каждом из них расскажем в следующих постах.

Всем продуктивного дня! 🔥
Для сотрудничества и предложений пишите на почту cooperation@martinscode.tech или в Telegram: @geggggr.

#Agile #Scrum #Kanban #Разработка #ФилософияРазработки #MartinsCode #IT #ГибкаяМетодология #БизнесИт #SoftwareDevelopment #interest

🚀 SCRUM: Почему эта методология захватила мир IT ❓

Scrum — это гибкая методология управления проектами, основанная на принципах Agile.

Разберёмся, как устроен Scrum и почему он действительно работает.

📌 Основные роли в Scrum:

— Product Owner — владелец продукта. Он определяет, что нужно сделать и с каким приоритетом.
— Scrum Team — команда, в которую входят разработчики, менеджеры и обязательно один Scrum Master. Он отвечает за соблюдение всех Scrum-процессов. Рекомендуемый размер команды — до 10 человек.
— Stakeholders — заинтересованные лица: инвесторы, партнёры, клиенты и т.д.

🌀 Как работает Scrum на практике:

1) Product Backlog (PBL):
Product Owner формирует список всех задач проекта — это живой документ, в который постоянно добавляются и приоритизируются элементы.

2) Sprint Planning и Sprint Backlog (SBL):
Scrum Team выбирает задачи из PBL на ближайший спринт (обычно длится от 1 до 4 недель) и формирует Sprint Backlog. Планирование может занимать до 8 рабочих часов, если спринт длится месяц.

3) Ежедневные митинги (Daily Scrum):
Каждый день команда собирается на короткое совещание (до 15 минут), где обсуждает, что сделано, что мешает, и какие планы на день.

4) Инкремент (Increment):
В конце спринта команда предоставляет рабочий результат — полностью готовый и протестированный функционал.

5) Оценка и обратная связь:
Stakeholders оценивают инкремент, дают фидбек и могут предложить новые задачи. Product Backlog обновляется и приоритизируется заново.

6) Sprint Retrospective:
Команда анализирует, как прошёл спринт: что получилось, что можно улучшить и как сделать следующий спринт ещё эффективнее.

⚙️ И так повторяется снова и снова, пока продукт не будет готов.

Делитесь в комментариях, что вы думаете о Scrum. Используете ли вы его в своей команде?

Всем продуктивного дня! 🔥
Для сотрудничества и предложений пишите на почту cooperation@martinscode.tech или в Telegram: @geggggr.

#MartinsCode #GameDev #TeamLeadСоветы #ПолезноЗнать #РазработкаПросто #interest

💬 Недельная сводка от Martin.s Code

Друзья, эта неделя выдалась по-настоящему насыщенной:

Работа кипит над ключевым проектом, который уже приближается к финальной стадии, задачи плавно передвигаются к последнему столбцу доски. Совсем скоро покажем геймплей — он того стоит!

📌 В рамках нашей философии гибкой разработки Agile мы продолжаем делиться опытом: на этой неделе рассказали о самом сердце Agile — Scrum, его ролях, процессах и пользе для любой команды. Если пропустили — загляните в предыдущий пост!

🎮 XENO JAM завершён!
72 часа, десятки участников и бесконечное воображение. Мы подвели итоги и поздравили победителей.

Параллельно идет разработка визуальной новеллы и ещё несколько проектов на согласовании — вскоре появятся новые анонсы.

Мы не просто разрабатываем — мы строим экосистему, где ценится качество, креатив и командная работа.

Всем хороших выходных 🔥
Для сотрудничества и предложений пишите на почту cooperation@martinscode.tech или в Telegram: @geggggr.

#MartinsCode #GameDev #Agile #Scrum #WeeklyRecap #Разработка #НовостиПроектов #VisualNovel #AndroidGame #ГеймдевВнутри

⬆️ Пред-финальный спринт

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

Даже мелочи вроде системы установки аватарки теперь работают безупречно.

⚙️ Впереди:
— Реализация ключевых социальных механик
— Авторизация через внешние сервисы
— Монетизация и внутриигровой прогресс
— Добавление звукового сопровождения
— Финальная балансировка игровых значений

Работа кипит — и мы уже готовим вам крупный апдейт.
Скоро покажем больше.

Всем продуктивного дня! 🔥
Для сотрудничества и предложений пишите на почту cooperation@martinscode.tech или в Telegram: @geggggr.

#gamedev #devlog #multiplayer #indiegame #MartinsCode #игры #unitydev #portfolio

⌛️ Story points VS Часы

Story Point — это относительная оценка задачи, которая учитывает сложность реализации, объём работы, риски и уровень неопределённости.

В Scrum мы оцениваем задачи именно в Story Points, а не в часах.
Для этого используется шкала Фибоначчи: 1, 2, 3, 5, 8, 13, 21 — это помогает избегать ложной точности и быстрее принимать решения.

После завершения спринта суммируются все Story Points задач — так мы получаем Velocity команды (скорость).

🃏 Как это происходит?
На сессии Planning Poker команда обсуждает задачу и одновременно показывает карточки с выбранной оценкой. Если оценки не совпадают — обсуждаем, пока не придём к общему решению.

💡 Почему это лучше, чем часы?
— Оценка опирается на сложность и неопределённость, а не субъективное время.

— Устраняется иллюзия точности (часы часто вводят в заблуждение).

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

— Учитывает опыт всей команды, а не отдельного разработчика. (Опытный разработчик может решить задачу за 1 час, при этом новичок будет решать её 8 часов, но сложность задачи остается одинаковой)

📊 Часы всё же нужны?
Да — они используются на уровне трекинга, но не на уровне оценки. Время — это результат, а не основа планирования.

#agile #scrum #planning #storypoints #productivity #teamvelocity #agilemetrics #MartinsCode #devlog #interest

📉Sprint Burndown Chart — График сгорания задач

Sprint Burndown Chart — это визуальный инструмент в Agile/Scrum, который отображает объём оставшейся работы в течение спринта. Он помогает отслеживать прогресс команды, выявлять отклонения от плана и своевременно реагировать на риски.

❓ Зачем он нужен?

— Позволяет быстро понять, укладывается ли команда в сроки
— Делает прозрачным объём выполненной и оставшейся работы
— Помогает ретроспективно анализировать скорость и эффективность команды

✏️ Как устроен график?

Ось Y — объём работ (в Story Points, часах и т.д.)
Ось X — временной отрезок спринта (обычно дни)

1) В начале спринта мы определяем суммарный объём задач — это верхняя точка графика.
2) На конец спринта (например, через 2 недели) мы ставим точку «0».
3) Между ними проводится идеальная линия — как работа должна «сгорать» каждый день, если всё идёт по плану.
4) Далее, ежедневно фиксируется фактический объём оставшейся работы — и строится реальная линия.

⚙️ Как интерпретировать?

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

На практике линия прогресса на Burndown Chart обычно идёт ступеньками, так как задачи закрываются неравномерно и чаще всего блоками.


#Agile #Scrum #Burndown #ProjectManagement #SprintChart #TeamVelocity #MartinsCode #interest

🎯Методика SMART: как ставить задачи правильно

Если вы хотите, чтобы задачи действительно выполнялись, а не оставались в списке "когда-нибудь", используйте методику SMART. Это простой и мощный инструмент для четкой постановки целей — как в работе, так и в жизни.

Методика расшифровывается так:

S — Specific (Конкретная)
Цель должна быть понятной и четкой. Не «улучшить работу отдела», а «сократить время ответа клиенту до 10 минут».

M — Measurable (Измеримая)
Вы должны понимать, как оценить прогресс. Например, «увеличить количество подписчиков на 1000» — это измеримо.

A — Achievable (Достижимая)
Цель должна быть реалистичной, с учётом ресурсов, времени и возможностей команды. Амбиции — это хорошо, но переоценка сил может демотивировать.

R — Relevant (Актуальная/Значимая)
Цель должна соответствовать текущим задачам команды или бизнеса. Если задача не приближает к ключевым результатам — от неё лучше отказаться.

T — Time-bound (Ограниченная по времени)
Любая задача должна иметь дедлайн. Без срока выполнения даже самая ясная цель теряет смысл. «До конца квартала», «в течение недели» — важно чётко определить срок.

#продуктивность #планирование #SMART #таймменеджмент #цели #эффективность #работа #развитие #interest

⚔️ Скоро в бой: начинаем разработку K/W

Совсем скоро приступаем к разработке игры K/W — для Samurai Studio.

Вы в роли рыцаря отбиваетесь от волн врагов — всё это от третьего лица с динамичным геймплеем. ⚔️

Уже совсем скоро начнётся 10-дневный спринт, где разработчики будут выкладываться на максимум.
Ожидайте первые кадры и новости — будет жарко!

Всем продуктивного дня! 🔥
Для сотрудничества и предложений пишите на почту cooperation@martinscode.tech или в Telegram: @geggggr.

#GameDev #IndieGame #ThirdPersonAction #RPGaction #KnightGame #DevSprint #MartinsCode #portfolio

📈 User Story и Use Case — в чём разница?

Когда ты проектируешь фичи или пишешь ТЗ, важно понимать не только что делать, но и зачем.

#️⃣ User Story — описание задачи от лица пользователя.

Формат:
Как [роль], я хочу [действие], чтобы [результат].

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

Важно четко и лаконично сформировать задачу, по которой дальше пойдут уточнения.

#️⃣ Use case - это пользовательский сценарий взаимодействия с системой.

Определяет:
— Кто пользователь
— Какие шаги он делает
— Как реагирует система

Часто оформляется в виде UML-диаграмм.

✏️ Таким образом:
User Story = цель. Use Case = путь.

Они отлично дополняют друг друга: сначала понимание что важно, затем — как это реализовать.

#Agile #Scrum #Burndown #ProjectManagement #UserStory #UseCase #MartinsCode #interest

🤝 Доверие в словах

Друзья, мы собрали большинство отзывов о нашей работе за весь период — с разных площадок, клиентов и проектов.

Теперь вы можете быстро оценить, как мы работаем и что о нас говорят реальные заказчики.

🔗 Переходите, читайте, делайте выводы — мы открыты и честны в своём подходе.

📊UML Use-case диаграмма: простой язык, мощный инструмент

В одном из постов наш подписчик попросил рассказать про UML-диаграммы.

Давайте разберем один из самых полезных типов — use-case диаграмму, и сделаем это простым и понятным языком.

🔍 Что такое use-case диаграмма?

Use-case диаграмма (диаграмма прецедентов) показывает, как пользователи взаимодействуют с системой:
— Кто с ней работает (акторы)
— Что они делают (use‑cases)
— Как связаны сценарии между собой

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

⚙️ Основные элементы диаграммы

Акторы — «человечки» на схеме: пользователи, админы, другие системы

Use‑cases — овалы, представляющие функции (например: Оформить заказ, Оплатить)

Связи (associations) — линии, связывающие акторов и сценарии использования

🔗 Виды отношений между use‑cases

<<include>> — включает: основной сценарий обязательно вызывает другой
Пример: Редактировать заказ включает Изменить и Отменить заказ

<<extend>> — расширяет: дополнительный функционал при определенных условиях
Пример: Авторизоваться может расширяться Редактированием профиля

Generalization – наследование: один актор или сценарий наследует поведение другого
Пример: Авторизованный пользователь наследует действия Неавторизованного + получает больше прав

✏️ Методика построения (с подхода Agile Modeling)

1) Определите всех акторов (пользователи, системы)

2) Свяжите их с соответствующими use-cases

3) Добавьте связи include, extend, generalization, чтобы убрать дублирование и лучше показать структуру

💡 Полезные советы

— Не перегружайте схему — до 10 use‑cases максимум
— Начинайте с акторов — так проще понять потребности
— Помните: use-case диаграмма показывает что делает система, а не как она это делает

Если материал был полезен — дайте знать в комментариях.
Можете задать вопросы в комментарии и написать, какую тему разобрать в следующем посте! 💎

Martin.s Code — студия, где идеи обретают форму

#interest

🌎 Пока Илон Маск берет паузу — мы берёмся за дело.

В ближайшее время мы стартуем работу над новым VR-проектом — и это именно та территория, где мы чувствуем себя как дома. 🏆

Meta Quest 3, качественный визуал, проработка каждой детали — всё как мы любим.

Пока идёт активная подготовка и согласование, делимся первым визуальным фрагментом — аккуратным тизером будущего большого мира.

Всем продуктивного дня! 🔥
Для сотрудничества и предложений пишите на почту cooperation@martinscode.tech или в Telegram: @geggggr.

Martin.s Code — студия, где идеи обретают форму

#portfolio