Сообщение #1
03 июля 2016, 01:33
|
Agile, который вначале радует, а затем вызывает депрессию
На дворе был лихой 2007-й год
Примерно в это же время некоторые IT-компании Украины начали перенимать западный опыт и внедрять на своих проектах новую методологию разработки софта — Agile (aka «методика гибкого увертня-программиста»).
Вся наша команда гордо собиралась каждый день в 11 утра на SCRUM-митинге, где каждый рассказывал о текущем положении дел и о том, что он планирует за сегодня сделать. Эти собрания обычно занимали не больше 10-15 минут, но к ним также нужно было хоть немного подготовиться. Тем более что заказчики — швейцарцы, а значит, общение на английском. То есть ещё минимум 5-10 минут уходило на то, чтобы прикинуть, о чём говорить. Но чаще всего накануне возникал какой-нибудь аврал, и утром нечем было похвастаться. А значит, для подготовки к SCRUM-митингу нужно было еще больше времени, чтоб объяснить причины своего не такого бравого продвижения в работе. В итоге вся эта эпопея с номинально короткими собраниями занимала от получаса реального времени.
Но нам нравилось. Все эти разноцветные листочки для каждой задачи, с написанными поверх них именами и количеством часов, эстимейшн покер, парное программирование, минимум документации и такой боевой темп с реально работающим прототипом продукта — это всё привлекало. Мы так поверили в Agile и SCRUM, что пару человек из нашей команды даже заказали себе домой по SCRUM-доске из пробки.
XP
Что касается экстремального программирования, то народная мудрость гласит — «безопасную вещь экстремальной не назовут». Короткие циклы «деливери» — это экстремально, да, но насколько оправданно? Одно дело, если релиз происходит каждые две недели, или раз в месяц, но ведь бывают и крайности. Например, я знаю одну геймдев компанию, где релиз происходит чуть ли не каждый вечер. То ли у них очень недоверчивый клиент, то ли они хотят стимулировать сотрудников ежедневно пушить свою работу, чтобы было видно, кто над чем работает — сложно сказать. И вот каждый день они выделяют одного человека — билд-инженера, который занимается сборкой. А программисты, конечно же, по полдня занимаются проверкой своего кода, который вечером пойдёт в продакшн. Клиент доволен — у него реал-тайм картинка ситуации на проекте и работающий код. Но сколько лишних телодвижений делают при этом программисты и тестировщики? Лично я бы предпочёл один раз принести одно тяжелое ведро воды, чем сто раз ходить за водой с кружкой в руке.
TDD
Оно у нас на проекте было скорее номинальным. То есть, сначала мы писали функционал и тестили его, и только затем покрывали его тестами. Я так и не приловчился мыслить и работать согласно принципам TDD, то есть никогда не начинаю с тестов, поэтому мне сложно судить о положительных и негативных сторонах TDD. Могу лишь предположить, что истина, как всегда, находится где-то посередине. Но для нас, зелёных юнцов, написание тестов было в радость, особенно когда загоралась зелёная полоска.
Парное программирование
Парное программирование не могло не вызывать восторг. Во-первых, вдвоём думается быстрее, да и вторая пара глаз довольно эффективно ловит орфографические и логические ошибки в коде. Во-вторых, нет лучше способа подтянуть человека в программировании, чем посадить его в пару с более опытным разработчиком и научить его думать по-другому. Мы с удовольствием пользовались этой возможностью поучиться друг у друга, потому как если бы не Agile и XP, начальство смотрело бы на нас как на тунеядцев. Но разве для парного программирования так уж обязательно брать на вооружение XP?
Когда я более чем год назад пришёл на новую работу, то с удивлением обнаружил, что никто там не молится на Agile. Более того, разработка велась в классическом Waterfall. И в то же время я регулярно видел случаи парного программирования. Ребята не стеснялись никого, а наши мудрые начальники наоборот поощряли работу в связке. Так что совсем не обязательно слепо следовать популярным методологиям в разработке софта, когда можно взять для себя лишь самое полезное и необходимое.
Agile почти рифмуется с «выгорай»
Но недели сменились месяцами, и мы начали ощущать на себе некоторое «выгорание». Дело в том, что какой бы идеальной ни была методология — всегда будут вылезать незапланированные баги, которые требуют больше времени, чем планируется. Чтоб латать все эти дыры и в понедельник выглядеть так, будто у тебя всё идеально, приходилось работать на выходных. Почти ежедневные овертаймы даже не обсуждались — каждый думал над тем, что ему нужно будет говорить на следующий день на SCRUM-митинге. И ситуация была такова, что никто не хотел выглядеть на собрании «слабаком». Поэтому каждый старался побольше сделать вечером и пораньше прийти на работу, чтобы успеть к 11 что-то закончить и сказать что-нибудь в духе — «Этот функционал готов, но его нужно потестить» или «Новый сервис работает, но у меня не было времени его полностью проверить». И звучит вроде бы хорошо — что-то работает, что-то готово, что-то функционирует, осталась лишь мелочь, ерунда — потестить.
Мы как будто собирали «лайки» от заказчиков. Им нравилось, что у нас дело спорится и вертится. Мы, будучи зелёными студентами, ловили их одобрительные кивки и вдохновлялись работать дольше, больше, лучше. Но в этой погоне за словами «я это сделал» и «оно работает» всегда скрывалось и кое-что другое — множество хвостов, и накапливающаяся из-за стресса вечных дедлайнов усталость. Почти никогда не бывало так, чтоб можно было перевести дух и работать в обычном режиме. Завтра митинг, в пятницу релиз. Так шли месяцы, пока проект наконец не закончился и мы не слезли с Agile-иглы.
И хотя я в будущем встречал Agile и в менее фанатичной форме, мы с друзьями пришли к выводу, что Agile — это фактически белко-колёсное предприятие, которое ориентируется в первую очередь на клиента, загоняя при этом своих сотрудников в утомительные циклы регулярного «деливери». Так или иначе, я сделал скидку на своё личное пресыщение этой методологией и успешно позабыл об Agile на несколько лет. До вчерашнего дня.
Ложка дёгтя в виде 10 минут SCRUM-митинга
Вчера я встретил Антона — разработчика одной киевской IT-компании, который, хоть и не пил алкогольного, но был в подавленном состоянии. Я начал расспрашивать его о жизни и о работе. Оказалось, что в жизни всё неплохо. На работе тоже всё хорошо. Кроме одного. И тут я услышал давно забытое слово «Agile». Антон — весьма общительный молодой человек, еще студент, при этом прекрасно справляется со своей работой. От чего же его удручает Agile? Почему его не радует работа так, как могла бы? Оказывается, дело в банальных собраниях. Но каким образом всего лишь 10-минутный SCRUM-митинг может отравлять программисту жизнь?
Может, у Антона всего лишь обострённое чувство рациональности? Что, если он понимает, что митинги — как маленький театр, где каждый играет свою роль? Что если он, как и я, не любит участвовать в этой гонке «я сделал больше всех» и «я единственный из команды, кто реализовал такой сложный функционал» (особенно если это удаётся далеко не всегда)? А может, всё дело в том, что не бывает ежедневных собраний по расписанию, без которых — совсем никак. Ведь все это понимают. SCRUM-митинги больше напоминают бюрократический ритуал, чем насущную необходимость. Для галочки. Чтоб на встречах с клиентами гордо говорить о том, что, мол, «У нас всё в топленом шоколаде — по канонам Agile и SCRUM». Может, весь этот Agile существует для того, чтобы держать сотрудников в ежовых рукавицах, давить из них соки и поить им клиентов? Хотелось бы верить, что есть и более гуманные способы поднять продуктивность.
Поэтому интересно ваше мнение:
Примерно в это же время некоторые IT-компании Украины начали перенимать западный опыт и внедрять на своих проектах новую методологию разработки софта — Agile (aka «методика гибкого увертня-программиста»).
Вся наша команда гордо собиралась каждый день в 11 утра на SCRUM-митинге, где каждый рассказывал о текущем положении дел и о том, что он планирует за сегодня сделать. Эти собрания обычно занимали не больше 10-15 минут, но к ним также нужно было хоть немного подготовиться. Тем более что заказчики — швейцарцы, а значит, общение на английском. То есть ещё минимум 5-10 минут уходило на то, чтобы прикинуть, о чём говорить. Но чаще всего накануне возникал какой-нибудь аврал, и утром нечем было похвастаться. А значит, для подготовки к SCRUM-митингу нужно было еще больше времени, чтоб объяснить причины своего не такого бравого продвижения в работе. В итоге вся эта эпопея с номинально короткими собраниями занимала от получаса реального времени.
Но нам нравилось. Все эти разноцветные листочки для каждой задачи, с написанными поверх них именами и количеством часов, эстимейшн покер, парное программирование, минимум документации и такой боевой темп с реально работающим прототипом продукта — это всё привлекало. Мы так поверили в Agile и SCRUM, что пару человек из нашей команды даже заказали себе домой по SCRUM-доске из пробки.
XP
Что касается экстремального программирования, то народная мудрость гласит — «безопасную вещь экстремальной не назовут». Короткие циклы «деливери» — это экстремально, да, но насколько оправданно? Одно дело, если релиз происходит каждые две недели, или раз в месяц, но ведь бывают и крайности. Например, я знаю одну геймдев компанию, где релиз происходит чуть ли не каждый вечер. То ли у них очень недоверчивый клиент, то ли они хотят стимулировать сотрудников ежедневно пушить свою работу, чтобы было видно, кто над чем работает — сложно сказать. И вот каждый день они выделяют одного человека — билд-инженера, который занимается сборкой. А программисты, конечно же, по полдня занимаются проверкой своего кода, который вечером пойдёт в продакшн. Клиент доволен — у него реал-тайм картинка ситуации на проекте и работающий код. Но сколько лишних телодвижений делают при этом программисты и тестировщики? Лично я бы предпочёл один раз принести одно тяжелое ведро воды, чем сто раз ходить за водой с кружкой в руке.
TDD
Оно у нас на проекте было скорее номинальным. То есть, сначала мы писали функционал и тестили его, и только затем покрывали его тестами. Я так и не приловчился мыслить и работать согласно принципам TDD, то есть никогда не начинаю с тестов, поэтому мне сложно судить о положительных и негативных сторонах TDD. Могу лишь предположить, что истина, как всегда, находится где-то посередине. Но для нас, зелёных юнцов, написание тестов было в радость, особенно когда загоралась зелёная полоска.
Парное программирование
Парное программирование не могло не вызывать восторг. Во-первых, вдвоём думается быстрее, да и вторая пара глаз довольно эффективно ловит орфографические и логические ошибки в коде. Во-вторых, нет лучше способа подтянуть человека в программировании, чем посадить его в пару с более опытным разработчиком и научить его думать по-другому. Мы с удовольствием пользовались этой возможностью поучиться друг у друга, потому как если бы не Agile и XP, начальство смотрело бы на нас как на тунеядцев. Но разве для парного программирования так уж обязательно брать на вооружение XP?
Когда я более чем год назад пришёл на новую работу, то с удивлением обнаружил, что никто там не молится на Agile. Более того, разработка велась в классическом Waterfall. И в то же время я регулярно видел случаи парного программирования. Ребята не стеснялись никого, а наши мудрые начальники наоборот поощряли работу в связке. Так что совсем не обязательно слепо следовать популярным методологиям в разработке софта, когда можно взять для себя лишь самое полезное и необходимое.
Agile почти рифмуется с «выгорай»
Но недели сменились месяцами, и мы начали ощущать на себе некоторое «выгорание». Дело в том, что какой бы идеальной ни была методология — всегда будут вылезать незапланированные баги, которые требуют больше времени, чем планируется. Чтоб латать все эти дыры и в понедельник выглядеть так, будто у тебя всё идеально, приходилось работать на выходных. Почти ежедневные овертаймы даже не обсуждались — каждый думал над тем, что ему нужно будет говорить на следующий день на SCRUM-митинге. И ситуация была такова, что никто не хотел выглядеть на собрании «слабаком». Поэтому каждый старался побольше сделать вечером и пораньше прийти на работу, чтобы успеть к 11 что-то закончить и сказать что-нибудь в духе — «Этот функционал готов, но его нужно потестить» или «Новый сервис работает, но у меня не было времени его полностью проверить». И звучит вроде бы хорошо — что-то работает, что-то готово, что-то функционирует, осталась лишь мелочь, ерунда — потестить.
Мы как будто собирали «лайки» от заказчиков. Им нравилось, что у нас дело спорится и вертится. Мы, будучи зелёными студентами, ловили их одобрительные кивки и вдохновлялись работать дольше, больше, лучше. Но в этой погоне за словами «я это сделал» и «оно работает» всегда скрывалось и кое-что другое — множество хвостов, и накапливающаяся из-за стресса вечных дедлайнов усталость. Почти никогда не бывало так, чтоб можно было перевести дух и работать в обычном режиме. Завтра митинг, в пятницу релиз. Так шли месяцы, пока проект наконец не закончился и мы не слезли с Agile-иглы.
И хотя я в будущем встречал Agile и в менее фанатичной форме, мы с друзьями пришли к выводу, что Agile — это фактически белко-колёсное предприятие, которое ориентируется в первую очередь на клиента, загоняя при этом своих сотрудников в утомительные циклы регулярного «деливери». Так или иначе, я сделал скидку на своё личное пресыщение этой методологией и успешно позабыл об Agile на несколько лет. До вчерашнего дня.
Ложка дёгтя в виде 10 минут SCRUM-митинга
Вчера я встретил Антона — разработчика одной киевской IT-компании, который, хоть и не пил алкогольного, но был в подавленном состоянии. Я начал расспрашивать его о жизни и о работе. Оказалось, что в жизни всё неплохо. На работе тоже всё хорошо. Кроме одного. И тут я услышал давно забытое слово «Agile». Антон — весьма общительный молодой человек, еще студент, при этом прекрасно справляется со своей работой. От чего же его удручает Agile? Почему его не радует работа так, как могла бы? Оказывается, дело в банальных собраниях. Но каким образом всего лишь 10-минутный SCRUM-митинг может отравлять программисту жизнь?
Может, у Антона всего лишь обострённое чувство рациональности? Что, если он понимает, что митинги — как маленький театр, где каждый играет свою роль? Что если он, как и я, не любит участвовать в этой гонке «я сделал больше всех» и «я единственный из команды, кто реализовал такой сложный функционал» (особенно если это удаётся далеко не всегда)? А может, всё дело в том, что не бывает ежедневных собраний по расписанию, без которых — совсем никак. Ведь все это понимают. SCRUM-митинги больше напоминают бюрократический ритуал, чем насущную необходимость. Для галочки. Чтоб на встречах с клиентами гордо говорить о том, что, мол, «У нас всё в топленом шоколаде — по канонам Agile и SCRUM». Может, весь этот Agile существует для того, чтобы держать сотрудников в ежовых рукавицах, давить из них соки и поить им клиентов? Хотелось бы верить, что есть и более гуманные способы поднять продуктивность.
Поэтому интересно ваше мнение:
- Нравится ли вам Agile? Насколько эффективен этот подход к разработке?
- Как вы относитесь к SCRUM-митингам?
- Какую методологию вы использовали бы (или используете) в своём стартапе?