Спасибо автору, есть действительно рабочие методы, которые применяю сам и довольно успешно
Но хочется подсветить одну очень банальную вещь. Оценка задач это навык, который не так сложно развить. И если у вас разработка регулярно не попадает в оценку на 70%, значит компетенции у разработки недостаточно и ее нужно развивать, а не воспринимать как нормальную историю
В реальный срок добавляется еще куча всего: ревью кода, правки по ревью, тестирование, правки по тестированию, согласования с аналитиком, созвоны по уточнениям, ожидание доступов от DevOps, ожидание, пока заказчик посмотрит, ожидание, пока кто-нибудь развернет на стейдже
Все, что вы тут перечислили должно быть заложено и проработно менеджером на этапе планирования, эти риски стандартны и возникают почти на любом проекте
Скажу честно, отчасти с автором я согласен, но если которые ведёт менеджер регулярно НЕ сдаются в срок, значит компетенции менеджера недостаточно и в первую очередь нужно работать над собой, а не пытаться себя оправдывать тем что в большинстве проектов так. И тут автору еще раз спасибо, действительно действительные способы
О человеке-оркестре уже тут написали, дублировать не буду, с мнением предыдущего комментатора полностью согласен
Хотелось бы обратить внимание на другое интересное заблуждение в статье
— Осознанно ли он делает выбор в нашу пользу, или мы просто очередная компания?
Да, вы просто очередная компания, основная цель сотрудника это заработок, кто бы что не говорил про саморазвитие, интерес к компании и прочее. Да, другие факторы тоже имеют место быть, но основное это всегда заработок
И плевать большинство людей хотели на то как называется ваша компания.
Подобные высказывания у меня сразу вызывают ассоциации с фразой "мы все семья". Нет, мы не семья. И да, вы в какой-то момент окажетесь просто очередной компанией для каждого сотрудника, даже который сейчас у вас работает.
Рынок труда это просто взаимовыгодное использование, считаю пора прекращать его романитизировать
Спасибо за ответ! Очень интересно увидеть более глубокое обоснование подхода.
Согласна с тем, что любая практика — это инструмент, и вопрос действительно в том, как и где её применять.
Тем не менее, когда я говорила о смешении уровней, я скорее имела в виду, что в статье фокус периодически смещается от философии Agile к конкретным проблемам инженерного процесса — и из-за этого создаётся ощущение, будто речь идёт именно о несостоятельности Agile как концепции, а не о трудностях его внедрения. К тому же само название статьи — «Тише едешь — дальше будешь: почему новомодные Agile-методологии уступают подходам прошлого века» — изначально задаёт противопоставление, поэтому материал и воспринимается в таком ключе, даже несмотря на заключение.
По поводу терминологии: согласна, что в широком смысле методология — это система приёмов, но в профессиональной среде разработчиков этот термин чаще применяют к управленческим фреймворкам (Scrum, Kanban и др.), а инженерные практики вроде DF, TDD или BDD называют подходами или техниками. Это помогает избежать путаницы при обсуждении.
Documentation First приводит к повышению гарантий качества и не исключает соблюдения ценностей семейства Agile
Полностью разделяю мысль, что Documentation First может стать мостом между дисциплиной и гибкостью. Возможно, если бы в статье чуть чётче звучало, что DF не альтернатива Agile, а его осознанное дополнение, идея воспринималась бы ещё сильнее.
В любом случае, спасибо за интересный материал и развёрнутый ответ — тема действительно интересная. И, как мы видим, не теряет актуальности
Интересная и живо написанная статья. Но автор очевидно смешал несколько разных уровней обсуждения — методологический, организационный и инженерный. В результате критика Agile выглядит не корректно.
Во-первых, Agile — не методология, а набор ценностей и принципов, из которых выросли конкретные фреймворки (Scrum, Kanban, XP и др.). Говорить о «провале Agile-методологий» некорректно — проблема не в Agile как идее, а в том, как его внедряют. Если команда показывает заказчику «div без стилей», это не издержка методологии, а отсутствие продуманного Definition of Done и нормального планирования.
Во-вторых, Documentation First сам по себе — не методология, а инженерная практика, усиливающая этап проектирования. Это вполне может быть частью Agile-процесса: никто не запрещает писать документацию перед кодом, если она помогает повысить осознанность и качество. Agile лишь предлагает не превращать документацию в самоцель, а держать баланс между скоростью и глубиной проработки.
По сути, описанная в статье боль — это типичные проблемы зрелых продуктов с техническим долгом, а не ограничения Agile. Здесь скорее видно, что трудности возникли не из-за гибкости, а из-за её формального применения. Чтобы внедрить Agile, важно ясно понимать, что это такое и как с ним работать. Без этого любая попытка превращается в набор ритуалов без понимания сути. И проблемы, которые автор описывает, решаются не сменой фреймворка, а через развитие культуры анализа, прозрачности и взаимодействия внутри команды.
Идея Documentation First вполне здравая и может отлично работать в связке с гибкими фреймворками. Но было бы честнее говорить не о «возвращении к старым методологиям», а о восстановлении инженерной культуры внутри Agile-среды. Тогда статья звучала бы не как критика гибкости, а как призыв к осознанности и системности — чего сегодня действительно не хватает многим командам.
Спасибо автору, есть действительно рабочие методы, которые применяю сам и довольно успешно
Но хочется подсветить одну очень банальную вещь. Оценка задач это навык, который не так сложно развить. И если у вас разработка регулярно не попадает в оценку на 70%, значит компетенции у разработки недостаточно и ее нужно развивать, а не воспринимать как нормальную историю
Все, что вы тут перечислили должно быть заложено и проработно менеджером на этапе планирования, эти риски стандартны и возникают почти на любом проекте
Скажу честно, отчасти с автором я согласен, но если которые ведёт менеджер регулярно НЕ сдаются в срок, значит компетенции менеджера недостаточно и в первую очередь нужно работать над собой, а не пытаться себя оправдывать тем что в большинстве проектов так. И тут автору еще раз спасибо, действительно действительные способы
О человеке-оркестре уже тут написали, дублировать не буду, с мнением предыдущего комментатора полностью согласен
Хотелось бы обратить внимание на другое интересное заблуждение в статье
Да, вы просто очередная компания, основная цель сотрудника это заработок, кто бы что не говорил про саморазвитие, интерес к компании и прочее. Да, другие факторы тоже имеют место быть, но основное это всегда заработок
И плевать большинство людей хотели на то как называется ваша компания.
Подобные высказывания у меня сразу вызывают ассоциации с фразой "мы все семья". Нет, мы не семья. И да, вы в какой-то момент окажетесь просто очередной компанией для каждого сотрудника, даже который сейчас у вас работает.
Рынок труда это просто взаимовыгодное использование, считаю пора прекращать его романитизировать
Спасибо за ответ! Очень интересно увидеть более глубокое обоснование подхода.
Согласна с тем, что любая практика — это инструмент, и вопрос действительно в том, как и где её применять.
Тем не менее, когда я говорила о смешении уровней, я скорее имела в виду, что в статье фокус периодически смещается от философии Agile к конкретным проблемам инженерного процесса — и из-за этого создаётся ощущение, будто речь идёт именно о несостоятельности Agile как концепции, а не о трудностях его внедрения. К тому же само название статьи — «Тише едешь — дальше будешь: почему новомодные Agile-методологии уступают подходам прошлого века» — изначально задаёт противопоставление, поэтому материал и воспринимается в таком ключе, даже несмотря на заключение.
По поводу терминологии: согласна, что в широком смысле методология — это система приёмов, но в профессиональной среде разработчиков этот термин чаще применяют к управленческим фреймворкам (Scrum, Kanban и др.), а инженерные практики вроде DF, TDD или BDD называют подходами или техниками. Это помогает избежать путаницы при обсуждении.
Полностью разделяю мысль, что Documentation First может стать мостом между дисциплиной и гибкостью. Возможно, если бы в статье чуть чётче звучало, что DF не альтернатива Agile, а его осознанное дополнение, идея воспринималась бы ещё сильнее.
В любом случае, спасибо за интересный материал и развёрнутый ответ — тема действительно интересная. И, как мы видим, не теряет актуальности
Интересная и живо написанная статья. Но автор очевидно смешал несколько разных уровней обсуждения — методологический, организационный и инженерный. В результате критика Agile выглядит не корректно.
Во-первых, Agile — не методология, а набор ценностей и принципов, из которых выросли конкретные фреймворки (Scrum, Kanban, XP и др.). Говорить о «провале Agile-методологий» некорректно — проблема не в Agile как идее, а в том, как его внедряют. Если команда показывает заказчику «div без стилей», это не издержка методологии, а отсутствие продуманного Definition of Done и нормального планирования.
Во-вторых, Documentation First сам по себе — не методология, а инженерная практика, усиливающая этап проектирования. Это вполне может быть частью Agile-процесса: никто не запрещает писать документацию перед кодом, если она помогает повысить осознанность и качество. Agile лишь предлагает не превращать документацию в самоцель, а держать баланс между скоростью и глубиной проработки.
По сути, описанная в статье боль — это типичные проблемы зрелых продуктов с техническим долгом, а не ограничения Agile. Здесь скорее видно, что трудности возникли не из-за гибкости, а из-за её формального применения. Чтобы внедрить Agile, важно ясно понимать, что это такое и как с ним работать. Без этого любая попытка превращается в набор ритуалов без понимания сути. И проблемы, которые автор описывает, решаются не сменой фреймворка, а через развитие культуры анализа, прозрачности и взаимодействия внутри команды.
Идея Documentation First вполне здравая и может отлично работать в связке с гибкими фреймворками. Но было бы честнее говорить не о «возвращении к старым методологиям», а о восстановлении инженерной культуры внутри Agile-среды. Тогда статья звучала бы не как критика гибкости, а как призыв к осознанности и системности — чего сегодня действительно не хватает многим командам.