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

Привет, Мегамозг. Начало рабочей недели — самое время анонсировать наше ежегодное летнее событие для всех, кто интересуется Agile — летний лагерь-конференцию AgileCamp. Если кратко, то мероприятие пройдет 23 и 24 июля в подмосковном курорте «Яхонты» — это 49 км от Москвы. Привычного формата докладов не будет, зато за 2 дня пройдем полный цикл создания продукта от анализа бизнес-модели до ретроспективы. Планируем 2 трэка. Стоп! У нас ведь лагерь! Назовем их отряды:) Итак, у нас будет 2 отряда: процессный и инженерный. Участники процессного отряда будут больше заниматься требованиями, бизнес-моделями и думать, как сделать счастливыми пользователей и команду. Инженерный поток будет заниматься парным программированием, рефакторингом, Unit-тестированием, TDD, DevOps. Посмотреть программу и зарегистрироваться можно тут. А за подробностями, лирикой и историей вопроса прошу под кат.

Привет, меня зовут Дима. Хочу поделиться с вами опытом работы над сервисом Carrot Quest (ссылка на описание проекта на Мегамозге). Это сервис для общения и управления пользователями на основе их поведения, другими словами marketing automation.

Долго мы искали для себя удобную форму работы и сколько перепробовали различных инструментов: использовали сервис Asana, работали со Scrum-досками, даже в Google Docs умудрялись записывать задачи. Мы постоянно искали удобную для всей команды методологию.

На первый взгляд может показаться, что Agile методология не является одним из тех подходов, для которых определяющую роль играет планирование. Судите сами: люди и взаимодействие между ними являются более важными, чем процессы и инструменты; работающий продукт важнее документации; готовность к изменениям, согласно Agile Manifesto, важнее следования первоначальному плану. С первого взгляда больше похоже на своего рода творческий беспорядок, чем на серьезную и основательную модель разработки программного обеспечения. Но это только с первого взгляда. Agile подход как нельзя лучше соответствует динамичности современного мира и предпочитает адаптивное планирование следованию изначальному генеральному плану. Видимо, именно поэтому он такой гибкий.

Диаграммы Ганта. Визуализируй это!

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

Одним из наиболее удобных и привычных способов визуализировать процесс разработки являются диаграммы Ганта. Они могут пригодиться не только для проектирования процесса разработки ПО. Хотите спланировать постройку дома? Не вопрос! С их помощью можно визуализировать даже ваш любимый рецепт домашней лазаньи!

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

В продолжение поста о том, что 20% населения России к 2020 году будет работать удаленно, а также публикации прогноза J’son & Partners Consulting, которые на днях распространили многие СМИ. Сам прогноз был опубликован еще в мае, и в частности его представила на Большом Медиакоммуникационном форуме представитель 1С-Битрикс Мария Сысойкина.

Так, согласно прогнозу, уже к 2016 году в России будет работать удаленно 2,71 миллион человек, из которых 642 000 будут использовать IT-решения:

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

В данном посте приведен список «базовых принципов» (а не набор шагов по достижению цели), который в службе электронного правительства Великобритании разработали для того, чтобы все сотрудники, занятые в создании сервисов Gov.uk, понимали, как (в общих чертах) должна происходить их работа.

Основная задача меморандума Gov.uk – объяснить сотрудникам общие «правила игры», сформировать корпоративную культуру, помочь им определиться с ожиданиями друг от друга и от работы в целом. И хотя указанные принципы могут на первый взгляд показаться банальными, возможно, их стоит иметь в виду при создании собственного внутрикорпоративного «манифеста» – а то, насколько это важно и нужно ли это небольшим стартапам, мы обсудили с резидентами Акселератора ФРИИ.

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

Зачем вообще нужны бизнес аналитики

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

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

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

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

Каждый месяц по всему миру происходят десятки, если не сотни, IT-ориентированных конференций, выставок и других мероприятий.

В очередной раз мы собираем все наиболее интересные международные даты этого месяца для того, чтобы представить читателям «Мегамозга» в одном месте.

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

Чаще всего Agile встречается в крупных компаниях и не распространен среди фрилансеров, но стоит ли фрилансеру использовать «водопад»? Нет. Фрилансеру также стоит использовать гибкие методологии проектирования и разработки, которые помогают использовать итерационную разработку.

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

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

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

Одна из таких методик заключается в следующем: делать один шаг за один раз.

Много лет назад меня наняла компания Omni-Corp для работы над новым блестящим продуктом. У нас был талант, бюджет и крутые технологии, но этот проект должен был потерпеть фиаско (и в результате его отменили) меньше чем через год.

Никто не идеален – у нас были свои проблемы, какие-то из них технические, какие-то – нет. Одной из них был способ управления требованиями:

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

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

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

Stand-up meeting, Daily Scrum Meeting или просто планёрки стали привычной практикой в IT. Я описывал различные нюансы стендапов ещё 5 лет назад в статье Stand-up meeting: лучшие и худшие практики. Казалось бы, техника проведения стендапов уже рассмотрена со всех сторон. Что в планёрке может быть сложного? Но совсем недавно наша компания начала практиковать несколько другой подход, с помощью которого мы ускорили выход задач в релиз.

Всё началось, когда летом 2014 года в Москве мы с Асхатом шли на тренинг и он обратил моё внимание на разницу между стендапами в Scrum и Kanban. До этого я не придавал особого значения таким нюансам. У нас в компании для части проектов используется Kanban, но стиль стендапов остался от Scrum'а.

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