Pull to refresh

Comments 25

Статья хорошая, доступно все описано. Хотелось бы ещё увидеть реальные, практические примеры успешного внедрения данной методики, и если есть такая возможность, то примеры внедрения в различных условиях(ну т.е 5 разработчиков, 10 разработчиков… совмещение различных ролей и тп.).
М-м-м… Я не думаю, что есть много людей способных рассказть это в таком срезе. Термину XP чуть больше десятка лет. Скрам? Скрам, как более-менее очерченый методологический фреймворк (если вообще об этом можно стопроцентно говорить), появился года два-четыре назад. Как часть Agile методики, которая также этим словом была обозвана лет как семь, не более. Учитывая, что мало-мальский серьёзный проект занимает год и более, видимо трудно определённо говорить о большом опыте внедрении этой методологии в столь разных условиях.

Я бы сказал так — тот, кто будет это утверждать, скорее всего лукавит. :-)
Интересно, откуда такие данные?
Предлагаю пользоваться википедией — SCRUM-подход к программной разработке впервые был описан более 20 лет назад!!! Кому стало интересно — за подробностями: en.wikipedia.org/wiki/Scrum_(development)#History (ссылка бьется парсером, для достоверного воспроизведения авторского замысла пользуйте копи-паст :] )

В свете этих обстоятельств логично предположить что XP-методология строилась уже от опыта использования SCRUM
По той же википедии самый важный пункт — это:
«In 2001 Schwaber teamed up with Mike Beedle to write up the method in the book Agile Software Development with SCRUM.»
Именно примерно с 2001-2002 началось массовое увлечение SCRUM, а до этого были только одиночные команды, поэтому нельзя говорить, что SCRUM-у уже 20 лет. 20 лет первому упоминанию, но 5-6 лет началу массового использования.
Это одна из самых молодых методологий сейчас.
Так же очень интересно внедрил ли кто-нибудь подобное для разработки сайтов. У нас в компании используется технология водопада. И я не представляю, как создание сайта можно превратить в несколько параллельных этапов т.к. измененный дизайн надо переверстывать и переподключать. К примеру, программировать функции можно ещё когда дизайн не нарисован, если знать хорошо, что будет представлять новый модуль и когда придет верстка «натянуть» на свой функционал. А вот верстать заранее никак нельзя пока не будет нарисован макет =(.
Отличная статья, спасибо автору!
Как человек, имевший практику scrum, хотел бы добавить несколько пунктов:

*) Scrum Board и Sprint Burndown chart
Очень важно для команды видеть текущее положение дел в спринте. Для этого просто необходимо иметь доску с текущими задачами. И не стОит пренебрегать графиком, чтоб избегать в дальнейшем всяких факапов.

*) Bug fixing
Один из возможных факапов, который практически всегда растягивает спринт. В этом случае имеет смысл выделить отдельную команду (2-3 человека) и ввести для них отдельный спринт длительностью 1 день. Для всеобщей вовлеченности можно менять людей от спринта к спринту между командами девелоперов и баг-фиксеров.
Для такой команды правила scrum могут (и, наверное, должны) быть подкорректированны.

*) wow-фактор
Также может выбить из итерации фактор «начальника». Когда итерация уже запланирована и идет на всех порах, неожиданно появляется «начальник» и со звездами в глазах начинает «впаривать» про то, что Product Team накреативила новую фичу, которую обязательно нужно сделать «вчера». Без нее бизнес встанет, бонусы урежутся, да и вообще всё пойдет к чертям.
Такие факапы надо сразу (коллективным разумом) перенаправлять к Product Owner'у, чтобы тот обяснил «начальнику» всю его неправоту вмешательства в спринт. Команда — ответственный организм. Она подписалась под задачами — она их должна выполнить полностью и в срок.
И все-таки я не могу понять, как для багфиксинга можно выделять 1 день. Конечно можно подтянуть 2-3 более-менее серьезных бага, но достаточно запутанные баги таким образом не выловить. Для этого нужно провести в дебагере 3-4 дня. Не будет ли подобный подход к багфиксингу способствовать тому, что достаточно серьезные баги будут кочевать из итерации в итерацию, т.е. из релиза в релиз?
я такие вещи просто в спринт ставлю, в какой — зависит от Product owner-a, зачем отдельный спринт выделять не понятно?!
Автор — молодец, хотя его статьям не хватает немного «взгляда с той стороны», т.к. похоже сам SCRUM он не использовал.
Добавлю:

>>Я часто сталкиваюсь с другой классификацией, когда XP называют Agile методологией. Сложно сказать…
XP — безусловно Agile, т.к. проповедует ту же гибкость. Но большой плюс XP — это набор конкретных артефактов, как достич гибкости и производительности. Минус — мало артефактов, как заставить команду быть командой. А это то, чему много внимания удалено в SCRUM.

>>… Долгий такой митинг. Часа на три…
Не забываем, что SCRUM — это Agile. После первого же митинга на 3 часа все напишут письма, что им такие митинги не нужны и следующий будет уже полчаса.
У нас сейчас daily meeting (ежедневный митинг) 5-15 минут, изредка до получаса, если что-то интересное обсуждаем.
Montly meeting (ежемесячный митинг) — 30-60 минут.
Montly Retrospective (когда команда раз в месяц собирается и обсуждает спринт) — это у нас долго проходит, т.к. мы ходим в кафе и едим и пьем пиво за счет работодателя. И там уже обсуждаем :)

>> Долгий такой митинг. Часа на три. И на нём решается, какие пункты (stories) попадут в реализацию на текущий забег. И формируется второй список – Sprint backlog.

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

Ну и самое главное в конце:
SCRUM — это чуть ли не единственная методология, которая направлена на развитие команды и постоянную поддержку командного духа. Именно команда и ее мотивация — это главный инструмент SCRUM. Все остальное — это только почва и инструменты для того, чтобы мотивировать команду на работу.
А если команда мотивирована, то она сама всё сделает максимально хорошо и быстро.
стараюсь использовать именно эту технологию. Не знал что она существует и формализованна. Не пишем код, занимаемся аналитикой и написанием всякох отчетов по экономике. С утра короткий митинг, в 11 обсуждение за кофе. Вечером подведение итогов.
Большое спасибо за статью. Очень интересно и познавательно.
Ну а теперь дам повод покидаться минусами.

На мой взгляд все это большой блеф.
Ребята придумали название для очевидных вещей и теперь зарабатывают на этом деньги.

Вспомните AJAX.
Он был. Он был еще до того как появилось название AJAX.
Однако, когда этой технике присвоили название, появились мастера, тренера, конференции и т.д. и т.п. по этой тематике.

То же самое и с Agile.
Очевидным и самым естественным вещам присваивают название, пиарят это название, выдают за что-то новое.
Вот скоро будет очередная коференция по Agile.
Компании попробуют применить это у себя.
Будут радоваться и кричать «А мы работаем по Agile!». Гордиться этим.

Но никто не хочет понимать что это у вас уже есть. Это наиболее естественный процесс построения работы.
Да, есть такое :)
Про Scrum слышу первый раз, хотя последние года 3 работаю по очень похожей схеме.
С разными командами/конторами/заказчиками по разному, но направление именно «естественный процесс построения работы» :)

Отчасти с Вами согласен. Но лишь отчасти. Да, все мы умные и все мы и так все знаем и не учите нас работать.=) Напридумывали тут.=) Да, и раньше у команды был начальник (не важно как его называли) и заказчик, да, и раньше собирались с пивом или на крайняк с кофе побеседовать о тонкостях проекта и чето порешать. Но пока это все не приобретает системность и испорченность, получить от подхода максимальную эффективность не получится.
Т.е. пока кто-то главный не скажет «мы работаем по Agile (или другой методологии), а это значит то, то и это..» толку от разработки будет довольно мало.
То же самое, как мне кажется, и в других областях, хотя, наверное, и не во всех.
Agile/Scrum — естественные и очевидные процессы с точки зрения разработчика. Подумал, сделал, проверил — и так много раз в день. А вот для заказчика/менеджера это принципиально новый подход. И пиар, мастера, тренера, конференции — расчитаны на них, на то что б изменить их «сознание».
На мой взгляд, XP — постулирует основополагающие прнципы.
В целом можно устать от таких забегов. Это может подойти если вся команда сангвиники или холлерики, оных просто это не устроит. Либо нужна особая уличная магия для особой мотивации. тут как было видо с конференции и там был пример как команда разрабатывала БД для десткого дома за бесплатно в не рабочее время и с большим энтузиазмом. Для описанного выше это очень понадобыиться.
Мне кажется, дело в том, что Вы немного не верно поняли слово Спринт. Это не значит, что в этот страшный период все разработчики должны рвать себе попы (простите за мой французкий). Все работают спокойно и в нормальном режиме. Добиться такого нормального процесса разработки без нервов и авралов — как раз и задача продукт манагера. А если ставить нереальные таски на спринты — это и правда всем очень быстро надоест…
Очень приятная статья, хорошо и живо написана! Задумался о применении подобной методологии в далеких от разработки областях…
Интересно, как в Скраме работают с stories, которые занимают больше 1-ого витка разработки (например 5 недель). Очевидно, что должно быть какое-то двухвитковое планирование или типа того…
Важно создать подробный Product Backlog, а большие таски разбить на субтаски. Поэтому если нужно написать как-то крупный модуль, но важно иметь список всех шагов к выполнению, оценить их по времени и взять на Ваши 5 недель такое количество, которое предположительно можете успеть. Тут самое тонкое место — это оценка времени, потому что задачи есть разные и разные учасники одну и ту же задачу могут сделать потратив разное время. Для этого устраивается во время планирования спринта planning poker, который позволит более-менее достоверно оценить временной промежуток для конкретной задачи. Если важно не брать слишком много задач, а брать столько, сколько сможете реально сделать. Тоесть использовать принцип «Взятые таски должны быть сделаны качественно на 100% „. Этот принцип позволит выполнять разработку последовательно и не возвращаться к написанному коду в будущем.
Статья прекрасна! Мне понравилась) Хотелось бы увидеть в дальнейшем развитие этой темы, а также может какие-нибудь приемы, позволяющие укрепить команду) Ну и вообще хорошо было бы услышать пример использования этой методологии в жизни.)
Еще, как мне кажется, важный момент. При планирование, нужно учитывать, что оценки по времени выполнения больше 1-го дня, не есть гут и нужно разбивать на подтаски. Во-первых избавляемся от студенческого синдрома, во-вторых у любого члена команды, каждый день есть обоснованное ощущение, что все движется в перед.
Шикарно написано, читается на одном дыхании, спасибо! Хоть нашел наконец, что такое спринт по-русски!))
Sign up to leave a comment.

Articles