6903
правки
Изменения
м
Нет описания правки
Модель Спиральной динамики, кстати, объясняет и то, почему принять такое изменение смыслов может быть далеко не просто — ведь для этого требуется изменить свою картину мира. Настолько не просто, что в комментариях к [https://www.facebook.com/photo.php?fbid=1326247467504783&set=a.777692369026965.1073741836.100003586281482&type=3 отзыву Дениса Гобова] на мой доклад был явный переход на личности с обесцениванием не только содержания доклада — дескать, старые перепевки про Agile и водопад — но и меня самого, призывая меньше выступать и больше работать. Ну, это неизбежно. А доклад, между тем, занял третье место на конференции — и это не только мне приятно, но и, надеюсь, означает, что мне удалось сфокусировано показать разницу смыслов и вытекающие из нее следствия для практики. При этом отзывы в обсуждениях были полярны: есть и те, кто говорит, что «хорошо когда хотя бы виноватых не ищут», имея ввиду, что все эти рассуждения — из далекого будущего, и противоположное мнение о том, что уже давно большинство компаний работает по-новому, а старые методы представляют больше исторический интерес. Так что разброс практик очень велик, об этом был [https://www.facebook.com/mtsepkov/posts/1542649422458673 мой пост].
А еще на осенней AnalystDays я проводил [[Agile: что надо знать аналитику, чтобы действовать?(AnalystDays осень 2017 в Минске)|'''мастер-класс по Agile''']], который был нацелен на практику, а не на теорию. В начале мастер-класса слушатели заявили свои кейсы и дальше я их по очереди разбирал в диалоге с автором. При этом основной задачей было не выдать какие-то ответы из теории, а показать способ рассуждений в Agile mindset. Потому что теорию аналитики могут легко найти — есть много статей, и есть нормативные документы — Agile Manifesto, Scrum Guide и другие. А вот сопоставить их с конкретной ситуацией проекта и найти адекватные решения, соответствующие логике Agile — отдельная задача. На основе реакции слушателей, я надеюсь, что у меня это получилось. Авторы кейсов получили еще и практические советы, с которыми будут работать дальше.
По контрасту хочу отметить доклад '''Yuriy Gaiduchok''' на AnalystDays. Это — хорошая иллюстрация того, что старая школа работает на снижение неопределенности. Угрозы определенности и ясность проекта, такие как отсутствие общей онтологии, контекстная зависимость, неполные списки — рассматриваются как угрозы, которые надо измерить через атрибуты качества чтобы их избежать. А современный подход, Agile говорит о том, что это — не угрозы, а имманентные характеристики современной ситуации, в которой необходимо работать. Что, естественно, не отрицает необходимость определять области и степень неопределенности. И знать и применять все эти техники для определения зон неопределенности проекта — нужно. Просто это — не про качество, а про рабочую ситуацию. Я все это [https://www.facebook.com/mtsepkov/posts/1542730499117232 написал в посте] и там было интересное обсуждение.
