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)
4) Какие другие Agile элементы, best practices, свои наработки Вы используете?
4.1) Где Agile Вам кажется неприменимым и почему?
4.2) Удавалось ли Вам сочетать Agile и waterfall?
Спасибо.
16 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівТак ли уж и не позволяют? Что это за особенности, если не секрет? Если код пишется — его можно TDDить.
Несомненно, в Agile много хорошего и нужного.
Тем не менее, использование его всегда и везде порой напоминает использование лома для измерения плотонсти углескислого газа на арбите Марса.
2.2) Из всего скрама мне какраз момент с самоорганизовывающейся коммандой был непонятен. Мы этот момент совсем исключили — на планинге раздавали таски на конкретных людей, а не «на тим».
2.4) Достаточно четкое видинье менеджмента, лидов, и других «заинтересованных», или «любопытных», на каком этапе находится проэкт, чем занята команда. Без необходимости устравать дополнительные митенги.
2.5) Для начала надо промыть мозги программистам и менеджменту. Когда программисты с энтузиазмом отнесутся к «эксперементу», то все получится.
3.1) Хорошая практика, но комфортно работать далеко не с кем попало. К томуже психологически, местами, тяжолая.3.2) Не применять. У нас акцент всегда был на мощном КУА.
3.3) Вроде всем извесно, что в переработках ничего хорошего нет.
То есть я так понял надо нанять RUP-овцев дать им денег а потом забыть обо всем до сдачи проекта? Был такой Элит-центр там и проект был и туалеты. Где гарантия того что то что на бумаге это желаемый результат? Заказчик проекта обязан быть в курсе и участвовать в проекте если хочет получить результат.
Другое дело что компания-подрядчик так рисковать не хочет. Поэтому сейчас так популярна модель «боди-шопа» где клиент платит за человеко-часы.
Подрядчик в данном случае и есть проектант. Так что точно по чертежу это не значит правильно. Заказчик обычно не знает что он хочет и поэтому «чертеж» это та лапша на уши которую IT конторы вешают не разобравшись в бизнес процессах заказчика. Или я здесь единственный с опытом сдачи проектов когда заказчик говорит «да сделано по чертежу но работает не верно». А вообще, жалею что оставил комент — бесполезный холивар.
То есть когда компания нанимает людей на проект примерно на $1млн то она должна нанимать RUP/Waterfall, забыть про проект и через два года все будет ок. Это мне напоминает Элит-центр, там было все и платы и туалеты в квартирах.
1. Вы — владелец кафе. Нанимаете рабочих что бы улучшаться и расширяться. Платите им по Х килобаксов в месяц.
— Придумали сделать зал с камином — через 2 недели сделали. Посетителей прибавилось.
— Придумали сделать вело парковку — через 2 недели сделали. К вам приезжают велосипедисты.
— Придумали открыть окошко для машин — сделали. Прибыль еще возросла.
При этом вы постоянно рядом, видите как идет работа и вносите коррективы по ходу дела.
Итог: вы довольны, рабочие то же не в обиде.
2. Вы купили большую квартиру в новом районе что бы сдавать. Сами работаете по
— Спрашиваете «за сколько месяцев управитесь?». Они говорят «мы агильные и работаем итерациями — сразу все заэстимейтить не можем».
— Просите нарисовать эскизы как все будет после ремонта. Они говорят «мы агильные и полный проект не делаем».
— Они звонят вам на работу по
— Через 2 недели они приглашают Вас посмотреть как они оштукатурили стены. Вы нихрена в этом не понимаете, но рады что хоть что-то готово.
— Они спрашивают «что делать дальше»? Вы говорите что хотите светильники по периметру комнаты. Они начинают долбить штукатурку что бы проложить проводку.
— Каждые 2 недели они делают что-то еще (где-то обои, где-то плитка). При этом постоянно пределывают сделанное ранее.
— Иногда работа тормозится потому что «Вася забухал». Но это «временное снижение велосити» и на оплату не влияет.
— Так будет продолжаться месяцами, пока вы не скажите «хватит». В итоге вы получите квартиру готовую на 80%. Унитаз не поставили так как Вы им не сказали что это приоритет.
Итог: вы недовольны тем что рабочие выдоили из вас на ремонт больше бабла чем стоила пустая квартира. Рабочие довольны и ищут нового лоха.
Выводы: Agile всегда выгоден компании, которая продает «головы», но реально работает и выгоден клиенту только если он готов сам разбираться и участвовать в проекте. Так же для Agile подходят проекты где результат итераций имеет практическое применение (сделали — зарелизили — продаем). Если разрабатывается крупный продукт, который будет продаваться только целиком и через год-полтора то промежуточные результаты мало кому интересны.
Коммент месяца!
Интересны, если заказчик плохо понимает чего хочет, готов участвовать в проэкте. Даже если эти промежуточные версии не несут фин прибыли. Софт всетаки отличается от стройки.
2.2. Команда сама внезапно не самоорганизуется. Ей нужно время — это естественный процесс, так сказать, закон человеческой природы. Ей нужен правильный менеджер — чтобы ускорить все-таки, где можно ускорить. Ну и правильные люди. Из семечек баобаба вряд ли вырастут розы, как ни старайся.
2.3. Нужно узнать, к чему именно не готов клиент. Может, он боится, что ему придется много самому делать? Не думаю, что если все формальности лягут на команду, клиент будет сопротивляться. А клиента я бы, прежде всего, подводила к регулярному участию в планерках. Как минимум, раз в неделю — согласование статуса. Можно 1 на 1 без команды. Но чтобы ритм вырабатывался. А там глядишь, втянется и дальше можно вводить.
2.4. Самое большое достоинство SCRUM, на мой взгляд, — это системность ведения процесса в доступной форме. Он интуитивен. Сюда же — ритм.
3.1. К парному программированию отношусь хорошо. Приходилось самой поработать немного в такой организации — впечатлило. У себя не внедрили еще. Всему свое время.3.2. ТДД проверяет такую схему на уровне метода: тест не проходит-> кодирование->тест проходит. Если подняться на уровень выше, то можно автоматизировать такого рода проверки с помощью других типов тестов, которые уже не метод будут тестировать, а фрагмент связки. Главное, чтобы мы получали максимально быстрый ответ на вопрос — поломалось что-то в системе или нет.
3.3.40-часовая неделя — в среднем, хорошо. Я за баланс работа/личная жизнь. Или вы предлагаете работать меньше, чем 40 часов в неделю?
А вы вообще допускаете такую мысль работать больше 40 часов в неделю? Но как, если практически ни один человек не способен продуктивно работать больше3-5 часов в день?
Я как раз не склонна к перегибам во времени работы. Случается, конечно, всякое — но это форс-мажоры, а не постоянная практика. 40 часов в недели, имхо, нормальный стандарт. Он в себя включает и продуктивные часы и не очень (а они тоже всегда будут).
«Сколько вы писали эту картину?»
«15 минут. 15 минут и всю жизнь».
Не нужно подменять продуктивными5-часами весь рабочий день. Есть еще вынашивание задачи, общение с коллегами, чтение литературы, покурить, попить чаю, сходить в туалет, в конце концов. Мы же не роботы и к тому же не прямым физическим трудом занимаемся, где легче оценить продуктивность. Если помножить чистые 5 часов в день на человеческий коэффициент вот и получим грязные 8.
В среднем, повторюсь, в среднем — 8 часов работы в день позволяет сделать нормальный прогнозируемый рабочий ритм. Я вижу это так, а как вы работаете?
Еще раз перечитала вопрос. Да, конечно, допускаю работу меньше 40 часов в неделю.
Почему нет? Разные ситуации бывают. В пограничных случаях вообще может лежать много интересно. Там можно на долго увязнуть в дискуссии.
Я говорила о процессе в среднем. Я считаю, что 8 часовой рабочий день может служить нормальным эталоном.
То есть5-9.
Да, согласна. Но мне лучше видны сложности большой одноуровневой команды, чем маленькой. В маленьком сложности проще, на мой взгляд.