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

Если взглянуть на эволюцию компьютерных интерфейсов, наблюдаются 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.

Если на вашем столе стоит чашка остывшего желанного кофе или чая, значит, что-то не так. Во всяком случае, так наверняка подумал бы Дэвид Аллен, автор знаменитого метода GTD (Getting Things Done). Мы хватаемся за тысячу дел, пытаясь попутно не забыть про бытовые мелочи, часто забываем о цели, но помним о неотвратимо приближающихся дедлайнах. Порой страх перед лавиной задач буквально парализует мозг и наступают апатия, прокрастинация, депрессия. Работа в такие моменты движется медленно, кажется, даже курсор мыши еле ползёт по монитору. Такая ситуация тем опаснее, чем больше человек работает в команде, особенно, если речь идёт о команде разработчиков.

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

Тимлид (aka ведущий разработчик, team leader) — один из таких «специалистов», обязанности которого многие видят по-разному. Думаю, что складываются различные представления примерно так: поработал кто-то в команде под руководством тимлида, который хорошо справлялся с задачами проектирования системы, и считает теперь, что это именно то, что должен делать тимлид; в другой же команде тимлид плохо справлялся с планированием спринтов, а с другими обязанностями более или менее, и стали считать сотрудники, что планирование — не то, чем должен заниматься тимлид.

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

Сегодня мы хотим поделиться впечатлениями от участия в тренингах Certified Scrum Master и Certified Scrum Product Owner от Innovel и ProCognita, которые проходили в Варшаве 29-30 июня и 1-2 июля соответственно. Здесь мы рассмотрим наиболее интересные с нашей точки зрения инструменты и техники, представленные на обоих тренингах, которые будут полезны как тем, кто делает свои первые шаги в SCRUM, так и уже имеющим некоторый опыт в применении гибких SCRUM в своих проектах. Мы оставили оригинальные названия упражнений, чтобы упростить поиск тем, кто впоследствии пожелает найти больше информации; кроме того, статья дополнена ссылками на англоязычные статьи, поясняющие суть некоторых упражнений.