Комментарии 10
Без последней строки (у автора текста она есть) текст не закончен
Любая индустрия проходит фазы становления. Аджайл, на деле, решает всего один вопрос: как структурированному, целе-ориентированному корпоративному менеджменту управлять толпой высокотехнологичных косячников, работу которых не хватает компетенции формализовать, а её оценку привести к общему метрическому знаменателю.
Для того, чтобы этот вопрос был поставлен, разработка ПО должна была пройти путь от тех самых "лабораторий", через "заводики" (специализированные компьютерные фирмы), через появление конкурентного рынка продукции таких "заводиков", к тому, что в любой корпорации теперь есть уже не своя лаборатория, а свой заводик.
Таким образом, если раньше разработкой ПО руководили профессиональные кадры, задачи были медленно меняющимися (бизнес над душой не висел, делался, как правило, универсальный продукт), бюджеты были ограничены, то, после проникновения разработки в корпоративный сектор, всё стало в точности до наоборот:
Денег куры не клюют, универсальность не нужна, потребности "давай-давай-переделай". Именно в этой ситуации аджайл почти идеален. Как только что-то из этого пропадает (а сегодня оно у американов опять пропадает, потребности стандартизуются, копипастеры совершенствуются), аджайл становится пятым колесом в телеге.
При этом, необходимо отметить, что в России по этим параметрам мы до нормального аджайла ещё и не доросли даже - у нас в инженерке ещё впереди это состояние, лет через 15. Сейчас аджайл бы, скорее, в науке и образовании прижился - там паттерн условий соответствует.
Можете не читать Agile Manifesto, а прочесть только список его "подписантов" и подумать о том, много ли среди них "бизнеса". Аджайл придумали разработчики успешных проектов (а вовсе не бизнес), которым пришлось реализовывать массу новых фич, поток которых был обусловлен успехом проектов. Затем он был подхвачен "стартап-культурой", у которой были аналогичные запросы.
Побуду адвокатом дьявола. Как-будто это все так плохо? Вопрос скорее в альтернативах. Стартап - это не только освоение инвестиций, а еще поиск способа обеспечить себе сначала безубыточность, а затем и профитность. И тут есть 2 способа: рабочий и не всегда. Рабочий - это хаос. Никаких планов, делай сейчас - думай завтра. В таких условиях совершенно невозможно что-то "сделать хорошо", только как есть. Agile же приносит за собой хоть какое-то планирование и, сюрпрайз-сюрпрайз, гибкость. И вот стартануть с эджайла - не очень подход, а вот когда ты вышел в профитность - уже хочется выстроить процессы и отойти от хаоса. Потому что в хаосе - выгораешь. Лучше пока ничего не придумали. Как придумают - и эджайл вымрет.
На самом деле беда ИТ в том что сюда пришли менеджеры, коучи, аналитики и прочие инфоцыгане. Вместе с собой они притащили и свои методы работы где важно громче всех кукарекать и проводить ИБД, притащили звонки, согласования, встречи, демо и прочее.
Как только Гугл, Амазон, Яндекс и прочие смогли создать свой бизнес. Ведь у них небыло скрама и штата цыган, зато был штат специалистов которых никто не трогал.
Клиенту не нужны ваши фичи, еженедельные поставки и прочее. Ему нужен законченный продукт. Чтобы не пытаться находу выяснить его требования можно привести аналитку, этап планирования проекта, проектирование архитектуры и прочее. В идеале система должна быть полностью готова ещё до того как будет создан первый файл проекта.
Люди забыли как строить UML и ER и прочие диаграммы. Забыли как писать документацию. В проектах которые я вижу документация это просто поток сознания и куски проектных решений, зато микросервисы. "После меня хоть потоп" вот девиз менеджеров проектов, тимлидов да и вообще всех. Главное сейчас прям тут выдать больше фич и КПИ, а дальше с почестями уйти пока никто не понял что ты тут накакал.
Я и сам видя проблемы в проекте вместо их решения стал создавать встречи, заводить задачи с описанием что нужно сделать, сообщать всем. Мог бы за 2ч все сделать, но тогда я ничего не получу, а так я получу почёт и уважение ведь я активный и деятельный. Только вот проблема не решена. Почему? Потому что всем плевать на проект, главное соблюдать КПИ и ИБД.
Клиенту не нужны ваши фичи, еженедельные поставки и прочее. Ему нужен законченный продукт.
Вы у всех клиентов в мире об этом спросили?) Всем клиентам нужно, чтобы доработки и новые фичи выходили максимально быстро. Этого требует современный рынок. Законченный продукт это какой? Которым никто не пользуется? Живой продукт постоянно дорабатывается и меняется.
В идеале система должна быть полностью готова ещё до того как будет создан первый файл проекта.
Такое проектирование возможно лишь для самых простых и примитивных систем. А сложные системы - пока будут проектироваться, уже устареют))
В проектах которые я вижу документация это просто поток сознания и куски проектных решений
Это проблема лишь вашей организации. Не везде так. Хотя в целом, встречается часто. Низкоквалифицированные It-шники бывают косноязычны, не любят схемы и документирование, а ещё частенько неграмотны, постоянно недовольны всем вокруг.
всем плевать на проект, главное соблюдать КПИ и ИБД.
Опять таки, зависит от компании. Если у вас заказная разработка, то в целом да, плевать. Если вам не хватает "почета и уважения", то продолжайте делать как делаете.
Или можете повзрослеть. И потратить свое время с пользой - прокачивая свои навыки. Почитайте умные книги, чтобы понять, для чего менеджер проводит демо перед клиентом, для чего он созвоны устраивает и т.д. Это софт скиллы. Улучшайте свои технические навыки, делайте диаграммы и т.п., не ожидая "почета и уважения". Ради себя и своих навыков. И в будущем, может быть уже даже в другой компании, это будет оценено по достоинству. Станете сеньором, тимлидом, потом руководителем отдела, может даже техническим директором. И там у вас будет настоящий "почет и уважение", а не тот суррогат, который вы сейчас пытаетесь получить, занимаясь хернёй.
По-моему это спор о форме, а нужно сфокусироваться на содержании то есть суть бизнеса это количество заработанных денег.
И agile, waterfall или конвейер на заводе форда будет оцениваться только с этой позиции.
Если ваш операционный руководитель любит замыкать все на себе, то будьте готовы ему напоминать и ждать его визирование, если он склонен делегировать, то будьте готовы общаться с скрам мастерами.
Повторю, на мой взгляд это лишь форма процесса, надстройка над людьми которые пишут код, если они не могут самоорганизовываться они ищут себе pm-ов, а как их труд организовывается это лирика.
Что бы выяснить что лучше нужно решить, лучше это про что? «Лучше» - всегда в конечном итоге про деньги. Человеко часы это себестоимость продукта.
Все что до сих пор не реализовано, не запущено, не разработанно является таковым только по причине дороговизны. MVP показывает, что дорого и ваш проект кладут под сукно.
Может хороша та методика которая раньше позволит определить это «дорого».
И давайте для себя определимся наконец, за что нам платят деньги? На мой взгляд нам платят деньги чтобы с нашей помощью перетащить таску из in process в done. На этом все, нам как рядовым разработчикам больше ничего не нужно делать, нет задачи оценивать или критиковать. Может это звучит цинично, но мой личный опыт подсказывает мне именно это. Если ты закрываешь таски в срок, не нарушаешь трудовую дисциплину, ты идеальный сотрудник, ты получишь все! Возможно даже решат что раз ты так хорошо решаешь таски, то пора тебе самому эти таски назначать, тут скорей всего бизнес потеряет хорошего разраба и получит плохого менеджера )
Как скрам мастер не вижу противоречия между аджайлом и тем подходом, о котором пишет автор. «Я стремлюсь к еженедельному деплою» — ну вот и отлично. Будет при этом человек 80% времени продумывать решение в голове, и 20% - писать код в IDE, или ему надо сразу покрутить в коде несколько прототипов и выбрать что-то одно - каждый работает как ему удобнее.
Разработчик пришёл к поговорке "7 раз отмерь - 1 раз отрежь"
После смерти Agile