SCRUM, XP и реальность. Куда бежать?

Доброго времени суток!

В своей статье Алексей Кривицкий даёт превосходное введение в SCRUM
dou.ua/...les/scrum-for-developers

Однако на практике обычно возникает много вопросов, требующих немедленных и правильных ответов.
Хочу задать несколько вопросов.

1) Организационные вопросы.
1.1) Если у кого-то есть подобные вопросы — пишите в комментарях.
Постараюсь их добавить в тело топика.
1.2) Также оставляю за собой право добавлять вопросы по мере обсуждения.
1.3) Особенно интересуют ответы из практики.
Просьба свести в минимуму теоретические рассуждения и священные «войны».
1.4) Все приведённые мной вопросы обобщенные и все совпадения с реальными ситуациями случайны.
1.5) Здесь не обсуждается, «SCRUM + XP = хорошо или плохо?». Здесь обсуждаются практические примеры того,
как что-то из вышеупомянутого у кого-то получилось или нет. И почему.

2) SCRUM — это строго определённый framework. Еcли нет хоть одного из обязательных компонентов — это уже
не SCRUM. И всё же... Какие компоненты SCRUM могут быть полезны в таком случае?
Просьба поделиться опытом.
2.1) В команде меньше 5 человек.
2.2) Команда не самоорганизуюшаяся.
2.3) Клиент не готов к ведению SCRUM.
2.4) В чём, на Ваш взгляд, наибольшее достоинство Scrum?
2.5) Как вы начинали внедрять SCRUM (или SCRUM-like)?
2.6) Есть ли у кого-то негативный опыт внедрения SCRUM? Каковы причины?
Какие выводы Вы для себя сделали?

3) Какие элементы XP Вы используете или нет. Почему?
3.1) Что Вы думаете о парном программировании?
3.2) Что делать, если технологические особенности проекта не
позволяют применять TDD?
3.3) 40-часовая рабочая неделя — всегда ли это хорошо?

4) Какие другие Agile элементы, best practices, свои наработки Вы используете?
4.1) Где Agile Вам кажется неприменимым и почему?
4.2) Удавалось ли Вам сочетать Agile и waterfall?

Спасибо.

Теми: Scrum, waterfall, XP

Ctrl + Enter

Mykola Gurov тролль 12.02.2012 22:28

3.2) Что делать, если технологические особенности проекта не
позволяют применять TDD?

Так ли уж и не позволяют? Что это за особенности, если не секрет? Если код пишется — его можно TDDить.

Відповісти

Підтримати

Denis Muratov 12.02.2012 19:15

Несомненно, в Agile много хорошего и нужного.

Тем не менее, использование его всегда и везде порой напоминает использование лома для измерения плотонсти углескислого газа на арбите Марса.

Grez 10.02.2012 18:28

2.1) Зависит от условий задачи. Почти всегда полезны были: бек-лог в той или иной форме, итерейшн планинги, дейли митенги.
2.2) Из всего скрама мне какраз момент с самоорганизовывающейся коммандой был непонятен. Мы этот момент совсем исключили — на планинге раздавали таски на конкретных людей, а не «на тим».
2.4) Достаточно четкое видинье менеджмента, лидов, и других «заинтересованных», или «любопытных», на каком этапе находится проэкт, чем занята команда. Без необходимости устравать дополнительные митенги.

2.5) Для начала надо промыть мозги программистам и менеджменту. Когда программисты с энтузиазмом отнесутся к «эксперементу», то все получится.

3.1) Хорошая практика, но комфортно работать далеко не с кем попало. К томуже психологически, местами, тяжолая.
3.2) Не применять. У нас акцент всегда был на мощном КУА.

3.3) Вроде всем извесно, что в переработках ничего хорошего нет.

Denis Pavlov 10.02.2012 16:59

он готов сам разбираться и участвовать в проекте.

То есть я так понял надо нанять RUP-овцев дать им денег а потом забыть обо всем до сдачи проекта? Был такой Элит-центр там и проект был и туалеты. Где гарантия того что то что на бумаге это желаемый результат? Заказчик проекта обязан быть в курсе и участвовать в проекте если хочет получить результат.

Beaver Green 10.02.2012 18:25

Заказчик как раз ничего не обязан. Обязан подрядчик, который подписался выполнить проект точно в срок по чертежу. Не выполнил — оплати неустоечку. Вот и гарантия.

Другое дело что компания-подрядчик так рисковать не хочет. Поэтому сейчас так популярна модель «боди-шопа» где клиент платит за человеко-часы.

Denis Pavlov

Denis Pavlov 10.02.2012 20:06

Подрядчик в данном случае и есть проектант. Так что точно по чертежу это не значит правильно. Заказчик обычно не знает что он хочет и поэтому «чертеж» это та лапша на уши которую IT конторы вешают не разобравшись в бизнес процессах заказчика. Или я здесь единственный с опытом сдачи проектов когда заказчик говорит «да сделано по чертежу но работает не верно». А вообще, жалею что оставил комент — бесполезный холивар.

Beaver Green

Denis Pavlov 10.02.2012 16:55

То есть когда компания нанимает людей на проект примерно на $1млн то она должна нанимать RUP/Waterfall, забыть про проект и через два года все будет ок. Это мне напоминает Элит-центр, там было все и платы и туалеты в квартирах.

Beaver Green 10.02.2012 15:41

Аналогии из жизни где подходит и не подходит Agile:
1. Вы — владелец кафе. Нанимаете рабочих что бы улучшаться и расширяться. Платите им по Х килобаксов в месяц.
— Придумали сделать зал с камином — через 2 недели сделали. Посетителей прибавилось.
— Придумали сделать вело парковку — через 2 недели сделали. К вам приезжают велосипедисты.
— Придумали открыть окошко для машин — сделали. Прибыль еще возросла.
При этом вы постоянно рядом, видите как идет работа и вносите коррективы по ходу дела.
Итог: вы довольны, рабочие то же не в обиде.
2. Вы купили большую квартиру в новом районе что бы сдавать. Сами работаете по 8-10 часов на работе. Наняли рабочих делать ремонт. Платите им по Х килобаксов в месяц.
— Спрашиваете «за сколько месяцев управитесь?». Они говорят «мы агильные и работаем итерациями — сразу все заэстимейтить не можем».
— Просите нарисовать эскизы как все будет после ремонта. Они говорят «мы агильные и полный проект не делаем».
— Они звонят вам на работу по 2-3 раза в день и срашивают «как лучше сделать — так или этак?». Вы их посылаете и просите не звонить днем.
— Через 2 недели они приглашают Вас посмотреть как они оштукатурили стены. Вы нихрена в этом не понимаете, но рады что хоть что-то готово.
— Они спрашивают «что делать дальше»? Вы говорите что хотите светильники по периметру комнаты. Они начинают долбить штукатурку что бы проложить проводку.
— Каждые 2 недели они делают что-то еще (где-то обои, где-то плитка). При этом постоянно пределывают сделанное ранее.
— Иногда работа тормозится потому что «Вася забухал». Но это «временное снижение велосити» и на оплату не влияет.
— Так будет продолжаться месяцами, пока вы не скажите «хватит». В итоге вы получите квартиру готовую на 80%. Унитаз не поставили так как Вы им не сказали что это приоритет.
Итог: вы недовольны тем что рабочие выдоили из вас на ремонт больше бабла чем стоила пустая квартира. Рабочие довольны и ищут нового лоха.

Выводы: Agile всегда выгоден компании, которая продает «головы», но реально работает и выгоден клиенту только если он готов сам разбираться и участвовать в проекте. Так же для Agile подходят проекты где результат итераций имеет практическое применение (сделали — зарелизили — продаем). Если разрабатывается крупный продукт, который будет продаваться только целиком и через год-полтора то промежуточные результаты мало кому интересны.

Kirill Zotin 10.02.2012 16:29

Коммент месяца!

Grez 10.02.2012 18:10

Если разрабатывается крупный продукт, который будет продаваться только целиком и через год-полтора то промежуточные результаты мало кому интересны.

Интересны, если заказчик плохо понимает чего хочет, готов участвовать в проэкте. Даже если эти промежуточные версии не несут фин прибыли. Софт всетаки отличается от стройки.

Diana Timoshenko Project Manager в Iveonik Systems 09.02.2012 23:21

2.1. Если в команде меньше 5 человек, то, как по мне, меньше — не больше. Труднее с 10+ в одной команде, чем меньше 5. А какие именно у вас проблемы с маленькой командой?
2.2. Команда сама внезапно не самоорганизуется. Ей нужно время — это естественный процесс, так сказать, закон человеческой природы. Ей нужен правильный менеджер — чтобы ускорить все-таки, где можно ускорить. Ну и правильные люди. Из семечек баобаба вряд ли вырастут розы, как ни старайся.
2.3. Нужно узнать, к чему именно не готов клиент. Может, он боится, что ему придется много самому делать? Не думаю, что если все формальности лягут на команду, клиент будет сопротивляться. А клиента я бы, прежде всего, подводила к регулярному участию в планерках. Как минимум, раз в неделю — согласование статуса. Можно 1 на 1 без команды. Но чтобы ритм вырабатывался. А там глядишь, втянется и дальше можно вводить.

2.4. Самое большое достоинство SCRUM, на мой взгляд, — это системность ведения процесса в доступной форме. Он интуитивен. Сюда же — ритм.

3.1. К парному программированию отношусь хорошо. Приходилось самой поработать немного в такой организации — впечатлило. У себя не внедрили еще. Всему свое время.
3.2. ТДД проверяет такую схему на уровне метода: тест не проходит-> кодирование->тест проходит. Если подняться на уровень выше, то можно автоматизировать такого рода проверки с помощью других типов тестов, которые уже не метод будут тестировать, а фрагмент связки. Главное, чтобы мы получали максимально быстрый ответ на вопрос — поломалось что-то в системе или нет.

3.3. 40-часовая неделя — в среднем, хорошо. Я за баланс работа/личная жизнь. Или вы предлагаете работать меньше, чем 40 часов в неделю?

Bubo bubo 09.02.2012 23:59

А вы вообще допускаете такую мысль работать больше 40 часов в неделю? Но как, если практически ни один человек не способен продуктивно работать больше 3-5 часов в день?

Diana Timoshenko

Diana Timoshenko Project Manager в Iveonik Systems 10.02.2012 10:15

Я как раз не склонна к перегибам во времени работы. Случается, конечно, всякое — но это форс-мажоры, а не постоянная практика. 40 часов в недели, имхо, нормальный стандарт. Он в себя включает и продуктивные часы и не очень (а они тоже всегда будут).

«Сколько вы писали эту картину?»
«15 минут. 15 минут и всю жизнь».

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

В среднем, повторюсь, в среднем — 8 часов работы в день позволяет сделать нормальный прогнозируемый рабочий ритм. Я вижу это так, а как вы работаете?

Bubo bubo

Diana Timoshenko Project Manager в Iveonik Systems 10.02.2012 10:21

Еще раз перечитала вопрос. Да, конечно, допускаю работу меньше 40 часов в неделю.
Почему нет? Разные ситуации бывают. В пограничных случаях вообще может лежать много интересно. Там можно на долго увязнуть в дискуссии.
Я говорила о процессе в среднем. Я считаю, что 8 часовой рабочий день может служить нормальным эталоном.

Mykola Bova Java Architect Developer в GroupBy 10.02.2012 14:28

2.1. Если в команде меньше 5 человек, то, как по мне, меньше — не больше. Труднее с 10+ в одной команде, чем меньше 5. А какие именно у вас проблемы с маленькой командой?

По классическому SCRUM должно быть 7+/-2 человека.

То есть 5-9.

Diana Timoshenko Project Manager в Iveonik Systems 10.02.2012 16:21

Да, согласна. Но мне лучше видны сложности большой одноуровневой команды, чем маленькой. В маленьком сложности проще, на мой взгляд.

Mykola Bova

SCRUM, XP и реальность. Куда бежать?

Схожі топіки

16 коментарів

Підписатись на коментарі

Новини