Ни об одной теме я не слышал столько негативных отзывов, как об Аджайл. Дескать, он и неэффективный, и не работает, и подходит для ленивых, и придуман для зарабатывания бабла на консультациях, и вообще, нам аджайл не подходит.
Я здесь не собираюсь никого разубеждать. Я хочу поделиться соображениями, почему большинству компаний аджайл действительно не подходит.
Начнём с того, что такое аджайл для разработчика? В первую очередь аджайл — это дисциплина. Дисциплина, которая позволит работать эффективнее, но отнюдь не задаром. Аджайл кое-чего требует от разработчика.
Итак, аджайл — это дисциплина, которая
Но вот в чём заковырка. Это имеет смысл, только
И тут мы подходим к самом главному: для большинства разработчиков это не является главным приоритетом. Да, такова грустная правда.
Среднестатестическому разработчику интересно писать какой-нибудь нибудь сложный заковыристый модуль (пусть даже никому не нужный), но неинтересно писать простой до безобразия, но работающий продукт. Я знаю, о чём говорю, я сам таким был. Мне было интереснее написать свой класс StringUtils, чем использовать существующую библиотеку типа commons-lang. Просто потому, что это интересно. Интересен сам процесс создания этой фиговины. А что там с клиентом? Да ничего с ним не случится, полгода ждал и ещё подождёт. Сейчас я свой StringUtils закончу и тогда займусь его проблемой.
И самое главное: рядовой разработчик ценит свой комфорт за компьютером. Моё рабочее место — мой дом родной. Я тут настраиваю всё как хочу, ставлю свой десктоп, музыку, аудиоплеер, программки там разные, фотографию в рамке на стол. У меня тут даже чашка своя отдельная. Тут у меня зона комфорта. Тут только я и мой компьютер. Ну да, приходят иногда начальники и тестировщики, врываются в мой мирок, но это временно. Поговорят и уйдут. И снова воцарится мир в моём мире.
Это факт: рядовой разработчик не хочет никого пускать в это пространство! Что вы говорите? Парное программирование повысит производительность? Уменьшит количество багов? Улучшит дизайн кода? Хм… да нет не верю. Да всяко же двое по отдельности сделают вдвое больше. Вот так и рождаются разговоры о том, что аджайл не работает.
Итак:
Поэтому Agile не подходит для большинства разработчиков. Agile отнимет у вас привычный комфорт, отнимет персональный десктоп и заставит работать по правилам. И это только для того, чтобы компании было лучше и клиент был доволен.
Пока в вашей компании собственный комфорт для разработчиков важнее успеха компании, никакой аджайл вам не поможет. Не нужно всех этих дорогущих тренингов, насильственных внедрений Scrum, Lean, TDD и т.д. Всё это ни-па-мо-жыт. Проблема глубже.
Помимо той мотивации, которую может придумать руководство компании, аджайл тоже предлагает свои мотиваторы. Поверьте, когда вы немножко привыкнете, вы поймёте, что практики аджайл могут быть очень весёлыми, как например, пинг-понг программирование. Как сказал Vlad911,
Коммитить код, будучи уверенным, что он работает как надо — само по себе большое удовольствие.
И наконец, один из самых больших мотиваторов — это, как ни странно, живое общение с клиентом. Сравните: когда к вам приходит начальник и спрашивает: «Ну что, наконец-то доделал?», и когда к вам приходит клиент и говорит: «Вау, вы это сделали! Это то, что надо, спасибо!» Оправдаться перед начальником легко: я был на митинге, мержил код, исправлял баги — что угодно. С клиентом такой фокус не прокатит. Надо либо делать работу, либо… другого варианта просто нет.
Так что если вы заинтересованы в успехе проекта, используйте аджайл. Если вам важнее ваша зона комфорта — что ж, заварите кофе и приступайте к чтению новостей. Agile вам пока не подходит.
Я здесь не собираюсь никого разубеждать. Я хочу поделиться соображениями, почему большинству компаний аджайл действительно не подходит.
Начнём с того, что такое аджайл для разработчика? В первую очередь аджайл — это дисциплина. Дисциплина, которая позволит работать эффективнее, но отнюдь не задаром. Аджайл кое-чего требует от разработчика.
Аджайл — это дисциплина
Чтобы информация внутри команды быстро распространялась, и любые проблемы сразу вылезали наружу, аджайл предписывает ежедневные утренние собрания — стэндапы, где каждый вкратце рассказывает, чем занимался вчера, что успел сделать и с какими проблемами столкнулся.
Так-то идея хорошая, но… это моё любимое время, когда я только пришёл на работу, заварил себе кофе — самое время полчасика пробежаться по новостям и свежим анекдотам. И вместо этого я должен встать в круг и отчитываться за вчерашний день?
Код должен быть простым и читаемым, чтобы его можно было легко менять, причём в любой момент и разным людям. Для этого надо свой код постоянно критически пересматривать и рефакторить. Те, кто относится к своему коду как к детищу, требование постоянно менять код воспринимают как личную обиду. «Я тут старался, созидал, а теперь — снова менять?...»
И конечно, мало кому нравится то, что твой код смотрят и меняют своими грязными лапами посторонние люди.
Чтобы убедиться, что проект работает, приходится писать юнит-тесты. То бишь кода получается вдвое больше, а на разработчика вешается вдвое больше работы. А ради чего? Всё равно тесты не дают стопроцентной гарантии и никогда не найдут всех багов. Так пусть тестировщики их и ищут, они для этого и существуют!
- Чтобы убедиться, что проект работает так, как хотел клиент, приходится писать приёмочные тесты. А с ними столько мороки… Они и медленные, и ломаются постоянно… Да какого чёрта, не проще ли руками всё прокликать? Тем более что для этого есть тестировщики.
Чтобы убедиться, что проект не развалится при интеграции изменений разных разработчиков, аджайл предлагает Continuous Integration сервер. Вот ещё, придумали на нашу голову! Теперь в мой почтовый ящик сыпется куча каких-то левых писем о том, что билд сломался. И я должен лезть на какой-то сервер и разбираться, почему тесты красные? Да я, может, и не при чём тут, чего я буду время тратить!
Чтобы постоянно обсуждать все вопросы дизайна, делать непрерывный code review, мгновенно находить ошибки и писать другу другу тесты, аджайл прописал парное программирование. Несомненно, этого разработчики боятся больше всего. Ещё бы! Целый день со мной рядом будет сидеть какой-то чувак, который будет мне указывать, как и что делать. Тыкать носом в мои ошибки. Ни тебе почту почитать, ни новости, ни анекдоты. Нет уж, увольте! А если у него другой стиль? Если наши мнения разойдутся? Если ему нравится ставить скобочки в том же ряду, а мне — в следующем? Мы целый день будем спорить? Спасибо, нам такого добра не надо.
Чтобы разработчик лучше понимал проблемную область и мог своевременно предлагать простые решения, необходимо прямое общение с клиентами. Ой-ой-ой, я и с коллегами-то предпочитаю говорить по телефону, а с клиентом…
Чтобы информация внутри команды быстро распространялась, и любые проблемы сразу вылезали наружу, аджайл предписывает ежедневные утренние собрания — стэндапы, где каждый вкратце рассказывает, чем занимался вчера, что успел сделать и с какими проблемами столкнулся. 
Код должен быть простым и читаемым, чтобы его можно было легко менять, причём в любой момент и разным людям. Для этого надо свой код постоянно критически пересматривать и рефакторить. Те, кто относится к своему коду как к детищу, требование постоянно менять код воспринимают как личную обиду. «Я тут старался, созидал, а теперь — снова менять?...» 
Чтобы разработчик лучше понимал проблемную область и мог своевременно предлагать простые решения, необходимо прямое общение с клиентами. Ой-ой-ой, я и с коллегами-то предпочитаю говорить по телефону, а с клиентом…Итак, аджайл — это дисциплина, которая
позволяет
создавать работающий продукт с высоким качеством в предсказуемые сроки.Но вот в чём заковырка. Это имеет смысл, только
если вы хотите
создавать работающий продукт с высоким качеством в предсказуемые сроки.И тут мы подходим к самом главному: для большинства разработчиков это не является главным приоритетом. Да, такова грустная правда.
Зона комфорта
Среднестатестическому разработчику интересно писать какой-нибудь нибудь сложный заковыристый модуль (пусть даже никому не нужный), но неинтересно писать простой до безобразия, но работающий продукт. Я знаю, о чём говорю, я сам таким был. Мне было интереснее написать свой класс StringUtils, чем использовать существующую библиотеку типа commons-lang. Просто потому, что это интересно. Интересен сам процесс создания этой фиговины. А что там с клиентом? Да ничего с ним не случится, полгода ждал и ещё подождёт. Сейчас я свой StringUtils закончу и тогда займусь его проблемой. И самое главное: рядовой разработчик ценит свой комфорт за компьютером. Моё рабочее место — мой дом родной. Я тут настраиваю всё как хочу, ставлю свой десктоп, музыку, аудиоплеер, программки там разные, фотографию в рамке на стол. У меня тут даже чашка своя отдельная. Тут у меня зона комфорта. Тут только я и мой компьютер. Ну да, приходят иногда начальники и тестировщики, врываются в мой мирок, но это временно. Поговорят и уйдут. И снова воцарится мир в моём мире.Это факт: рядовой разработчик не хочет никого пускать в это пространство! Что вы говорите? Парное программирование повысит производительность? Уменьшит количество багов? Улучшит дизайн кода? Хм… да нет не верю. Да всяко же двое по отдельности сделают вдвое больше. Вот так и рождаются разговоры о том, что аджайл не работает.
Итак:
для большинства разработчиков собственный комфорт важнее, чем работающий софт, чем успех компании и всё прочее.
Проблема глубже
Поэтому Agile не подходит для большинства разработчиков. Agile отнимет у вас привычный комфорт, отнимет персональный десктоп и заставит работать по правилам. И это только для того, чтобы компании было лучше и клиент был доволен.
Пока в вашей компании собственный комфорт для разработчиков важнее успеха компании, никакой аджайл вам не поможет. Не нужно всех этих дорогущих тренингов, насильственных внедрений Scrum, Lean, TDD и т.д. Всё это ни-па-мо-жыт. Проблема глубже.
Где взять мотивацию?
Помимо той мотивации, которую может придумать руководство компании, аджайл тоже предлагает свои мотиваторы. Поверьте, когда вы немножко привыкнете, вы поймёте, что практики аджайл могут быть очень весёлыми, как например, пинг-понг программирование. Как сказал Vlad911,
Парное программирование — это отличный способ повысить мотивацию. Всегда можно договорится со своим напарником о том, что делать и как делать, чтобы это не превращалось в рутинную работу, можно динамически меняться ответственностью и не заниматься «одним и тем же», что часто приходится делать в одиночку.
Коммитить код, будучи уверенным, что он работает как надо — само по себе большое удовольствие.
И наконец, один из самых больших мотиваторов — это, как ни странно, живое общение с клиентом. Сравните: когда к вам приходит начальник и спрашивает: «Ну что, наконец-то доделал?», и когда к вам приходит клиент и говорит: «Вау, вы это сделали! Это то, что надо, спасибо!» Оправдаться перед начальником легко: я был на митинге, мержил код, исправлял баги — что угодно. С клиентом такой фокус не прокатит. Надо либо делать работу, либо… другого варианта просто нет.
Так что если вы заинтересованы в успехе проекта, используйте аджайл. Если вам важнее ваша зона комфорта — что ж, заварите кофе и приступайте к чтению новостей. Agile вам пока не подходит.
