Вы когда нибудь задумывались о том, как в условиях мультикомандной разработки современного продукта избежать задержек из-за синхронизации команд? Далее я поделюсь опытом такой разработки на примере нашей команды Циан.Финансы. Деталями вертикального подхода к разработке и почему мы работаем именно так.
Зачем нам вулканец на борту: обзор Spock Framework
12 мин
Автоматизация тестирования помогает постоянно контролировать качество IT-продукта, а также снижать затраты в долгосрочной перспективе. В автоматизации существуют различные подходы, например, Behavior Driven Development (BDD), разработка через поведение.
С этим подходом связаны инструменты cucumber, robot framework, behave и другие, в которых разделены сценарии выполнения и реализация каждой конструкции. Такое разделение помогает составить удобочитаемые сценарии, но требует значительных затрат времени и поэтому может быть непрактичным при написании реализации.
Рассмотрим, как можно упростить работу с BDD, используя подходящие инструменты – например, фреймворк Spock, который сочетает в себе красоту, удобство принципов BDD и особенности jUnit.
С этим подходом связаны инструменты cucumber, robot framework, behave и другие, в которых разделены сценарии выполнения и реализация каждой конструкции. Такое разделение помогает составить удобочитаемые сценарии, но требует значительных затрат времени и поэтому может быть непрактичным при написании реализации.
Рассмотрим, как можно упростить работу с BDD, используя подходящие инструменты – например, фреймворк Spock, который сочетает в себе красоту, удобство принципов BDD и особенности jUnit.
Тимлидство — роль, которая может стать ловушкой для разработчика, а может дать огромные возможности для создания ПО
7 мин
Вернёмся года на два назад, когда я был разработчиком. Что я думал? «Хочу стать тимлидом. Это круто, он решает все вопросы, получает больше денег, им становятся после сеньора». Тогда не было никого, кто сказал бы мне: это вообще про другое. Пришлось учиться на своих ошибках.
У меня есть такая черта: стараться во всем наводить идеальный порядок, систематизировать, выстраивать процессы. Поэтому меня всегда тянуло брать на себя больше, чем просто написание кода. В моём первом стартапе, назовем его «T», был полный хаос в процессах разработки.
Я дважды становился тимлидом
У меня есть такая черта: стараться во всем наводить идеальный порядок, систематизировать, выстраивать процессы. Поэтому меня всегда тянуло брать на себя больше, чем просто написание кода. В моём первом стартапе, назовем его «T», был полный хаос в процессах разработки.
Книга «Мифический человеко-месяц, или Как создаются программные системы »
12 мин
Привет, Хаброжители! Немногие книги по управлению проектами можно назвать столь же значимыми как «Мифический человеко-месяц». Смешение примеров из реальной разработки ПО, мнений и размышлений создает яркую картину управления сложными проектами. Эти эссе основаны на пятидесятилетнем опыте работы Брукса менеджером проектов в IBM System/360, а затем в OS/360. Первое издание книги вышло 45 лет назад, второе 25 лет назад. Возникают новые методологии, появляются новые языки программирования, растет количество процессоров, но эта книга продолжает оставаться актуальной. Почему? Спустя полвека мы продолжаем повторять ошибки, которые описал Брукс. Некоторые темы, поднимаемые в книге, кажутся устаревшими, но это лишь видимость. Фундаментальные проблемы, стоящие за ними, все так же актуальны в наше время. Важно знать свое прошлое, чтобы понимать, куда развивается индустрия разработки программного обеспечения. Поэтому, спустя 45 лет мы и читаем Брукса Многое изменилось в мире, но девять женщин всё так же не могут выносить ребенка за один месяц.
Что делать, если никто не хочет документировать? Организация документирования микросервисов по минимуму
6 мин
Представьте что у вас команда специалистов, которая по принципу code-first делает систему с множеством бизнес-историй на базе микросервисов. Все люди опытные, всем есть что делать кроме того как писать документации или спецификации на разработанный API. И все изначально знают, что если захотел использовать какой сервис, то надо заглянуть в код и потом спросить в общем чате если что непонятно. Знакомая ситуация не так ли? -))) И в целом все нормально, если бы со временем не росла команда, не росло количество сервисов и функций, не появлялись баги от бизнеса и тестеров, не требовалось предоставлять API для интеграции смежным командам...
Эта статья, на момент написания, является моим личным мнением о минимальной структуре документирования микросервисов в условиях его отсутствия. Личное мнение родилось в ходе мозгового штурма реальной ситуации и поисков повышения качества в разработке среднего по масштабу бизнес приложения.
Кто там выше тимлида?
8 мин
Не так давно я прочитал интересную статью о том, как стать тимлидом и что нужно делать в этой роли. И мне захотелось рассказать про следующую ступень развития — в качестве менеджера и руководителя IT-отдела или IT-директора в небольшой компании.
Стоит отметить, что для разработчика существует несколько векторов развития, которые хорошо описаны в статье Три дороги для программиста: эксперт, руководитель, основатель. Я же сосредоточусь на втором направлении — руководителе.
Позиционирование продукта: Курс «Создание программного продукта и управление его развитием»
6 мин
Привет Хабр! Сегодня в рамках курса продакт-менеджмента от Acronis мы поговорим о том, как нужно позиционировать продукт, и чем это отличается от позиционирования бренда. Кроме этого, речь пойдет об уникальных компетенциях, конкурентных преимуществах и о том, что является самой большой ценностью для бизнеса на высококонкурентных рынках. Всех заинтересованных приглашаю под кат!
Проверка гипотез: Курс «Создание программного продукта и управление его развитием»
5 мин
Привет, Хабр! Мы продолжаем говорить о продакт-менеджменте из прошедшего курса и этот пост посвящен работе с гипотезами, которые вы хотите реализовать при разработке программного продукта. Многие хорошие идеи “не взлетают”, потому что не соответствуют потребностям рынка, и сегодня мы рассмотрим способы поиска того, что нужно делать. В этом посте вы найдете способы анализа рынка, правила выбора источников информации о требованиях к продукту, методы проверки гипотез, а также полезный опыт одного бренда с мировым именем.
Как создать KPI по стрессу — и превратить его из врага в помощника
8 мин
Привет, Habr! Меня зовут Илья Калугин, я работаю проджект-менеджером в FINCH. Мы создаем высоконагруженные проекты для крупных брендов вроде «Газпром-медиа», «Спартака» и «Столото».
Создание проектов — это всегда про стресс, с которым нужно как-то уживаться. Странные правки заказчика, непонимание внутри команды, дедлайны — достаточно привычные вещи, от которых в IT не убежишь. Значит, со стрессом надо как-то подружиться — и попробовать сделать так, чтобы он работал на пользу.
В этой статье я расскажу о том, почему стресс — ключевая метрика при измерении возможности команды, как выполнить KPI по стрессу и причем тут велоспорт?
Создание проектов — это всегда про стресс, с которым нужно как-то уживаться. Странные правки заказчика, непонимание внутри команды, дедлайны — достаточно привычные вещи, от которых в IT не убежишь. Значит, со стрессом надо как-то подружиться — и попробовать сделать так, чтобы он работал на пользу.
В этой статье я расскажу о том, почему стресс — ключевая метрика при измерении возможности команды, как выполнить KPI по стрессу и причем тут велоспорт?
Исправь код, продай техническую фигню, покрути рулетку на Russian Python Week 2020
2 мин
Рефакторинг — сложная вещь. У каждого разработчика свои критерии хорошего, плохого и красивого кода. Из-за двух строк можно развернуть холивар на две страницы комментариев на Хабре. Почему бы тогда не сделать «Битву рефакторинга»? Мы и сделаем — с 14 по 18 сентября на Russian Python Week 2020 запускаем такую битву. На битве каждый может улучшить или «разбомбить» код своего коллеги в прямом эфире. Что это за формат и как пройдет, расскажем дальше.
Как справиться с декомпозицией задач и не перестараться
10 мин
Всем привет!
Меня зовут Виктор, я системный аналитик в компании «Спортмастер». И сегодня я хотел бы поговорить о декомпозиции задач и передачи их в разработку. Любой объект состоит из частей, будь это автомобиль или программный продукт. И чтобы собрать любой из этих объектов в единое целое из составных частей, потребуется время. Иногда — даже очень много времени. Особенно, если перед этим вы не просто разобрали основную часть, а решили докопаться до сути на атомарном уровне.
Где же та грань между адекватной постановкой задач и тотального хаоса? Поделюсь примером того, как к нам в «Спортмастере» периодически поступают задачи в разработку от бизнеса.
Меня зовут Виктор, я системный аналитик в компании «Спортмастер». И сегодня я хотел бы поговорить о декомпозиции задач и передачи их в разработку. Любой объект состоит из частей, будь это автомобиль или программный продукт. И чтобы собрать любой из этих объектов в единое целое из составных частей, потребуется время. Иногда — даже очень много времени. Особенно, если перед этим вы не просто разобрали основную часть, а решили докопаться до сути на атомарном уровне.
Где же та грань между адекватной постановкой задач и тотального хаоса? Поделюсь примером того, как к нам в «Спортмастере» периодически поступают задачи в разработку от бизнеса.
Справочный центр Selectel: интерфейс, техническая реализация и возможности
8 мин
Каждой предоставляемой услугой Selectel можно управлять в личном кабинете — панели управления. Многими нашими продуктами также возможно управлять через запросы к API. Инструкции по работе с продуктами и документация API доступны в едином справочном центре.
Основная идея справочного центра — предоставить нашим клиентам возможность в любое удобное для них время самостоятельно найти ответы на большинство интересующих их вопросов об услугах Selectel.
Далее расскажем о том, как мы изменили подход к подготовке документации и обновили внешний вид базы знаний.
Ближайшие события
Firebird Conf: конференция для разработчиков и администраторов СУБД Firebird
6 июня
09:00 – 20:00
Москва
«Другой» менеджмент или почему бывает сложно общаться с людьми на работе
9 мин
Недавно сменил очередное место работы, я программист, Team Lead, PM, BA, Data Analytic, HR, QA, CTO, продюсер и психолог (последнее и по образованию, и по факту).
Не так давно я очень заинтересовался конфликтами в рабочем коллективе, а точнее – от куда они берутся и что с ними можно делать, чтобы они не мешали работе, а или даже наоборот – помогали. Больше всего бросилось в глаза то, что люди никогда не говорят о том, что они действительно хотят сказать, даже когда переходят на повышенные тона.
Приведу пример. Если вы как-то связаны с it, то, наверное, вам удавалось слышать такие фразы как:
- Я уже 3 года, тут работаю, а он только пришёл
- Front End ничего не смыслит в Back End
- Менеджеры надоели со своими бесполезными митингами
- Дизайнеру это просто вправо подвинуть, а нам переделывать неделю
И вроде бы эти фразы производит впечатление лаконично и логично аргументированной позиции. Но мне кажется люди совсем не то хотят сказать на самом деле. По моему, сугубо личному, опыту все эти фразы можно заменить на «заметьте меня, я тоже важен», а иногда и «я важнее других».
Пользовательские персоны: Курс «Создание программного продукта и управление его развитием»
6 мин
Привет, Хабр! Мы продолжаем публикацию серии материалов, посвященных продуктовому менеджменту, и сегодня речь пойдет про пользователей продукта. Вопреки расхожему мнению, при разработке продукта недостаточно просто «прикинуть», кому нужен ваш продукт. А для тех, кто хочет знать, как это делается согласно проверенными временем практикам, подробные инструкции поиска своей целевой аудитории — под катом.
Проектные решения: игра по твоим правилам
27 мин
Не секрет, что чем крупнее программный проект, тем больше его успех зависит от результатов работы аналитиков, в частности, от выбора правильной стратегии составления и согласования проектных решений. Однако как организовать работу этих творческих сотрудников? И как сделать так, чтобы результаты их деятельности были одинаково понятны как представителям заказчика, так и программистам? Как оценить возможные сроки выполнения и значимость этой работы для проекта? В этой статье я попытался сформулировать свои рецепты оптимизации управления аналитической работой на проектах по созданию программного обеспечения для государственных заказчиков. Приветствуется любая критика.
Источник
Источник
Алгоритм планирования задач на TypeScript. Теория графов наконец-то пригодилась
8 мин
В этой статье я хочу рассказать об алгоритме, который помогает ответить на извечный вопрос всех проектов:
Когда проект будет закончен?
Более формально проблема звучит так: "Проект состоит из задач, которые могут зависеть друг друга, а также могут иметь один и тех же исполнителей. Когда проект может быть закончен?"
Прикладное целеводство. Доклад Яндекса
12 мин
Зачем нужны цели? Как их формулировать? Какие проблемы могут возникнуть? По случаю Я.Субботника Pro я подготовил доклад, основанный на нескольких годах опыта ведения целей для команд в Яндексе.
«Я что-то накодил и все упало»: провалы в Python-разработке на Russian Python Week 2020
3 мин
На конференциях обычно принято рассказывать об успехах: «Мы обучили нейросеть на пяти миллионах Террабайт данных, чтобы отличать красную машину от белой и продали проект Amazon за 5 млрд долларов» Об ошибках при этом не принято рассказывать. Максимум, что встречается: «Мы немного напортачили, но за полчаса разобрались, ничего особенного».
Когда вокруг только истории «успешного успеха» даже сеньоры и техлиды чувствуют себя неуверенно — ведь они сравнивают успех спикера со своими ошибками. И сравнение не в пользу участников. Мы решили сломать эту тенденцию и на Russian Python Week запускаем целую секцию под кодовым названием «FailPy». Она будет посвящена провалам Python-разработчиков. Расскажем зачем и для кого это нужно.
Когда вокруг только истории «успешного успеха» даже сеньоры и техлиды чувствуют себя неуверенно — ведь они сравнивают успех спикера со своими ошибками. И сравнение не в пользу участников. Мы решили сломать эту тенденцию и на Russian Python Week запускаем целую секцию под кодовым названием «FailPy». Она будет посвящена провалам Python-разработчиков. Расскажем зачем и для кого это нужно.
Нам нужно поговорить…
11 мин
Иногда инженеры теряют интерес к проектам, задачам и к компании — мотивация падает, а с ней и производительность. В итоге сотрудники выгорают и/или увольняются. Для этого много причин, но самая распространенная — отсутствие внимания к успехам и проблемам инженеров.
В ЦФТ эту проблему решили регулярные встречи с инженерами один на один. Встречи помогают: вовремя выявить проблемы в работе, профессионально развиваться, повышать мотивацию и находить новые смыслы. О том, как готовиться ко встречам, какие вопросы задавать и как регулярно их проводить, расскажет Михаил Емельянов. Теперь вы будете знать, что делать, если инженер сказал: «Нам нужно поговорить...»
Михаил Емельянов — Head of Android Department в ЦФТ. В IT-разработке 12 лет, с Android — 10, из которых 2 года руководит командой Android-разработки в ЦФТ. Разрабатывал проект мультимедиа, различные проекты в финтехе и запускал стартапы.
В ЦФТ эту проблему решили регулярные встречи с инженерами один на один. Встречи помогают: вовремя выявить проблемы в работе, профессионально развиваться, повышать мотивацию и находить новые смыслы. О том, как готовиться ко встречам, какие вопросы задавать и как регулярно их проводить, расскажет Михаил Емельянов. Теперь вы будете знать, что делать, если инженер сказал: «Нам нужно поговорить...»
Михаил Емельянов — Head of Android Department в ЦФТ. В IT-разработке 12 лет, с Android — 10, из которых 2 года руководит командой Android-разработки в ЦФТ. Разрабатывал проект мультимедиа, различные проекты в финтехе и запускал стартапы.