Home » Книги » Scrum и XP: заметки с передовой

Scrum и XP: заметки с передовой

August 9, 2012

Posted by admin under Книги

13 Comments

Автор: Хенрик Книберг

Предисловие Майка Кона

И Scrum, и XP (экстремальное программирование) требуют от команд завершения вполне осязаемого куска работы, который можно предоставить пользователю в конце каждой итерации. Эти итерации планируются таким образом, чтобы быть короткими и фиксированными по времени. Такая целенаправленность на выпуск рабочего кода за короткий промежуток времени означает только одно: в Scrum и XP нет места теории. Agile-методологии не гонятся за красивыми UML моделями, выполненными при помощи специальных case-средств, за созданием детализированных спецификаций или написанием кода, который сойдёт на все случаи жизни. Вместо этого Scrum и XP команды концентрируются на том, чтобы завершить необходимые задачи. Эти команды могут мириться с ошибками в ходе работы, но они понимают, что лучшее средство выявить эти ошибки – это перестать думать о софте на теоретическом уровне анализа и дизайна, и, закатав рукава, полностью посвятить себя созданию продукта.

Именно акцент на действии, а не на теории ярко выделяет эту книгу среди прочих. То, что Хенрик разделяет эти взгляды, видно с самых первых страниц книги. Он не предлагает нам длинное описание того, что такое Scrum; вместо этого он просто ссылается на необходимые веб-ресурсы. Первым делом Хенрик начинает с описания того, как его команда работает со своим product backlog’ом. Затем он проходит по всем элементам и практикам правильно поставленного agile-проекта. Без теоретизирования. Без справочных данных. Ничего этого не нужно: книга Хенрика – не философское объяснение, почему Scrum работает или почему мы должны делать так, а не иначе. Это описание того, как работает одна успешная agile-команда.

Хенрик предлагает набор избранных практик и описывает живые примеры, чтобы помочь нам понять, как использовать Scrum и XP на передовой.

На русском: http://scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenches-rus-final.pdf

Оригинал: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Dmitry Pavlov

Немного критики гибких методологий (субъективно, разумеется):

Что скрам, что экспи – это потогонные модели, которые позволяют выжимать все соки из молодых специалистов первые 5-10 лет. Эти методики появились потому, что конкурентная бизнес среда ставит айтишное сообщество в условия перманентного рабочего стресса, что приводит к затяжной и глубокой депрессии. Это методики, которые убивают интерес к технологиям, обучают не думать, а действовать как заведенная игрушка, ни во что не вникая глубоко, сосредоточившись на “коллективном разуме”. Эти методики превращают специалиста в посредственного и легко заменяемого юнита, который обучен двум-трем полуавтоматическим действиям для бесконечного цикличного выполнения. Agile превращает художников в маляров.
- Oleg Blagin
  
  Методики могут видимо применяться и без стресса. Кто-то может назвать данную методику “потогонной”, а кто-то “технологичной”. Кто-то из разработчиков может стать “художником”, а кто-то способен быть только “маляром”.
  И нужно ли в современном мире много “художников”? Может быть достаточно немного “художников” и побольше “маляров”?
  - Алексей
    
    Вы сами готовы стать маляром, вместо художника?
  - Dmitry Pavlov
    
    Конечно, никому не нужна армия “художников”. Я никакой негативной окраски в понятие “маляр” не вкладываю. Просто хочу описать ситуацию без излишних восторгов вокруг agile, чтобы было ясно (в частности тем самым молодым ребятам, которые в большинстве своем хотят быть именно “художниками”), что agile методики – не самые лучшие помощники в этом. Зато – это отличный способ быстро набраться базового опыта и познакомиться с проектной работой в команде. Что само по себе – большой плюс.
- Karina Margole
  
  Я с вами очень сильно не соглашусь. Один из основопологающих принципов гибких методик – sustainable development – то есть, методика позволяет разрабатывать проекты без вреда производительности, а также ментальному и физическому состоянию разработчиков.
  
  Более того, один из пунктов манифесто гибких методик гласит “люди и взаимодействия над инструментами и процессами”. Вся суть гибких методик в том чтобы дать разработчикам пространство для того чтобы делать наилучшую работу, постоянно развиваясь и придумывая новые, элегантные решения для все более сложных проблем.
  
  И разница между компанией которая высасывает из людей все до последней капли и той, что делает упор на развитие людей, это в том, что одна разорится через 5-10 лет, оставив за собой волну непригодных продуктов и недовольных людей; а другая будет расти и процветать много лет, развивая первоклассные решения проблем и развивая высококлассных специалистов мирового уровня.
  
  P.s. Простите за кривую терминологию. Я работаю на английском языке и не знаю как порой перевести все это на русский.
  - Dmitry Pavlov
    
    манифест – манифестом. как правило, на российском промышленном аутсорсе – все сводится к тезису “да, но нет” то есть, манифест, развитие и элегантные решения – дело хорошее, но нас (менеджмент местно аутсорс компании, менеджмент на стороне заказчика) интересуют сроки и всегда лучше ASAP (и даже еще быстрее) и минимальные затраты. на time & material – это опять сроки, а agile на fixed price – это утопия.
    - Sergey Sova
      
      Чтобы понять всю пользу Scrum и XP нужно сначала поработать по чистому Scrum и XP. А так, вы (или ваша компания) сначала изменили скрам, а потом говорите, что скрам гавно!
      - Dmitry Pavlov
        
        Я так не говорю 🙂 Это ваши слова.
        
        Методологии – и практики экстремального программирования, и скрам сами по себе – хороши и применимы в своей области применения. Так же как впрочем и ватерфол при своих условиях (устарела просто сейчас).
        
        Я говорю о том, что мне не доводилось сталкиваться самому или слышать от коллег по цеху (тех, кто имеет достаточный опыт и понимает, о чем говорит), что где-то любую из этих методологий реально применяют. Чаще всего дело кончается попытками следовать методологии в начале проекта (когда менеджмент расслаблен и впереди прекрасные прогнозы идеального проекта), а потом, когда суровая реальность в виде сроков и бюджета наваливается на менеджмент, он отдает указ команде наплевать на всякое методологическое баловство и “запилить как-нить так, побырому, чтобы всё и сразу, а иначе клиент всех распнет, а компания всех уволит”. 🙂
        
        Agile создаввался для того чтобы хоть как-то работать и пытаться управлять хаосом в этом безумном и непрогнозируемом мире. Не стоит это забывать. Это главное. И “плясать” следует не от кучки догматично изложенных в манифестах пунктах, а от реально поставленной задачи в реальных условиях, выбирая в какждый момент времени то, что даст наилучший результат и пользу. Для этого даже придумали название MVP.
- Vassili Kravtchenko-Berejnoi
  
  Мне кажется, что при правильной настройке скрам оставляет значительно больше пространства для творчества разработчика, чем негибкий процесс, и уж тем более, чем хаотичный процесс. Просто скрам направляет это творчество в несколько другое русло. А именно, из любительского в профессиональное: “сделай не так, как тебе нравится, а так, как хочет клиент.” Понять, что он хочет, помочь ему понять, что он хочет, не писать лишнего, но оставить себе место для маневра, причем только там, где оно впоследствии потребуется… Сделайте так, чтобы клиент получил, что ему нужно, и худо-бедно остался в рамках своего бюджета. Поверьте, все ваше исскуство писать коротко и красиво вам потребуется при этом в полной мере, иначе вы просто не уложитесь.
  
  А скрам вам поможет сделать именно то, что нужно. Не уйти в сторону и не возвращаться потом ценой авралов, работы ночами, стрессов, депрессий, и т.п. Ну, да про это вы и сами знаете.
- Anonymous
  
  Соглашусь с одним лишь НО. Применить можно что угодно для уничтожения. В России вы видимо часто сталкивались с продуктовыми заказчиками, которые ставили себя во главе разработки – именно это приводит к описанному вами эффекту. Это называется микроменеджмент, а по большому счету просто не профессионализм начиная с расчета бюджета на проект и заканчивая планированием каждой итерации с задней мыслью “вчера бы”.
  - Dmitry Pavlov
    
    В идеальных условия – возможно. Но идеальных условий не бывает. Я “съел много собак” и не встречал пока ни одного полностью правильно спланированного, посчитанного, реализованного и сданного проекта, ни при waterfall подходе, ни при вариациях Agile, ни в режиме outsource, ни в продуктовой разработке, ни в рамках локальной команды, ни в распределенной. Если кто встречал идеальные проекты – он либо кривит душой, либо просто пока не отдает себе отчета в том, что это не так 🙂 Я твердо верю только в один вариант проекта – когда все неидеально и криво. И работать надо учиться исходя именно из этого. Модели – это хорошо. Но реальность она аналоговая и в модели обычно не особо вписывается при ближайшем рассмотрении.
Andrey Karpovich

Напишу насчет качества перевода: спасибо, что сделали, но блин…
Среди участников перевода не нашел никого в амплуа редактор текста, и скажу, что его очень не хватало, просто до слез не хватало.

“После того как команда закончил свой мозговой штурм по поводу всех этих стикеров, они проводят “точечное голосование” для определения улучшений, которым следует уделить особое внимание в ходе следующего спринта. У каждого члена команды имеется три магнитика, которыми он может воспользоваться для голосования. Каждый член команды может лепить магнитики как ему вздумается, хоть все три сразу на одну задача.”
Illya Tsishkevich

не находит файла на русском.

Scrum и XP: заметки с передовой

Предисловие Майка Кона

Share This

Новые статьи на сайте