AgileDays -2011:Отчет Заборова М.А.

Подстраницы (10) →

Доклады

1 День

Henrik Kniberg. Everyone likes change, but nobody likes to be changed.

• Everyone likes change, but nobody likes to be changed (Henrik Kniberg, AgileDays-2011)

Как убедить кого-то? Не надо этого делать. Измените себя.

Не меняйте людей. Сделайте так, что бы они меняли себя сами. Объясните им, почему они должны это сделать. И покажите им путь.

Дальше самотерапия:

• Напишите, что вы хотите в себе поменять.
• Напишите почему.
• Напишите цель к которой вы стремитесь (и почему).
• напишите, где вы сейчас.
• Напишите следующий шаг.
• и т. д.

Пример, как заставить ребенка убирать в комнате:

• не заставлять ничего делать
• не делать за него

мотивы:

• не потерять игрушки
• не наступать
• больше пространсва для игры

Первый шаг

• поними любую вешь — положи на место
• теперь следующий
• смотри появилось чистое пространство

MikhailZaborov 10:28, 4 марта 2011 (MSK) Очень примитивно. С моими детьми это не работает :(. Не знаю как у других

Никто не любит изменяться

Варианты пути зависят от того, где вы находитесь:

• для «большой водопадной компании» — путь известен
• Для «маленькой стартап конторы»: Agile — тяжеловесная бюрократия

Разные пути:

• биг-банг
• инкрементальный
• пилот

Замкнутый круг:

• Разработчики — мы хотим Agile, но менеджеры не разрешат.
• Менеджеры — мы хотим Agile, но заказчики не позволят.
• Заказчики — мы хотим Agile, но разработчики не смогут c ним управляться (cannot manage it).

Куча историй про скорость и задачи в разных компаний. Как сделать так, что бы перестать бороть пожары и начать имплементить фичи и т. д.

Идеи

• Сделать ситуацию болезненно прозрачной
• Bug Bush — каждый вторник команда борется с багами.
• Как автоматизировать тестирование — достаточно банально: автоматизируйте только то, что важно (высокие риски сбоя и сильные последствия) и то что легче автоматизировать, чем делать руками.

  MikhailZaborov 10:42, 4 марта 2011 (MSK) Спасибо, кэп!

• Привлекайте внешних экспертов (например, раскидывайте правильные книжки везде, где только можно)
• Делайте обратимые эксперименты.
• Показывайте BussinessValue от изменений.
• Не путайте проблемы и страхи.
• Не делайте ненужную документацию. Вставляйте fake, что бы проверить, кто ей пользуется (например, «если вы это читаете — я куплю вам пиво»).

Выводы: Скучновато. Местами банально, местами очень спорно. Новых мыслей практически нет.

Вопросы в Open Space

Спросил Хенрика про то, что делать с расслаблением команды (когда команда дает очень осторожные оценки, снижая общую скорость). Не увидел глубокого понимания. Одна из идей — отменить оценку вообще.

Беспальчук Игорь 19:06, 18 марта 2011 (MSK) Хенрик сказал, что, возможно, проблема с мотивацией. Но, видимо, это был «неправильный ответ» :)

Николай Алименков, Алексей Солнцев В погоне за качеством. Code Review

Украинская пара из XPInjection

Очень клевый стиль. Реальный парный доклад. Один закончил фразу, другой ее продолжил. Клево!

Активно общаются с аудиторией — очень клево.

По содержанию: всесторонне и очень качественно расмотрели вопрос. Кому интересна тема — рекомендую видео к просмотру… (презентация на английском.. без авторов не очень интересна).

Выводы: Очень здорово и интересно. Ребята — молодцы!

Сергей Дмитриев. Ретроспективы. Настраиваем наш процесс разработки

• Пришел только на конец доклада (слушал про Code Review).
• Показалось интересным (рассказывали про то, как разнообразить ретро).
• Надо бы посмотреть видео.

Семен Молотков, Евгений Кобзев Экстремальный аджайл — танцуют все

Доклад о том как внедряли SCRUM для всех ролей для продукта «Электронный бухгалтер Эльба» в компании «CКБ-Контур».

С точки зрения внедрения SCRUM достаточно скучно…

с бизнесовой точки зрения бизнеса, я узнал про этот проект когда он был на уровне бизнес-идеи… интересно, что он превратился в что-то реальное

Борис Вольфсон, Масштабирование Scrum на большую распределенную команду

Боря рассказывал абстрактную картинку.. которая вроде как работает у них в компании

2 альтернативные иерархии управления (Скрам мастера и PO). Поскольку чем реально занимаются SM и PO у них не понятно — выглядит это все как голые логические построения. Никаких практических примеров и косвенных признаков, что это действительно живое :(

Тимофей Евграшин, Культура лидерства в Agile

Анна Обухова Agile Distribution Risk Score — планируйте распределенность осознанно

Вместо Тимофея рассказывала Анна Обухова.. Как и все доклады Exigen Services. Очень скучно :(.

Стас Фомин 20:55, 7 мая 2011 (MSD): Не вместо, а до! Тимофей все успешно рассказал!

Опять про проблемы распределенности.

Выводы: Скучно и не интересно

Собственно Тимофей

А Тимофей выложил презентацию — забавная

Круглый стол нужен ли фокус фактор

Обсуждались 2 темы:

• Собственно фокус фактор (на обсуждение которого практически на попал, но там активно участвовал Миша Новиков).
• Бодались с Николай Алименков (Mikalai Aliemenkov) из XPInjection. Очень содержательно и продуктивно.

2 день

Андрей Бибичев. Архитектура в Agile: переосмысляя идею модульности и компонентности

Доклад Андрея. Оказался очень низкоуровневым. По сути, это хорошие практики кодирования… Причем он в этот раз докладывал не очень структурировано…

Выводы: Мне это уже не очень интересно. Разработчикам наверное стоит посмотреть.

Станислав Калканов В чем счастье заказчика? Готовые фичи вместо гант чарта!

Доклад получился про то как внедряли Agile в Люксофте… Доклад добротный но ничего особо нового..

Забавные выводы — Что бы все работало заказчик должен уделять команде много времени. Если он этого не может — он сам во всем виноват…

Николай Гребнев Domain Driven Design в условиях разработки распределенных приложений

Коля рассказывал живо и интересно…

Хотя видно, что волновался.. иногда говорил много лишних слов. Вначале немного спотыкался, но к середине разогнался.

Но к сожалению месседж доклада не понятен :(.. Судя по отзывам народа в кулуарах и в твиттере. Доклад народу не понравился :(

Асхат Уразбаев Применение принципов Lean в масштабах предприятия

Ликбез про Lean.. Как всегда очень добротно и качественно

---

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