Что значит правильнее — стабильнее, отказоустойчивее, более легко понятнее — быстрый вход, быстровостанавливаемый в случае ошибки или краха, с правильными метриками и алертами на все.
Почему не нанять сразу крутых разработчиков:
Agile подходы набирают популярность из-за хорошей реализации работы с неопределенностью за счет постоянной поставки результата. Однако, почти любой Agile-процесс требует выделенной команды на проект и почти ничего не предоставляет для стратегического планирования. Реальность организацией такова, что им нужно выполнять все свои обязательства вовремя и в полном объеме имеющимися ресурсами. А с другой стороны, программно-портфельное управление — это отдельные книжки-приложения к PMBoK и до них мало кто добирается, хотя почти в любой организации есть «направления» и ограниченные ресурсы.
Поэтому, я создал Метод управления проектной организацией «Pulse management» — Метод Пульса (далее Метод). Это набор рекомендаций и Правил на основе Теории Ограничений, Agile-подходов и проектного управления обеспечивающий выполнение обязательств Организацией вовремя и в полном объеме в условиях ограниченных ресурсов и высокой неопределенности содержания проектов.
Казалось бы, в небольших командах разработки (20+ человек) не должны возникать проблемы с разобщённостью, работой над общим кодом и принятием технических решений. Но все мы знаем, что это не так (не говоря уже о командах вроде нашей, где 80+ человек). Три года назад для их решения мы начали проводить еженедельную внутреннюю конференцию разработчиков DevForum. Под катом вы узнаете про то, как он помогает нам, почему не всегда подходят другие форматы (вроде еженедельных встреч или Sprint Review) и инструкцию по его созданию.
На РИТ++ Никита Соболев (sobolevn) выступил, как он сам назвал это, с проповедью на тему качества кода и процессов в компании. Особо впечатлительных просим налить себе ромашкового чаю, но отойти от экранов не предлагаем. Вы можете не соглашаться ни с одним из тезисов, настаивать, что трёп о сериалах — залог здоровой атмосферы в коллективе, и утверждать, что вам не нужны строгие рамки линтера и CI, чтобы писать хороший код. Но если вы хоть раз винили окружающих в неудачах на работе, вам стоит прочитать или посмотреть рассказ Никиты.
Работали ли вы когда-нибудь на плохой работе?
Я работал и долго. Моя компания была ужасна. Все было очень плохо, за что ни возьмись — все из рук вон. У нас были отвратительные процессы, ненавистные клиенты и неумелые разработчики. С этим ничего нельзя было поделать. Когда все так плохо, просто не знаешь, за что взяться, с чего начать. Чувствуешь себя жалким винтиком, который не может ни на что влиять.
Когда я говорю, все плохо, я имею в виду, что у нас был:
Да, это была аутсорс-разработка, но не это делало её плохой. Люди сделали ее такой.Читать полностью »
Есть среди разработчиков те, кому хочется не только писать красивый код, но и создавать эффективные практики, упрощающие командную работу. Получив заветные лавры тимлида, окунувшись в водоворот постоянных коммуникаций, решения бытовых вопросов и, о боже, лишившись возможности писать тот самый красивый код, некоторые впадают в депрессию. А наш гость AppsCast Сергей Боиштян пошел иным путем и, вкусив реалии жизни тимлида, вернулся в ряды инженеров. Почему тимлидство не для всех и почему рост — это не всегда новая «лычка» на рукаве, в диалоге с Сергеем.
Итак, мы продали клиенту программный B2B продукт.
На презентации ему все нравилось, но в ходе внедрения выяснилось, что кое-что все-таки не подходит. Можно конечно сказать что нужно следовать “best practice”, и изменить себя под продукт, а не наоборот. Это может сработать, если у вас есть сильный бренд (например, из трех больших букв, и вы можете послать всех на три маленькие буквы). В противном случае, вам быстро объяснят, что заказчик добился всего благодаря своим уникальным бизнес-процессам, и давайте-ка, лучше меняйте свой продукт, или ничего не получится. Есть вариант отказаться и сослаться на то, что лицензии уже куплены, и с подводной лодки деваться уже некуда. Но на относительно узких рынках такая стратегия долго работать не будет.
Приходится дорабатывать.
Читать полностью »
«Работа заполняет время, отпущенное на неё».
Закон Паркинсона
Если ты не британский чиновник образца 1958 года, не надо следовать этому закону. Никакая работа не обязана занимать всё отведённое на неё время.
Читать полностью »
Привет! Мы продолжаем серию митапов Backend United. Четвёртая встреча называется «Окрошка», и посвящена она будет инцидентам. Вместе с коллегами из Tutu.Ru, Ozon и Авито поговорим про работу с инцидентами, об инструментах для улучшения incident response и о ценности техдолга.
Встреча пройдёт 10 августа, начало в 12:00. Регистрируйтесь сами и приглашайте коллег. Под катом — тезисы выступлений, ссылки на регистрацию и видеотрансляцию митапа.
Модульность является одним из ключевых принципов разработки программного обеспечения с 1960-х годов. Применение этого принципа приносит в программирование много полезного. Модульность способствует эффективному использованию принципа разделения ответственностей, что ведёт к улучшению возможностей по созданию, многократному использованию, компоновке кода.
В наше время применение принципа модульности в проектировании ПО приняло новую форму, воплотившуюся в компонентах. Это — разработка, основанная на компонентах (Component Driven Development, CDD). Современные библиотеки и фреймворки для разработки пользовательских интерфейсов, такие как React, Vue и Angular, а также CDD-ориентированные инструменты наподобие Bit, позволяют создавать приложения, опираясь на модульные компоненты. В распоряжении программиста оказываются паттерны и инструменты, необходимые для разработки компонентов в изоляции и построения композиций компонентов.
Компонент — это чётко очерченный независимый фрагмент интерфейса приложения. В качестве примеров компонентов можно привести такие сущности, как кнопки, слайдеры, окна для вывода сообщений чатов. Понимая особенности CDD и умея применять этот подход к разработке, мы можем использовать компоненты в качестве основы приложений. Это, при создании программных проектов, даёт нам всё то полезное, что означает применение принципов модульного программирования.
Если присмотреться к тому, что происходит сейчас в сфере веб-компонентов, можно заметить, что CDD становится стандартизированным подходом к разработке фронтенда.
Материал, перевод которого мы сегодня публикуем, представляет собой руководство по разработке, основанной на компонентах.
Читать полностью »
В одной из компаний, где я работал, была очень строгая отчётность. Все рабочие часы должны были быть закрыты в отчётности какой-то задачей, а отчёты сдавались ежедневно. В общем, человек ко всему привыкает, и вполне можно было вспомнить, чем ты занимался сегодняшний день и всё расписать. Но однажды нас попросили дополнительно составить такую отчётность за предыдущие полтора месяца. Естественно, такое пожелание вызвало некоторые затруднения у сотрудников.
Для меня же это выполнить это требование было довольно легко. Просто у меня всё записано. Каждый рабочий день.
Читать полностью »
