Основатель компании-разработчика Hello World Technologies Евгений Тюменцев о том, почему ценности гибкой методологии не подходят для крупных проектов.
Основатель компании-разработчика Hello World Technologies Евгений Тюменцев о том, почему ценности гибкой методологии не подходят для крупных проектов.
А где в статье "о том, почему ценности гибкой методологии не подходят для крупных проектов"?
Здравствуйте, Андрей!
Спасибо за отклик!
1. В начале статьи я поставил вопрос: "Может ли это ускорить изменения?" Имея ввиду Agile.
2. И по ходу статьи сделал заключение, ссылаясь на исследование Науса и Фарра: "Для программирования свойственно падение производительности труда по мере роста проекта".
3. Отсюда в конце сделал вывод, что "Agile не решает проблему, которая существует в ИТ-отрасли с самого её появления, а вместо этого адаптирует к ней и заказчиков, и исполнителей", то есть несмотря на Agile скорость изменений будет падать, пока не достигнет неприемлемого уровня, в смысле, что Agile на это никак не влияет. А значит ожидание: " в гибких методологиях инструмент, который увеличит скорость изменений " неоправданно.
При этом "Хочу заметить, что я ни в коем случае не нахожу ценности неверными или вредными. Каждая из них сама по себе приносит пользу."
Важная и критичная составляющего Agile метода - команда с высокой степенью самоорганизации. Таких людей подобрать совсем не простая задача
Вот как в реальности транслируются принципы Agile в Москве:
Ценности гибких методологий задекларированы в Agile-манифесте. Их четыре:
1. Люди и взаимодействие важнее процессов и инструментов.
Да, поэтому берем однокурсников гендира, сотрудников, имеющих смутное представление о предмете работы в принципе, зато лид и взаимодействие будет важнее процессов и инструментов. Точно, Инструментам можно научить, кажется?
2. Работающий продукт важнее исчерпывающей документации.
Абсолютно верно, поэтому на десять тысяч строк кода будет как максимум сто копирайтов, а чаще всего вообще ни одного адекватного комментария, кроме авто документируемых функций
3. Сотрудничество с заказчиком важнее согласования условий контракта.
О-да, если заказчику захочется вдруг вмешаться в процесс дизайна приложения и UI/UX, нужно смело браться за работу, пытаясь реализовать понимание заказчиа о продукте. Постойте-ка, на минуточнку, а какое может быть представление о продукте у заказчика, если он его в глаза не видел? Может быть, увидев свои желания - он ужаснется своим представлениям о usability? Получим очередной Excel в форм-факторе iPhone4?
4. Готовность к изменениям важнее следования первоначальному плану.
Ну конечно, в российских условиях это превращается. Сдать заказчику на от*бись. Мы планировали собственный дизайн?Заказчик приволок "своего" дизайнера, вообще не имеющего представление о UI/UX? Замечательно! Выкидываем все нафиг! Или по-другому - наш супер-пупер программист сделал "как умеет", все сдаем, говорим что это наша концепция UI/UX подготовилась к изменениям, мы же готовы, что всегда будет получаться г*вно? Готовы! Ну и зае*ись!
+1500
Да, так и есть
Комментарий недоступен
Не мечи бисер перед свиньями, не трать время. В России вообще не принято использовать узкую специализацию. Берут человека который ВСЕ делает ПЛОХО. То есть если в резюме указать ОДНУ вещь, которую ты делаешь действительно ХОРОШО, например аналитику, то будешь годами сидеть без работы, плюс фактор кумовства в Москве никто не отменял. Поэтому возьмут человека который будет плохим системным администратором программистом и аналитиком, зато очевидная экономия на ИТ с точки зрения менеджера продукта. То же самое с архитектором, программистом и аналитиком. То есть все принимают правила игры, что в России в резюме можно написать вообще всё, что угодно, никакого доверия сертификатам, а проверять будут все равно так, как будто вчера институт закончил, при этом отдавая предпочтение однокурсникам. Так что вообще все равно, что и как ты знаешь, это не имеет почти никакого значения - главное- как ты "обманешь" работодателя. Поэтому хорошие кодеры - это full-stack програмисты, пргарммисты - это архитекторы систем а архитекторы систем - это у нас генеральные директора, не окончившие MBA, и все всё знают и умеют, а спеси - просто вагонами разгружай. Лично я вообще не встретил за 4 года в Москве вообще ни одного архитектора, все либо глубоко законспирировавшиеся менеджеры продукта, либо вообще пользователи ПК Visio, имеющие сугубо абстрактное представление о предмете. Потому что даже специализации такой в высшей школе нет - все без исключения в лучшем случае "инженер-программист"-ы. То есть это вообще не российская тема, нам не понять, зачем нужен отдельный человек для рисования в Visio архитектур, хоть немного приближенных к реальности, а не просто веселые картинки для заказчика (хотя на эту задачу как раз и берут), отдавая на откуп программистам всю архитектуру систем,на коленке сделал - молодец, сэкономил деньги гендиру на дачку. Нет - не беда, возьмем другого "гения". Так и получается, что в условиях отсутствия жесткой конкуренции все бросаются на "универсалов", и под iOS чот-то криворукое слабать, и страничку HTML наковырять, главное уметь сделать картинку, а уж как оно внутри работает - лучше вообще не спрашивать. Все равно никто никогда не пишет комментарии.
В тексте очевидно смешаны понятия Scrum, Agile и для Velocity странная формула приведена. Вот коллеги из Scrum Alliance описывают что это такое, простое среднее https://www.scrumalliance.org/community/articles/2014/february/velocity
Добрый день, Михаил!
Спасибо за отклик!
Не могли бы Вы уточнить, в чем произошло смешение понятий Scrum и Agile? Я использовал только Agile-манифест. В тех пунктах, где речь идет о ценностях (2-5) больше ни о каких Agile-практиках не упоминается. Возможно, путаница возникла из-за Veloctiy. Но про нее я написал отдельно, как следствие, вытекающее из итеративного процесса разработки.
Насчет velocity - я как раз и описал формулу вычисления средней скорости.
Автор пишет, что Agile не подходит для крупных проектов, описывает проблемы и их решение. И среди решений я так и не увидел "уход от Agile" :)
А что вы хотели? Agile - это как демократия. Его все обязаны хвалить, даже если на самом деле думаю иначе..такой тренд навязан обществом. На самом деле обе системы хреновые - и Agile и демократия, но просто другие системы, известные человечеству - еще хуже :) Так что за неимение лучшего пока деваться некуда...
Здравствуйте, Илья!
Спасибо за отклик!
Цель статьи была сказать: "Agile не решает проблему, которая существует в ИТ-отрасли с самого её появления, а вместо этого адаптирует к ней и заказчиков, и исполнителей", то есть несмотря на Agile скорость изменений будет падать, пока не достигнет неприемлемого уровня, в смысле, что Agile на это никак не влияет. А значит ожидание: " в гибких методологиях инструмент, который увеличит скорость изменений " неоправданно.
При этом "Хочу заметить, что я ни в коем случае не нахожу ценности неверными или вредными. Каждая из них сама по себе приносит пользу."
Комментарий недоступен
срачь - это святое :)
что гораздо чаще, нечто среднее между этим.Гораздо чаще это костыли. Хорошее решение требует очень много времени на проектирование и разработку. Я не видел ни одного проекта, который бы такими интеративными кусками в конце разработки не разваливался при эксплуатации. Даже спорили на внушительную сумму денег с коллегой, что его латание систем выльется в полную деградацию работы. Так оно и получилось.
Взгляд достаточно однобокий. Ведь самое главное в Agile - это делегирование решения самой проблемы, а не четкого технического задания. Для этого нужно во-первых перестать относиться к разработчикам, как к простым исполнителям, во-вторых четко показывать им картину, в чем нуждаются пользователи и сроков, когда это должно быть сделано - из сроков релиза как раз и проистекает в каком виде можно успеть сделать решение: совсем "костыль", "перфекционистское" или, что гораздо чаще, нечто среднее между этим.
По своей работе постоянно встречаюсь с подобным скепсисом, когда Agile воспринимается скорее как "гомеопатия", призванная бороться с какими-то недостатками, чем как философия, которая предлагает сфокусироваться на улучшении главной метрики: Time To Market и делать для этого все возможное.
делегирование решения самой проблемы, а не четкого технического задания
Эта концепция совершенно ортогональна Agile. В смысле - не противоречит, а просто никак не связана. Встречал подрядчиков, которые как раз наоборот, работают строго по принципу "не учите нас решать проблемы, просто расскажите о них". И при этом совершенно не взаимодействуют с заказчиком по ходу дела после завершения фазы бизнес-анализа вплоть до сдачи работ.
Комментарий недоступен
Для маленьких проектов-agile, для крупных - классическая проектная технология
Комментарий недоступен
от закона Конвея не убежишь.
Ребята, расходимся! Agile и не обещал быть идеальным для всех. Серебряная пуля дура, короче.
Прочитал пост, так и не увидел ответ на вопрос, почему же Agile не подходит для больших проектов.
Вода, кэпство и ничего по теме.
Тогда почему в офисе сбера на первом этаже стоят огромные буквы «Agile Go Home»?
Кто знает?)
"Go Agile Or Go Home" там вроде