Слышала от многих разработчиков, что они не любят рабочие встречи. Говорят: "Пустая трата времени", "Митинги бесполезны", "А работать то когда?". Так вот, если у вас такие встречи, то вы явно что-то делаете не так.

Когда говорят о выборе архитектуры IT-системы, почти всегда упускают один ма-а-аленький нюанс: мы делаем продукты для пользователей, не для себя. А пользователям совершенно неважно, какая у сервиса архитектура. Никто в отзывах не ставит звёздочки за event-driven подход или классную реализацию service mesh — разве что в редких случаях, когда речь о продуктах для разработчиков. 

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

Сегодня хочу поделиться с вами процессом разработки сайта по методике agile внутри огромного российского энтерпрайза, который работает по всем канонам каскадной разработки (waterfall). Примером послужит один из сайтов нашей компании, над которой работает наша молодая agile-команда.

Начало декабря. Утро понедельника. В переговорной собралась команда для обсуждения планов на спринт.

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

Владелец продукта кивнул, принимая тяжёлое, но важное для команды решение, и твёрдо произнёс: «Нам нужно поставить ёлку».

Всем привет! Меня зовут Максим, и я работаю бизнес-аналитиком на проекте Швейцарских Железных Дорог. За последние пять лет я описал больше четырех сотен пользовательских историй, экспериментируя со структурой и форматом. Под катом рассказ о том, какие проблемы у меня возникали, и как их удалось решить.

Конспект лекций — Питер Тиль (курс: CS183) Стартап — Стэнфорд, весна 2012 г.