Agile *

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

Привет Филип, можно спросить, как ты стал отличным front-end-разработчиком? Можешь дать совет?

Признаться, я был удивлен тем, что подобный вопрос задают мне, так как я никогда не считал себя «отличным» front-end-разработчиком. На самом деле, я не уверен, что был достаточно квалифицирован для всего, за что брался, когда только начинал работать в этой сфере. Я подавал заявки на работу только потому, что не понимал, как мало я знаю, а получал её, потому что люди, на собеседование к которым я приходил, не знали, какие вопросы задавать.

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

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

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

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

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

Если про передачу требований от уровня бизнеса к системному уровню сказано немало и выработался определенный инструментарий, то вот какие артефакты использовать для взаимодействия и передачи знаний между бизнесом, аналитиком и UX-проектированием — вопрос открытый. Этой темой я продолжаю цикл статей по бизнес-анализу в мобильной разработке.

Всем привет! Сегодня я хочу рассказать историю о своем увлекательном путешествии на «антиконференцию» AgileCamp 2015.

До участия в этом мероприятии у меня не было опыта применения Scrum и Kanban, поэтому было очень интересно опробовать гибкие методологии на практике. Заранее прошу прощения, если где-то напутал с терминологией или переиначил смысл услышанного – прежде всего мне хотелось поделиться своими впечатлениями. Буду рад любым вашим комментариям, в том числе с замечаниями и дополнениями.

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

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

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

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

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

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

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

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

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

Такие гибкие методологии, как Lean Startup и Scrum, помогут вам понять, чего хотят клиенты, и как им поскорее это дать. Сильнейшие Agile-команды следуют пяти основным паттернам. Чтобы понять, соответствуют ли ваши рабочие процессы принципам Agile, проверьте, насколько вы следуете этим паттернам. Чтобы оставаться гибкими, следуйте этим паттернам постоянно.

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

Проведение ретроспектив – это активность, которую каждая agile-команда проводит для того, чтобы решать свои проблемы. Что такое ретроспектива? Это регулярная встреча, на которой команда обсуждает свой рабочий процесс и что-то в нем меняет.

Зачем нужна ретроспектива?

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

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

Предлагаю вашему вниманию перевод интервью, вышедшего в подкасте «Software Enginering Radio» в апреле 2015 года. Свен Йохан и Эберхард Вольф обсуждают внутреннее и внешнее качество ПО, вспоминают общепринятые модели качества и стратегии, направленные на поддержание внутреннего качества ПО. Технический долг, в основном, рассматривается в контексте управления программными проектами.

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

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

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

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

Рубрика «Как работают профессионалы» нашла еще одного высококлассного специалиста на рынке информационных технологий и знакомит читателей «Мегамозга» с его рабочими привычками.

Знакомьтесь – Даниил Трабун, главный редактор журнала «Афиша».

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