Пользовательские истории (User Stories)

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

—Джефф Паттон — «Пользовательские истории»

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

Далее

На основании чего вы тестируете свой продукт? Или управление требованиями к ПО 101

По мере того как компания росла, на работу поступало все больше людей, привыкших к традиционному процессу разработки. Однажды ко мне пришла начальница другой команды и сказала: «Джефф, нужно, чтобы вы внесли вот эти изменения в продукт, над которым сейчас работаете». «Нет проблем, – ответил я, – только расскажите мне, для кого мы делаем эти изменения и какие задачи люди будут решать с их помощью». Что я услышал в ответ? «Это нужно для соответствия требованиям». «Я вас понял, – кивнул я. – Мне только нужно знать подробнее, для кого мы внедряем эти штуки, как эти люди будут их использовать, а также какой этап их рабочего процесса изменится». Она посмотрела на меня так, словно я был самым тупым человеком на свете, и повторила с нажимом: «Это. Для. Соответствия. Требованиям». И в этот момент я осознал, что слово «требования» на самом деле означает «заткнись». Вот что означают требования для большинства людей. Они перестают говорить о людях и проблемах, которые надо решить.

—Джефф Паттон — «Пользовательские истории»

Цитата выше очень злободневная, но даже она отражает лишь часть проблемы. Удивительно, но факт — в двух из трёх компаниях, в разработке пяти из шести программных продуктов, с которыми мне довелось иметь дело, про требования вообще не задумывались. Либо применяли что-то похожее на эту концепцию к отдельным, наиболее ярко выраженным частям (как правило, базовый функционал продукта) и только на отдельных этапах. Как результат, изрядная часть продукта развивается хаотично, накапливает избыточные элементы или, наоборот, недоделки, наращивает техдолг, а значительную часть усилий команда прикладывает не к тому, что на самом деле важно.

Дальнейший мой спич имеет целью небольшой ликбез в части важности управления требованиями в разработке ПО. Учебник Вигерса заменить не претендую, но и ориентируюсь не столько на бизнес-/системных аналитиков, сколько на остальных участников — разработчиков и QA. Хотя если у аналитиков всплывёт что-то в памяти или возникнет потребность что-то добавить — тоже неплохой результат.

Продолжить чтение «На основании чего вы тестируете свой продукт? Или управление требованиями к ПО 101»

Почему ветвление в git — это плохо

Это перевод статьи с dev.to. Оригинал.

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

С автором согласен — подход очень органичный для CI, но требует очень высокой дисциплины команды (частых коммитов) и автоматизации сборок и базовых тестов.


Многие кодят используя фичебранчи в git. Понятно для чего — не хочется ввязываться в разбор возможных конфликтов в процессе пуллов (с кодом) или после того как ваш пуш сломал что-то для всей команды (с людьми).

Я нахожу эти аргументы безосновательными, а порой и вредными. Попытка программировать внутри вашей маленькой временной капсулы в целях избегания воздействия остальных членов команды — плохая идея. Продолжить чтение «Почему ветвление в git — это плохо»

Работа в Paragon Software: unexpected end of story

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

Начни я писать подобный анализ чуть раньше, был высокий риск сорваться на типовую историю в жанре «тут все дураки, один я непонятый Д’Артаньян».

Нет, определённо в компании достаточно не просто умных, а очень умных людей, неплохо выстроены некоторые процессы, которые и в более известных компаниях только учатся строить (например, Continuous Integration). Есть и ряд «человекоориентированных» бонусов, в т.ч. уникальных — кофемашины, гибкий график работы, возможность удалёнки, пять «бесплатных» отгулов в год. И Scrum.

В общем, выглядит всё достаточно гибко и инновационно.

 

Продолжить чтение «Работа в Paragon Software: unexpected end of story»

Книги марта — Agile и управление процессами создания ПО

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

В март также вошли пара книжиц по Python, но едва ли есть смысл делать обзоры учебников по языкам программирования. Они не то чтобы сильно разнообразные. Продолжить чтение «Книги марта — Agile и управление процессами создания ПО»