Тема, о которой буду говорить, крайне неоднозначная. Предвижу нехилый холивар по этому поводу, если, конечно, статья заинтересует кого-то. Прежде, чем перейти непосредственно к чтению, взгляните ещё раз на заголовок и на его последнее слово. И не нужно говорить, что я не прав. Я и сам знаю, что многие со мной не согласятся. Да и цели у меня такой нет. Итак…
За мою короткую карьеру, если её можно так назвать, разработчика, удалось поработать в разных (дело не только в названиях) организациях. Все мы время от времени меняем работу, кто-то чаще, кто-то реже. Естественно, мы сравниваем их между собой по каким-то критериям, выставляем субъективные или не очень оценки. Для себя. Для своего будущего. Делаем выводы. Расстраиваемся или радуемся. Через несколько месяцев после смены работы опять начинаем сравнивать своё текущее место с предыдущим. Порой в голову проникают мысли, мол, зря это было. На старой работе было всё-таки здорово, хоть и платили меньше. Зато уже всех знал, мог выйти в центр офиса и сказать что-то вроде “да пошло оно всё, к черту дедлайны, имел я вашу работу”. Пойти перекурить тире попить чай, снова сесть за компьютер, нехило так поовертаймить и успешно закончить свой кусок.
Все мы знаем, что часто задачи ставятся примерно так:
Я очень рад, что увидел этот баян-бабаян совсем недавно. Это значит, что именно я столкнулся со столь академическим идиотизмом достаточно поздно в своей жизни и всецело благодарен ей за это. Именно это и побудило меня написать статью. Мы можем посмеяться над роликом, поговорить три минуты, как это жизненно и весело и, если бы не такие моменты, наша работа была бы скучной и унылой, пройти мимо и вообще сказать, что не бывает ничего идеального, все ошибаются, заказчики не обязаны разбираться в тонкостях нашей работы и так далее.
Об agile я узнал чуть более года назад. До этого работа также строилась на подобных методах, однако я не знал, как это называется. Да и не нужно было. Были таски, нестрогие эстимейты, дедлайны, Redmine и SVN. На другом месте работы были скрам, спринты, пленнинги (или их интерпретация руководителями), использовались JIRA и BitBucket, что в общем-то то же самое, только лучше. Об инструментариях много говорить не буду, так как это субъективно, их большое количество, как платных, так и бесплатных, да и важно это только во вторую очередь. Никакой, даже самый лучший инструмент, не поможет, если организация труда на низком уровне.
Плохой организацией труда я называю перекидывание людей с проекта на проект в хаотичном порядке, когда самое главное — это количество заведенных и выполненных задач, когда аврал — это повседневный процесс разработки, когда редмайн от тасков со статусом urgent и immediate уже не знает, куда дальше краснеть (разработчикам редмайна стоит задуматься над добавлением в коробку статуса с миганием и сопровождением звуковым сигналом, как у скорой помощи, и обязательно апперкейсом), это выставление эстимейтов без участия разработчиков. Такое часто бывает на аутсорсе, когда вы или ваш руководитель непосредственно общаетесь с англоязычными коллегами, которые находятся в других часовых поясах. Выполнение этих задач становится вашей целью. Со временем вы начинаете верить в то, что эффективность измеряется количеством тикетов, сделанных вчера, проэстимейченых сегодня и запланированных на завтра. Это становится нормой. Это меняет человека. Меняется даже взгляд. Человек превращается в упоротого оленя. Серьёзно, я не шучу. Хорошая проверка коллектива на упоротость — неформальная обстановка. Корпоратив или какой-то праздник.
Хочу, чтобы читатель понимал, что я виню не методологии, а неправильное их использование с точки зрения исполнителя. Представляя себя на месте руководителя, думается, что меня бы вряд ли интересовало, как будет решена задача, ведь главное — конечный результат. Как вы это сделаете, ну давайте будем честными, — чаще всего, не важно.
Не знаю, как вам, но мне, чтобы хорошо выполнять свою работу, нужна концентрация внимания. Если человек участвует в двух или более проектах, по каждому из которых каждый день проходит митинг, если нужно постоянно переключаться с одной задачи на другие, — вряд ли можно надолго сконцентрироваться и хорошо выполнить работу. Однако я понимаю, что будущее, как и настоящее, не без этого. И, видимо, придётся привыкать, так как это может стать одним из ключевых навыков.
Для меня хороший вариант — стендап минут на 5-20, в котором мы вкратце узнаём о том, кто чем занимается и, в случае необходимости, после его окончания, общаемся уже в процессе работы между собой. Хороший вариант — это пленнинг раз в неделю или две (иногда — месяц) с обязательным присутствием всех, кто будет участвовать в последующем спринте. Всё это избавляет от необходимости каждый день по полтора часа (не дай Бог, по скайпу) заниматься болтовнёй. Ну не нужно всем каждый день в деталях знать, чем занимаются все остальные! Нужен тебе дизайнер — подошёл к нему, узнал необходимую информацию, — пошёл дальше работать.
Любая крайность — это плохо. У меня был опыт каждодневного полуторачасового общения по скайпу. Это крайность. Не использовать инструменты, которые в хороших руках ускоряют рабочие процессы — крайность. Каждая команда должна для себя найти ту золотую середину, в которой им будет комфортно работать, а не подгонять всех подряд под определённые стандарты. Тем более, их нет. Возможно, выработать свои методики, основанные на популярных, действенных практиках. И это не просто. На поиски и пробы могут уйти драгоценное время и деньги инвесторов. Но нельзя просто так взять ивыставить заявку на 250 тыс коней начать использовать agile.
Agile !== «бегать с выпученными глазами и пытаться всё успеть, чего бы это ни стоило», хотя спринт зачастую подразумевает именно это. Для меня agile — это как раз набор методологий, которые должны помогать всем — от руководителя до офисного менеджера.
Почему agile помогает мне работать?
Тут всё просто. Без организации работы всё будет плохо. Разработчик относится более ответственно к своей работе, организует себя, привыкает к определённому режиму. Руководитель может следить за процессом, выявлять слабые стороны. О научном и практическом обосновании говорить здесь неуместно — отдельная тема для разговора.
Почему agile мешает мне работать?
При неправильном понимании его использование приводит к таким бедам, как плохой микроклимат внутри коллектива, просроченные дедлайны, увольнения, общая неудовлетворённость процессом и результатом разработки.
Среди нас найдётся много людей (себя бы тоже причислил к их числу), которые неправильно трактуют некоторые понятия, связанные с современными подходами к управлению разработкой. Хотелось бы, чтобы руководители понимали их как можно лучше, слушали не только себя и, что самое главное, — старались как можно гибче применять в каждом конкретном случае. Ведь не всегда процесс разработки — конвейер.
В заключение — несколько ассоциативных ссылок (имеют лишь касательное отношение к теме):
За мою короткую карьеру, если её можно так назвать, разработчика, удалось поработать в разных (дело не только в названиях) организациях. Все мы время от времени меняем работу, кто-то чаще, кто-то реже. Естественно, мы сравниваем их между собой по каким-то критериям, выставляем субъективные или не очень оценки. Для себя. Для своего будущего. Делаем выводы. Расстраиваемся или радуемся. Через несколько месяцев после смены работы опять начинаем сравнивать своё текущее место с предыдущим. Порой в голову проникают мысли, мол, зря это было. На старой работе было всё-таки здорово, хоть и платили меньше. Зато уже всех знал, мог выйти в центр офиса и сказать что-то вроде “да пошло оно всё, к черту дедлайны, имел я вашу работу”. Пойти перекурить тире попить чай, снова сесть за компьютер, нехило так поовертаймить и успешно закончить свой кусок.
Все мы знаем, что часто задачи ставятся примерно так:
Я очень рад, что увидел этот баян-бабаян совсем недавно. Это значит, что именно я столкнулся со столь академическим идиотизмом достаточно поздно в своей жизни и всецело благодарен ей за это. Именно это и побудило меня написать статью. Мы можем посмеяться над роликом, поговорить три минуты, как это жизненно и весело и, если бы не такие моменты, наша работа была бы скучной и унылой, пройти мимо и вообще сказать, что не бывает ничего идеального, все ошибаются, заказчики не обязаны разбираться в тонкостях нашей работы и так далее.
Об agile я узнал чуть более года назад. До этого работа также строилась на подобных методах, однако я не знал, как это называется. Да и не нужно было. Были таски, нестрогие эстимейты, дедлайны, Redmine и SVN. На другом месте работы были скрам, спринты, пленнинги (или их интерпретация руководителями), использовались JIRA и BitBucket, что в общем-то то же самое, только лучше. Об инструментариях много говорить не буду, так как это субъективно, их большое количество, как платных, так и бесплатных, да и важно это только во вторую очередь. Никакой, даже самый лучший инструмент, не поможет, если организация труда на низком уровне.
Плохой организацией труда я называю перекидывание людей с проекта на проект в хаотичном порядке, когда самое главное — это количество заведенных и выполненных задач, когда аврал — это повседневный процесс разработки, когда редмайн от тасков со статусом urgent и immediate уже не знает, куда дальше краснеть (разработчикам редмайна стоит задуматься над добавлением в коробку статуса с миганием и сопровождением звуковым сигналом, как у скорой помощи, и обязательно апперкейсом), это выставление эстимейтов без участия разработчиков. Такое часто бывает на аутсорсе, когда вы или ваш руководитель непосредственно общаетесь с англоязычными коллегами, которые находятся в других часовых поясах. Выполнение этих задач становится вашей целью. Со временем вы начинаете верить в то, что эффективность измеряется количеством тикетов, сделанных вчера, проэстимейченых сегодня и запланированных на завтра. Это становится нормой. Это меняет человека. Меняется даже взгляд. Человек превращается в упоротого оленя. Серьёзно, я не шучу. Хорошая проверка коллектива на упоротость — неформальная обстановка. Корпоратив или какой-то праздник.
Хочу, чтобы читатель понимал, что я виню не методологии, а неправильное их использование с точки зрения исполнителя. Представляя себя на месте руководителя, думается, что меня бы вряд ли интересовало, как будет решена задача, ведь главное — конечный результат. Как вы это сделаете, ну давайте будем честными, — чаще всего, не важно.
Не знаю, как вам, но мне, чтобы хорошо выполнять свою работу, нужна концентрация внимания. Если человек участвует в двух или более проектах, по каждому из которых каждый день проходит митинг, если нужно постоянно переключаться с одной задачи на другие, — вряд ли можно надолго сконцентрироваться и хорошо выполнить работу. Однако я понимаю, что будущее, как и настоящее, не без этого. И, видимо, придётся привыкать, так как это может стать одним из ключевых навыков.
Для меня хороший вариант — стендап минут на 5-20, в котором мы вкратце узнаём о том, кто чем занимается и, в случае необходимости, после его окончания, общаемся уже в процессе работы между собой. Хороший вариант — это пленнинг раз в неделю или две (иногда — месяц) с обязательным присутствием всех, кто будет участвовать в последующем спринте. Всё это избавляет от необходимости каждый день по полтора часа (не дай Бог, по скайпу) заниматься болтовнёй. Ну не нужно всем каждый день в деталях знать, чем занимаются все остальные! Нужен тебе дизайнер — подошёл к нему, узнал необходимую информацию, — пошёл дальше работать.
Любая крайность — это плохо. У меня был опыт каждодневного полуторачасового общения по скайпу. Это крайность. Не использовать инструменты, которые в хороших руках ускоряют рабочие процессы — крайность. Каждая команда должна для себя найти ту золотую середину, в которой им будет комфортно работать, а не подгонять всех подряд под определённые стандарты. Тем более, их нет. Возможно, выработать свои методики, основанные на популярных, действенных практиках. И это не просто. На поиски и пробы могут уйти драгоценное время и деньги инвесторов. Но нельзя просто так взять и
Agile !== «бегать с выпученными глазами и пытаться всё успеть, чего бы это ни стоило», хотя спринт зачастую подразумевает именно это. Для меня agile — это как раз набор методологий, которые должны помогать всем — от руководителя до офисного менеджера.
Почему agile помогает мне работать?
Тут всё просто. Без организации работы всё будет плохо. Разработчик относится более ответственно к своей работе, организует себя, привыкает к определённому режиму. Руководитель может следить за процессом, выявлять слабые стороны. О научном и практическом обосновании говорить здесь неуместно — отдельная тема для разговора.
Почему agile мешает мне работать?
При неправильном понимании его использование приводит к таким бедам, как плохой микроклимат внутри коллектива, просроченные дедлайны, увольнения, общая неудовлетворённость процессом и результатом разработки.
Среди нас найдётся много людей (себя бы тоже причислил к их числу), которые неправильно трактуют некоторые понятия, связанные с современными подходами к управлению разработкой. Хотелось бы, чтобы руководители понимали их как можно лучше, слушали не только себя и, что самое главное, — старались как можно гибче применять в каждом конкретном случае. Ведь не всегда процесс разработки — конвейер.
В заключение — несколько ассоциативных ссылок (имеют лишь касательное отношение к теме):
- Статья Stop Trying to Incentivize Your Employees to Be More Like You
- Фильм “Офисное пространство”
- Марина Миронович: Как жить дальше, если вы все-таки решили написать свой MVC-фреймворк
- Перевод хорошей статьи