Обратная связь

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

среда, 15 июля 2015 г.

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

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

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

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

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

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

понедельник, 11 мая 2015 г.

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

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

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

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

четверг, 5 марта 2015 г.

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

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

среда, 25 февраля 2015 г.

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

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

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

вторник, 24 февраля 2015 г.

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

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

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

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

понедельник, 23 февраля 2015 г.

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

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

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

воскресенье, 22 февраля 2015 г.

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

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

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

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

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

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

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

вторник, 10 февраля 2015 г.

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

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

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

вторник, 23 декабря 2014 г.

Impact Mapping на практике

Когда читал книгу Impact Mapping первый раз, у меня было желание бросить её на середине. Всё, что там написано, слишком очевидно. Я нашел в себе силы и дочитал, благо книга коротная и с большими картинками. Как в последствии выяснилось, вся соль была в том, что все эти очевидные и простые практики из книги я не применял в своей работе.

Иногда заказчики писали свои цели в официальных документах к проекту. Иногда мне казалось, что я и так понимаю цели заказчика — они абсолютно очевидны. К чему уточнять очевидное? Разницу я почувствовал, когда начал применять Impact Mapping в работе.