Видео и презентация: Пять самых важных составляющих процесса выпуска проектов

В начале осени мы описали как работаем, как создаем IT-продукты с нуля. Статью про пять самых важных составляющих процесса выпуска успешных проектов писали целый месяц вместе с Андреем Шапиро, плюс было несколько рецензентов, среди которых наши заказчики. На Цукерберг Позвонит статья собрала 15 000+ просмотров, после публикации мы получили поток вопросов и увидели огромный интерес к теме.

Стало понятно, что надо рассказывать про наш подход, поэтому осенью мы сделали два выступления — одно на осенней .NETconf, другое на HappyDev 2015. Ниже видео и слайды с выступлений по этой теме.

Пять самых важных составляющих процесса выпуска успешных проектов

Для создания ПО мы выбрали эмпирический подход и почти отказались от детерминистского. Опыт показывает, что нельзя просто взять и описать большой продукт в ТЗ, а потом реализовать его по описанию. Жизнь оказывается всегда шире, чем наше представление о ней. С другой стороны, эмпирический подход отражает постоянное углубление нашего понимания предметной области, бизнеса заказчика и изменений на рынке по мере создания и совершенствования продукта.

Инструменты для проекта на .NET и JavaScript: Часть 1

Когда я говорю, что в нашей компании мы используем .NET Framework, то собеседники обычно представляют «бедный» набор из ОС Windows, TFS, C#, MSSQL и ASP.NET + немного JavaScript.

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

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

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

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

Стендапы в стиле Kanban

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

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

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

Customer satisfaction для программистов: Используем Domain Driven Design

В Domain Driven Design есть много аспектов связанных с кодом, шаблонами и подходами к проектированию ПО. Это всё правильно и полезно, но вряд ли заказчик оценит то, что вы выделили функцию без side effects в Value Object и покрыли её тестами. Зато заказчику точно будут интересны и важны части DDD, которые связаны с поставкой продукта и коммуникацией.

Customer satisfaction для программистов: Проблем быть не должно

Как однажды сказал Сергей Архипенков: «Если у проекта нет проблем, значит он умер». Проблемы при разработке ПО есть всегда. С другой стороны, заказчика нужно оградить от лишней головной боли, для него проблем быть не должно. Здесь главный вопрос в том, как эти проблемы преподносить заказчику?

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

Customer satisfaction для программистов: Все программисты — оптимисты

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

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

Итак, в основе планирования разработки программ лежит ложное допущение, что все будет хорошо, т.е. каждая задача займет столько времени, сколько «должна» занять. (с) Брукс

Customer satisfaction для программистов: Доверие и прозрачность

Есть отличная статья Управленческие инструменты: Почему заказчики требуют дурацкие отчеты? от компании Stratoplan. Рекомендую прочитать саму статью, а здесь я коротко опишу как мы используем матрицу 2x2 в своей работе.

Рисуем матрицу, где по одно оси «Прозрачность» вашей работы для заказчика, а по другой «Доверие» заказчика к вам:

Customer satisfaction для программистов: Визуализация

Одна из ключевых практик в Kanban — это визуализация работы: «You cannot improve what you cannot see». Следующие три подхода нацелены на визуализацию целей проекта, задач и текущего процесса.

Customer satisfaction для программистов

Часто разработчики говорят мне, что soft skills им не нужны. Разработчик — не менеджер и управленческие навыки может не развивать. С одной стороны так и есть — разработчику очень важно углублять свои знания в технологиях и методологиях проектирования ПО. С другой стоны, я уверен, каждому хочется уметь отстаивать свою позицию и получать заслуженную похвалу за хорошую работу. А если так, то почему бы не продвинуться в этом направлении?

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

Серия статей «Customer satisfaction для программистов»

Материала получилось довольно много, поэтому каждый раздел выйдет отдельной статьей:

• Визуализация
• Доверие и прозрачность
• Все программисты — оптимисты
• Проблем быть не должно
• Используем Domain Driven Design

Под «заказчиком» я имею ввиду любые отношения заказчик-исполнитель, где вы являетесь исполнителем. Заказчиками могут быть пользователи вашего продукта, может быть Project Manager, может быть совет директоров, может быть бухгалтер из соседнего отдела и т.д.

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

Модель принятия решений

Когда-то меня вдохновило выступление Евгения Кривошеева Design & Process Models. В нём рассматривается много аспектов разработки ПО, рекомендую выделить 2 часа и посмотреть видео целиком. Сейчас я хочу остановится на взаимодействии связанных между собой моделей и том, как это можно использовать в повседневной работе:

• Business Model — бизнес заказчика, на чём он зарабатывает деньги.
• Process model — как должен быть устроен процесс формирования ценности: этапы, фазы, роли, артефактры для получения ценности. Описывает также порядок появление нижележащих моделей и их взаимодействие. Например, пишем код и рефакторим до хорошего дизайна или сначала делаем дизайн (upfront) и потом пишем код.
• Requirements Model + Domain Model — какие требования есть к продукту/проекту, тексты, UML-диаграммы и т.д.
• Design Model — архитектура, шаблоны проектирования и т.п.
• Implementation Model — исходный код