Alovak thoughts

My friend creates a large number of automation tests for service several teams work on. Recently we discussed different aspects of cucumber feature scenarios such as coupling and decoupling, conditional steps, etc.

The main question he wanted to clarify was how to handle horizontal integration tests when some steps in the middle are different? We reviewed different approaches for such cases.

Read more

Developers in our cross-functional team do many things: Ruby/JavaScript/HTML/CSS/deployments/etc. We use cards and whiteboard to manage tasks. Each task (code, requirements, etc.) is reviewed before moving card to the ‘Done’ column on the board. We don’t have additional test phase except demo in the end of iteration because our code is covered with RSpec and Cucumber :)

Recently we started to write posts about release changes. We describe features that matter to our users. Of course all features should be valuable but we have different kind of users, so we are blogging only about features for external users (not admins, supporters, etc.).

I created some posts and I noticed that when I make a screenshot or check how does new feature work I see small defects that make my impression worse. But before I create post I didn’t see them and nobody saw. So, I found that blogging is a very useful tool to make your attention more precise. It allows you to change the context and to look at things differently

Maybe our developers should start blogging about stuff they create?

Мы используем User Story (US) для описания требований к разрабатываемой системе. Формат US такой:

As a <role>, I want <feature> so that <value>

Перед тем, как “собирать” US для нашего приложения мы должны определить типы пользователей (роли) в нашей системе. Как их определить?

Read more

Мы используем User Story (US) для описания требований к разрабатываемой системе.

Иногда при работе с US возникают вопросы, на которые можно ответить, зная три важных аспекта User Story, описанных Ron Jeffries:

Read more

20 декабря прошла встреча AgileClub. На встрече обсуждались вопросы оценки и планирования. Было интересно и познавательно.

Я провел игру по оценке задач очень похожую на White Elephant Sizing.

Приблизительно 10 человек оценили 19 задач за 10 минут. Оценка в условных единицах: 1, 2, 3, 5, 8. Участники игры сделали несколько выводов:

• способ очень быстрый
• задачи оцениваются относительно друг друга
• задача, оцененная в 2 единицы в начале процесса оценки, может быть переоценена после оценки других задач
• при такой оценке не происходит обмен знаниями (у нас не происходил)
• этот способ работает, когда команда примерно представляет, что стоит за задачей (у нас уточняющие вопросы во время игры никто не задавал :)

Вот, что я думаю про knowledge sharing при таком способе. Обмен происходит, если участник объясняет почему он перетягивает задачу из одной колонки в другую (т.е. делает переоценку, когда не согласен с текущей оценкой). В Planning Poker, если оценки одинаковые, участники тоже ничего не обсуждают.

В то время, когда Юра Шиляев и Дима Зданович обсуждали процесс разработки проекта Димы, я ходил по комнате и фотографировал. Фотографии можно посмотреть здесь.

Или прямо здесь:

P.S. Спасибо компании ScienceSoft за помощь в проведении встречи!

Над предыдущим проектом мы работали более двух лет, но почему-то так и не смогли достичь цели. Мы делали много задач, однако они не приводили нас к желаемому результату. Почему? Потому что цель (желаемый результат) была очень размыта и вариантов движения было очень много. Нам не хватало четкого видения того, к чему мы идем.

В новом проекте мы решили исправить это упущение. Нам нужен Vision.

Vision - это такая штука, которая позволяет вам четко понять ту ли работу вы делаете, которая вам нужна. Она дает вам общее представление о  продукте, который вы будете делать. Для кого? Зачем? А ещё это критерий принятия различного рода решений по проекту.

Чтобы лучше понять, что я понимаю под “Vision” и получить именно его от заказчика, я отправил ему ссылку на статью на сайте Joel Spolsky, которая описывает что это и как это создать. Joel предлагает вот такой шаблон:

• For (target customer)
• Who (statement of the need or opportunity)
• The (product name) is a (product category)
• That (key benefit, compelling reason to buy)
• Unlike (primary competitive alternative)
• Our product (statement of primary differentiation)

В поисках формального способа получения видения, благодаря Денису Петелину, я прочитал про “Матрицу Захмана”. Эта матрица полезна и позволяет рассмотреть компанию/проект со всех сторон и на всех уровнях, но требует много ресурсов на то, чтобы описать, а потом поддерживать в актуальном состоянии то, что написано. Vision от Joel’а для меня проще. Его проще создать, понять и удержать в голове.

Через некоторое время заказчик прислал заполненный шаблон и 4 страницы текста разъясняющего этот Vision. Наша команда вместе с Product Owner’ом провела несколько часов в обсуждении этой информации. Когда видение стало четким, простым и лаконичным, появилось ощущение силы и энергии, которая направляет и движет к цели. По крайней мере меня.

Теперь мы можем двигаться вперед уверенно и быстро. Поехали!

Наш заказчик любит писать и читать письма, получать отчеты. Разговаривает с нами “голосом” он очень неохотно. При этом его позиция заключается в следующем: я не должен говорить вам, что нужно делать. Вы разработчики - это ваша задача реализовать то, что я хочу. С меня идея, а с вас - реализация. Вполне разумно.

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

Поэтому мы будем проводить демонстрации в конце каждой итерации для нашего заказчика и его команды, а не только для Product Owner’а. Участвовать в демонстрациях заказчик согласен. Как мы будем их делать - определимся позже.

Очень важно стремиться к тому, чтобы демонстрация результатов итерации не требовала серьезных затрат (времени, внимания и т.п.), как с вашей стороны, так и со стороны заказчика. Это, вероятнее всего, значит, что итерации должны быть короткими. Например 2 недели для команды в 5 человек.

Вы можете продемонстрировать и 40 фич, но что останется в голове после демо?

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

Предварительный план работы по проекту такой:

1. Определяем цели и видение проекта
2. Выделяем роли пользователей
3. Описываем user stories для первого релиза
4. Выделяем истории на итерацию
5. Реализовываем
6. Демонстрируем
7. Переходим к пункту 4 и так по кругу

О том, как мы определяли цели и видение проекта я напишу в следующий раз.

В субботу я выступил на Meetup’е посвященном Ruby и Python. Желающим узнать в чем сила языка рекомендую посмотреть видеозапись моего выступления.

Я уже в отпуске! On vacation!

Photo by Kenzoka