я добавил "(оригинал: story points)", чтобы было понятно, о чем речь. я подумаю как точнее и ближе по смыслу перевести "story points". В английском используют story, и по смыслу мне показалась что "сюжет" подойдет. Что делать, если лексика agile имеет отношение и литературе?
Английские кальки еще более отвратительны. Я владею английским практически на уровне как родного русского, но все эти "это сделало мой день" и прочии кальки меня просто бесят.
По смыслу это "сюжетные баллы", ну или "баллы за историю", "баллы истории". Поправил "точки" на "баллы".
Наш национальный язык русский, а не анлийский, и тем более не английские кальки. Мне остается сожалеть, что те, кто учил вас agile, не удосужились сделать правильный перевод "story points"
story points переводится на русский как "сюжетные точки" или "сюжетные баллы". В России государственным языком является русский язык, им и следует пользоваться, а не кальками с английского. Ну, если в России живете.
Ну если заказчик не умеет правильно оценивать риски, может ему и не место в IT? Кроме того, заказчик может заложить в контракте с исполнителем неустойку, что переложит риски на плечи исполнителя.
Сейчас есть желание как раз добавить туда водопада) (описать фичи, сделать базовое ТЗ, выбрать стек) и попробовать заново с минимальными требованиями, чтобы хоть что то сделать )
Ну, разумно. В agile нет долгосрочного планирования, как результат нет и нормальной, расширяемой архитектуры. Вместо этого есть постоянное переделывание. Непонятно, зачем такой методологией вообще пользоваться.
Водопад порождает ТЗ, ТЗ порождает фичи, план, архитектуру, и спецификацию конечного продукта. По спецификации конечного продукта Вы будете судить, закончен ли продукт или нет, например просто проставляя галочки напротив каждой фичи/функционала.
Самое веселье начинается когда заказчик постоянно меняет требования, но отказывается платить так как не получает конечного продукта. Это приводит к банкротству компании и сокращению персонала, знаю из опыта.
Фактически, Вы написали что его нельзя пихать везде и всюду, а у нас его именно везде и всюду и пихают. Поскольку почти вся инфраструктура сейчас зиждется на IT, лично я в этом вижу угрозу нашей национальной безопасности. Как пример, Вы согласитесь лететь на самолете, который проектировали и собирали по Agile?
А не утонуть в постоянных изменениях требований к продукту по каждому чиху - а давайте это добавим и это. Так никогда и не закончишь mvp. Это морально выматывает, сам с таким столкнулся
И я тоже. А автор статьи так и пишет: "It also has the potential for scope creep, and an ever-changing product becomes an ever-lasting one." (что я перевел как "У Agile также есть потенциал для непрерывного и/или неконтролируемого рост объема проекта, и вечно меняющийся продукт становится вечнодлящимся проектом.")
Аджайл, это комбинация фундаментальной ошибка научного метода (если метод хорошо работает, то он должен хорошо работать всегда и везде) и системной ошибки выжившего (обоснование доказательства работы метода только по подтверждающим результатам и игнорирование отрицательных / противоположных фактов).
Это скорее к тем, кто его везде пихает.
Он поощряет продуктовый экстремизм со стороны заказчиков, поощряет тяп-ляп (низкое качество из-за ожидания частых изменений) и работает только для универсальных команд (без разделения общих ресурсов).
В точку. А теперь вопрос: а в каких компаниях распространены универсальные команды и почему? Может быть, универсальная команда -- признак "галеры", и их делают универсальными исходя из принципа "незаменимых людей быть не должно"? Как Вы считаете?
А вот большинство перечисленных в статье проблем к Аджайлу отношения не имеют и могут встречаться в любых проектах не зависимо от методологии.
В случае с Waterfall спрогнозировать трудозатраты на новую разработку возможно только получения детального ТЗ. А время на подготовку ТЗ плохо прогнозируется для нового продукта.
Как раз возможно и без детального ТЗ. Любой разработчик с опытом от 2 лет сможет сказать сколько приблизительно у него займет выполнение работы по ТЗ, даже если ТЗ и неполное. Оценка трудоемкости ТЗ -- одна из обязанностей разработчика, и если в компании разработчики не способны это сделать, то увы этой компании. Возможно она вообще не должна заниматься IT бизнесом.
Методология разработки либо поощряет прогнозирование, либо нет. В случает Waterfall необходимо думать наперёд (то есть осуществлять стратегическое планирование), а в Agile - нет. Если нет стратегического планирования, то нет и продуманной архитектуры, а если нет продуманной архитектуры, то в конечном итоге программный продукт хорошим не станет. По крайней мере, более-менее сложный программный продукт
При работе по Waterfall тоже взаимодействуешь с заказчиком, просто нет так интенсивно как в Аgile
ТЗ формализует процесс разработки, оно необходимо
Не лучше. Я лично столкнулся именно с той ситуацией, что описана в этом пункте: пришел в стартап который работал над ПО, сорцы документированы не были, разобраться в них было очень трудно и приходилось дергать разработчиков что уже были "в теме". А это время. А сами сорцы, кстати, представляли жуткий пример техдолга. Но "работающий софт важнее исчерпывающей документации", несомненно; проблема в том что без документации а) перестаешь понимать как он работает, б) софт становится невозможно развивать дальше.
Реальность то, о чем договорились в контракте с заказчиком. А что он требования постоянно меняет, так пусть сначала определиться с тем, что хочет, потом заключает контракт
В странах Азии тоже смотрят. А в США на возраст смотрят на возраст когда вы уже на интервью лично явились, но боятся дискриминировать так как знают что это незаконно и их могут засудить. Вот, собственно, и весь сказ — адвокатов они боятся, а не потому что они какие-то добряки.
после сорока вас интересует не ваш личностный/профессиональный рост, а рост вашего счета в банке. ориентироваться стоит именно на это. в 50 вы уже будете нахрен никому не нужны.
я добавил "(оригинал: story points)", чтобы было понятно, о чем речь. я подумаю как точнее и ближе по смыслу перевести "story points". В английском используют story, и по смыслу мне показалась что "сюжет" подойдет. Что делать, если лексика agile имеет отношение и литературе?
Английские кальки еще более отвратительны. Я владею английским практически на уровне как родного русского, но все эти "это сделало мой день" и прочии кальки меня просто бесят.
По смыслу это баллы, ну или очки.
По смыслу это "сюжетные баллы", ну или "баллы за историю", "баллы истории". Поправил "точки" на "баллы".
Наш национальный язык русский, а не анлийский, и тем более не английские кальки. Мне остается сожалеть, что те, кто учил вас agile, не удосужились сделать правильный перевод "story points"
story points переводится на русский как "сюжетные точки" или "сюжетные баллы". В России государственным языком является русский язык, им и следует пользоваться, а не кальками с английского. Ну, если в России живете.
PS. поправлю на "сюжетные баллы"
Ну если заказчик не умеет правильно оценивать риски, может ему и не место в IT? Кроме того, заказчик может заложить в контракте с исполнителем неустойку, что переложит риски на плечи исполнителя.
Все верно. Нет ТЗ, нет долгосрочного планирования, а как результат нет ни нормальной архитектуры, ни конечного продукта.
Ну так пусть получит столько денег, на сколько оценил свою работу. В следующий раз не ошибется. Такое вот обучение с подкреплением.
Ну, закономерно: результат ничто, процесс -- всё! Типично для agile.
Ну, разумно. В agile нет долгосрочного планирования, как результат нет и нормальной, расширяемой архитектуры. Вместо этого есть постоянное переделывание. Непонятно, зачем такой методологией вообще пользоваться.
Водопад порождает ТЗ, ТЗ порождает фичи, план, архитектуру, и спецификацию конечного продукта. По спецификации конечного продукта Вы будете судить, закончен ли продукт или нет, например просто проставляя галочки напротив каждой фичи/функционала.
Ну, Вы смелый человек. Лично я в такой самолет не сяду. С другой стороны Илон Маск ракеты в космос запускает, а в SpaceX по agile работают, если не знали: https://cliffberg.medium.com/spacexs-use-of-agile-methods-c63042178a33
А конечный продукт нормальный получился, без техдолга, в том или ином виде? Или его до сих пор не закончили?
Самое веселье начинается когда заказчик постоянно меняет требования, но отказывается платить так как не получает конечного продукта. Это приводит к банкротству компании и сокращению персонала, знаю из опыта.
Фактически, Вы написали что его нельзя пихать везде и всюду, а у нас его именно везде и всюду и пихают. Поскольку почти вся инфраструктура сейчас зиждется на IT, лично я в этом вижу угрозу нашей национальной безопасности. Как пример, Вы согласитесь лететь на самолете, который проектировали и собирали по Agile?
И я тоже. А автор статьи так и пишет: "It also has the potential for scope creep, and an ever-changing product becomes an ever-lasting one." (что я перевел как "У Agile также есть потенциал для непрерывного и/или неконтролируемого рост объема проекта, и вечно меняющийся продукт становится вечнодлящимся проектом.")
Это скорее к тем, кто его везде пихает.
В точку. А теперь вопрос: а в каких компаниях распространены универсальные команды и почему? Может быть, универсальная команда -- признак "галеры", и их делают универсальными исходя из принципа "незаменимых людей быть не должно"? Как Вы считаете?
С какими из них Вы встречались в Waterfall'е?
Как раз возможно и без детального ТЗ. Любой разработчик с опытом от 2 лет сможет сказать сколько приблизительно у него займет выполнение работы по ТЗ, даже если ТЗ и неполное. Оценка трудоемкости ТЗ -- одна из обязанностей разработчика, и если в компании разработчики не способны это сделать, то увы этой компании. Возможно она вообще не должна заниматься IT бизнесом.
И каков конечный результат такой деятельности?
Они не странные, они жизненные.
Методология разработки либо поощряет прогнозирование, либо нет. В случает Waterfall необходимо думать наперёд (то есть осуществлять стратегическое планирование), а в Agile - нет. Если нет стратегического планирования, то нет и продуманной архитектуры, а если нет продуманной архитектуры, то в конечном итоге программный продукт хорошим не станет. По крайней мере, более-менее сложный программный продукт
При работе по Waterfall тоже взаимодействуешь с заказчиком, просто нет так интенсивно как в Аgile
ТЗ формализует процесс разработки, оно необходимо
Не лучше. Я лично столкнулся именно с той ситуацией, что описана в этом пункте: пришел в стартап который работал над ПО, сорцы документированы не были, разобраться в них было очень трудно и приходилось дергать разработчиков что уже были "в теме". А это время. А сами сорцы, кстати, представляли жуткий пример техдолга. Но "работающий софт важнее исчерпывающей документации", несомненно; проблема в том что без документации а) перестаешь понимать как он работает, б) софт становится невозможно развивать дальше.
Реальность то, о чем договорились в контракте с заказчиком. А что он требования постоянно меняет, так пусть сначала определиться с тем, что хочет, потом заключает контракт
В странах Азии тоже смотрят. А в США на возраст смотрят на возраст когда вы уже на интервью лично явились, но боятся дискриминировать так как знают что это незаконно и их могут засудить. Вот, собственно, и весь сказ — адвокатов они боятся, а не потому что они какие-то добряки.