На самом деле, далеко не такой уж плохой вариант по сравнении той дичью, которая реально часто кроется за красивыми модными названиями.
Согласен, кстати. От спринтов потом все подтягивается: цели, приоритеты, декомпозиция, циклы, фокус, оценка задач, ответственные...
Главное в Agile - в том, чтобы
а) глубоко понимать клиента и иметь с ним отличный контакт (через Product owner’а или Business Analyst, но также тем, что видят запрос и реакцию клиента в виде user story)
б) решить часть проблем клиента, а не все сразу, зато не через год, а за 2-8 недель, и далее также решать для клиента все больше проблем каждые 2 недели.
В) и делать это маленькой командой, кайфующей от взаимодействия друг с другом и отклика от клиента, минимизировать для них бюрократию и посадить в одном месте (В крайнем случае - реально поощрять частое общение заочно, созвоны не для бюрократии, а «смотри, я вот это делаю, и получается это; поправь у себя? - правлю… ты что видишь? - о! Заработало").
В итоге, на отрезке в год, команда, условно, Тинькова уже почти год как внедрила приложение для конечных пользователей, сначала крошечное, но затем прошла 20 итераций и сделала его гладким и супер удобным, реально решающим повседневные задачи, стабильным и отбросила все лишнее.
А, условно, РосБанк, спустя год мучений, только релизит первую версию, набитую ненужными и неудобно расположенными функциями с тридцатью окошками и формами, из которых 90% не нужны, и про этом постоянно падающую.
И аналогично в B2B: agile команда выпустила банку за год 20 итераций "системы, заточенная на выполнение 50 самый частых операций за три секунды», которой уже почти год же как пользуются.
В то время как обычная команда будет только подходить к релизу монстра, с которым еще год будет нужна масса мучений, обучений, падений.
И что прикольно – в первом режиме пять разработчиков, сидящих вместе и вовлеченных в жизнь клиента, принесут больше пользы клиенту, чем во втором – 50 программистов, не понимающих проект и с mindset “идиоты, идиотские совещания, хоть бы от меня отстали"
И главное - компания с Agile-внедрением за это время уйдет от конкурентов далеко вперед.
И это распространено на всех уровнях - изначально это стартап-культура, ставшая основой и успешных корпораций.
В стартапе - маленькая команда решает повседневную проблему для клиента быстрее и лучше, чем корпорация - потому что, с одной стороны, прекрасно в нее погружены, с другой - не забюрократизированы, с третьей - заряжены морально.
И, например, Y Combinator не устает продвигать подход (и вкладывать сотни миллионов каждый год в тех, кто это понимает): Make what people want, делайте то, что люди _хотят_. Изучайте поведение клиента и выпускайте то, что подстроено под его поведение - в не ломаете поведение под свой продукт.
Но это работает и в корпорации - например, одна из моделей организации - придумана и называется Spotify, в которой сотни разработчиков также организованы в такие маленькие «племена», заточенные на выпуск разных полезных элементов (и для конечных пользователей, и для авторов / издателей, и для рекламодателей и пр - каждый погружен и кайфует в своем).
Главная и моральная, и инженерная сложность во всем этом - иметь понимание, как сначала выпустить предельно мало (но полезно), а программировать грамотно - с заделом, чтобы все было более-менее масштабируемым и не пришлось по три раза переписывать.
PS я обучался недавно год в Беркли на управлении проектами: вот именно _так_ в США это преподают. Главный принцип – от погруженных и кайфующих от ощущения полезности людей, для реального клиента, максимально мало за раз, максимально быстро. Главное следствие – компания с таким подходом быстро уходит от конкурентов далеко вперёд. Стартапы превращаются в корпорации, agile-корпорации обгоняют за бюрократизированные waterfall корпорации, а клиенты - получают все более быстро все более удобные продукты, реально решающих их потребности.

IT-юмор
7.5K постов53.3K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору