Рубрика «управление разработкой» - 119

Когда у нас надёжно заработала непрерывная интеграция на Jenkins и устоялись процессы выпуска релизов продукта, возникла мысль: а почему бы не перенять передовой опыт и не поставить в офисе свой электронный излучатель информации (information radiator): большой красивый экран, на котором автоматически отображаются происходящие с проектом процессы?

Электронный «излучатель информации» при минимуме затрат - 1

Мысль хорошая, но ведь это стоит денег и времени, т. е. того, чего никогда нет. Особенно сейчас. Особенно у маленьких компаний без бюджетов на всевозможные вспомогательные цели. Сделать всё предстояло за «пять копеек» и за «пять минут» — и вот как я с этим [частично] справился.

Читать полностью »

image

Марк Бениофф — знаменитый калифорнийский предприниматель, успешный бизнесмен, миллиардер, основатель одного из крупнейших облачных провайдеров и разработчиков CRM-систем Salesforce.com. С августа 2012 года — член совета директоров Cisco.

Как выяснилось, создание специальных систем по управлению взаимоотношениями с клиентами (CRM) — дело прибыльное. Себе господин Бениофф «назначил» $31,3 миллиона, его подчиненные в среднем получают $151 512. Иными словами, на $1 зарплаты программиста приходятся $207 вознаграждения генеральному директору.

Бениофф владеет 5% акций Salesforce при оценке компании в $56,06 миллиарда. Его состояние оценивается в $4,2 миллиарда.

22 мая 2015 года стало известно о переговорах Microsoft и Salesforce о ее покупке, но стороны не договорились о цене. Microsoft предлагала за крупнейшего после Oracle производителя облачного софта порядка $55 миллиардов. Марк Бениофф поднял цену до $70 миллиардов.

Интерес к Salesforce также проявляют Oracle, IBM и SAP.

Однако, по всей видимости, он рассчитывает на то, что покупатели не предложат больше. Бениофф все-таки не намерен продавать компанию: позже он заявил, что хочет сам принимать судьбоносные решения в компании, а именно сейчас Salesforce переживает самый интересный период за всю историю своего существования. Читать полностью »

image

В мире криптовалют все говорят о «Гражданской войне», и не о той, что развязалась между Капитаном Америкой и Железным человеком. Они говорят о гражданской войне в проекте Bitcoin, которая длится уже год. Это ожесточенное сражение за контроль над масштабируемостью.

С одной стороны, есть разработчики Core, которые хотят сохранить ограничение размера блока в 1 Мбайт. Они рассчитывают, что подающая надежды сеть Lightning Network решит любые проблемы с перегрузками.

С другой стороны, есть сторонники из лагеря Bitcoin Classic, которые хотят увеличить ограничение размера блока как минимум до 2 Мбайт. Пока побеждают Core, так как большая часть майнеров Bitcoin придерживается их варианта реализации проекта.

Эти разногласия подняли некоторые фундаментальные вопросы о природе децентрализованного проекта вроде Bitcoin. Кто же в итоге задает направление развития децентрализованного проекта? Кто принимает окончательные решения по разработке? Другими словами, как следует управлять подобным проектом?
Читать полностью »

Зачем, кому это нужно, чем это сделать

Не раз задавалась вопросом: как бы так комфортно организовать входящие требования к системе — на этапе, когда требования только собираются, когда формируются вопросы и озвучиваются ответы, а ещё всё постоянно меняется и пересматривается, а ещё когда в реализации задействовано несколько систем, а ещё, а ещё…
При этом очень бы хотелось:

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

Да и вообще.
Читать полностью »

image

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

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

И хотя такой прогресс очень вдохновляет, инструменты,- неважно, насколько они будут крутыми,- автоматически не приносят организации преимуществ. Их надо интегрировать в существующие процессы и процедуры. Они встраиваются как в организации, так и в работу людей, которые ими управляют. Будучи неверно интегрированными, они могут даже замедлять процесс работы.

В своём исследовании я обнаружил несколько ловушек, в которые могут попасться организации, внедряющие у себя подобные инструменты.
Читать полностью »

image

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

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

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

image

Когда я начинал как разработчик на Rails, я постоянно ковырялся с фреймворками все свое свободное время, которого, однако, у меня было достаточно. Я не был женат, работал в Coles и подрабатывал на фрилансе, выполняя заказы на PHP и Rails.

Как-то я услышал о проводимом в городе Аделаида Ruby Meetup. Сразу после работы я рванул на поезд и отправился на это мероприятие. Когда я туда попал, несколько человек спросили меня, чем я занимаюсь. Я рассказал о работе в Coles, о PHP и Rails, на что мне ответили «ты не должен больше работать в Coles» и трое из них протянули мне свои визитные карточки, сказав, чтобы я подал им резюме. Я отправил заявку в Sealink и меня взяли.

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

В Мельбурне есть много джуниоров, посещающих Ruby Meetup'ы. Я знаю это наверняка, так как помогал организовывать ночные хакатоны, на которые они тоже ходят. И вот представьте, если бы какой-нибудь новичок на митапе сказал бы вам, что он активно ищет работу, вы бы его наняли? Возможно, нет. Создается впечатление, что на таких мероприятиях царит атмосфера отвращения к найму джуниоров, ведь потому, что они, джуниоры, отнимают столь драгоценное время команды, которое могло быть потрачено на разработку, на их обучение.
Читать полностью »

Когда бизнесу нужны «облака» и виртуализация - 1

В марте 2016 года журналисты «Первого блога о корпоративном IaaS» провели опрос среди представителей компаний. 54% опрошенных ответили, что в перспективе рассматривают возможность переноса части ИТ-инфраструктуры в публичное облако.

Виртуализация серверов и облачные технологии (это IaaS, SaaS и остальные XaaS-сервисы) с каждым годом все больше проникают во многие сферы деятельности. В 2016 году компании во всем мире потратят на публичные облачные услуги $204 млрд. Это на 16,5% больше, чем в 2015году. Компания «ИТ-ГРАД» провела исследование рынка облачных технологий в области электронной коммерции, опросив сто крупнейших ретейлеров, работающих в России.Читать полностью »

image

Мы продолжаем запускать в партнерстве со Stepic бесплатные онлайн-курсы по дисциплинам из Технопарка, Техносферы и Технотрека. Сегодня мы хотим представить наш новый курс: «Основы постановки задачи на разработку программ».

Кроме того, мы перезапускаем три курса: «Web-технологии», «Многопоточное программирование», «Hadoop» — и снова открываем на них запись.
Читать полностью »

Немного истории

В самом начале 2010 года Vincent Driessen пишет отличную статью A successful Git branching model. Для понимания того, о чем пойдет речь дальше, со статьей нужно, конечно же, познакомиться. А для тех, кому сложен язык оригинальной статьи, на хабре есть её отличный перевод.

С этого момента описанная модель ветвления GitFlow, начинает, что называется, расходиться по миру. Её берут на вооружение многие команды. Авторы пишут много статей об успешном её использовании. Она получает поддержку в большинстве инструментов, которые используют разработчики:

Git

Кажется, что модель идеальна. Быть может так оно и есть, если у вас небольшая команда, неизменяемый скоуп релизов, высокая культура работы с VCS. Тогда, действительно, GitFlow может и удовлетворит все ваши потребности. Но, к сожалению, описанные условия подходят не всем командам и не всем проектам. К слову, найти статьи, в которых бы авторы описывали проблемы этой модели не так уж и просто даже в 2016 году. Но как мы все знаем, серебряной пули нет, а, значит, и в этой модели всё хорошо далеко не для всех.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js