Изменения

Очень любопытный был рассказ '''Владимира Горшунова''' «On the way to business Agility: MIF publishing house case study» про '''внедрение Agile в издательстве МИФ''' (Манн, Иванов, Фабер). Это — второй подход издательства к Agile, и в этой истории можно увидеть достаточно характерную ошибку, которую допустили несколько лет назад. А именно, менеджеры МИФ позвали внедрить Agile для команд, выпускающих книги. Это было сделано, а дальше выяснилось, что такая локальная оптимизация не сильно повлияло на успехи издательства в целом по двум причинам: во-первых, срок выхода книги существенно сократить все равно не удалось, он связан больше с внешними технологическими ограничениями, а не с работой самой команды выпуска, а, во-вторых, основная прибыль делается издательством не на выпуске отдельных книг, и, тем более, их первого тиража, а на допечатках и проектах по выпуску серии связанных книг, такая продуктовая линейка, а этот уровень трансформацией затронут не был, да и вообще он был инкапсулирован у топов компании. Вывод: перед Agile-трансформацией, да и перед любыми другими тоже, стоит проанализировать цепочки создания ценности компании, чтобы оценить принципиально достижимый потенциал экономического успеха. С тех пор с топами компании работал Петербургский институт коучинга (если я не ошибаюсь, в докладе — было, но я не записал), и компания созрела для следующей итерации внедрения Agile уже на масштабах всей компании, о котором рассказывал Владимир. Но там — начало пути, так что о результативной перестройке говорить еще рано, тем более что для внедрения был выбран SAFe фреймворк, который поддерживает сложную работу с цепочками создания ценностей, но при этом — является очень сложной конструкцией, и, на первый взгляд, overqualified для компании масштаба МИФ. Но такие проблемы — у всех управленческих конструкций, у МИФ — уникальное позиционирование, которое они хотят сохранить — а значит надо делать собственную структуру, адекватную задачам компании. Но история — очень интересная.

А на весенней AnalystDays был отдельный '''трек по Agile''', который формировал Вадим Мустяца. Краткий отчет можно прочитать [https://www.facebook.com/VadimVMustyatsa/posts/1418632141534433 в его посте]. В рамках этой секции в своем докладе [[Как выбрать для проекта практики проектирования и работы с требованиями (Максим Цепков на AnalystDays-2017)|'''Как выбрать для проекта практики проектирования и работы с требованиями''']] я рассказывал про то, как изменения в ведении проектов сказалось на изменениях в работе с требованиями. От представлений о наличии единственно-правильного метода ведения проекта и требований в нем к конструированию такого метода для конкретного проекта. Не для всей области, а только в части работы с требованиями. Кстати, термин «Требования» (Requirement) — тоже изменил свое значение, вернее, получил новое: ранее о применялся к описанию IT-системы как черного ящика, занимая определенное место на V-диаграмме, а в новом стандарте OMG Essence альфе требований соответствует вся проектная документация — концепция, сами требования, архитектура, детальный дизайн и все остальное. При этом классические авторы по работе с требованиями — Вигерс, Коберн и другие — писали довольно давно. С тех пор появилось много методов, практик и подходов, включая тоже не новые user story и use case, а также практики UI-design — usability — UX, которые сильно отличаются от обычных практик анализа. И по всем ним есть свои книги и мастер-классы, так что сделать качественный обзор в одном докладе — невозможно. Поэтому я пошел другим путем — я кратко рассказал эволюцию методов, показав различие на каждом этапе, а далее — дал набор вопросов, на которые надо ответить, чтобы сконструировать свой метод, и показал спектр вариантов ответа.