Alovak thoughts
Ruby/Rails developer
powered by tumblr
seattle theme by parker ehret
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.
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 для нашего приложения мы должны определить типы пользователей (роли) в нашей системе. Как их определить?
Мы используем User Story (US) для описания требований к разрабатываемой системе.
Иногда при работе с US возникают вопросы, на которые можно ответить, зная три важных аспекта User Story, описанных Ron Jeffries:
20 декабря прошла встреча AgileClub. На встрече обсуждались вопросы оценки и планирования. Было интересно и познавательно.
Я провел игру по оценке задач очень похожую на White Elephant Sizing.
Приблизительно 10 человек оценили 19 задач за 10 минут. Оценка в условных единицах: 1, 2, 3, 5, 8. Участники игры сделали несколько выводов:
Вот, что я думаю про knowledge sharing при таком способе. Обмен происходит, если участник объясняет почему он перетягивает задачу из одной колонки в другую (т.е. делает переоценку, когда не согласен с текущей оценкой). В Planning Poker, если оценки одинаковые, участники тоже ничего не обсуждают.
В то время, когда Юра Шиляев и Дима Зданович обсуждали процесс разработки проекта Димы, я ходил по комнате и фотографировал. Фотографии можно посмотреть здесь.
Или прямо здесь:
P.S. Спасибо компании ScienceSoft за помощь в проведении встречи!
Над предыдущим проектом мы работали более двух лет, но почему-то так и не смогли достичь цели. Мы делали много задач, однако они не приводили нас к желаемому результату. Почему? Потому что цель (желаемый результат) была очень размыта и вариантов движения было очень много. Нам не хватало четкого видения того, к чему мы идем.
В новом проекте мы решили исправить это упущение. Нам нужен Vision.
Vision - это такая штука, которая позволяет вам четко понять ту ли работу вы делаете, которая вам нужна. Она дает вам общее представление о продукте, который вы будете делать. Для кого? Зачем? А ещё это критерий принятия различного рода решений по проекту.
Чтобы лучше понять, что я понимаю под “Vision” и получить именно его от заказчика, я отправил ему ссылку на статью на сайте Joel Spolsky, которая описывает что это и как это создать. Joel предлагает вот такой шаблон:
В поисках формального способа получения видения, благодаря Денису Петелину, я прочитал про “Матрицу Захмана”. Эта матрица полезна и позволяет рассмотреть компанию/проект со всех сторон и на всех уровнях, но требует много ресурсов на то, чтобы описать, а потом поддерживать в актуальном состоянии то, что написано. Vision от Joel’а для меня проще. Его проще создать, понять и удержать в голове.
Через некоторое время заказчик прислал заполненный шаблон и 4 страницы текста разъясняющего этот Vision. Наша команда вместе с Product Owner’ом провела несколько часов в обсуждении этой информации. Когда видение стало четким, простым и лаконичным, появилось ощущение силы и энергии, которая направляет и движет к цели. По крайней мере меня.
Теперь мы можем двигаться вперед уверенно и быстро. Поехали!
Наш заказчик любит писать и читать письма, получать отчеты. Разговаривает с нами “голосом” он очень неохотно. При этом его позиция заключается в следующем: я не должен говорить вам, что нужно делать. Вы разработчики - это ваша задача реализовать то, что я хочу. С меня идея, а с вас - реализация. Вполне разумно.
Для команды важно, чтобы заказчик видел результаты работы, а не просто читал отчеты в письмах. Ещё лучше, чтобы он попробовал воспользоваться результатом. Опыт использования, осознание увиденного позволит ему ответить на ваш вопрос: получил ли он то, что хотел, либо нужно что-то изменить? Это и есть начальная точка следующей итерации.
Поэтому мы будем проводить демонстрации в конце каждой итерации для нашего заказчика и его команды, а не только для Product Owner’а. Участвовать в демонстрациях заказчик согласен. Как мы будем их делать - определимся позже.
Очень важно стремиться к тому, чтобы демонстрация результатов итерации не требовала серьезных затрат (времени, внимания и т.п.), как с вашей стороны, так и со стороны заказчика. Это, вероятнее всего, значит, что итерации должны быть короткими. Например 2 недели для команды в 5 человек.
Вы можете продемонстрировать и 40 фич, но что останется в голове после демо?
Сегодня ко мне в голову пришла идея создать дневник проекта, который мы начали разрабатывать чуть более двух недель назад. Мы начали этот проект после осознания того, что разрабатываемый в текущий момент продукт пытается удовлетворить слишком много потребностей разнообразной аудитории. В дневнике нового проекта я буду публиковать ту информацию, которая поможет увидеть работу в “стиле agile” :)
Предварительный план работы по проекту такой:
О том, как мы определяли цели и видение проекта я напишу в следующий раз.
В субботу я выступил на Meetup’е посвященном Ruby и Python. Желающим узнать в чем сила языка рекомендую посмотреть видеозапись моего выступления.
