Зависит от многих факторов. У меня было два индикатора:
Внутренний - "делаю одно и тоже, ничего нового" или "а что нового я узнал за последний год-два".
Внешний - поднимаю резюме, и хожу по собеседованиями. Получил офер - значит пока в тонусе. Не получил - значит отстал, пора догонять.
Разумеется я не бежал сразу менять работу. Сначала я изучал что-то новое. Пытался применить это в текущей работе. Но так как регулярное переписывание на новые технологии накладно для бизнеса - однажды наступает такой момент, что пора менять работу.
И сам и по принуждению. Почти 15 лет назад я работал в госучреждении в провинциальном городе. Последние лет 5 - на западные зарубежные компании. Смог бы я получить офер от компании из США/Канады/Австралии на удаленке, если бы все эти 10 лет сидел бы на одном месте? Вот так сразу из грязи в князи? Разумеется нет. Небо и земля. Как по процессам, управлению, так и подходам и технологиям. В ИТ нужно быть релевантным, об этом все знают.
Но условный делфи тут особо не причем. Единственное требование - инструмент должен позволять решать современные задачи, желательно в востребованной области,в идеале в области, которая нравится самому программисту. Сколько у нас энтепрайза и сколько мейнфреймов? Если сам инструмент идет в ногу со временем, то смысла его менять конечно же нет. Но ведь тогда надо и развиваться вместе со своим инструментом. Изучать, щупать его новые возможности.
Мне показалось, что этот человек все 30 лет проработал на одном месте. В нашей стране тоже есть такие 30-летней выдержки в НИИ имени Ленина. Не удивительно, что такие не могут работу найти. Они в целом отстали от профессии, дело не только в условном sql. А в общей эрудиции, погружении в современные темы и тренды.
Разумеется, параллельные миры существуют одновременно.
Жилье за 20-30 лямов могут себе позволить владельцы/топы довольно крупных бизнесов или чиновники/депутаты.
Параллельно им существуют врачи и учителя. Слышал историю в интернетах, как врач из ковидного госпиталя полгода жила как человек, получая 100-130 тр/месяц. Сократила ипотеку на 8 лет.
Однажды я пришел на древнее легаси. Так же проблемой было полное незнание предметной области на тот момент и полное отсутствие ориентации в коде. Мне попался умный аналитик. Он как радар наводил меня на нужные участки кода (описывая словами что этот код должен делать), я находил эти места, вносил изменения и мы вместе тестировали. Позже я уже начал ориентироватся в коде, и немного в предметной области. Это был положительный опыт.
Некоторое время спустя на этом проекте сменился аналитик. Он был глупым. Проект и я не поменялся. Но уже я ему рассказывал про проект, то что знал. Это был отрицательный опыт.
В другой раз мне попался глупый аналитик, который писал в стиле «система должна уметь…». Он не представлял сколько времени займет реализация и можно ли вообще это сделать. Я получил крайне негативный опыт.
В той же компании на другом проекте мне попался умный аналитик. Из ее описаний я чуть ли не один к одному перекладывал интерфейсы модулей и енумы. А потом в конце этапов мы синхронизировали код и документацию. Это был крайне позитивный опыт.
Участвовал в проекте, это была продуктовая компания, где постановой задач занимался сам CEO/CTO и другие сотрудники, которые в том числе и сами пользовались этим софтом. Опыт смешанный. Они были ближе к глупым аналитикам. По сути они не были аналитиками, а пользователями и переводчиками требований от внешних клиентов. Вся документация была разбросана по задачам в жире. И вот это было ужасно. Программистов перекидывали с модуля на модуль и когда возвращался обратно - приходилось по таскам в жире восстанавливать последовательность изменений, чтобы понимать что там произошло, как все это тестировать и что-нибудь не сломать.
Так же я участвовал в проектах, где я сам был и аналитиком и программистом. Из плюсов - лучше понимаешь предметную область. Из минусов - быстро надоедает и нельзя одновременно анализировать на верхнем уровне и кодить с поиском крайних кейсов на нижнем. Время разработки увеличивается раза в два. И это были совсем небольшие проекты, на 2-4 человека месяца. Бонусом были восторженные благодарности за продукт, который реально помогал людям. Опыт смешанный, полезный и познавательный, но я за разделение труда. Пока аналитик думает, как это должно выглядеть - я успею что-нибудь сделать по другой задаче/проекту.
Главный минус серой зп - не выплатят при увольнении (= могут кинуть).
Главный минус белой зп - пенсионные накопления отберут / сгорят (= могут кинуть).
Поэтому я бы смотрел в сторону правильно оформленных отношений через ИП (несколько договоров, работа по этапам / тз). Это повышает шанс остаться при своих в обоих случаях.
Я имел ввиду именно тех, кто из России/Украины/Белоруссии/СНГ. Еще бывает удаленка на зарубеж. В целом-то понятно, что они звезды. Хотелось бы конкретики, если кто-то таких знает.
Пожалуй у всех программистов была/есть мечта написать программу, которая пишет программы. Но по факту тем самым программисты будут пилить сук, на котором сидят.
Через 10 лет программисты все еще будет нужны. Но появятся принципиально новые технологии (например сейчас у нас идет развитие квантовых компьютеров).
И думаю рано или поздно появится какой-нибудь нейроинтерфейс, который позволит исключить руки из процесса написания кода. Они на данный момент являются бутылочным горлышком.
Вопрос с паттерном стратегия. Как раз была такая ситуация на реальном проекте. Наличие стратегии не является достаточным условием. Вызовы во внешние системы идут не один к одному, а один наш вызов может раскладыватся на несколько внешних вызовов. И в разных внешних системах - это будет разный набор. Что тоже есть адаптер. Так вот, в этой ситуации я лучше забуду применить полноценную стратегию, чем адаптер. Правильный ответ "адаптер + стратегия". И адаптер тут важнее.
И 10-ый вопрос. Там как раз таки сначала будет хэш таблица, а вот в ней ключом будет ид клиента (номер паспорта), а вот значением будет битовая карта. Сначала мы ищем сам ключ, и только потом находим соответствующую битовую карту. Поэтому правильный ответ "хеш таблица + битовая карта". И хеш таблица тут важнее.
И есть вопрос слабо относящийся к программистам (для которых составлена большая часть вопросов). Это вопрос про ИИ. Дата сатанизм имеет свою узкую специфику.
У профессионального программиста не бывает семьи, потому что он изучает новые технологии во вне рабочее время.
В смысле я должен испытывать удивление и огорчение, что у меня багу нашли? В моем коде тестировщики находили такие баги, что даже я не догадался бы, что такое возможно, лично написав код. Это может вызывать только восхищение из профессионализмом.
100% покрытия кода тестами - это как достичь скорости света. Уйма энергии в никуда, правило Парето и тут хорошо работает.
Может пускай Павел пишет читабельный код в хранимках? Да и пока я не заглянул в код хранимки - я не могу сказать разберусь иои нет. И вообще, хранимки у нас теперь антипаттерн.
Вопросы про менеджеров - полностью зависит от того, какой человек этот менеждер. Некоторым достаточно сказать «я попробую, но не обещаю», а не стучать на него высшему руководству.
Мда, никогда не интересовался древнерусским. И тут на тебе - двойственное число. Времена почти как в английском и вообще половина не глаголы. Ааааааааа.
Чистый аджаил хорошо покрывает конкретно разработку программного обеспечения по требованиям, по которым уже была проведена глубокая аналитика. Т.е. управление требованиями остается на совести заказчика/владельца продукта. Но чаще всего заказчик не айтишник и не имеет опыта построения ИТ систем, даже если ему знакома предметная область.
Если каждый набросок в бэклог должен проходить еще и этап аналитики внутри команды разработки, то для начала придется добавить в спринт задачу "описать бизнес-процесс" (= написать ТЗ). А это по факту уже натягивание ватерфолла на спринты.
Мало того, если поторопиться, то придется все кардинально переписывать и не раз. Аджаил говорит "лучше об этом узнать раньше, чем поздно". В принципе логично и правильно. А что нам говорит бизнес? "Почему, чтобы добавить кнопку вам надо месяц и все переписать" или "Какого ... я должен оплачивать переработки складских работников, которые вынуждены по ночам переставлять товар и переклеивать штрихкоды. Вы что не можете сразу по-нормальному сделать???!!!".
Нет, не могут. Потому что по аджаилу в бэклог набрасывают заженные спички, а команда разработки занимается тушением пожаров.
Если вернутся к вашим банковским системам, то для дальнейшего развития и устранения багов аджаил подходит довольно хорошо, о чем вы и написали в своей статье. Почему? Потому что вы пришли на устоявшуюся систему, которая 146% была реализована по ватерфоллу 20 лет назад. А что будет если вам дадут задачу написать АБС с нуля по аджаилу? Не узнаешь пока не попробуешь. Но никто этого делать не будет.
При этом использование аджаила в гораздо более простых системах (как мой пример со складом) уже обнажает проблемы. Нельзя начинать писать код без предварительного анализа бизнес-процессов (=написание ТЗ =ватерфолл). Потому что по итогу приходится не только переписывать программное обеспечение, но и заново расставлять 20 тыс позиций на складе по новым правилам. В аджаиле об этом ни слова.
При этом можно поднятся выше программного обеспечения. И применить аджаил на всех этапах и начать с описания бизнес-процессов. Но хорошо бы выбрать какое-то иное средство прототипирования. Непосредственно кодинг конечно быстрее, чем строить дом, но порой не достаточно быстро. Например, как в фильме про братьев Макдональдс. Они на асфальте рисовали мелом расстановку кухонных блоков и тестировали процесс быстрого приготовления пищи. Т.е. спринт у них был ну 1 час. Тут кстати в целом интересный момент. Макдональдс существует со своими бизнес-процессами с 1940, а персональные компьютеры появились только спустя 40 лет. Что как раз и доказывает, что компьютеры это инструмент, а программное обеспечение - лишь малая часть бизнес-процесса.
Аналогичная проблема при использовании TDD. Нельзя сначала писать тесты, а потом реализацию. Потому что в процессе описания бизнес-процессов, уточнения требований, раз за разом придется с нуля переписывать все эти тесты. Тесты нужно писать на уже более-менее стабильный функционал.
Аджаил, который я упоминаю - это совокупность всего, в том числе конкретных методик типа scrum/kanban/lean.
Вы по-прежнему остаетесь в рамках программного обеспечения. Абстрагируйтесь от него, ведь оно стало массовым только в последние лет 30-40, когда появились первые персональные компьютеры. Если подняться выше - увидите всю картину.
Элементы аджаила зародились не в ИТ, а как минимум в Японии после второй мировой войны в сфере производства. Просто бравые, по большей части, американские парни подумали "а чем мы хуже" и решили адаптировать это дело под производство программного обеспечения. Но я все же надеюсь они не забывали, что компьютер - это всего лишь инструмент, а программное обеспечение - всего лишь маленькая часть больших бизнес-процессов где бы то ни было (на складах, на заводах, в банках).
На начальной стадии не был сделан User Story Mapping, т.е. сразу ломанулись что-то делать не видя процесса
Погодите, откуда тут взялось описание процесса? По аджаилу к нам приходит заказчик и говорит "сделай то не знаю что", выдавая неопределенные требования на словах в час по чайной ложке. Если уж мы взялись за аналитику и описание бизнес-процессов - разве вся эта писанина не первый этап по ватерфоллу? И как же так вышло?
Если выделять тезисы, то он один - применять аджаил к месту.
Дело не в DoD и тем более не в тестах. Дело в отсутствии общей картины и достаточного анализа. Другими словами в отсутствии более-менее продуманного ТЗ на первое время. Что приводит к факапам, но не с точки зрения аджаила (у него как раз все хорошо), а с точки зрения бизнеса, людей, времени и денег. Область видимости аджаила ограничена, чтобы видеть всю картину и все проблемы, которые он создает.
Таким образом, я призываю не бояться необходимости переписывать, нужно бояться того, что об этом мы узнаем слишком поздно.
Например это. Изначально аджаил оперировал только таким артефактом как программное обеспечение. Если же заглянуть в ГОСТы 19/34, то там можно обнаружить другие виды обеспечения (организационное, методологическое и так далее). Переписывание программного обеспечения - это лишь малая часть.
Я в своем комментарии привел пример из своего опыта. Это обычный бизнес по продаже некоторого физического товара, который захотел новомодные ИТ-штучки и франшизу. Вместо аджаила лучше было бы сесть, подумать, описать бизнес-процессы и обкатать их хотя бы в голове, а лучше на складе, убрать противоречия, увидеть более полную картину. Другими словами составить ТЗ. А вот уже потом включать аджаил, заполнять бэклог, запускать спринты и болтать на митингах часами рабочего времени каждый день. В итоге это займет допустим неделю. А еще пойти на склад, расставить товар по полкам, наклеить свои штрихкоды и ценники, и это займет месяц-два.
Пользователю и клиенту важен продукт (даже если с ним что-то не так, то вы узнаете об этом раньше и сэкономите кучу денег).
Нет, клиенту на самом деле важно увеличение прибыли, уменьшение расходов, поток клиентов, благоприятная атмосфера в рабочем коллективе. И где-то потом уже продукт. Только аджаил этого не замечает.
С аджаилом есть одна проблема. Называется тяп-ляп и в продакшен. Так как никто не анализирует множество требований в совокупности и на противоречия до начала разработки - есть высокий риск на очередном требовании "добавьте кнопку" все переписать с нуля и не раз.
На легаси проектах, которые первично были реализованы по ватерфоллу - этой проблем никто не заметит, потому что на текущем проекте в основном текучка и устоявшиеся бизнес-процессы. А вот для стартапов, которые не знают, какой учет им потребуется партийный или серийный - аджаил вселенское зло. Даже если программист перепишет все за неделю, то наклейки придется печатать и переклеивать на коробках месяц-другой сутками на пролет и всей толпой.
Согласен, а еще удаленка. Я воспользовался вторым способом.
Моему отцу 60, года два назад менял работу, было 2 или 3 офера. Архитектор. Из недавних задач - блокчейн осваивал.
Зависит от многих факторов. У меня было два индикатора:
Внутренний - "делаю одно и тоже, ничего нового" или "а что нового я узнал за последний год-два".
Внешний - поднимаю резюме, и хожу по собеседованиями. Получил офер - значит пока в тонусе. Не получил - значит отстал, пора догонять.
Разумеется я не бежал сразу менять работу. Сначала я изучал что-то новое. Пытался применить это в текущей работе. Но так как регулярное переписывание на новые технологии накладно для бизнеса - однажды наступает такой момент, что пора менять работу.
И сам и по принуждению. Почти 15 лет назад я работал в госучреждении в провинциальном городе. Последние лет 5 - на западные зарубежные компании. Смог бы я получить офер от компании из США/Канады/Австралии на удаленке, если бы все эти 10 лет сидел бы на одном месте? Вот так сразу из грязи в князи? Разумеется нет. Небо и земля. Как по процессам, управлению, так и подходам и технологиям. В ИТ нужно быть релевантным, об этом все знают.
Но условный делфи тут особо не причем. Единственное требование - инструмент должен позволять решать современные задачи, желательно в востребованной области,в идеале в области, которая нравится самому программисту. Сколько у нас энтепрайза и сколько мейнфреймов? Если сам инструмент идет в ногу со временем, то смысла его менять конечно же нет. Но ведь тогда надо и развиваться вместе со своим инструментом. Изучать, щупать его новые возможности.
Мне показалось, что этот человек все 30 лет проработал на одном месте. В нашей стране тоже есть такие 30-летней выдержки в НИИ имени Ленина. Не удивительно, что такие не могут работу найти. Они в целом отстали от профессии, дело не только в условном sql. А в общей эрудиции, погружении в современные темы и тренды.
Разумеется, параллельные миры существуют одновременно.
Жилье за 20-30 лямов могут себе позволить владельцы/топы довольно крупных бизнесов или чиновники/депутаты.
Параллельно им существуют врачи и учителя. Слышал историю в интернетах, как врач из ковидного госпиталя полгода жила как человек, получая 100-130 тр/месяц. Сократила ипотеку на 8 лет.
Ну а программисты где-то посередине.
Хорошая статья, системный подход)
Я работал и с глупыми и с умными аналитиками.
Однажды я пришел на древнее легаси. Так же проблемой было полное незнание предметной области на тот момент и полное отсутствие ориентации в коде. Мне попался умный аналитик. Он как радар наводил меня на нужные участки кода (описывая словами что этот код должен делать), я находил эти места, вносил изменения и мы вместе тестировали. Позже я уже начал ориентироватся в коде, и немного в предметной области. Это был положительный опыт.
Некоторое время спустя на этом проекте сменился аналитик. Он был глупым. Проект и я не поменялся. Но уже я ему рассказывал про проект, то что знал. Это был отрицательный опыт.
В другой раз мне попался глупый аналитик, который писал в стиле «система должна уметь…». Он не представлял сколько времени займет реализация и можно ли вообще это сделать. Я получил крайне негативный опыт.
В той же компании на другом проекте мне попался умный аналитик. Из ее описаний я чуть ли не один к одному перекладывал интерфейсы модулей и енумы. А потом в конце этапов мы синхронизировали код и документацию. Это был крайне позитивный опыт.
Участвовал в проекте, это была продуктовая компания, где постановой задач занимался сам CEO/CTO и другие сотрудники, которые в том числе и сами пользовались этим софтом. Опыт смешанный. Они были ближе к глупым аналитикам. По сути они не были аналитиками, а пользователями и переводчиками требований от внешних клиентов. Вся документация была разбросана по задачам в жире. И вот это было ужасно. Программистов перекидывали с модуля на модуль и когда возвращался обратно - приходилось по таскам в жире восстанавливать последовательность изменений, чтобы понимать что там произошло, как все это тестировать и что-нибудь не сломать.
Так же я участвовал в проектах, где я сам был и аналитиком и программистом. Из плюсов - лучше понимаешь предметную область. Из минусов - быстро надоедает и нельзя одновременно анализировать на верхнем уровне и кодить с поиском крайних кейсов на нижнем. Время разработки увеличивается раза в два. И это были совсем небольшие проекты, на 2-4 человека месяца. Бонусом были восторженные благодарности за продукт, который реально помогал людям. Опыт смешанный, полезный и познавательный, но я за разделение труда. Пока аналитик думает, как это должно выглядеть - я успею что-нибудь сделать по другой задаче/проекту.
Главный минус серой зп - не выплатят при увольнении (= могут кинуть).
Главный минус белой зп - пенсионные накопления отберут / сгорят (= могут кинуть).
Поэтому я бы смотрел в сторону правильно оформленных отношений через ИП (несколько договоров, работа по этапам / тз). Это повышает шанс остаться при своих в обоих случаях.
Я имел ввиду именно тех, кто из России/Украины/Белоруссии/СНГ. Еще бывает удаленка на зарубеж. В целом-то понятно, что они звезды. Хотелось бы конкретики, если кто-то таких знает.
Пожалуй у всех программистов была/есть мечта написать программу, которая пишет программы. Но по факту тем самым программисты будут пилить сук, на котором сидят.
Через 10 лет программисты все еще будет нужны. Но появятся принципиально новые технологии (например сейчас у нас идет развитие квантовых компьютеров).
И думаю рано или поздно появится какой-нибудь нейроинтерфейс, который позволит исключить руки из процесса написания кода. Они на данный момент являются бутылочным горлышком.
А каким java программистом надо быть, чтобы зарабатывать 10k$ в месяц?
Есть пара не очень понятных вопросов.
Осторожно спойлер
Вопрос с паттерном стратегия. Как раз была такая ситуация на реальном проекте. Наличие стратегии не является достаточным условием. Вызовы во внешние системы идут не один к одному, а один наш вызов может раскладыватся на несколько внешних вызовов. И в разных внешних системах - это будет разный набор. Что тоже есть адаптер. Так вот, в этой ситуации я лучше забуду применить полноценную стратегию, чем адаптер. Правильный ответ "адаптер + стратегия". И адаптер тут важнее.
И 10-ый вопрос. Там как раз таки сначала будет хэш таблица, а вот в ней ключом будет ид клиента (номер паспорта), а вот значением будет битовая карта. Сначала мы ищем сам ключ, и только потом находим соответствующую битовую карту. Поэтому правильный ответ "хеш таблица + битовая карта". И хеш таблица тут важнее.
И есть вопрос слабо относящийся к программистам (для которых составлена большая часть вопросов). Это вопрос про ИИ. Дата сатанизм имеет свою узкую специфику.
Смутило про уголь - чтобы отапливать дома всю зиму этот уголь надо вагонами подвозить. Там действительно так много угля?
Насчет собак - надо же. В России такая же схема. И они спокойные, если сам человек идет без своей собаки.
Ерунда какая-то...
У профессионального программиста не бывает семьи, потому что он изучает новые технологии во вне рабочее время.
В смысле я должен испытывать удивление и огорчение, что у меня багу нашли? В моем коде тестировщики находили такие баги, что даже я не догадался бы, что такое возможно, лично написав код. Это может вызывать только восхищение из профессионализмом.
100% покрытия кода тестами - это как достичь скорости света. Уйма энергии в никуда, правило Парето и тут хорошо работает.
Может пускай Павел пишет читабельный код в хранимках? Да и пока я не заглянул в код хранимки - я не могу сказать разберусь иои нет. И вообще, хранимки у нас теперь антипаттерн.
Вопросы про менеджеров - полностью зависит от того, какой человек этот менеждер. Некоторым достаточно сказать «я попробую, но не обещаю», а не стучать на него высшему руководству.
Теперь интересно послушать мнение того, кто это задание выдавал.
Мда, никогда не интересовался древнерусским. И тут на тебе - двойственное число. Времена почти как в английском и вообще половина не глаголы. Ааааааааа.
Короче, суть в чем.
Чистый аджаил хорошо покрывает конкретно разработку программного обеспечения по требованиям, по которым уже была проведена глубокая аналитика. Т.е. управление требованиями остается на совести заказчика/владельца продукта. Но чаще всего заказчик не айтишник и не имеет опыта построения ИТ систем, даже если ему знакома предметная область.
Если каждый набросок в бэклог должен проходить еще и этап аналитики внутри команды разработки, то для начала придется добавить в спринт задачу "описать бизнес-процесс" (= написать ТЗ). А это по факту уже натягивание ватерфолла на спринты.
Мало того, если поторопиться, то придется все кардинально переписывать и не раз. Аджаил говорит "лучше об этом узнать раньше, чем поздно". В принципе логично и правильно. А что нам говорит бизнес? "Почему, чтобы добавить кнопку вам надо месяц и все переписать" или "Какого ... я должен оплачивать переработки складских работников, которые вынуждены по ночам переставлять товар и переклеивать штрихкоды. Вы что не можете сразу по-нормальному сделать???!!!".
Нет, не могут. Потому что по аджаилу в бэклог набрасывают заженные спички, а команда разработки занимается тушением пожаров.
Если вернутся к вашим банковским системам, то для дальнейшего развития и устранения багов аджаил подходит довольно хорошо, о чем вы и написали в своей статье. Почему? Потому что вы пришли на устоявшуюся систему, которая 146% была реализована по ватерфоллу 20 лет назад. А что будет если вам дадут задачу написать АБС с нуля по аджаилу? Не узнаешь пока не попробуешь. Но никто этого делать не будет.
При этом использование аджаила в гораздо более простых системах (как мой пример со складом) уже обнажает проблемы. Нельзя начинать писать код без предварительного анализа бизнес-процессов (=написание ТЗ =ватерфолл). Потому что по итогу приходится не только переписывать программное обеспечение, но и заново расставлять 20 тыс позиций на складе по новым правилам. В аджаиле об этом ни слова.
При этом можно поднятся выше программного обеспечения. И применить аджаил на всех этапах и начать с описания бизнес-процессов. Но хорошо бы выбрать какое-то иное средство прототипирования. Непосредственно кодинг конечно быстрее, чем строить дом, но порой не достаточно быстро. Например, как в фильме про братьев Макдональдс. Они на асфальте рисовали мелом расстановку кухонных блоков и тестировали процесс быстрого приготовления пищи. Т.е. спринт у них был ну 1 час. Тут кстати в целом интересный момент. Макдональдс существует со своими бизнес-процессами с 1940, а персональные компьютеры появились только спустя 40 лет. Что как раз и доказывает, что компьютеры это инструмент, а программное обеспечение - лишь малая часть бизнес-процесса.
Аналогичная проблема при использовании TDD. Нельзя сначала писать тесты, а потом реализацию. Потому что в процессе описания бизнес-процессов, уточнения требований, раз за разом придется с нуля переписывать все эти тесты. Тесты нужно писать на уже более-менее стабильный функционал.
Аджаил, который я упоминаю - это совокупность всего, в том числе конкретных методик типа scrum/kanban/lean.
Вы по-прежнему остаетесь в рамках программного обеспечения. Абстрагируйтесь от него, ведь оно стало массовым только в последние лет 30-40, когда появились первые персональные компьютеры. Если подняться выше - увидите всю картину.
Элементы аджаила зародились не в ИТ, а как минимум в Японии после второй мировой войны в сфере производства. Просто бравые, по большей части, американские парни подумали "а чем мы хуже" и решили адаптировать это дело под производство программного обеспечения. Но я все же надеюсь они не забывали, что компьютер - это всего лишь инструмент, а программное обеспечение - всего лишь маленькая часть больших бизнес-процессов где бы то ни было (на складах, на заводах, в банках).
Погодите, откуда тут взялось описание процесса? По аджаилу к нам приходит заказчик и говорит "сделай то не знаю что", выдавая неопределенные требования на словах в час по чайной ложке. Если уж мы взялись за аналитику и описание бизнес-процессов - разве вся эта писанина не первый этап по ватерфоллу? И как же так вышло?
Если выделять тезисы, то он один - применять аджаил к месту.
Дело не в DoD и тем более не в тестах. Дело в отсутствии общей картины и достаточного анализа. Другими словами в отсутствии более-менее продуманного ТЗ на первое время. Что приводит к факапам, но не с точки зрения аджаила (у него как раз все хорошо), а с точки зрения бизнеса, людей, времени и денег. Область видимости аджаила ограничена, чтобы видеть всю картину и все проблемы, которые он создает.
Например это. Изначально аджаил оперировал только таким артефактом как программное обеспечение. Если же заглянуть в ГОСТы 19/34, то там можно обнаружить другие виды обеспечения (организационное, методологическое и так далее). Переписывание программного обеспечения - это лишь малая часть.
Я в своем комментарии привел пример из своего опыта. Это обычный бизнес по продаже некоторого физического товара, который захотел новомодные ИТ-штучки и франшизу. Вместо аджаила лучше было бы сесть, подумать, описать бизнес-процессы и обкатать их хотя бы в голове, а лучше на складе, убрать противоречия, увидеть более полную картину. Другими словами составить ТЗ. А вот уже потом включать аджаил, заполнять бэклог, запускать спринты и болтать на митингах часами рабочего времени каждый день. В итоге это займет допустим неделю. А еще пойти на склад, расставить товар по полкам, наклеить свои штрихкоды и ценники, и это займет месяц-два.
Нет, клиенту на самом деле важно увеличение прибыли, уменьшение расходов, поток клиентов, благоприятная атмосфера в рабочем коллективе. И где-то потом уже продукт. Только аджаил этого не замечает.
С аджаилом есть одна проблема. Называется тяп-ляп и в продакшен. Так как никто не анализирует множество требований в совокупности и на противоречия до начала разработки - есть высокий риск на очередном требовании "добавьте кнопку" все переписать с нуля и не раз.
На легаси проектах, которые первично были реализованы по ватерфоллу - этой проблем никто не заметит, потому что на текущем проекте в основном текучка и устоявшиеся бизнес-процессы. А вот для стартапов, которые не знают, какой учет им потребуется партийный или серийный - аджаил вселенское зло. Даже если программист перепишет все за неделю, то наклейки придется печатать и переклеивать на коробках месяц-другой сутками на пролет и всей толпой.