Управление разработкой *

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



Но в 13 лет родители купили мне компьютер, и жизнь начала меняться: я быстро стал местным эникейщиком, у которого взрослые дяди и тети спрашивали, как установить “виндоус на процессор”. В 15 я задался вопросом, как написать свою игру. Спросил двоюродного брата, который уже стал “уважаемым человеком” и делал сайты в Москве. Брат привез учебник Лафоре по C++ и сказал: “Осваивай программирование”.

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

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

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

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

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

Привет, Хабр! Хочу сейчас затронуть тему коммуникации заказчиков с техническими специалистами Веб-студий и SEO компаний. Хотя, думаю, вопрос этот актуален для всех компаний, так или связанных с технологиями — ведь априори заказчик говорит на другом языке. Как показывает практика, клиент редко хочет тратить свое время на заполнение ТЗ и тем более не хочет вникать в разработку или суть предлагаемой услуги. Он хочет по взмаху волшебной пачки денег получить то, что рисовало его воображение. В результате любой рискнувший взяться за разработку исполнитель может сделать то, что клиенту не понравится. Сегодня этот подход к разработке наконец-то понемногу исчезает, клиент становится умнее и основой его желаний становится не просто сделать красиво и эффектно, но ещё и чтобы это работало, как часы и приносило доход. Но и тут нередко случаются крайности — клиент начинает считать себя супер профи. Как найти баланс и выжить в процессе общения с заказчиком, мы и попробуем разобраться.

Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?

Сегодня я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те метрики, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.

Если тема заинтересовала, добро пожаловать под кат.

Если взглянуть на эволюцию компьютерных интерфейсов, наблюдаются 3 конкретные вехи: командная строка, десктоп с мышкой и «трогательные» интерфейсы. С анонсом Siri и прочих голосовых ассистентвов породилось мнение, что появилась новая веха в этой истории. Я же убежден, что Siri и аналоги пока это только проба пера.

На сегодняшний день голосовой интерфейс сильно ограничен в возможностях. Новой же революцией в UX, как в свое время стали тач устройства, являются боты и conversation UX (о котором сейчас так много пишут на западе). Это не просто тренд или банальная альтернатива для решения существующих задач. Это новый способ взаимодействия с интерфейсом, расширяющий горизонты.

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

На Гайдаровском форуме Герман Греф заявил, что Сбербанк будет переходить на новые информационные технологии, выбрав в качестве основного партнёра российско-американскую компанию с численностью 60 чел. При этом Сбербанк потратил 65 млрд. руб. на амбициозный и сложный проект централизации ИТ- структуры и на сегодняшний день у него более 22 000 ИТ-сотрудников, включая 6 тыс. человек в Сбертехе. Основная причина перехода — скорость внесения изменений в ИТ, которая была низка и привела к отставанию ИТ Сбербанка от лидеров по развитию и гибкости ИТ-инфраструктуры. А насколько важна скорость внесения изменений в разработке? На что нужно обратить внимание в управлении процессом разработки? Стоит ли использовать модели и методологии? Попробуем разобраться.

В статье ответим только на один вопрос – как мы решаем, что и когда реализовывать в платформе «1С:Предприятие».

Именно в такой формулировке нам его задают редко, но часто и даже очень часто появляются конкретные вопросы – «почему вы сделали это?», «почему вы НЕ сделали это?», «почему бы вам не сделать это?», «когда вы сделаете это?», «когда же вы, наконец, сделаете это?!!!», …

Попробуем описать то, как мы решаем, что когда делать.

Когда я прочитал: «Agile is much more than just Scrum» — в описании сертификационного курса Certified Agile Professional компании ScrumTrek, то первое, о чем я подумал: почему ScrumTrek, тогда уж нужно было назваться AgileTrek? После прохождения этого обучения я вернулся к этому утверждению с более серьезным настроем. Так что же я вынес с тренинга? Записи, раздаточный материал и сертификат Certified ICAgile Professional? А как же понимание, что такое Agile? В чем заключается концепция Agile-подхода? Что такое Agile mindset?

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

Помните, как обозначается идея в презентациях, инфографике и даже клипартах офисного пакета? Верно, в виде горящей лампочки. Это неслучайно — когда долго работаешь над проблемой и внезапно возникает инсайт, в голове как будто что-то вспыхивает. С этих мгновенных озарений начинается любой процесс: научное исследование, разработка программы, старт бизнеса, творчество.

Разработчики создают разнообразное и полезное ПО, которое получает отклик пользователей: от корпоративного софта до мобильных игр. Откуда берутся идеи и как их можно стимулировать?
Мы пригласили в МЕГУ знакомого разработчика и, прогуливаясь по торговому центру, попросили его открыть тайну рождения идей, а заодно подсказать участниками проекта МЕГА ACCELERATOR, о котором вы можете прочитать на Мегамозге, что же с его точки зрения можно придумать для улучшения покупательского опыта. Он раскрыл для читателей Хабра несколько секретов и техник, которые можно эффективно применять, работая практически над любым проектом.

Дано: собственные и аутсорс-проекты, некоторые участники работают удаленно.

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

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

Изначально сервисов было более 100, но постепенно список сокращался, и мы остановили наш выбор на трех, удовлетворяющих вместе наши нужды лучше всего: Jira, Slack и GanttPro. Но, если вдруг эти сервисы не помогут вам в планировании задач и работы с командой, делюсь с вами полным списком:

Процесс поиска очень часто усложняется тем, что все сервисы, как один, пишут «Лучший сервис, помогающий превратить ваши идеи в реальность и реализовать ваши проекты. Сегодня.». Так, а что вы делаете-то? Поэтому в этом списке без лишних эпитетов, только что какой сервис умеет. :)

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

Иногда мы обращаем внимание на различные вопросы, связанные с управленческими решениями или общими подходами к менеджменту в сфере ИТ. Одна из наиболее острых проблем — эффективность работы сотрудников. Сегодня мы рассмотрим ее с необычной стороны.

Предлагаю перевод небольшой статьи Андерса Абеля на волнующую меня в данный момент тему — качественный и формализованный процесс подготовки задач к передаче в разработку при условии, что разработка ведется по скраму. Если у кого-то есть опыт использования описанного данным автором подхода, итересно было бы, если бы вы поделились нюансами. Оригинал статьи: «Using Kanban for Scrum Backlog Grooming».

картинка по запросу grooming:



***

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

Предлагаю вашему вниманию перевод небольшой статьи Гойко Аджича на тему разделения пользовательских историй от 2012 года, с иллюстрациями и примерами автора: "Splitting User Stories: The Hamburger Method" — сделал его, в первую очередь, для себя.

Проблематика: История слишком велика и процесс разбиения и оценки слишком сложен; бизнес-пользователей не устраивает ни один вариант разбивки, предложенный командой разработки; команда не имеет достаточного опыта и использует только техническое разделение историй; запущен новый проект и у команды не выходит сформулировать достаточно простые пользовательские истории.

Решение: Метод гамбургера

В нашем блоге на Хабре мы любим разбирать интересные кейсы, связанные с практической стороной использования виртуальной инфраструктуры стартапами. Помимо этого мы обращаем внимание и на зарубежный опыт — анализируем все, что связано с работой сложных ИТ-систем, инфраструктуры и железа.

Например, совсем недавно мы рассказывали:

• о том, как Spotify масштабирует Apache Storm,
• рассматривали аппаратное обеспечение для глубокого обучения
• и бегло поговорили о примере оптимизации полосу пропускания в сетях Ethernet.

Сегодня мы расскажем о главных отличиях между PaaS и IaaS.

Хотите узнать что такое управление рисками и как с ними справляться с ловкостью ниндзи?
Тогда добро пожаловать под кат!

(В этой статье изложены мысли, навеянные творчеством Тома ДеМарко, и скорее всего статья будет неинтересна тем, кто уже знаком с его произведениями)

Управление командой по Scrum методологии приобрело широкое использование за счет своей простоты и возможности применить «из коробки». Сложнее ситуация, когда в рамках одного проекта работает несколько команд. В этом случае применяют иерархическую модель Scrum-on-Scrum. Но вот что делать, когда есть нескольких команд разработчиков и одна команда тестеров.

Сегодня мы решили обсудить заметку Кента Бека (Kent Beck), автора методологии экстремального программирования, о том, как взвесить «стоимость» вашего программиста.

Этот пост написан по мотивам мастер-класса Бориса Вольфсона (директора по развитию HeadHunter), посвященного (сюрприз!) основам Agile. Материал будет полезен всем, кто либо совсем не знаком с данной методологией разработки сложного ПО, либо имеет о ней смутное представление.

Практические кейсы, о которых мы уже рассказывали:

• ИТ-инфраструктура для высоконагруженного проекта Hotels.ru
• Переход на IaaS и масштабирование сети постаматов PickPoint
• Каким стартапам нужен IaaS: Сервисы распознавания речи
• Как бизнес работает с IaaS
• Что происходит на рынке IaaS

Помимо этого мы обращаем внимание и на зарубежный опыт — анализируем все, что связано с работой сложных ИТ-систем, инфраструктуры и железа.

Например, совсем недавно мы рассказывали:

• о том, как Spotify масштабирует Apache Storm,
• рассматривали аппаратное обеспечение для глубокого обучения
• и бегло поговорили о примере оптимизации полосу пропускания в сетях Ethernet.

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