Персональные инструменты
 

Недостающая часть Scrum — как стать успешным инженером в Agile? (Антон Кекс, AgileDays-2011)

Материал из CustisWiki

Перейти к: навигация, поиск

Аннотация

Докладчик
Антон Кекс

Scrum учит нас эффективному управлению проектов, созданию самоорганизующихся команд. Но зачастую Scrum-проекты могут быть обречены, если участвующие в них разработчики позволяют себе не следовать инженерным практикам, помогающим улучшить качество кода, покрытие тестами, и дисциплину внутри команды. Основы этих технических практик лежат в методике XP, которая успешно применяется во многих организациях повсеместно со Scrum. В докладе я расскажу о своем опыте внедрения этих практик, а также почему следование им обязательно в успешных Agile-проектах.

Видео

Видео нет (докладчик случайно стер скринкаст). Но если вы знакомы с докладчиком, попробуйте упросить записать скринкаст заново, тогда мы смонтируем видео!




Примечания и отзывы

Из Эстонии. Основатель и глава фирмы. Хороший обзор, но для новичков.

  • В первую очередь итеративно и инкрементально, адаптивно.
  • Нельзя молиться и верить что работает — нужны тесты.
  • Простота. Максимизировать несделанной работы.
Стас Фомин: «Максимизировать несделанной работы» — явно что-то не так.
  • Большие половины в мире используют agile, 84 % из них — scrum, но только половина — итерации, то есть реально много фуфла. flaccid scrum
  • Вид программистов-ковбоев. И программистов-бюрократов, что хуже…
  • Внедрение сверху-вниз. Много плюсов — для менеджеров.
  • Кен Швабер разочаровался в альянсе, сертифицирующем скрам-мастеров, и начал делать программу обучения и сертификации скрам-разработчиков
  • Agile требует жесткой дисциплины, иначе ничего не выйдет
  • YAGNI: simplicity — лишние патерны, проги на будущее — но без оговорки Эванса? — работает из предположения, что добавить потом также просто и что не можешь угадать.
  • Продать парное программирование девелоперам…

вроде для новичков — ушел потом вернулся — когда игры кончились

  • История про тесты. Которые просто удаляют, а не исправляют.
  • Build-мигалка под потолком…
  • Не меряйте разработчика числом строк — он начнет писать длинно, а не элегантно.
  • Вертикальная разработка.
    • Горизонтальная — прототип формы, который не работает, потом — следующий слой.
    • Вертикальная — фича снизу доверху
  • Против чрезмерной специализации. Если все кроме одного попали под грузовик, один должен мочь продолжать.
  • Стандарты кода — чтобы ощущали своим.
  • Архитектура — часть дизайна, которую сложно изменить потому что она вбита. Значит лучше, если нет архитектуры… Пришло из строительства, где дизайн дороже. Он считает, что код и есть дизайн, а вовсе не какой-нибудь UML. С одной стороны, против быдло-кодеров. но с другой…
  • Software craftmanship
  • Двойной монитор с дублем экрана и две клавиатуры и мышки. Только пальцем на экране не показывать.
  • Главное у людей — отношение к работе, а не skills



Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Недостающая часть Scrum — как стать успешным инженером в Agile? (Антон Кекс, AgileDays-2011)»