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

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

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

Даже относительно крупным компаниям приходится перестраиваться. «[В последнее время] заказчики выводят на конкурсы любые независимые этапы, по окончании которых можно получить завершенные бизнес-результаты (оптимизация части инфраструктуры в ключевых регионах, рост быстродействия критичных для бизнеса приложений, таких как «1С»)», – рассуждает директор департамента ИТ-аутсорсинга ALP Group Дмитрий Бессольцев.

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

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

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

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

Да и вообще.

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

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

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

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

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

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

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

На мой взгляд самую коварную ошибку допустили создатели, когда сказали, что скрам это фрэймворк, который нужно адаптировать под себя. Я много раз слышал, как люди ссылаясь на это утверждение, оправдывали отсутствие или модификацию фундаментальных элементов скрама, таких как роль Product Owner, burndown диаграмма, цель спринта, демонстрация, готовый продукт в конце спринта и др. Для таких многочисленных «адаптаций» даже появился специальный термин «Скрамно» (ScrumBut).

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

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

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

Я рос в депрессивном поселке городского типа, где большинство парней, повзрослев, выбирало путь уверенной деградации. Лет с 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" — сделал его, в первую очередь, для себя.

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

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