Message from 奥诚掎 deleted. Reason: new user and forwarded (?)

п.3 не согласен.
1. Продукт существует пока есть бэк лог. Т.о. если вы забыли о продукте(или его части) после заливки, то он на пути к R.I.P.
2. Если хотите получить 100% без багов функционал, то вы на тестировании уйдёте в вечность. Даже на поддержке не гарантируют 100% надежность и доступность. Деплой должен соответствовать DoD и критериям приёмки.

В комментариях к одной из моих статей про Scrum на vc.ru, как это часто бывает, появились люди, утверждающие что никаких данных и никакой статистики, подтверждающей эффективность Agile, нет и все это - чистая пропаганда. Я знаю, что статистика есть, я ее слышал в ряде докладов, в том числе - в докладе Сазерленда на SECR-2011 http://2011.secrus.org/lang/ru-ru/key-speakers/jeff-sutherland ссылку на который привел. Но такие люди обычно не хотят истины, они хотят лишь увериться в правильности своего мнения. Поэтому подобные ссылки быстро объявляют предвзятым мнением, а не разбираться. И, поскольку у всякой такой дискуссии есть читатели, то я сделал еще пару шагов, результаты которых тут публикую.

Я довольно быстро вышел на статью Michael Sweeney Agile vs Waterfall: Which Method is More Successful? https://clearcode.cc/blog/agile-vs-waterfall-method/ со статистикой и ссылками и на несколько отчетов. 2013 IT Project Success Rates Survey Results http://www.ambysoft.com/surveys/success2013.html, 2018 IT Project Success Rates Survey Results http://www.ambysoft.com/surveys/success2018.html (на сайте есть и другие) и Standish Group 2015 Chaos Report https://www.infoq.com/articles/standish-chaos-2015/

Можно по-разному относиться к качеству этих отчетов, но фишка в том, что у защитников регулярного менеджмента (включая проектный) и даже такой статистики нет. Если же смотреть по-существу, то основная претензия о том, что в методике просто опрашивали о применяемом методе, а не проверяли, насколько он соответствует каноническому описанию. Но эта претензия - не важна. Люди взяли метод, и применяют его с тем качеством, с которым могут. И дальше их проект оказывается успешен или не успешен - и это характеризует метод, а не только людей. Метод, который невозможно качественно применить бесполезен, даже если он якобы гарантирует результат.

Во всех этих отчетах Agile-методы рассматриваются без разделения. Но по ним есть отдельная статистика, которую ежегодно публикует Version One https://www.stateofagile.com/ а пару лет назад ScrumTrek начал публиковать такую же по России. И на нее можно опираться. Среди методов Scrum рулит :)

Отмечу еще, что многие из компаний, которые начинают применять Agile, оценивают его эффективность по внутренним показателям. И когда эти кейсы рассказывают - то говорят о цифрах эффективности или, чаще, о возможностях которые дал Agile. Примером служит доклад «Банк России: знать путь и пройти его — не одно и то же» https://youtu.be/UeXBwq7rXX8 на AgileDays-2018, в котором приводили такой пример: используя Scrum за полгода удалось сделать первый такт изменений, к которым до этого не могли подступиться полтора года, и которые по самым оптимистичным оценкам требовали не менее полутора лет. А тут решили попробовать итерациями, и получили значимый результат. Как легко догадаться формально получается, что Agile эффективнее в бесконечное число раз. Впрочем, скептики объявляют эти данные частными случаями, им нужны исследования.

Впрочем, зарубежный опыт говорит, что упертых защитников старого можно убедить только директивно. Во всяком случае, история зарубежного опыта, которую я услышал AgileKitchen в аппарате правительства в 2015 (мой конспект http://mtsepkov.org/GosAgile-2015-11) говорит, что именно так были вынуждены поступить правительства Великобритании и Штатов, когда после крупных провалов проектов, управляемых традиционно, делали применение Agile обязательным для госпроектов, в 2011 и 2014 годах соответственно. В Англии подробности можно посмотреть на https://www.gov.uk/government/organisations/government-digital-service, а в Штатах - в истории https://www.usds.gov/mission

Не очень понятно, впрочем, в чём критическое отличие этого коммента от тех, плохих, от нехороших людей, которые хотят лишь искать доказательства подтверждающие правильность своего вывода 🤷‍♂

критикуем людей которые рассматривают лишь примеры ,которые подтверждают что agile не взлетел, тем что рассматриваем примеры которые взлетели 👏

#whois Всем добрый день. Меня зовут Анастасия, работаю в RuYou менеджером проектов. В компании только вводим скрам, присоединилась, чтобы узнавать что то новое в части гибких методологий)

Привет!Добро пожаловать!Зачем вводите скрам, чего хотите получить? 🙂

хотим сократить количество проектов на разработчика и выстроить процессы)

Иии?

Ну скрам же создан для сокращения проектов: хочешь профукать проект - сделай скрам  ) все ж понятно )

Лучше уточнить)

Испугали человека. На самом деле раньше я бы сама испугалась, но важно же понимать, зачем вы это делаете и что даёт инструмент. Откуда берётся представление, что скрам позволяет сократить проекты на разработчике? Есть хороший источник информации, скрамгайд, нужно начинать с него и потом, если остаются вопросы, спросить про книжки, где можно получить более глубокое понимание границ применимости.

Или задать конкретные вопросы

Испугали или нет, мы пока не знаем, узнаем у @br_nastia, когда появится 😉

Бедная девочка, только появилась в чате, ее сразу админ тэгает ))

Я б тоже испугался ))

ох уж этот непрошенный коучинг

И не говори)

Да где же коучинг? Просто интересно же 😀