1. Инженерная разработка это цифры. Анализ без цифр это просто мнение.
2. Создание правильной ракеты занимает бесконечное количество времени. Поэтому следует создавать ракеты в которых что-то не правильно.
Читать полностью »
1. Инженерная разработка это цифры. Анализ без цифр это просто мнение.
2. Создание правильной ракеты занимает бесконечное количество времени. Поэтому следует создавать ракеты в которых что-то не правильно.
Читать полностью »
Если все фичи в процессе разработки продукта кажутся одинаково важными, то выбрать самую приоритетную из них порою очень сложно. Тогда на помощь менеджеру продукта могут прийти полезные фильтры для определения приоритетов.
Когда люди работают в офисе, контролировать их деятельность сравнительно просто. Вокруг работника масса глаз: мимо проходящее начальство, коллеги, да хоть вездесущие уборщицы, которые просят поднять ноги. Но все становится намного сложнее, если человек работает удаленно. При использовании формата сдельной оплаты «результат-деньги» контролировать нужно лишь сроки. Он отлично подходит для небольших команд до 5-10 человек, но задача экспоненциально усложняется, когда число исполнителей растет и заказчик покупает человекочасы, а не какой-то определенный объем работ. В последнем случае, чаще всего, для контроля используется трекер рабочей активности, в нашем случае — WorkSmart.
Трекеры бывают разными. Некоторые представляют собой одну лишь кнопку «вкл/выкл», которая запускает таймер. Другие — неотрывно следят за каждым шагом и движением, вызывая чувство дискомфорта:
Это самое чувство дискомфорта усугубляется, если человек конкретно не понимает и не видит, что именно, когда и как фиксирует трекер, но не в случае WorkSmart, о чем мы расскажем далее.
Читать полностью »
Когда на предприятии затевается внедрение информационной системы, особенно силами внешнего подрядчика, то почти всегда говорится: самое большое препятствие – это люди. Сама система, кодирование нового функционала, обучение – это просто трудозатраты. А вот преодолеть саботаж внедрения, переломить мышление, особенно руководителей, заставить выйти из зоны комфорта старой системы (даже если она ужасна) – это действительно трудно. Причем, внедренцы обычно говорят: основная работа по «изменению людей» должна лежать и лежит на заказчике.
Реальную необходимость во внедрении системы оставим в стороне, она не является предметом обсуждения данного материала – считаем, что система действительно нужна. Внедрение идет по всем канонам, с техническим заданием, функциональными требованиями, планом-графиком и т.д. Ключевой критерий успешности проекта – реализация всех требований заказчика. Такой критерий вполне вписывается в методику оценки качества, которое есть степень соответствия требованиям потребителя. И вот система внедрена.Читать полностью »
Ввиду блокировок телеграма, актуально было бы написать про Atlassian Stride, как мы на него перешли, и с какими прелестями решения от любимого Atlassian столкнулись.
Atlassian Stride был запущен в ноябре 2017, как замена облачному HipChat. Де-факто, основной конкурент, это, конечно же, Slack. Я постараюсь сравнивать Stride со Slack, и Telegram со стороны текстовой переписки.
Самый большой плюс, это, безусловно, бесшовная интеграция в экосистему Atlassian. Есть у вас jira, confluence — и единый аккаунт у пользователя, где вы можете управлять доступом к разным кускам и возможностям этих двух приложений. А теперь у вас есть третье приложение — Stride, и управление пользователями чатика доступно из той же админки.
Я лид команды в Pixonic, где работаю уже год. О старте и развитии одного из наших новых проектов я ранее написал статью на Хабре. По ходу дальнейшего производства, спустя еще полгода, у меня накопилось большое количество интересного опыта, которым хотел опять поделиться. На этот раз речь пойдет о процессе наращивания функционала в мобильном клиенте и поддержании кода в гибком состоянии.
Уверен, подавляющее большинство хотя бы раз запускали какую-нибудь многопользовательскую игру. На старте клиент, как правило, пишет несколько магических сообщений и через несколько секунд (хотя в случае с одним известным десктопным шутером — несколько минут) игрок попадает в главное меню, где есть заветная кнопка «В бой» или типа того. Но процесс запуска состоит из огромного количества этапов, которые происходят очень быстро и без вмешательства игрока:Читать полностью »
Привет. Я Катя. Я пишу фронтенд в Яндекс.Деньгах.
Я расскажу, как работа в большой компании помогла мне вырасти из верстальщика в программиста. О том, как я перестала бороться с особенностями браузеров, и начала — с плохой архитектурой и низким rps. Пусть эта история сэкономит время талантливым разработчикам, которые штампуют лендинги вместо того, чтобы биться за настоящий фронтенд.
В этой статье я расскажу, что мы разрабатываем, как оптимизируем рабочие процессы и зачем развивать свои soft skills. На подходе вторая часть — она будет технической. В ней подробно расскажу про стек, почему их два и как мы дружили БЭМ с React (спойлер: будет много кода). Поехали!
Бэклог продуктовых задач является одним из основных и обязательных артефактов Agile. Фактически, это набор требований, полученных от бизнеса и сформулированных в виде задач для разработки. Что нужно делать для того, чтобы эти задачи всегда были в порядке? И как это связано с концепцией backlog grooming?
Каждому разработчику знакома ситуация, когда реализация новой возможности в системе занимает большое количество времени, но релиз уже близко, а тимлид или менеджер проекта пятый раз за день задают уже надоевший вопрос: “Ну когда будет готово?”. И тогда встает непростой выбор — сделать все правильно и не уложиться в сроки релиза или реализовать минимально работающий, но не идеальный с точки зрения технического решения, функционал. Очевидно, что в большинстве случаев будет выбран второй вариант, так как релиз и предоставление результата клиентам здесь и сейчас важнее чистоты кода и архитектуры системы. Но проходит несколько месяцев, и вот уже старое не идеальное техническое решение мешает реализации другого функционала. И дальше такие решения будут накапливаться в огромный ком. Разбираясь с этой проблемой, очень важно сделать правильные выводы и выбрать нужное решение. От этого решения будет зависеть дальнейшая судьба всего проекта. В данной статье мы постараемся разобраться с природой технического долга и посоветовать пути его устранения.
Читать полностью »
В данной статье хотелось бы рассказать про организацию процессов Continuous Integration / Continuous Delivery, автоматизирующих сборку, тестирование и доставку приложений применимо к решениям на платформе InterSystems.
Рассмотрим такие темы как: