К основному контенту

Agile Gathering IV: survey

Мы благодарны за ответы всем, кто заполнил online опрос на тему недавно проведенной конференции Agile Gathering IV. Был получен 31 ответ, что составляет одну треть присутствующих.

Пройдёмся по деталям.

Общее впечатление


Вот каким образом аудитория оценивает различные аспекты мероприятия:


Большинству "всё понравилось", мы рады ;)




Доклады


Таков рейтинг докладов:


Таким образом лидирует Алексей Солнцев с "Agile командами" (судя по реакции публики - весьма предсказуемые результаты), на втором месте - наш многоуважаемый гость из Индии Naresh Jain.

Пожелания о темах

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



Выходит, что тема QA и тестирования - наиболее желаемая.

За ней идут - "люди и команды", "практические вопросы" и "неуспешные случаи внедрения Agile". Что ж, я надеюсь, мы найдём докладчиков для освещения этих тем на следующей конференции, которая, кстати, состоится в июне в Киеве!

Ниже приводятся необработанные пожелания, комментарии и темы - без правки орфографии :).

Спасибо за ваши отзывы, мы учтём!

Общие пожелания
  • Хотел бы видеть расписание докладов в печатном виде в раздаточных материалах
    Хотелось бы доклады сократить, общение в кулуарах увеличить ;)
    Понравились доклады с примерами личного опыта. В отличии от длинных "академических" докладов (e.g. "System Dynamics")
  • Единственное пожелание - в следующий раз постараться проанонсировать мероприятие получше. например можно было на UAWEB08 в конце доклада рассказать или слайд сделать (в конце). на хабре анонс не помешает... мне конечно это уже не актуально, но новых людей привлечь так можно будет ...
  • Единственная организационная недоработка - короткий обеденный перерыв. Ребята были с поезда, голодные, а в ближайшей точке питания супчика пришлось ждать 20 мин
  • Очень класcно всё было :)
  • Печенье к чаю, конференция длится полный рабочий день и хочется есть. некоторые докладчики просто неумеют выступать перед публикой, было бы лучше, если бы они от себя рассказывали больше. Очень понравился Солнцев.
  • Кофе на всех получилось маловато...И если б к нему хоть самых простых печенюшек что ли ...
  • Лучше бы мы собрались перед докладами
  • Сделать перерыв на обед 1 час
Пожелания докладчикам
  • Больше работы с аудиторией, реальные примеры из жизни, личный опыт, юмор
  • Побольше примеров из жизни. Жизненный опыт... Теорию можно почерпнуть из литературы.
  • В целом доклады интересные, может не всё про agile - но, по моему, это нормально ;)
  • Прослушивайте докладчиков перед выступлением
  • Многие докладчики явно не являлись мастерами презентации. Было бы неплохо заострить их внимание на том как они ведут презентацию
  • Неплохо было бы, если бы название темы, соответствовало ее содержанию.
  • "Theory of Constraints and System Dynamics" - по больше бы практических примеров, а то немного суховато вышло.
  • Пусть Б. Лебеда в следующий раз точнее переводит тему :)
Желаемые темы

QA
  • Тестирование в Agile (сложные длительные проекты)
  • QA motivation
  • Agile in testing (QA)
  • QA в agile-проэктах
  • Автоматизированное тестирования в Agile проектах
Individuals and teams
  • Мотивация разработчиков
  • Создание микроклимата в команде
  • Психологические отношения скрам-мастер - программист )
Practical cases
  • Обмен опытом по решению практических проблем в Agile проектах
  • Сравнение разных agile практик от человека который их пробовал
  • Примеры (workflow) из реальных проектов (анализ, тест, разработка, коммуникации)
Negative cases
  • Несостоявшийся "SCRUM в больших проектах"
  • Agile разработчик в не-agile среде
  • Где Scrum не работает и почему
Project management
  • Управление agile-проектами
  • Управление рисками
Complex projects
  • Внедрение Agile в крупных проектах и распределенных командах
  • Agile в крупных проектах - more information
Engineering
  • Инженерные практики
  • Паттерны TTD
Other
  • Agile и фриланс
  • Эффективное поэтапное введение Scrum в проекте, где его не было
  • Трекинг Agile проектов
До новых встреч!

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Основополагающие принципы Agile-манифеста

Мы следуем таким принципам: Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. Работающий продукт — основной показатель прогресса. Инвесторы, разработчики и пользователи должны иметь возможность поддержив

Скрамбан - собираем лучшее

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.

Ретроспектива спринта - эффективный формат

Автор: Майк Кон (Mike Cohn) Перевод с английского Неважно, насколько опытной является Скрам-команда, при этом всегда существует возможность для ее улучшения. Не смотря на то, что хорошая Скрам-команда будет постоянно искать возможности для своего улучшения, она должна выделять короткий период времени в конце каждого спринта для сознательного размышления над тем, как идут их дела, и для поиска способов их улучшения. Все это происходит во время Ретроспективы спринта.