Блог:Максима Цепкова
2017-12-03: SQAdays - в тестировании не происходит ничего нового...
Две недели назад 17-18.11 в Петербурге прошел SQAdays-22. И, собственно, я хотел назвать свой отчет о конференции «зрелая конференция зрелой отрасли», но потом заглянул в свой отчет о прошлой конференции — и обнаружил, что он примерно так и называется, в то время как впечатления — сильно разные. И тогда я решил вынести в название цитату из выступления Рины Ужевко на открытии — о том, что «в тестировании не происходит ничего нового». Эта реплика была адресована участником конференции, с призывом подавать доклады и не стесняться своего относительно скромного опыта: все равно ничего принципиально нового не происходит, поэтому ваш рассказ — уместен на конференции.
Мне же это резануло слух и я написал реплику на FB: «Каждый раз, когда это говорят про какую-то область деятельности — область или умирает или это затишье перед взрывным ростом. Так было, например, с языками — в какой-то момент казалось, что все языки уже разработаны, все известно, а потом произошел взрыв новых языков с новыми парадигмами… Думаю, так будет и с тестированием — оно накануне взрыва технологий для тестирования обучающихся систем, например, автоводителей; и автоматизации, в которой автотесты пишут роботы — но этих роботов обучают люди; и в других направлениях. В каких именно выстрелит первым — я не знаю, но многие направления потенциального развития — понятны.» В комментариях Рина и Влад Орликов согласились с этим. Развитие новых векторов пока идет в отдельных точках, и накапливается критическая масса, которая породит бурный поток. Но пока — затишье. И да, возможность для всех поделиться своим опытом.
На конференции обмен опытом шел интенсивно, и не только в залах: в большом фойе были мини-выступления от gett.com, которые приехали на конференцию большой командой сильных специалистов, организовали мини-островок в холле, при этом звали выступать на нем не только своих специалистов, но и других. Выступления были сильными, интересными и краткими. А напротив них в близком формате выступал СКБ-Контур.
А в целом энергетика конференции была не столь сильной. Новички — учились, а опытным было многое известно, они не ждали ничего нового. И баркемпы не особо увлекали народ. Впрочем, когда вбрасывалась сильная тема, то народ оживлялся, это замечательно показал Леша Федоров. Он, кстати, излагал мое выступление на IT Global Meetup (мой отчет), и когда из аудитории начали идти вопросы — призвал меня к ответу на фото справа можно это обсуждение увидеть.
Но, с другой стороны, все этом может быть и случайностью, или просто связано с осенним настроением. Потому что за полгода ничего принципиально измениться не могло, а вот мои ощущения от конференции — разные. В пользу ситуативной разницы говорит еще одно наблюдение.
2017-11-24: Agile и бирюзовые организации - круглый стол в Открытой школе бизнеса
Сегодня был на круглом столе «Agile и бирюзовые организации» в Санкт-Петербурге. Очень интересная встреча, которая собрала очень разных практиков, рассказывающих о своем пути по направлению к бирюзовым организациям. И я очень благодарен Тимофею Левицкому, которые организовывал мероприятие и Сергею Федорову, директору Открытой школе бизнеса, в которой происходила встреча.
2017-11-23: в субботу 25.11 выступаю на online-конференции по управлению проектами
В субботу 25.11 выступаю на бесплатной online-конференции «Управление проектами в малом и среднем бизнесе» http://pmconf.online/ Конференция будет весь день, с 10 утра, много интересных спикеров, которые расскажут о самом разном опыте, а мой доклад «Agile для тех, кто хочет разобраться: что он дает для управления проектом и на какие современные вызовы отвечает» — в 18:00. Регистрируйтесь и смотрите!
Ну а завтра я в Петербурге на круглом столе «Agile и бирюзовые организации»
2017-11-22: Материалы по Agile - как войти в тему
Публикую очередную версию своего ответа о материалах, позволяющих человеку познакомиться с темой Agile. Казалось бы, материалов много, но выбрать правильное — не просто. Особенно если человек имеет хороший опыт работы менеджером или руководителем подразделений и проектов. Предыдущая версия была меньше трех недель назад книги и материалы по Спиральной динамике, бирюзовым организациям и Agile — как войти в тему — тема актуальна.
Итак, стандартные распространенные тренинги это Scrum Master, Product Owner (тоже Scrum) и базовый тренинг по Kanban для члена команды. Они рассчитаны для рядовых сотрудников или начинающих руководителей групп/проектов. И если у человека есть солидный опыт в отрасли, то многие материалы ему будут казаться поверхностными, и потому понимания не появится. Поэтому я предлагаю альтернативный путь знакомства? который хорош еще тем, что он почти бесплатный :)
- Посмотреть один из докладов по основам Agile: Бориса Вольфсона на AgileDays-2015 или Алексея Пименова на Agile для государства.
- Чтение материалов в инете и литературы, чтобы глубже познакомиться, и для этого я бы рекомендовал первоисточники. Все читать все, надо посмотреть ознакомительные фрагменты, и посмотреть, что будет по духу близким — то и читать.
- Хенрик Книберг «Скрам и XP: заметки с передовой» — она старая, но хорошо передает дух. По ссылке доступен оригинал и русский перевод, выполненный коллективным разумом и выложенный в свое время на InfoQ. Потом его оттуда убрали, но в других местах - остался.
- Джеф Сазерленд «Scrum — революционный метод управления проектами». Он адаптирован для не-IT аудитории и больше про идеологию, но основные вещи там хорошо разобраны.
- Дэвид Андерсон «Канбан — Альтернативный путь в Agile».
- Дальше можно самому выбирать доклады с конференций AgileDays и других, много записей на канале ScrumTrek (обе ссылки на доклады — оттуда).
- Хороший вариант — найти и сходить на выступление или тренинг одного из ведущих специалистов по Agile, например, к Пименову, Лобасеву или кому-то еще. Уровень тренера оценить достаточно просто — у хорошего тренера должны быть выступления на AgileDays, AgileKitchen или других профильных мероприятиях, и они должны быть доступны в сети. Смотрите, оцениваете тренера, смотрите, насколько его манера изложения в вас откликается и решаете — идти или нет. Тут сложность в том, что ведущие специалисты редко проводят тренинги для начального уровня, поэтому начинать с такого тренинга - нет смысла. Зато вы получите много практики, выходящей за пределы стандартной программы. Я это мог оценить, когда проходил тренинг Scrum Master у Хенрика Книберга (отчет, продолжение), а Product Owner - у Джефа Паттона (отчет). Давно это было...
- Еще один вариант — сходить на ознакомительную встречу по Agile. Такие встречи в форме публичных лекций, meetup, AgileKitchen, бизнес-завтрака, или мини-конференции относительно часто (несколько раз в год) в бесплатном формате ведущие специалисты. Их анонсы можно смотреть в группах AgileRussia, Agile вне IT, Agile Belarus и других. Но важно, чтобы это был ведущий, а не начинающий специалист, и вам отзывалось то, что он говорит. Критерий тут - доклады на профильных мероприятиях.
2017-11-20: Agile: зачем стоит применять его методы и как именно - выступление на ВОЭ
В четверг на прошлой неделе, наконец, состоялось мое выступление на конференции Великая октябрьская эволюция, которое дважды переносилось по разным причинам. Публикую в блоге запись выступления.
Беседа с Ольгой Гусевой 16.11.2017 на беcплатной online-конференции Великая октябрьская эволюция, которую проводит Анатолий Баляев. Тема — «Agile: зачем стоит применять его методы и как именно».
В современном мире любой успешный тренд покрывается густой пеленой мемов, люди начинают ожидать от него волшебных решений — а потом разочаровываются. Agile — не исключение. Между тем, он появился в IT как средство решение конкретных управленческих задач, с которыми не справился классический менеджмент, и за 15+ лет развития доказал свою успешность — если его методы применяются по назначению. И сейчас он идет в другие отрасли — не потому. что «можно», а потому, что новые вызовы третьей промышленной революции добрались до них. Я расскажу, на какие вызовы и как именно отвечает Agile, какие задачи бизнеса он решает.
В беседе упоминаются мои материалы по Agile, доступные на этом сайте, и, в частности, доклад Agile - ответ на вызовы третьей промышленной революции, а история развития Agile с точки зрения Спиральной динамики с последующей адаптацией к нижним уровням - была в выступлении Agile и игрофикация: за каким менеджментом будущее? (AgileBusiness-2017) (рисунок справа).
В конференции я участвовал третий раз. Конференция преимущественно идет почти месяц по вечерам, но есть и offline-мероприятия. Все записи этого и прошлых лет доступны на сайте конференции, смотрите, там много интересного.
Видео беседы https://youtu.be/pwSFOiGp1LA
2017-11-07: Agile Business Conference - хроники развития Agile в корпорациях
Неделю назад выступал и общался на Agile Business Conference-2017. Это — вторая конференция и сейчас уже можно говорить о достаточно сформировавшемся профиле: это конференция, на которую приходят корпорации, крупные и очень крупные компании чтобы узнать — что происходит с Agile в других сомасштабных им организациях, и что именно им могут предложить. Потому что практически во всех крупных корпорациях сейчас используют или пробуют использовать Agile тем или иным образом. В одних — нацеливаясь на организацию в целом, как делает Альфа-банк. В других — для ведения отдельных проектов, как делает РосАтом. В третьих — для ведение новых разработок, как делает концерн Калашникова. Многие — экспериментируют и ищут свои варианты адекватного использования, и конструируют свои версии.
Если сопоставлять эту конференцию с прошлогодней, то надо отметить, что преимущественно рассказывались другие кейсы с других площадок. И это — естественно, корпорации — медленны, год для них — не срок для получения значимых результатов, о которых можно рассказать. Это касается не только государственных компаний, на конференции был рассказ Wargaming Про Agile-управление портфелем проектов — там характерное время изменений тоже 3-5 лет, не мало. Но вот если смотреть картину в целом, то видно, что в сегменте корпораций идет устойчивое поступательное движение. Со своими победами, поражениями, сменами курса в конкретном случае, но это — не имеет особого значения для продвижения в целом, это про трудности на пути.
И я бы сравнил это с разворачиванием какого-нибудь масштабного технологического проекта, например, космического или атомного — если смотреть ежегодные хроники, то движение было медленное, успехи происходили на разных площадках, где-то были неудачи, но в целом движение шло. И, на мой взгляд, это сравнение уместно, потому что сейчас внедрение Agile в корпорациях — это по-сути выработка управленческой технологии, работающей на масштабе больших корпораций, для мира третьей волны Элвина Тоффлера, который приходит на смену индустриальному обществу. И это — самая сложная часть технологии. Там где индивидуум или малая команда может приносить конечную пользу, технология уже отработана, и, более того, масштабирована на достаточно масштабные проекты, об этом свидетельствует OpenSource-проекты, Википедиа. Есть фреймворки для средних компаний со сложной цепочкой. А вот для крупных компаний с длинными цепочками создания ценности, такими как РосАтом, решения еще нет, его — создают. Что не удивительно, для индустриального общества это тоже были самые последние масштабные проекты.
Мой доклад на конференции Agile и игрофикация: за каким менеджментом будущее? (AgileBusiness-2017) тоже был посвящен будущему больше чем настоящему. Потому что сравнивать методы, исходя из набора плюсов и минусов можно в контексте сегодняшних задач. А для того, чтобы ответить про будущее, надо положить их в модель этого будущего и посмотреть, насколько они ей соответствуют. И такая модель есть — это развитие общества по Спиральной динамике, уровни которой, с моей точки зрения, хорошо детализируют волны Тоффлера. И в этой картине Agile-манифест соответствует зеленому уровню, а Scrum возник как конструкция управления желтого уровня, которая отсутствует в классическом менеджменте — что и является реальной причиной его успеха. После реального успеха начались попытки его использования на более низких уровнях с адаптацией под соответствующую культуру, часто безрезультатные, которые, собственно, и являются основаниями утверждать, что «Scrum не работает». Конечно, любая организационная конструкция не работает, если не соответствует культуре организации. Как верно отметил Андрей Павленко в своем посте про мой доклад: «Одно из лучших выступлений на конференции и один из лучших слайдов этого выступления. Присмотритесь особо к правой, нисходящей тенденции "адаптации" Аджайла к незрелым уровням спиральной динамики — это же почти исчерпывающий справочник фейлов при "внедрении" Аджайла :)»
Я активно комментировал доклады в процессе самой конференции, и дальше соберу эти комментарии в посте, чтобы они не потерялись в FB. По ряду из них развернулись интересные обсуждения в комментариях.
Слушаю рассказ Shane Hastie (ICAgile) про обучение и сертификацию] Agile. Чем отличаются продажные презентации от системного представления? Тем что в системных люди представляют все поле деятельности, раскрывая его сегменты, в том числе, естественно, обозначая свою практику в них. А Я-центричное продажное представление показывает только собственное поле деятельности. И у Shane Hastie — именно такой рассказ, на карте образования нет ни Scrum ни Kanban… Печалька. Потому что Agile mindset в таком представлении нет, это — обычный продуктовый маркетинг.
В посте — обсуждение о том, что считать продающей презентацией, а что — не считать :)
Асхат Уразбаев представляет исследование Agile в России, провели в этом году. Взяли шаблон VersionOne, который публикует эти исследования по всему миру. Явно идет интерес к Agile вне IT-сектора, и не только в таких композитных сегментах, как телеком и банки. Поскольку исследование первое — нельзя сравнить с прошлым годом. Зато можно сравнивать с тем, как в мире. Что интересно — у нас четверть идет своим путем против всего 8 % на Западе. И вообще — очень много интересного. Читайте отчет, когда его опубликуют — пока он готов, но не сверстан :)
Пока я собирался написать этот пост, отчет был опубликован ведущими новостными агентствами, вот ссылка на публикацию ТАСС — в статье основное содержание, а внизу — ссылка на полный отчет.
Кстати, в комментариях мне рассказали, что российское отделение PMI провело свое исследование про Agile и опубликовало его на пару недель раньше. Интересно сравнить, я пока не делал.
Ksenia Samersova, Wargaming — рассказ опыта Agile в большой организации. Отчасти разочарован докладом. Потому что сначала 25 минут о проблемах большого масштаба, которые вполне понятны. А потом — метафора путешествия, вообще говоря, малой группы людей и простые решения, совершенно несоразмерные поставленной задаче. Ну то есть в метафоре путешествия разговор шел, если не о великом переселении народов, то об эпохе географических открытий, когда Землю исследовали всесторонне. А в рассказе — всего лишь рассказ об организации одной экспедиции.
Что обидно — за докладом явно есть интересное содержание. Потому что взят сложный фреймворк SAFe, который в этом случае (в отличие от ряда других) соразмерен организации и задаче, и реально использован для упорядоченности хаоса. Но то, как это представлено: определили цели, расставили приоритеты — вызывает вопрос: что, во всем Wargaming в течении 5 лет не было ни одного менеджера, который знал, что полезно сделать иерархию целей и расставлять приоритеты? Я из опыта понимаю, что там были проблемы, решить которые было сложно. Но в докладе — не проявлено. Жаль. С другой стороны, может, это и фича, которую дает SAFe: ты можешь наложить его не особо разбираясь в конструкции, и он приемлемо отформатирует хаос? Потому что про сам фреймворк, упорядочивание хаоса показано хорошо, много деталей и процедурных подробностей. Но интересно-то почему именно эти процедуры отформатировали хаос разумным образом, а 3 года альтернативные пути — не смогли? Почему так важно новую бизнес-инициативу не делать сразу, хотя есть заинтересованный Business Owner, а необходимо пройти через митинг раз в две недели? И вот много таких вопросов.
В посте — интересное обсуждение про SAFe и ответ самой Ксении на такую мою оценку выступления.
Anna Obukhova Powerful Powerless Leader. Анна биолог, ушла в IT, менеджмент, а потом вернулась в психологию на уровне биологии, когда механизмы лидерства доводятся до работы мозга. Тема доклада — сопоставление доминантности и лидерства. Доминантность проявляется в клетке, когда среда безопасна и еды достаточно, и ты доказываешь превосходство через агрессию к своим — в клетке нет доступа к внешнему результату. А лидерство — в дикой природе, когда надо искать пищу и защищаться от врагов, вести по неизвестности. С разбором лидерства, характеризуемого ранговым потенциалом, примативность и витальность, определяемых на физиологическом уровне работы мозга. Превосходно.
Доклад был интересен, и разворачивался неожиданной стороной — появился второй пост Anna Obukhova. Лидер: поиск нового + защита своих. Такого человека вы не наймете, он наймет сам. Agile разделил: поиск нового — product owner, защита своих — scrum master, и этим решил проблему дефицита сотрудников. Но — без тоталитаризма, SM на ретроспективе ищет новое или помогает этому. А PO — проверяет безопасность своих предпринимательских идей для команды, экономической или другой. Но это — вторичная компетенция в области главной. Реально — неожиданный разворот доклада, сюрприз-сюрприз!
Сергей Малоземов. Применение Agile в проектах атомной отрасли (видео) — рассказан конкретный кейс применения Agile для решения задачи проектирования, вернее, не полного проектирования, а фазы генерации идей. Традиционным образом сделанная адаптация проекта АЭС под европейский требования оказалась слишком дорогой, и потребовалось за 3 месяца придумать способы снижения стоимости при соблюдении требований. И здесь кроссфункциональные команды и открытое agile-общение в сочетании с легкой, но достаточно жесткой scrum-структуризацией процесса сыграли свою роль, результат был достигнут, проработка порожденных идей дало 26 % экономии. Что важно — Agile был встроен в корпоративную среду крупной компании, принципиальных противоречий — не обнаружено, а наоборот, отмечен позитивный эффект от использования. И предполагается это развивать. И для меня — это важный индикатор ментальной готовности корпораций к применению новых методов. И пример — не единичен, например, я недавно узнал на встрече в PMO club, что концерн Калашникова по Agile разрабатывает новые виды оружия.
Кныш Николай и Сергей Щербинин из Райффайзена рассказывают, к чему они пришли в трансформации банка. Интересно, что схему, которую они рассказывали — Chief PO, Tech Lead, Chapter Lead я слышал от Нижегородской компании на тренинге Книберга в 2011: у них было три ветки управления из PO, SM (это chapter-ветвь) и техлидов, и при этом в команды они набирали студентов, силами которых решали весьма сложные разработческие задачи. Правда, компания была не слишком большая, до тысячи человек, однако формально в том, что рассказывал Райффайзен — просто добавили один уровень, потому что у них 60 PO — цифра называлась. Впрочем, это не умаляет ценности доклада Райффайзена.
Алексей Ионов (тренер) и Константин Воронин (Ингосстрах) — про Agile в корпорации. Довольно интересная сборка мозаики под ситуацию, когда компания индустриального общества с соответствующими ему паттернами менеджмента инкорпорирует в себя фрагменты Agile для того, чтобы отвечать на вызов Business Agility. Многие слайды — проблематизируют руководство, подталкивают к переменам, показывая их неизбежность. А решение представляют аккуратно, смешивая новое со старым и сохраняя работоспособность конструкции в целом. При этом в рассказе достаточно интересный мыслительный паттерн: для многих практик Agile мы выходим на корни и аналоги в развитии менеджмента, например, производственный lean или обучающуюся организацию, описанную в пятой дисциплине Питера Сенге и другие. Кстати, композитные конструкции сейчас распространены, Алексей говорит о книгах, которые их описывают: Agile Innovation, Лидер и племя, Драйв Дэниэла Пинка.
И все это — только четверть выступлений, потому что шло три трека параллельно и еще мастер-классы. И в ряде случаев реально приходилось выбирать. Я не попал на выступление Андрея Бадина про Agile в государственных проектах, потому что параллельно был мой собственный доклад, не услышал как дела в Сбербанке и издательстве МИФ, в котором тоже интересный кейс разворачивается, и ряд других. Но будет запись, узнаем.
2017-11-04: книги и материалы по Спиральной динамике, бирюзовым организациям и Agile - как войти в тему
На конференциях и в переписке меня часто спрашивают, как можно быстро познакомиться со Спиральной динамикой, концепциями бирюзовых организаций или Agile, по отдельности или вместе. Потому что вокруг этих тем есть столько мемов, что в короткие изложения в популярных статьях людей не удовлетворяют. При этом серьезных материалов тоже много, и они объемные. Поэтому запрос звучит так «есть ли качественные концептуальные тексты на эту тему без излишней сложности?». Правда, на него ответ отрицательный. Но есть приближения — о которых я и расскажу в этом посте.
По Спиральной динамике нужно читать первоисточник — книгу Дона Бека и Криса Кована. Все краткие изложения. которые я видел — тем или иным образом методологически ущербны. Если очень хочется краткого введения, то я порекомендую свое Краткое описание уровней Спиральной динамики — оно относительно точно.
По Спиральной динамике есть еще интересная статья Марка Розина Путешествие по спирали, в которой он сопоставляет корпоративные культуры уровням Спиральной динамики. Именно он придумал соответствующие уровням названия культур. соответствующих уровням: принадлежности, силы, правил, успеха, согласия и синтеза.
Про бирюзовые организации ситуация следующая. Фредерик Лалу решил найти и исследовать «новые» организации, о которых так долго говорили предсказатели. Для этого взял систему Спиральной динамики и Интегрального подхода Уилбера, адаптировал их для описания организаций, а не индивидуумов, и дальше зафиксировал: новые организации — те, которые соответствуют желтому (по Спиральной динамике) уровню. Только у него цвет из Уилбера — teal, который переводчик назвал бирюзовым. То есть методологически бирюзовые организации = организации желтого уровня по Спиральной динамике. А практически Лалу, исследуя их, нашел много сложных механизмов, о которых авторы Спиральной динамики не подозревали, они в организациях видели гораздо более простые механизмы. И Лалу их описал. И самое ценное в мире - это именно механизмы бирюзовых организаций, которые надо вычленять из достаточно длинных общих рассуждений. У меня есть краткий конспект книги для тех, кто хочет познакомиться.
Таким образом, ни какой методики "как забирюзеть за 30 дней" не существует. И можно просто двигаться в эту сторону, работая от ценностей. Однако, Лалу в книге достаточно хорошо описал механизмы, которые такие организации используют, все-таки он профессиональный консультант МакКинзи. И многие из них - сложные, изобретать их не просто, поэтому не надо изобретать с чистого листа, можно брать готовое и адаптировать, пользоваться чужими уроками. Впрочем, многие все равно предпочитают делать свое и идти по граблям, а дальше заключают, что оно не работает. Потому что основное, что выяснил Лалу — механизмы-то сложные, просто на здравом смысле их не сделаешь.
По Agile. Совсем сложно, потому что нет одной книжки. Основы лучше читать у Сазерленда «Scrum — революционный метод управления проектами», плюс Agile-манифест и принципы. Agile-манифест и Scrum появились 15 лет назад и с тех пор методология и практика — развивались, в частности появился Kanban, и инкорпорирован Lean. Только новые книжки писали для тех, кто знал предыдущие, и не только как теорию, но и как практику. Так что структура — сильно слоистая.
И в заключении - про связь всех этих концепций. В общественном сознании их связал Греф, подняв одновременно темы Agile и бирюзовых организаций. А для меня Agile (Scrum) — это способ организации работы для желтого уровня Спиральной динамики, то есть бирюзовых организаций. Но сам Agile так не развивался, и вообще он возник давно, до того как эти концепты появились в широком сознании даже на Западе. Так что это — моя интерпретация.
А в заключении поста - скрайбинг моего доклада Будущее уже наступило: от Agile к Бирюзовым организациям (Дни PR и маркетинга на Юге 2017).
2017-11-02: встреча по визуальным моделям в Райффайзенбанке - супер!
Вчера был на мини-конференции Райффайзенбанка Использование визуальных моделей в ИТ. Полдня, 150+ участников, 5 выступлений. В трех из них - реальный опыт использования Enterprise Architect в Касперском, Райффайзенбанке и ЛАНИТе. Что надо отметить - опыт очень разный и дополняющий друг друга и это - особенно интересно.
Ира Сурова из Касперского рассказывала, что они используют EA для единообразного ведения требований. В 2010 у них в R&D всех аналитиков собрали в единый отдел по специализации для управления ресурсами, но при этом аналитики работают в проектах, и в каждом проекте - внимание - свой подход к ведению проекта. Определяемый PM. И это - логично, потому что в R&D бессмысленно нормировать процесс. Да и проекты у них очень разнообразные и их много. А прогресс движения проекта - оценивают независимо от внутренней организации. И аналитик должен поддержать тот процесс, по которому работает команда. Аналитики в отделе Ирины отвечают именно за требования, архитектура - прерогатива разработчиков и те ревниво относятся к нарушению границы "если аналитик нарисовал диаграмму классов - она неправильная" (Disclaimer: цитата - неточная, воспроизведена по памяти, и далее - тоже). А по требованиям надо поддерживать текущее состояние продукта и его изменения, потому что для разработчиков важно уметь представлять требования именно в формате задач - что ему надо изменить в системе, а вот для тестировщиков, и для последующей работы - фиксировать состояние системы. И именно поэтому им потребовалась автоматизация, ведение в виде документов просто не позволяло так гибко работать. А тут единицей требований у них является use case, и дальше они их классифицируют по темам и резлизам и делают выгрузку текстовых документов. Потому что разработчикам, оказывается, диаграммы - не нужны, и модель смотреть они тоже не хотят.
Методика, как вести требования и изменения - достаточно тяжелая, у EA тут свои ограничения, с которыми приходится бороться, потому что честной версионности репозитария он не обеспечивает (да, можно хранить репозиторий в svn, но с этим проблемы), и ряд других сложностей. Поэтому методика у них - общая. Но при этом ряд проектов работает с "легкой" версией, используя EA просто как каталог, оглавление use case, а сами требования ведут в отдельных документах. Оглавление при этом испольхуется, потому что EA интегрирован с TFS, в котором отслеживается прогресс движения проектов.
Тут была самая интересная часть доклада Ирины: уже есть опыт, в каких проектах приживается ведение требований в EA полноценно, а в каких - нет. Приживается там, где есть жесткие сроки и обязательства по функционалу в релизах, много зависимостей от смежников, много изменений по обратной связи от пользователей - модель их трассирует. Для новых проектов приживается хуже, чем для изменений в старом, что понятно - контекст нового все и так помнят. Модель востребована активными тестировщиками, но не востребована разработчиками, и этот фактор тоже сказывается: чем более команда совместно с аналитиком работает с требованиями, тем менее удобно использование EA, и наоборот, автономная работа аналитиков способствует его использованию, особенно когда аналитиков несколько - коллективная работа в нем лучше. Факторы более-менее объяснимы, но я бы не сказал, что их можно было так вот уверенно предсказать.
Максим Шаломович и Денис Епишев из ЛАНИТ тоже рассказывали про ведение требований в EA, но на примере одного проекта, потому что проекты у них сильно разные и общей практики ведения требований в компании нет. Проекту примерно три года и он развивается, требования часть меняются. Что интересно, они решили ту задачу, которую не получилось сделать в Касперском: они передают разработчикам не выгруженный из EA документ, а саму модель. И архитекторы делают в ней детальный дизайн, а по необходимости - делают выгрузки. И диаграммы на UML разработчики тоже хорошо читают. Внешним подрядчикам тоже могут передать модель, вернее, фрагмент модели, или выгрузку в документ. Что интересно - разработчики уже освоились, и на попытки "срезать углы" и что-то написать в тексте - справшивают "а где модель, так не пойдет". Верифицируют модель на полноту, фиксируют что не проработано - и ставят баги, а не додумывают за аналитиков.
И у них как раз поставлена развитая работка с ветками требований в EA. Есть релиз-бранчи, а для больших фич делают отдельные фича-бранчи. Но merge - ручной, средствами EA. Есть средства автоматического merge на основе сравнения xml, их они пробуют, пока не используют, но к этому идут. Вообще тут проблема в том, что автоматический merge нельзя делать построчно, надо учитывать xml-структуру репозитария, иначе получится некорректная модель. А квант хранения модели в файле - велик, поэтому задач объединения - много. Понятно, что ручное объединение веток может оказаться трудоемким, если менять как попало, поэтому у них есть правила, которыми все аналитики руководствуются. Но их соблюдение - на людях, EA тут не помогает.
Вообще они рассказывали свой опыт первый раз и у них - круто. Они, кстати, сами сказали, что осознали, насколько много сделали только при подготовке доклада. Так что рассказывайте о своих успехах - и сами их оцените, и другим людям опытом поможете.
А Юрий Карабутов и Дмитрий Столяров рассказывали про опыт Райффайзена. Они используют EA совсем по-другому, для описания архитектуры IT-ландшафта банка. В котором 300+ достаточно интегрированных систем, которые непрерывно развивают 50+ команд разработчиков, при этом идет 100+ инициатив одновременно, затрагивающих по нескольку систем. Описание всего этого они и ведут в EA. Структура описания текущего состояния такая.
- Бизнес-уровень
- capability - описание бизнес-области
- service - типа "открытие счета"
- use case - как именно открывают счета (удаленно, конвейер, бранч)
- business object
- Уровень приложений
- application - отдельная система, строгого определения, что считать отдельной системой нет, опираются на традицию
- component - от единственной в маленьких системах до 4-уровневой структуры в больших
- interface - для описания взаимодействия между системами
Проект изменений - Solution создается копированием скриптами в новую модель из описания текущего состояния интересующей части модели, при этом на элемент-источник делают связи. На бизнес-уровне добавляется описание требований, под которыми они понимают пожелания бизнеса разной степени формализации, что, скорее, соответствует нуждам стейкхолдеров (needs), а не requirements. Пожелания ведутся во внешней системе и оттуда импортируются. А дальше для удовлетворения этих пожеланий элементы описания изменяются, добавляются новые, старые помечаются как удаленные, и это все трассируется. При этом регламент изменений - тоже на людях, и консистентность модели поддерживается ночными проверками, выявляющими проблемные объекты, восстанавливающими связи, где возможно, пересобирающими различные сводные диаграммы и отчеты. Такая вот сложная конструкция у них живет и обеспечивает управление IT-ландшафтом банка.
А вот мой доклад Визуальные модели корпоративного приложения (Meetup в Райффайзенбанк 2017-11-01) был не про EA. Он был про различные диаграммы, которые мы использовали и используем в разработке корпоративных приложений для описания бизнес-уровня и для проектирования самого приложения. Для корпоративных учетно-аналитических приложений мы используем собственный шаблон Учетной машины, о котором я рассказывал в ряде докладов, последний из них DDD - модель вместо требований (Максим Цепков на AnalystDays-2014). Шаблон построен на основе Domain Driven Design, в нем используется модель, для описания которой используются диаграммы классов, активности и разработанные нами диаграммы учета. И именно на нем был фокус в моем выступлении, а примеры диаграмм были расширены теми, которые используются для описания архитектуры предприятия и места в нем разрабатываемой системы, а также представления ее через метафору системы. Были примеры диаграмм в свободной нотации, которые, кстати, обычно лучше воспринимаются заказчиками, чем формальные диаграммы, и диаграмм в UML и Archimate, сделанных в Visio и EA. У нас в компании в последних проектах тоже используется, но не он был в фокусе доклада.
И еще один доклад делала Наталья Желнова. Она в режиме демонстрации показывала работу в Bizagi modeler - как от описания бизнес-процесса в BPMN перейти к use case. Правда, на модельном примере - к сожалению, живые проекты, которые она ведет Центре развития технологий Сбербанка она показать не могла.
У остальных выступающих, кстати, на ряде слайдов текст не читаемый или условные номера вместо букв, и они предупреждали, что это тоже по соображениям безопасности. Организаторы вели видеозапись и обещают ее опубликовать вместе с презентациями (моя уже доступна на странице доклада). Будем ждать. Хочу сказать им большое спасибо за организацию встречи! И надеюсь на продолжение.
2017-10-29 IT Global Meetup в Питере: в гости ходят не только люди, но и сообщества
Пост на FB
В субботу 28.10 был на очередном #itgm (IT Global Meetup) - это глобальная встреча IT-сообществ Питера, несколько лет назад объединившихся в метасообщество (сообщество сообществ) #piterunited. Эти встречи проходят трижды в год - все сообщества, обычно 500-700 человек, собираются в одном помещении и каждое (которое желает) проводит свой островок с выступлениями. Обычно желающих полтора десятка, вчерашняя встреча не была исключением. Такой формат позволяет выйти за рамки своей специализации и оглядеться вокруг - послушать доклады, пообщаться. Хотя это - возможность, а не обязанность, и многие ее не используют, а предпочитают общаться со своими - так комфортнее. Но со своими-то можно пообщаться и чаще, потому что у большинства сообществ есть еще отдельные встречи.
И вот вчера сообщество тестировщиков SPB SQA Group сделало следующий шаг в общении. Они взяли тему, которая не является узкоспециализированной, а вызывает отклик у многих и устроили на своем островке встречу с другими сообществами, которые приходили в гости. Первый такт было общение с SPb SPM Club в форме обсуждения проблем качества требований - работа в группах, и на старте специально следили, чтобы в каждой группе был минимум один PM, Результатом был список проблем и решений. При этом островок SPM был временно закрыт: ленточка, табличка "менеджеры идут общаться с тестировщиками", и стулья тоже перенесли :)
Второй такт - с СПб СоА (Сообщество аналитиков Санкт-Петербурга), в форме моего выступления про путь от требований до задач, которые надо выполнять. Хотя сценарий был проговорен, само выступление было с учетом того списка проблем, который остался, и некоторые из которых на предыдущем такте снабдили фейковыми решениями "сделать все по правилам". И хотя многое из рассказанного уже было в моих докладах, такого концентрированного рассказа про путь от Needs and Opportunity через Req к Architecture and Design и далее Task - не было. Так что я теперь знаю, о чем делать доклад на следующей #analystdays.
Третий такт - выступление DevOps, Александр Чистяков (Alexander Chistyakov), которым приходится разгребать все те проблемы с требованиями, которые дошли до эксплуатации. Естественно, в эксплуатации возникают проблемы не только с требованиями, но и с реализацией, но в данном случае темой были именно требования. С интересными кейсами...
И последний такт - выступал Александр Александров, один из основателей профессии тестирования в России, который на очень хорошем инженерном уровне рассказывал о качестве, о том, что, собственно, надо делать тестировщику для того, чтобы заказчики и пользователи получали продукт, отвечающий их нуждам и ожиданиям.
Как один из выступающих, я представляю, какая работа была проделана организаторами. Они придумали сквозной сценарий, так, чтобы доклады были связаны и шли последовательно, и согласовали эти темы и сценарии с докладчиками, у которых собственный профессиональный взгляд и позиция. Они договорились с другими сообществами, для которых такая кооперация была новым делом, обычно островки делают изолированно. И, наконец, фасилитировали общение на островке, работу со стикерами. Поэтому я хочу отметить их всех в этом посте и сказать спасибо!
Алексей Фёдоров, Ольга Самарина, Тая Толстунова, Ольга Христенко, Люда Ионина, Иван Тречёкас, Юлия Атлыгина, Елена Коренева, Екатерина Гайнутдинова.
2017-10-26 - SECR-2017: Ivar Jacobson и другие
Прошла очередная, тринадцатая конференция SECR-2017, и название поста отражает мое главное впечатление о ней. А вообще это было в Санкт-Петербурге, два дня 4 трека докладов и один - мастер-классы, а на третий день, в воскресенье - еще три мастер-класса параллельно.
На конференции - много умных и опытных профессионалов, и этим она отличается от других. И это - не только докладчики, но и участники, и ряд докладчиков, общаясь со мной, отмечали качество вопросов от слушателей. А еще конференция отличается от других широтой охвата тем, возможностью заглянуть в соседние области, которая, на самом деле, не часто получается. Так устроены многие региональные конференции, задача которых - поднять уровень сообщества в целом. А вот российские преимущественно специализированные - аналитики, java-разработчики, .net-разработчики, интернет-разработка и многие другие. Хотя, тут надо отметить, что ряд конференций интернет-разработки расширяет свою тематику, поскольку web и мобильная разработка сейчас охватывает практически все области IT. И еще широким мероприятием является питерский IT Global Meetup, на котором, кстати, я буду выступать в ближайшую субботу. Возвращаясь к SECR хочу отметить, что широта охвата - увеличивается, хотя формально это, быть может не слишком заметно. Просто отдельные доклады превращаются в секции: в прошлом году пришли аналитики, в этом году - технические писатели и секция TOC и ТРИЗ. И достаточно широко представлены ВУЗы, в том числе региональные, например, из Ульяновска, где ВУЗ тесно сотрудничает с местными IT-компаниями. Интерес ВУЗов и вообще, тез, кто занимается наукой, понятен - SECR имеет статус партнера ACM SIGSOFT и доклады, поданные в форме научных статей (и прошедшие отбор), попадают в электронную библиотеку и индексируются. За лучший научный доклад, кстати, уже несколько лет присуждается премия Бертрана Майера.
Естественным образом, в рамках задачи "заглянуть в смежную область и на мировой уровень", SECR зовет иностранных спикеров. В этом году приезжал Ивар Якобсон, в общем-то человек-легенда. А еще - Эрик Райс, только не тот, который написал про Lean, а тот, который гуру в Usability (их двое, а имена совпадают, поэтому поясняю). И ими число иностранных спикеров не ограничивалось. А еще в этом году был интересный эксперимент: мы предлагали русскоязычным докладчикам делать выступления по-английски. И было достаточно много тех, кто согласился. Одна из целей - сделать конференцию действительно международной и интересной не только для русских участников и спикеров. Потому что иначе спикер, прочитав свой доклад, в общем-то скучает. И вопрос же не только в переводе, но и в слайдах. С другой стороны, для российских докладчиков это получается возможность порепетировать доклад для рассказа на международных конференциях, что тоже ценно. Посмотрим, что из этого выйдет, насколько конференция пойдет в международное русло.
В целом на конференции я много общался и меньше ходил на доклады. Зато с тех докладов, которые слушал - сразу публиковал заметки в facebook. Поэтому формат рассказа дальше будет такой: я расскажу о выступлениях Ивара Якобсона, потому что мне кажется, что содержание - важно. Немного представлю свой доклад, а затем - соберу посты из FB.
2017-10-25: Работа с конфликтами и ответственностью в сообществах многих лидеров - выступление на ВОЭ
Беседа с Анатолием Баляевым 24.10.2017 на беcплатной online-конференции Великая октябрьская эволюция, которую проводит Анатолий. Тема - «Работа с конфликтами и ответственностью в сообществах многих лидеров».
Одной из проблем сообществ, особенно если они включают ярких лидеров, являются попытки придти к единому мнению и все согласовать — это отнимает много времени и сил, и иногда даже парализует работу. Я делился практиками работы с ответственностью и конфликтами из холакратии и бирюзовых организаций, которые позволяют конструктивно решать эти проблемы. Часть из них была апробирована мною при консультировании разных организаций и сообществ и принесла пользу.
В конференции я участвовал третий раз. Конференция преимущественно идет почти месяц по вечерам, но есть и offline-мероприятия. Все записи этого и прошлых лет доступны на сайте конференции, смотрите - там много интересного.
Видео беседы https://youtu.be/ay5rlgojBeA
2017-10-19: IT осваивает soft skills по-взрослому - впечатления AnalystDays и ITSpring
Осенний AnalystDays подтвердил то четкое впечатление, которое у меня возникло еще весной на IT Spring (видео докладов): IT интенсивно и глубоко осваивает soft skills. В докладах — не только конкретные техники, но и разные модели сознания и психологии. И это востребовано не только HR или продвинутыми менеджерами, а широким кругом аналитиков и разработчиков. Года три-четыре назад такие доклады на IT-конференции широкого профиля встречались редко и практически не воспринимались. И об этом я буду писать в этом обзоре второй AnalystDays этого года, только что закончившейся в Минске, и апрельской IT-Spring, которая тоже была в Минске и о которой я еще не публиковал отзыва в блоге. Упомяну и весеннюю AnalystDays, которая проходила в Москве, на которой я, правда, был всего один день из двух и поэтому слушал мало докладов — почти весь день общался с участниками после своего доклада. В общем, этим постом я не только делюсь свежими впечатлениями, но и вспоминаю те IT-конференции этого года, о которых еще не публиковал отзывов.
В ходе докладов я сразу выкладывал отзывы в ленту FB, и сейчас в посте заодно сохраняю ссылки для истории.
2017-10-18: Не та нынче молодежь? Нет, она просто другая - и точно не хуже чем раньше!
У Монтеня в Опытах (16 век) есть глава, в которой он сравнивает рассуждения современных ему писателей об упадке молодежи с аналогичными рассуждениями древних римлян. Тезис состоит в том, что если бы все они были правы, то цивилизация давно бы пришла к варварству. И показывает, что существенная часть "упаднических" трендов - это новое, которое старшие поколения просто не воспринимают из-за своих шор. А я, читая все эти цитаты, вспоминал многих русских писателей 19 века которые так же сокрушались об упадке молодежи. Да и сейчас это - модная тема.
Все это я вспоминаю, когда читаю распространенные сейчас рассуждения сторонников классического менеджмента про Agile - дескать, легковесен, нет тех великих конструкций мыслей, и вообще - не способен. Понижает порог входа и порог выхода. В общем, не та нынче молодежь. На самом деле, Agile просто принципиально другой, и соль в нем там, что классическим менеджментом воспринимается как идеологическая бессмысленная вода - ценности, самоорганизация, совместное движение к общей цели... Они-то знают, что на самом деле есть стройные бизнес-процессы, с огороженными колючей проволокой границами, и кнут и пряник для движения по проходам, и ничего другого люди не понимают. Рассуждать так могут и весьма достойные люди, настоящие специалисты в строительстве бизнес-процессов - Монтень тоже цитирует далеко не последних мыслителей. Это ничего не меняет, новое - неизбежно придет.
Все это не означает, что вся молодежь - талантлива, и все Agile-коучи или выступающие эксперты по Agile - обязательно несут свет нового. Анализируя текущую ситуацию, я могу выделить несколько групп людей, которые по-разному пришли в коучи и тренеры.
Первые - это те, кто пришли из IT-практики. У одних есть реальный опыт, просто он небольшой, 1-2 года - это сейчас нормально, часто за этот срок успевают сменить несколько проектов и сильно вырасти, и реально стать экспертом, особенно если было у кого поучиться. Я не говорю, что любой с опытом 1-2 года станет экспертом, но я сужу по выступающим на IT-конференциях и митапах руководителям групп и проектов - этого действительно достаточно. Они ломают дрова и совершают ошибки, но при этом на них же учатся, своих и чужих, быстро обмениваются опытом - они на это ориентированы. И так со всеми новыми технологиями - молодые их быстро осваивают и становятся экспертами пока более опытные еще думают - что это такое и достаточно полезно ли оно, чтобы в нем начать разбираться. И, что интересно, пока они думают, это новое уже становится известным и, отчасти устаревшим, на смену приходит еще более новое. При этом в IT так происходит не только с управленческими, но и с инженерными с технологиями - новые фреймворки и подходы в web и мобильной разработке появляются раз в квартал, а не раз в несколько лет. И осваивать их надо "с колес", без учебников. А еще у молодых тренировка в компьютерных играх, которые тоже не просты и быстро обновляются. И с управленческими технологиями они обходятся так же.
А есть другие "эксперты", они обычно приходят из тренингового сообщества, которое интенсивно осваивает Agile по книгам, подобно тому, как они осваивают многие другие подходы. Получается - не слишком, но дальше надо уже дифференцировать на следующем уровне, отличая тех, кто стремится получить реальный опыт и разобраться и тех, кто просто приклеил модный бренд. Те, кто разбирается - получают опыт и объединяются с первой группой. А вторые - ну, они знают, что для продаваемости тренинга Agile - полезно, и вставляют его как часть программы, чтоб было, не слишком углубляясь в содержание и воспринимая его через свои шоры.
А еще есть третья группа - те, кто активно ходил на тренинги личностного роста, часть которых учит умению называть себя экспертами и пользоваться модными брендами. И у них представление Agile - просто смесь модных лейблов... Они тут объединяются со второй частью тренеров, использующих бренд.
Так что в целом - среда неоднородна. Но для меня важно, что первая группа - достаточно многочисленна, и именно она обеспечивает движение Agile. И пополняется она не только за счет практиков из IT - по мере распространения в другие отрасли будут появляться практики там, и серьезные бизнес-тренеры тоже разбираются и приходят в Agile, Потому что за ним - будущее, это - управленческая технология общества третьей волны.
Написано по мотивам обсуждения на FB, опубликовано здесь
2017-10-11: Спиральная динамика и создание бирюзовых коопераций - встреча в Minsk Knowledge Office
Сегодня был на встрече в Minsk Knowledge Office. Я рассказывал про Спиральную динамику, а потом все вместе обсуждали на конкретном кейсе возможности создания бирюзовых коопераций не в светлом будущем, а в настоящее время. И я хочу поделиться своими впечатлениями со встречи, а заодно - опубликовать презентацию для участников. Видео встречи https://youtu.be/UmWNkova47o
Во-первых, сама площадка - очень интересная. Сообщество управления знаниями организовали в Минске Андрей Мирошниченко и Артур Пинчук. Это площадка, на которой люди представляют свои проблемы и могут в коллективном обсуждении получить помощь для решения. И именно это - не выступления или представление себя, а запрос помощи от сообщества - основное назначение. И в начале встречи, когда все представляются, ответ на вопрос о том, какой кейс хочешь сообществу представить, о чем хочешь выступить - он обязателен. Естественно, можно сказать, что пока ты просто послушаешь, но это надо явно сказать - а значит, как минимум, подумать над вопросом.
Во-вторых, из представлений участников я в очередной раз получил подтверждение, что тема бирюзовых организаций и спиральной динамики - востребована и интересна. При чем интересна очень разным людям, с разных позиций. И это были очень взвешенные позиции, а не просто интерес к модному случайно услышанному слову. Это - радует, это подтверждает, что под hipe-темой есть большое реальное движение.
В своем рассказе я дал концептуальный обзор Спиральной динамики как модели развития человека, организаций и общества в контексте третьей промышленной революции, закате индустриального общества и переходу к обществу третьей волны. С особым акцентом на конструкции бирюзовых организаций. По отзывам участников, такой концентрированный синтез концептов в кратком изложении получился хорошо и дает ориентиры, с которыми можно дальше работать, детализируя содержание по разным источникам. И я рад, что мне это удалось. В посте я выкладываю презентацию, а позднее должно появиться видео - встречу записывали.
Но основную часть встречи занимал разбор конкретного кейса, который был анонсировал в посте перед встречей. Я хочу отметить, что меня интересует не столько конкретный кейс, сколько возможные сценарии действий и условия, при которых возможна кооперация. Предпосылки тут такие. Сейчас на рынке консалтинга, в частности, в Agile, в работе с ценностями и фасилитации и других, а также на некоторых других рынках, например, в IT, есть достаточное количество участников - небольших компаний, которые внутри устроены как желтые (по Спиральной динамике) самоорганизующиеся команды, быть может с оговорками. Но все они действуют на рынке, который рассчитан на оранжевый интерфейс и потому именно его выставляют. И по этому интерфейсу их находят и заказывают услуги. Дальше в некоторый момент команда-исполнитель может понять, что заказ - не совсем профильный, чего не было видно при начальной диагностике. Именно "не совсем" - то есть ты сам сделать можешь, но качество будет средненькое. В идеальном будущем в этот момент должны сработать некоторые механизмы, привлекающие в кооперацию других исполнителей с более адекватной компетенцией. В настоящем этому препятствует оранжевый контракт, к котором предполагается некоторый результат и компетентность исполнителя по его достижению, и в котором опция привлечения кооперантов не предусмотрена, можно только сделать или отказаться. И ситуация обычно осложняется тем, что у тебя нет надежного кооперанта, которого можно привлечь с гарантией хорошего результата, можно лишь экспериментировать, и сколько надо экспериментов, чтобы получить качество выше среднего - неясно. В общем, тема - интересная и без очевидных решений. Обсуждение дало некоторое количество идей, над которыми буду думать.
А еще обсуждение шло извилистыми дорогами и иногда выводило на интересные сопутствующие темы. Для меня, например, важным был вопрос о том, что является двигателем перехода на следующий уровень Спиральной динамики, если говорить об организациях. В книге Дона Бека и Криса Кована на эту тему есть совершенно общий ответ - несоответствие внешних условий внутренней структуре организации, а значит этот переход реактивен: сначала меняются условия, потом меняется организация. А дальше про каждый конкретный уровень написано - что является причиной выхода, и как это решается на входе в следующий уровень. С другой стороны, есть альтернативный ответ: Петр Щедровицкий четко показывает развитие организаций и общества как развитие разделения труда. При этом это развитие носит не реактивный, а проактивный характер: новые схемы придумываются, апробируются, а затем происходит переход. Эти две точки зрения на причины хочется обдумать на конкретном материале.
В конце встречи многие участники говорили об извлеченных уроках для себя. Так что встреча прошла с пользой.
2017-10-08: заметки с РИФ-Технологии
Неделю назад был на форуме РИФ-Технологии в Ульяновске. Ленинский мемориал, 3500 участников, семь параллельных треков выступлений и большая технологическая выставка в холле. И для специалистов и для широкого круга интересующихся, включая школьников. Потому что в Ульяновске проблема: в городе 150+ компьютерных компаний, и им нужны специалисты. А школьники не видят IT-карьеры, а если видят — не подозревают о том, что она возможна в Ульяновске на мировом уровне. И IT-сообщество вместе с региональными властями и системой образования работает над этим, я про этом писал еще несколько лет назад в отчете про Стачку. И приглашение школьников на IT-форумы — часть работы по выращиванию новых кадров.
Я выступал на треке Процессы и управление с рассказом про Роли в проекте — как проектировать разделение ответственности, адекватное особенностям проекта, какие есть типовые варианты, и как разделение ответственности описывать. Передо мной Иван Селевестров рассказывал про Agile.
А потом я ушел посмотреть другие секции и попал на любопытный доклад Татьяны Субботиной о проблемах, которые встречаются на проектах с госзаказчиком. Интересно, что рассказ был на примере реального проекта, в котором встретилось очень много грабель, которые очень больно отозвались компании-разработчике. Для меня лично все грабли — знакомые, эти проблемы достаточно часто бывают на проектах с крупным корпоративным заказчиком. А для Татьяны оказались новыми. Но, что интересно, компания Татьяны довольно давно работает на рынке госзаказов, у них — много проектов и казалось бы, грабли тоже должны быть известны — ан, нет, этот проект был у нового заказчика и оказалось, что специфика довольно велика, и в ходе проекта сталкиваешься со многими неожиданностями. Основная проблема, на мой взгляд, была в том, что у заказчика достаточно тяжелые коммуникации между подразделениями и менеджер проекта не адекватно представлял себе работу подразделений-пользователей и их проблемы — а достучаться не мог. А у них ситуацию диагностировать не получилось. Плюс они чересчур серьезно приняли тендерное задание на проект — а оказалось, что его писали за полтора года для тендера, ситуация уплыла принципиально, но переделывать документ не стали и подрядчика не предупредили — действительно, а зачем?
А после обеда был на интересном докладе Сергея Аверина из Acronics «Выбор JS-фреймворка для крупного проекта». Реальная проблема для них - используемые фреймворки предъявляли чрезмерно высокие требования к разработчикам. Для них web-разработка - вспомогательная к тяжелой серверной разработке, по-сути пишется административное приложение. Которое надо не просто написать однократно, а докручивать по мере развития сервиса, и задачи - простые и относительно небольшие: добавление кнопок, отдельных параметров и конфигураций для нового функционала. А те фреймворки (ExtJS, JQuery), которые они использовали - не позволяли это делать, плюс сами приложения были на разных стеках. И они запустили масштабный проект по выбору нового фреймворка, чтобы перейти на него, переписать старые приложения и вообще использовать однородный стек. Проект вели техлиды команд, и в его процессе был практически сделан собственный фреймворк, поняв, что же именно им нужно, но при этом осознав, что развитие будет слишком дорогим. И в результате сделали композитный вариант: добавили к Angular 2.0, который как раз стал гораздо более зрелым к окончанию экспериментов, собственный диспетчер событий, обеспечивающий нужное им взаимодействие и понятность кода, и получили то, что надо. Из важных идеологических вещей отмечен TypeScript. Кстати, весной предыдущая версия доклада была на HighLoad и есть видео.
Вообще на конференции были сильные технологические треки, и мне жалко, что не получилось послушать больше. Ну, что поделать, это - обычная проблема конференций с большим количеством треков :)
А в заключении - ссылки на мои посты-заметки.
Пост Забавно :) Два трека: процессы и управление и дизайн и проектирование. В перовом - рассказ о том, что ситуация в проекте меняется - и это нормально, что фиксация через артефакты - работает плохо, надо действовать через коммуникации. Об этом говорил Иван Селеверстов, говорил я в своем докладе. В треке дизайна и проектирования - рассказ Таня Субботина по опыту крупного госпроекта. И там акцент на документацию и артефакты, как способ фиксации, сожаление, что на проекте постоянные изменения требований с рефреном "власть развращает", хотя для трехлетнего проекта изменения - очевидны, и много других акцентов, связанных с нормативным процессом. Но что интересно, противоречие - только формальное, на самом деле речь идет о приближении с разных сторон к примерно одному результату, и потому ставим разные акценты - те, которые представляются важными. И многое из того, о чем рассказывает Татьяна для меня - очевидно, пройденный этап - все это надо делать. Но - в необходимом объеме, а не максимально хорошо. Просто в ситуации проекта Татьяны было естественное ограничение по ресурсам, надо было сделать все, что можешь. А мой рассказ и рассказ Ивана - из позиции многих больших корпораций, в которых как раз ресурсов не жалеют, и надо разрушить чрезмерное регулирование. Так что правда - в обоих докладах.
О ведении документации - с интересным обсуждением. Еще заметки с РИФ.Технологии. Все-таки разброс используемых технологий часто является большой неожиданностью. Люди в 2017 году говорят, что они видят потенциал confluence и думают о том, чтобы перейти на нее с Word. Мы в CUSTIS используем MediaWiki с 2004 (confluence еще не было), и я уже лет 5 полагал, что вики используют все :) Ан, нет...
- Виктор Алексеев А я как не любил вики, так и не люблю. Правда Ворд я тоже не люблю, но меньше
- Максим Цепков Ну, люблю или нет - это вопрос личный. А вот технологии коллективной работы на документами - это не вопрос любви.
- Асхат Уразбаев Кажется это скорее к уровню зрелости организации
- Максим Цепков Ну, да. Просто, оказывается, я сильно переоценивал уровень зрелости IT-компаний, получается... Пост об этом. Ты думаешь, мир уже ого-го где, а он еще не там :(
- Асхат Уразбаев Да они же разного возраста
- Дмитрий Синяев А когда заказчик заставляет хотя бы Redmine (т.к. бесплатно) завести подрядчика, при этом во всю намекая на Jira - это какой уровень зрелости IT компании?
- Максим Цепков Я думал, что в IT организация не может быть столь не зрелой, чтобы использовать Word и (при 10+ сотрудников или проектах больше 2 чел*недель) работать без таск-трекера. И это не вопрос зрелости организации, типа, в отрасли не принято иначе. А оказывается, все не так...
- Максим Цепков Не, про wiki погорячился. Все-таки, если над документом работает 1 человек и сам документ не больше 50 страниц, то word может казаться удобнее. Но в посте речь шла о компаниях, которые больше
- Arseniy Maslov Maxim Tsepkov чем не нравится Office 365 с Word Online?
- Максим Цепков Office 365 - это по идеологии продвинутый GoogleDocs получается. И это - другая парадигма. Я тут ниже с Александром Горником эту тему обсуждаю, и как раз понял, что тут разница именно в парадигмах ведения документов - как есть разница в парадигмах программирования. Я предпочитаю html-wiki парадигму, и wiki люблю без wysiwyg
- Александр Горник Вики? Трелло + гуглодоки =). Еще вот есть http://notion.so (только пилотно пробуем пока)
- Максим Цепков Гуглодоки - это вариант для небольших автономных документов. Для сложных и долгих проектов - не вариант. А трелло - не про документацию, это ведение дел.
- Александр Горник У нас 2 миллиона строк кода, 15000 тестов и 30 разработчиков. Кодовая база с 2008го.
- Максим Цепков Круто! Значит вы сумели придумать, как жить именно в таком варианте. А 2м строк кода - это единый проект? Из какой области? И сколько документов (в любых единицах - штуках, килобайтах/мегабайтах)? А организацию работы где-нибудь рассказывали публично?
- Александр Горник Да, это один продукт (mindbox.ru). Автоматизация маркетинга. Про организацию работы я рассказывал на аджайл дейс, в этом году буду на agileconf рассказывать. Про документы в объеме не скажу, мы стараемся долгосрочную документацию не держать, только при разработке фичи. Долгосрочное только публичное: help и developers.mindbox.ru
- Максим Цепков Да, для краткосрочной googledocs вполне нормально, коллективная работа есть - в отличие от чистого word, ссылки на долгосрочную там тоже делаются. При этом долгосрочная ведется в чем-то еще, описание архитектуры там где- то тоже присутствует. Еще техни...Еще
- Александр Горник Help - intercom, в нем суппорты работают и они же отвечают, developers - readme.io. Бэклог к нас в трелло, в карточках эпиков и других где нужно - ссылки на гуглодоки
- Ivan Popenko Александр Горник про Notion напиши потом, пожалуйста, как оно.
2017-10-02: Что делать, когда число специализаций превышает размер команды
Специализация в IT все возрастает, и все они нужны в разработке. Раньше достаточно было разработчика широкого профиля вместе с аналитиком, потом появилась специализация на front-end и back-end. А сейчас есть специализации на каждую мобильную платформу, и в целом количество специализаций превышает ограничение численности эффективной команды 7±2. В посте была описана именно такая ситуация, и сейчас я пишу по мотивам обсуждения. Там был дан пример команды.
- Аналитик
- BackEnd разработчик
- Разработчик АБС (Банковская система)
- Веб-разработчик
- iOs разработчик
- Android разработчик
- Тестировщик
Мы имеем уже семь узких специализаций. И многие практики перестают работать: непонятно, как делать оценку, потому что каждый компетентен в своей области. Непонятно, как обеспечить взаимозаменяемость специалистов, чтобы снять критичность при болезни одного, как избежать пробок в потоке работы из-за перегрузки одного специалиста и что делать с неполной загрузкой.
Универсальных рецептов тут, естественно, нет, однако, это не означает, что все надо придумывать самому. Есть достаточно много практик, из которых можно выбирать подходящие для ваших условий, и которые я выношу в пост. И хотя все написано на IT-примерах, это достаточно легко обобщается и на бизнес-команды, в которых вопрос специализаций стоит еще острее.
2017-09-28: как ломаются сложные системы
Выношу из поста на FB, чтобы сохранить ссылку на статью
Просторы интернета иногда выносят совершенно замечательные находки. Например, эта статья 1998 года, переведенная на русский в 2009 о том, что сбои - неотъемлемый и непрерывно проявляющийся атрибут сложных систем. В них встроены механизмы от сбоев, позволяющие функционировать игнорируя единичные сбои, устранение которых экономически не оправдано. И поэтому всегда идет баланс между операционной функцией и защитной, основная цель которой - не допустить катастрофу, и потому никогда не работают с полной производительностью. Читайте!
Как ломаются сложные системы
Мой коммент из обсуждения здесь тоже сохраню. Статья действительно старая, и аксиома из теории систем как бы известно. Только вот почему-то люди не проектируют тот софт, который разрабатывают как часть сложной системы, которая постоянно сбоит и которую надо восстанавливать. Всякое резервное копирование - да, а вот сама разрабатываемая система - любой архитектор уверен, что она сбоить не будет, и, более того, практик такого проектирования сбоящих систем - нет. Вот об этом статья заставила задуматься...
Из репоста Никита Зимин Вот это просто вау. Очень близко к тому как я представляю себе работу даже не столь уж сложных систем как например какое-нибудь SaaS приложение.
2017-09-22: Ивар Якобсон приезжает на SECR
Почему я пишу в блоге о том, что Ивар Якобсон приезжает на SECR? Потому что Ивар приезжает второй раз, он уже был в 2013 году и я тогда был на его мастер-классе. И меня поразила энергия, с которой он проводил мастер-класс в свои 70+ лет - это была не просто лекция гуру, это была работа в группах, и он подходил, спрашивал о ходе обсуждения и результатах в конкретной группе (понятно, что участники обсуждали по-русски), давал оценки. А еще меня восхищает в Иваре концептуальное мышление, и, что более важно - его способность к обновлению, способность отказываться от своих же признанных теории и кооперативно(!) делать новое.
Поэтому я рад, что он приезжает, и в этом году я снова буду и на выступлении и на мастер-классе. Тем более, что тема очень актуальная - модель управления рисками и здоровьем проекта, которой, собственно, посвящен OMG Essence. Ивар - руководитель группы, которая его создала, так что это - выступление из первых рук. Но чтобы пообщаться - не обязательно приходить именно на мастер-класс, можно услышать выступление на SECR, а потом пообщаться в кулуарах конференции. Конференция - она ведь для того и создана, чтобы общаться.
По мотивам моего поста в FB
2017-09-21: встреча в PMOclub
Вчера выступал в #pmoclub, рассказывал об эволюции проектов и руководства ими, тех изменениях которые приносит Agile, и которые придут следом. Было много слушателей, интересное общение.
И открытие для меня: было трое человек из концерна Калашников, говорят, специально приехали из Ижевска. У них в составе проектного офиса уже год как работают Scrum-команды в разработке новых типов оружия. И за двухнедельный спринт успевают сделать в железе реальный кусочек, который можно пощупать и оценить, и благодаря этому получается быстро скорректировать маршрут движения проекта - а в обычном подходе это бы было проявлено через полгода. Вдохновляет!
2017-09-19: маятник централизация - децентрализация как фактор развития
Известно, что все большие компании, да и средние тоже, переживают периоды централизации. которые потом сменяются периодами децентрализации. Марк Розин в своей книге «Успех без стратегии» назвал это маятником централизации-децентрализации. И этот маятник может качаться, просто создавая движение, предотвращая застой и окостенение организации и в этом будет его польза.
Однако, этот же маятник может быть двигателем развития организации, если каждое колебание сопровождать адекватной культурной трансформацией. Для этого его надо наложить на уровни Спиральной динамики, которые представляют модель развития и человека и общества и организаций. Эти уровни образуют отчетливую дихотомию Я-Мы, это было самым первым открытием Клера Грейвза в его исследованиях, и это дихотомия хорошо накладывается на маятник.
В результате получается вот такая схема.
Эту схему Марк показал в своем выступлении на ПиР-2017, рассказывая о трансформации РосАтома (видео). Которая стартовала в 2005 в красной культуре силы, прошла через централизацию, получив синюю культуру правил примерно к 2011, затем — сильные дивизионы оранжевой культуры успеха к 2016 и сейчас начинает переход к зеленой культуре согласия — эффективно сотрудничающим дивизионам.
После того, как схема нарисована, кажется, что она — очевидна. Казалось бы, чего нового — совместили две дихотомии. Но фишка в том, что пока ты эту схему нарисованной не увидел — ее у тебя нет, ты не видишь такую взаимосвязь и не получаешь соответствующие выводы. Именно поэтому я публикую этот слайд (с разрешения автора) - Марк пока его не публиковал, поэтому я не могу просто сослаться.
Источники для интересующихся
- Краткое описание уровней Спиральной динамики — мое короткое описание с примерами из повседневной работы
- Марк Розин «Успех без стратегии» как книга для бирюзовых организаций — мой конспект книги для тех, кто еще ее не читал.
- Путешествие по спирали — статья Марка Розина, где он сопоставляет корпоративные культуры уровням Спиральной динамики. Именно он придумал соответствующие уровням названия культур. соответствующих уровням: принадлежности, силы, правил, успеха, согласия и синтеза.
- ПиР-2017 — Россия успешно вступает в мир третьей волны — мой отчет о ПиР.
- Видео выступления Марка Розина на youtube
[ Хронологический вид ]Комментарии
А взглянуть на страницу результатов теста можно? Еще хотелось бы услышать ваше мнение о времени первого появления достаточно крупных цветовых сообществ.
В общем, не проблема, ниже вырезка из результатов в части спиральной динамики. А про появление цветовых сообществ - я не понял. Где, в каком объеме. Потому что есть сильная неравномерность - в общественной жизни, в науке, в бизнесе (деловом сообществе). Отдельные представители были всегда (ну, с античности), и они объединялись в какие-то кружки. То есть нужен более развернутый вопрос.
Ага, спасибо.
Ваши тексты мне нравятся, хотя тема тимбилдинга не близка.
Мне кажется, ваша профориентация (на бизнес) несколько деформирует общее видение картинки (бизнес таки оранжевый мем). В частности, видится ошибочным представление, что "уровень понимания" начинается с оранжа. О попытке "отождествления" оранжевых с желтым неплохо имхо сказано в этом эссе (и вообще замечательный текст): http://gregory.pp.ru/sd/main.html
О времени появления - ну вот тут примерно даны некоторые оценки: http://www.plot.su/other/166-spiral-dynamics.html
Мне эти оценки не нравятся. Считаю, что значимые проявления новых мемплексов связаны с качественными изменениями технологического развития общества. Эта мысль в отдельных материалах по СД проскальзывает, но конкретные точки перелома не описаны. Некоторые свои мысли (не слишком причесанные) по этой теме оформил тут, возможно, вам будет интересен еще один взгляд на модель: https://docs.google.com/document/d/11gJfUH7P2EIWslN848nVWeK138SSSaUCgJPAztKrxWc/pub
Ну и ссылку на страничку с результатами своего теста оставлю, тоже проходил его пару лет назад: http://www.jobeq.net/PPE/VSQ_UserFeedback.php?LANver=RU&XID=209897&TID=5464
зы Почему-то не получил уведомления о вашем ответе, хотя на комменты подписан.
Нет, если воспринимать бизнес как деятельность, то он есть на всех уровнях, при том разный. Я со времени поста, чтобы детальнее разобраться и как-то уложить свое понимание сделал пару докладов про спиральную динамику на ИТ-шных конференциях. И вроде как хорошо укладывается, что традиционный менеджмент (Друкер, Адизес) это красный + синий + оранжевый, и в жизненном цикле корпораций Адизеса эти составляющие хорошо видны. А текущее развитие менеджмента - Agile в ИТ - начинался как зеленый протест, ушел на желтый уровень, а сейчас пытаются строить бирюзовый, но успех пока не достигнут. Как статья это не оформлено, но тут Спиральная динамика - логика развития системы ценностей (Максим Цепков на AgileDays-2014) есть презентация и видео - если интересно.
И да, я окончательно пришел к выводу, что второй ярус начинается с оранжевого, но это - не "уровень понимания". вообще каждый уровень вносит что-то новое, что дальше сохраняется, это общий принцип. А ярус выделяется просто исходя из аналогии уровней. И поскольку сейчас движение общества уже хорошо видно, по сравнению со временем исследований Грейвса, то можно посмотреть на верхние уровни и сделать выводы про аналогию.
Да, эссе - смотрел, не понравилось - слишком поверхностно. И поэтому местами там, на мой взгляд, идет наклеивание ярлыков без достаточных оснований.
Вашу модель посмотрел, интересно. Во многом согласен. Но вот однозначное сопоставление уровней с формациями считаю неправильным, потому что надо расщеплять формацию на смесь деятельностей (государственное управление, общественное движение, бизнес, ...), переход по уровням переходит неравномерно и реально существует смесь. Когда же приписываешь уровень формации целиком, то это просто запутывает.
Про уведомления - я посмотрю. Возможно, чтобы они ходили, надо подтвердить адрес электронной почты, это в Настройках (придет письмо, кликнуть ссылку).
Английская статья "Spiral Dynamics" из википедии (http://en.wikipedia.org/wiki/Spiral_Dynamics) сейчас является перенаправлением на биографию Дона Бека. Оригинальную статью удалили 15.03.2015, а 10.08.2015 - сделали статью с перенаправлением. Основания для удаления - оценена как промо книги.
Я не нашел, как извлечь из википедии оригинальную статью, которую я читал в 2013, но archive.org все помнит. Я читал примерно вот это, а последняя версия перед удалением эта.
Я бы сказал, что логика очень странная. С другой стороны, на момент удаления в статье стало столько ссылок на книгу, что можно было так оценить, наверное. А в 2013 библиография была более сбалансирована.
Русский перевод тоже доступен только в архиве.
И, что интересно, эти изменения со статьей по Спиральной динамике - замена отдельной статьи на перенаправление на биографию Дона Бека произошли практически в момент смерти Криса Кована 15.07.2015. В в его некрологе рассказывается. в том числе, о расколе между соавторами книги.
Сохраняю для себя.
А это - ссылка на пост Макса Богуславского с впечатлениями о конференции, FB принес в ленте воспоминаний.
Есть книга-исследования "Введение в организации будущего" - Фредерик Лалу. Автор попытался найти работающие бирюзовые организации, и изучить их ценности и процессы изнутри. Некоторые организации в исследовании желтые, но некоторые и врпавду можно отнести к бирюзовым. Это к вопросу о переднем крае развития организаций
Большое спасибо! Я посмотрел ознакомительный фрагмент, купил электронную версию, буду читать. Для меня тут интересны не только механизмы управления внутри, но и масштаб и сложность достигаемых результатов и способ вписанности в экономику.
Тренинг не записывали, но кусочки техники ведения видны на видео доклада на сайте конференции или на youtube на 11 минуте (и на других тоже), а в начале доклада видна камера, подключенная к компу. В презентации кусочки 9-12 слайды, 88-91 слайды и еще разбросано внутри
Сохраняю ссылки.
История Денверского аэропорта - Демарко Том и Тимоти Листер "Вальсируя с медведями" Глава 3 .Пересмотр истории международного аэропорта в Денвере: здесь есть начало главы бесплатно, дальше просят денег за книгу.
Максим, интересно, что изменилось за 7 лет?
Изменилось довольно сильно, я как раз на РИТ вспоминал про этот пост в своем докладе про счастье на работе. Если в 2012 первый мир был в меньшинстве, хотя уже не был исключением, то теперь именно он - норма. И скепсис по отношению к нему со стороны второго мира сильно уменьшился. Выбор места работы поэтому происходит более сознательно. Третий мир в том виде, в котором был в 2012 - практически ушел в прошлое. Естественно, сейчас есть люди, которые прочитав этот пост говорят "понимаю, что я в третьем мире". Но при разборе фактуры оказывается, что условия все-таки сильно мягче. Идея штрафов за опоздание, например, воспринимается как явно нереалистичная, а тогда оно было.
Максим, поздравляю с выходом на новую платформу. Планируете ли прикрутить RSS-ленту, чтобы можно было удобно Вас читать?
Спасибо! А RSS-лента - есть, подписываться можно на Блог, на обновление отдельных Категорий и на все изменения (но все изменения - не слишком интересно). Правда, "из коробки" сделано не слишком удобно, кроме блогов.
Чтобы подписаться на изменение блога надо на странице блога (Блог:Максима Цепкова) нажать на значок Atom, который появляется в панели меню слева. А все остальное делается со страницы Свежие правки, тоже доступной из панели слева: по мере того, как фильтруешь запрашиваемый список правок, меняется url у значка Atom - получается нужная rss-лента.
Да, всё работает :)
Дополнение. Сейчас выложены все 8 частей, но, к сожалению, там уже pdf, а не rtf :(
Почти презентация, зато с задачами и упражнениями
К докладу "Слагаемые хорошего курса подготовки бизнес-аналитиков в среде Agile Scrum" попробовала собрать все по оценке БА на странице http://allbait.blogspot.com/2014/10/blog-post_47.html
Пост на FB - чтобы найти
Спасибо за интересное описание других докладов и хороший отзыв на мой! Я рад, что доклад был понят как описание "анти-догматичного процесса" - это действительно была одна из целей, о которых я думал при написании доклада. Любопытно, что про совместное использование обоих методов я говорил http://de.slideshare.net/AlexeiVinogradov/notestscases (слайд 17), и даже рекомендовал (в приемочном тестировании). И еще в самом конце (слайд 27) - говорил про то, что не призываю сломя голову использовать, я руководствоваться контекстом и учитывать особенности (там как раз не один Кэп, а сразу три на слайде:)). Я гляну еще, когда будет готово видео, потому что я это озвучивал голосом, на слайдах это может быть неоднозначно понятно.
Понятно. Значит момент про совместное использование я упустил. Поправлю.
А что учитывать особенности - это большинство докладчиков понимают и призывают, а слушатели почему-то часто воспринимают делай 1-2-3. Но я имел ввиду более подробное рассмотрение, для каких проектов и процессов такая замена разумна и в каком объеме, если такой опыт имеется, например, Вы пробовали в различных проектах и там оказалось несколько по-разному или на одном проекте границы нащупывали и двигали.
На совсем подробноее рассмотрение всего интересного не хватало времени доклада, но я тогда посчитаю эту фразу вопросом и отвечу в блоге, после того как вывесят видео. Такого рода вопросов есть уже много, это опять же радует. Сразу отмечу, что ответ не будет в стиле "это правильно, это неправильно", а будет описывать личный опыт и свои мысли по этому поводу и приглашать к дискуссии :).
Максим, спасибо за ссылку на книгу Левенчука! И за Ваш блог в целом.)
P.S. почему-то у меня не получилось зайти через OpenID аккаунт Google.
Максим, привет! Всегда приятно и интересно читать твои емкие обзоры. Спасибо.
Спасибо! А ты кто? А то по регистрации это нельзя понять.
К сожалению, сайт конференции gamefest.biz - был утрачен организаторами. На новом сайте конференции материалы и информация прошлых лет - отсутствует. Видео на сайте GameTrek http://gametrek.ru/archives/2175 - сохранилось.
Мне кажется что на эту тему надо смотреть шире, а именно попытаться понять почему принимается решение о взятии долга. Результаты разбора (статья, доклады) и много интересных ссылок можно посмотреть тут http://www.maxshulga.ru/search/label/техдолг. В том числе есть мнение, что не надо тратить время на отслеживание долга: http://swreflections.blogspot.ru/2015/02/dont-waste-time-tracking-technical-debt.html
Максим, спасибо за ссылки. А по отслеживанию долга все просто: любая практика (code review, парное программирование и другие) может быть уместной и лишней в конкретном проекте. Для нее надо понимать - какие цели мы через нее достигаем, являются ли они существенными и нельзя ли их достичь через более легкие практики.
Ссылки на материалы с обсуждения на Facebook
Алексей Шершнев опубликовал свою презентацию на встрече.
Массив схем развивается и можно посмотреть два текущих среза
Прочитав книгу Марка Розина "Успех без стратегии" добавил в набор схем типологию организаций 4F, тем более, что она сопрягается со Спиральной динамикой. Подробности Блог:Максима Цепкова/2016-08-01: Марк Розин "Успех без стратегии" как книга для бирюзовых организаций#Типология компаний 4F
В список не попали естественно-научные схемы устройства мира с соответствующим аппаратом рассуждений из математики и физики. Их наличие для меня очевидно, так что я не стал даже фиксировать. Сформировались в старшей школе, особенно математика - я уже тогда из интереса читал ВУЗовские материалы по матану и аналитической геометрии, решал задачки. А институт их расширил.
Навел фокус - Блог:Максима Цепкова/2018-01-09: Схемы, которыми я мыслю. Изменений немного.
Очередной фокус (2023-05).
При обсуждении мне рассказали, что в интегральной теории Уилбера, на которую тоже ссылается Лалу, различаются уровни teal, соответствующий желтому Спиральной динамике и turquoise, соответствующий бирюзовому. Среди российских специалистов по интегральной теории принято переводить teal как изумрудный.
Максим, добрый день. Большое спасибо за такое полное и структурированное изложение книги и идей Лалу.
Прочитала ее с большим удовольствием, но при этом не покидало странное ощущение, похожее на то, которое возникает при чтении различной эзотерической литературы - "прикольно, но разве так бывает?" :)
Встречали ли лично Вы в России организации, близкие по духу к "бирюзовым"? Есть ли среди них IT-компании?
Оксана, тут вопрос - насколько близкие. А главное - близкие по духу или по практике? Потому что наша компания по духу, по ценностям - достаточно близка, однако с практиками не экспериментирует, применяя наработанное в более ранней культуре.
На AgileDays-2013 был очень интересный рассказ Антона Волкова из «Танки онлайн» про эксперименты с их практиками, в 2014 он приезжал и в кулуарах рассказывал про развитие практик. На последней AgileDays был доклад Станислава Сажина "Зарплату мне назначают сотрудники" - там очень много близкой практики по самоорганизации. По частным разговорам я знаю, что в Киви двигаются в этом направлении. А в небольших ИТ-компаниях и стартапах такой дух вообще часто встречается, но по мере роста он может трансформироваться в разные стороны.
Про доклады можно почитать в моих отзывах на конференции Категория:Конференции
Максим, большое спасибо :) Обязательно почитаю. А вот про отрыв духа от практики - это интересно, неужели более традиционные практики не мешают ценностям более высокого уровня по спирали развития? А насколько практики Вашей организации более традиционные? Если говорить по классификации Лалу - они ближе к "зеленым" или еще более ранних уровней?
Нет, ближе к синим (по Спиральной динамике, по Лалу - янтарный) и оранжевым - классическая организованность. По спиральной динамике последующий уровень включает в себя предыдущие, так что если практики применять осмысленно и в уместном объеме, понимая их ограниченность, то они не мешают. Более того, отчасти становится проще, потому что внешний мир ждет от компании именно традиционного взаимодействия. Хотя есть опасность в том, что начнут работать стереотипы и осмысленность потеряется - это надо рефлексировать. При этом teal-практики agile в компании тоже есть и работают, так что организация смешанная.
Этот отзыв был снабжен иллюстрациями и опубликован на портале Спиральная динамика 21.06.2016.
Постом в Facebook об этой публикации: "Представляем вашему вниманию исключительно качественный конспект и блестящий анализ книги Фредерика Лалу от Максим Цепков" поделились более 30 раз. Мне запомнилась высокая оценка Максима Каленова "Кто слышал где-то про Лалу и разноцветные организации - найдите время прочитать анализ от Максим Цепков. ИМХО это лучшее дополнение к книге. Сильно снижает "миссионерское" настроение книги, чем переводит её в разряд полезных инструментов :)"
Добрый день, Максим. Прочел Ваши рефераты по книгам Розина и Лалу и появился вопрос. Бирюзовые организации отличаются от традиционных тремя вещами:
1) Социальная адаптивность - всякий может выбрать любое доступное ему занятие и роль.
2) Гибкость и самостоятельность решений - всякий может принять любое (в т.ч. и финансовое) решение, но существуют механизмы контроля: полная открытость информации, совет с теми кого это затронет, способы решения конфликтов.
3) Люди организованы не в процессную иерархию, а в набор более-менее самодостаточных команд.
И тут возникает проблема. Самоуправляемая команда может быть эффективнее многоступенчатой иерархии. Но увеличивая свою эффективность, самодостаточная команда рано или поздно придет к тому, что лучше генерировать доход себе, а не владельцу бизнеса. Противоречие эффективность/контролируемость традиционно решается в виде маятника централизации/децентрализации. А как насчет бирюзовых организаций?
На этот вопрос можно отвечать с нескольких точек зрения. Для начала, вот какой вопрос. Если самодостаточная команда может поставлять конечный продукт то чем. собственно, владелец бизнеса владеет? Каков его вклад? Если никакого - то команда замечательным образом уйдет. И это будет логично, вообще удивительно что она работала у какого-то там владельца. Но обычно владельцы бизнеса владеют какими-то конкретными вещами, которые у команды отсутствуют, и тем самым они нужны команде. То есть команда не является самодостаточной. Ну и достаточно часто маленькая команда не может выдать конечный продукт.
Опыт бирюзовых организаций показывает, что даже если на операционном уровне команды достаточно автономны, все равно есть аспекты, на которых сказывается эффект масштаба и для которых команда - слишком мала чтобы их осуществлять. Это касается инфраструктурных вещей типа бухгалтерии, юристов и управления финансами, хотя их можно аутсорсить в сервисные компании. И это касается развития бизнеса - обучения персонала, расширения сферы деятельности, и так далее - возникает внутреннее профессиональное сообщество и другие поддерживающие структуры. Роль центрального аппарата при этом сильно меняется. У Лалу это хорошо показано на кейсе медбратьейв Buurtzorg. Но я вижу примерно такие же вещи и в IT, хотя там много небольших компаний.
При этом жесткость границ организации действительно размывается, они становятся более подвижны и децентрализованы, их нельзя централизовать силой - однако в области разумной кооперации федерация сохраняется. Примерно так.
Можно попробовать рассмотреть это подробнее на кейсах.
И просьба - если можно, ссылку на Ваш профиль в соцсетях, хочется представлять, с кем я веду диалог.
Спасибо, теперь идея понятна. Ищутся не способы контроля, а построения культуры композиции долговременных интересов. При этом замковым камнем системы может быть что угодно: материальные активы, социальные связи, или даже умения фасилитации как у Семлера... ЗЫ. Давно хотел завести себе Фейсбук и, раз нашелся повод, то вот мой профиль https://www.facebook.com/and.kuzn
Да, именно так. Долговременные интересы для совместной деятельности, и кооперация вокруг них. При этом соблюдается автономность действующих агентов. особенно в принятии решений. А человек - вовлечен во много потоков такой деятельности. Это очень хорошо видно в холакратии с ее кругами.
Спасибо большое за статью, рекомендую ее моим студентам. Мы в Метаверситете какое-то время разглядываем спиральную динамику с разных сторон и даже положили ее в основу нескольких цепочек занятий. Все равно остается всегда много недоговоренного, и Ваша сборка дает хорошее целостное видение. Спасибо.
Рад, что оказалась полезной в образовании. А цепочка занятий по Спиральной динамике в Метаверситете - круто!
https://www.mann-ivanov-ferber.ru/books/otkryivaya-organizaczii-budushhego-illyustrirovannoe-puteshestvie - иллюстрированное издание для менеджеров и детей 8)
Да, видел эту книгу. Но внимательно с точки зрения содержания не разглядывал. Те, кто смотрели, говорят, что текст сохранен, только картинки добавлены. Получается развлекалка для тех, кто лонгриды не может осилить...
Facebook выдал в воспоминаниях фотку с конференции
Обнаружил, что забыл упомянуть интересный доклад Дмитрия Абрамова "Scrum не для всех. Люди, которые разрушат вашу команду" - о том, почему при начальном переходе на Scrum правильно расстаться с определенными типами людей, несмотря на профессионализм, для обеспечения перехода. При этом Дима подчеркивал, что после внедрения ценз снижается, потому что человек приходит уже в сложившуюся культуру.
Доклад станислава Сажина на сайте конференции, там же видео.
Для истории. Анонс 3 модуля был здесь. Помимо этих лекций есть достаточно много доступных лекций разных лет по этой же теме на сайте фонда Г.П. Щедровицкого http://www.fondgp.ru/lib/mmk/180
Для истории - пост в FB
Статья выложена у меня на сайте Проекты — для достижения результата, а не для освоения бюджета
Комментарий от Димы Безуглого при repost
Максим Цепков Опубликовал отличный обзор наших дискуссий и доклада на #AnalystDays. Часть комментариев на мой взгляд очень хорошо дополняют, то что прозвучало на докладе.
Однако он смягчил ряд тезисов.
Дальнейшее обсуждение читаем на FB.
Денис Бесков в комменте дал ссылку на русский перевод Александра Остервальде Построение бизнес-моделей. Я уже скачал с litres, читаю.
Схема переведена на английский с использованием оригинала из книги Бэкона Specialization of scientists by Francis Bacon
Осенью 2020 мне написал Yves-Michel Marti из The Baconian Company, что он нашел эту схему, она ему показалась интересной, и он хочет включить ее в статью для сборника (это анонс), который должен выйти в январе 2021. Позднее он прислал текст статьи «How Intelligence feeds Innovation. Merchants of Light of the Elizabethan Renaissance», принятый к публикации. В статье приведена эта схема и высоко оценена «An astute Russian researcher, Maxim Tsepkov, had the brilliant idea of describing the information processing process with process mapping software». Пользуясь случаем, я хочу поблагодарить Максима Осовского, который в свое время вдохновил меня на перевод.
Из комментариев Сергей Косовский: Огонь! Давно эта проблема у меня в голове висела! Спасибо за решение.
Из комментариев Эдуард Галиаскаров: Очень похожий подход я использую и студентам даю по use cases. А подсмотрел его у Арлоу и Нейдштадт в книге UML2 и унифицированный процесс. С другой стороны сам uml предлагает сворачивать каждый сценарий в отдельную деятельность.
Я: надо будет запомнить книгу
Еще обсуждения идут в группе Анализ в ИТ-проектах
Дополнение. При автоматизации важно предусмотреть в системе возможность зафиксировать результат разбора с кейсом-инцидентом. Например, если контрагент не согласен со стоимостью поставки и мы пошли на уступки - как это зафиксировать в системе? Это может быть отдельный документ о списании долга или возможность добавить скидку или изменить цену в старых накладных. Или если при проверке отчета обнаружена необходимость его исправить, при том, что документы нужным образом исправить нельзя. Впрочем, последний случай в принципе решается, если отчет можно экспортировать в Excel и исправить там - но хорошо бы, чтобы в системе оставались следы.
А регистрация и типизация инцидентов и автоматизация взаимодействия по ним - это уже следующий уровень.
Из поста на FB
В качестве ответа на статью Марк Мельник написал две статьи, в которых предлагаю термины, к которым мы более привычны: сценарий, типовой сценарий, рассматриваю ограничения нотации BPMN в моделировании сценариев. Там же я выдвигаю требования к ИС, которые хотелось бы видеть в реализации: https://habrahabr.ru/post/304242/ https://habrahabr.ru/post/305016/
Статьи интересные, мне понравились. На FB по ссылке можно посмотреть обсуждение.
Обсуждение на FB исторических примеров, которые я прописал весьма диагонально
Из комментов на FB
Игорь Беспальчук: Очевидное место исследований в ИТ - это исследования существующих продуктов, компонент, технологий. С целью изучения их свойств и границ возможностей.
Максим Цепков: Это интересная тема. Если быстро, то я подумал, что это получается как-то странно: изучаем отраслевой же искусственный мир. А потом вспомнил, что многие химические и фармацевтические компании изучают вновь синтезированные вещества для оценки потенциала применения в своей области. То есть получается цепочка R-D-R-D-...
Обсуждение на FB. Там несколько репостов, и в каждом - свои ветки дискуссий.
"По мере фокусировки на основном проекте семьи — рождении и воспитании детей, — будет происходить уже осознанная работа на желтом уровне и дальнейшее движение к бирюзовому во взаимодействии с новыми структурами образования." - самый спорный, на мой взгляд, пункт пересборок. Ибо самый базовый и самый мистический. Свыше показаны человечеству примеры "запрета", тормоза на размножение в истории нескольких тысячелетий и сотен поколений. Так что оптимистичная, на Ваш Максим взгляд, история не есть единственно верная из возможных историй. Хочется быть позитивистом, но здесь именно, в этом прогнозе мне предпочтительней осторожность. Моё предложение иметь выборку нескольких социальных уровней по этническому, социокультурному или территориальному признаку чтобы анализировать "пересборку семейного уклада", поскольку в этом вопросе однозначно присутствует функция фильтра и "за бортом" процессов останется колоссальное количество населения планеты.
Обсуждение на FB. В комментах есть интересная тема про вектора в сегменте малого бизнеса, я его не выделил отдельно, а, возможно, зря. И еще немного про blockchain
Сохраняю из комментариев facebook.
Елена Верещагина: Эх... не так страшен Agile, как эйфория вокруг него... https://vc.ru/p/agile-victims
С большим уважением отношусь к автору поста. Но не могу не заметить о странности противопоставления Agile и "всему остальному" опыту, накопленному в проектном управлении.
Успех того или иного проекта определяется, на мой взгляд, не сколько методологией, сколько профессионализмом участников, понятными целями и сыгранной командой. Разве не так?
И мой ответ.
Елена, к сожалению, статья тиражирует много ложных мифов. И, более того, пытается подкрепить их ложными фактами. Первое - о том, что Agile подходит только маленьким компаниям. Реально Agile подходит и большим компаниям, хотя с его внедрением есть определенные сложности (о которых я писал). Более того, Microsoft и IBM внедряют у себя Agile-подходы уже несколько лет. При чем начали это делать именно потому, что лишились лучших выпускников - они уходили в небольшие стартапы за той свободой самореализации и отсутствием регулирования, которое дает Agile. Далее, успех проектов по Agile в IT выше, чем успех проектов, сделанных в классической методологии. Хотя цифры для сложных проектов - невелики. При этом достигается кратно дешевле. Подробности можно посмотреть, например, в докладе Джефа Сазерленда на SECR-2011 (видео и презентация опубликованы) и в других источниках.
Один из известнейших провалов классической методологии - отсрочка запуска уже построенного нового Денверского аэропорта на полтора года (!) из-за того, что не смогли запустить софт управления доставкой багажа. И неудача американской системы страхования, на которую ссылается автор статьи - это тоже провал классического подхода, а не Agile. Ген.подрядчиком вроде был IBM, а разработка обошлась 1.7 млрд $, так что провал был впечатляющим. И именно после него Обама озверел и потребовал принять Agile-методологию как обязательную для ведения ИТ-проектов с для государства в штатах. Так что дело обстоит ровно наоборот, чем пытается представить автор статьи. Что касается классического проектного подхода, то о его провале говорит то, что начиная с 6 версии PMBoK авторы пытаются включить в стандарт Agile-подход. Получается печальная эклектика. Вот так.
Так что Agile не страшен, и за ним - будущее.
Елена
Максим, больше всего вокруг шумихи про Agile мне не нравится высокий эмоциональный тон дискуссии - в духе "кто не с нами - тот против нас". Вот и Вы не правы, утверждая, что автор говорит о неприменимости Agile к крупным компаниям, просто расставляет некоторые акценты - на что стоит обратить внимание.
Да и признаюсь, меня бы эта история не зацепила, если бы воочую не наблюдала провалы многих проектов и инициатив в ИТ (в основном, крупных компаний), связанных именно с "внедрением Agile".
Автор говорит о вполне конкретных вещах - необходимости интеграционного и регрессионого тестирования, об архитектурной целостности системы и т.п.
Там, где Agile внедряется - это как правило компромисс и микс, а не ортодоксальное отрицание накопленного опыта.
Методологии приходят и уходят, а инженерные практики остаются. На голом энтузиазме далеко не уедешь...
Как я знаю, многие ИТ специалисты, наевшись "гибких практик" ищут компании, где можно просто достойно делать свое дело, не гоняясь за всякими безумными нововведениями ради "красного словца" людей, которые делают на этом имя... Вопрос - правда, какое и для кого...
Мой ответ Дискуссии вокруг Agile могут быть с разным эмоциональным накалом, в зависимости от позиции участвующих. Так же как и все остальные дискуссии. Что касается данной статьи, то я указал на конкретные проблемы у автора приведенной статьи с пониманием темы и владением материалом. При том, что он позиционирует себя в качестве эксперта. Автор, с моей точки зрения, не расставляет акценты, а явно говорит о слабой применимости Agile. При том что в ряде крупных компаний он успешно используется. А статистика говорит о сравнительной успешности Agile-проектов. Провалы внедрения Agile, о которых я тоже знаю, связаны как раз со слабым профессионализмом тех, кто этим занимался. И это характерно не только для Agile, а для многих эффективных инструментов, ставших модными из-за своей эффективности - их пытаются внедрить не разобравшись.
И я отдельно хочу подчеркнуть, что Agile - это вовсе не энтузиазм, а как раз набор организационных и инженерных практик, которых в нем много. Включая интеграционное и регрессионное тестирование, которое автор почему-то выносит за пределы Agile. Ряд из практик Agile я перечислил, отвечая выше Екатерине Филатовой. И да, эти практики работают.
Ссылка на пост FB - репосты и обсуждения в комментах.
Историю про приписывание провала ObamaCare методологии Agile в статье на которую сослалась Елена Верещагина рассказал в группе GosAgile, которая началась чуть больше года назад с AgileKitchen в Аппарате правительства, на которой Асхат рассказывал, что провал сайта медицинских страховок инициировал как раз обязательное применение Agile вIT-проектах для государства в Штатах.
Коммент Дмитрий Синяев А пруфы привести сможете?
Просто обзор заметок по данной теме лично у меня сформировал следующее мнение (возможно ошибочное) 1. Когда при запуске начались проблемы, ряд СМИ написал, мол обгадились из-за того, что не использовали "современные подходы", то же New Yorker писал что вот Agile, Scrum.
Только вот потом другие порталы писали, что подрядчики по проекту (их было несколько), в частности, те кто пилил front-end и back-end использовали Agile. И что проблема глубже, а использование agile еще не гарантирует, что вы на проекте не обгадитесь.
ИМХО журналисты которые первыми написали, зарабатывали себе очков на неудачном запуске, не особо вникая в детали.
2. Что касается "послужила причиной перехода" - это тоже как-то не вяжется например с тем, что проекты по разработке ПО с использованием Agile реализовывались в 2012 году в FBI. А проблемный запуск Obamacare был в 2013 году. ИМХО параллельные активности, но консультанты Agile считают по-своему.
3. Для проекта, КМК, намного критичнее было, то что его республиканцы сливали, в сенате, в верховном суде и всячески вставляли палки в колеса, это в итоге привело к тому, что в 2014 году была проблема с согласованием бюджета.
4. Сейчас Трамп прикроет всю эту программу и тогда это будут просто выкинутые деньги на ветер, и будет не важно Waterfall, Agile или магия вуду использовались на проекте.
Мой ответ
Пруфы - легко. Тем более, что они есть в моем отчете с AgileKitchen http://mtsepkov.org/GosAgile-2015-11 Презентация Асхата http://www.slideshare.net/ScrumTrek/agile-55075828 История HealthCare.gov в вики https://en.wikipedia.org/wiki/HealthCare.gov, история US Digital Service на их сайте https://www.usds.gov/story
Из них видно, что фейл проекта произошел при запуске осенью 2013 года. Отдельные подрядчики могли работать как угодно, но в целом проект велся по классической водопадной технологии. Для меня достаточным признаком является обнаружение проблем с регистрацией практически перед запуском. Что означает отсутствие интеграционного тестирования, а возможно и вообще практики continuous integration в рамках проекта, и отсутствие итеративных поставок конечного продукта. То есть базовых практик Agile. Не говоря о многократном возрастании стоимости.
И поскольку облажались все регулирующие структуры, в которых, по-видимому, сидели апологеты проектного метода, то после этого фейла, в 2014, Обама организовал в составе аппарата Белого дома US Digital Service. Который занялся не только разработкой норм на ведение проектов, но и практической реанимацией HealthCare.gov.
А политика - она поверх этих технических фейлов наворачивалась, это производная. Как не валили проект в сенате, бюджет подрядчики освоили, шутка ли 1.7 млрд $ за сайт, пусть со сложным бэк-эндом.
Мое дополнение. Кстати, на той же AgileKitchen был интересный рассказ Марины Макарчук из Ростехнадзора - о том. что они уже два года перешли на Agile с 3-недельной поставкой релизов для своего основного комплеска из 17 подсистем. Чем избавились от конкретной боли. когда после очередного полугодового релиза всех подсистем 1-2 месяца шло утаптывание их интеграции в боевой конфигурации - при том, что установленные законом 2-недельные сроки для обработки Ростехнадзором обращений других организаций никто не отменял. Теперь все нормально. Правда, чтобы убедить подрядчика, который бsk сторонником классического подхода и уверял, что "Agile не работает" в таких проектах потребовалась эскалация до замминистра. Так вот, Agile работает.
Правда, мои ссылки Дмитрия не устроили, и там пошел разбор на тему качества и доказательности различных ссылок. Кому интересно - читайте, начиная отсюда
Для себя сохраню следующий собственный коммент
Печальный для сторонников классического проектного метода факт состоит в том, что проект разработки HelthCare.gov - государственный проект и он велся по тем методикам проектного управления, которые были приняты в США как стандарт. Там на эту тему есть регулирование. И блистательно провалился. И, более того, по результатам разбора и анализа этого кейса администрацией президента было принято решение не просто наказать виновных или изменить нормы, а создать отдельную организацию, не связанную с предыдущими, которая должна была построить новые нормы ведения IT-проектов. основанные на Agile. И именно этим она занималась как основной деятельностью, заодно работая по конкретным проектам.
Таким образом, провал ранее принятых стандартов проектного подхода был зафиксирован делом, а не словом.
Обсуждение в группе Бирюзовые организации продолжается.
Коммент Igor Panyuta Поддерживаю мнение Елены Верещаги. Во-первых, она практик и занимается реальным делом ежедневно. В вопросах IT её мнение для меня входит в пятёрку самых интересных. Наблюдаем ещё один пример перманентного конфликта между тем, кто делает и тем, кто учит. Воистину – “Кто умеет - тот делает, кто не умеет — тот учит” (Бернард Шоу). Подозрение вызывает уже сам по себе факт очередной активной шумихи. На этот раз это AGILE. Начинаешь разбираться и понимаешь, что по сути это один из инструментов в УП (Управлении Проектами) или PM (Product Management). Этих инструментов существует десятки и сотни. Почему вдруг один из них вдруг стал панацеей от всех бед? Это как если слесарь вдруг будет утверждать, что рожковый ключ на “17” самый главный и универсальный инструмент. И много он таким инструментом наработает? PM занимается не только IT. Круг использования инструментов PM достаточно широк и в бизнесе, и в быту. Во всех случаях инструментарий решения вопросов свой. Не представляю, как можно один единственный объявлять самым-самым? Если вернуться к аллегории со слесарем, то самыми универсальными инструментами являются молоток и зубило, древние и проверенные. Профессионализм связан со знанием как можно большего количества инструментов. Предлагать AGILE как универсальный инструмент? На все случаи жизни? Смешно, Максим. На мой взгляд, приведенная Еленой статья более объективная и взвешенная, упоминаются как достоинства, так и недостатки, ограничения AGILE. Доверия к приведенным фактам выше, чем к эмоциональным восторгам и опровержениям. Метафора с “Карнавальной ночью”? Всё это весело в кино или пока это тебя не касается лично в реальной жизни. А когда останавливается бизнес, останавливается денежный поток – это близко к катастрофе, а репутационные потери посчитать невозможно. Мой личный успешный опыт решения проблем в реализации проектов связан с высокой квалификацией исполнителей и здравомыслием, и никак не связан со знанием инструментария PM. ;-)
Мой ответ
Я тоже практик и занимаюсь реальным делом ежедневно. Коучингом и тренингами занимаются другие. Впрочем, у них - тоже реальное дело. А еще я вижу историю развития Agile и проектного менеджмента, и их взаимодействие. Так вот, в приведенной Еленой статье видно отсутствие владения фактическим материалом человеком, который полагает себя экспертом. И приписывание Agile тех недостатков, которыми он не обладает. Автор почему-то уверен, что практики тестирования в Agile отсутствуют. При этом все провалы из-за поставки некачественного ПО списывает на использование Agile-методов, не потрудившись разобраться. Особо ярким примером выступает история ObamaCare, проблемы с которой автор приписывает методологии Agile, в то время как проект велся именно по классической методологии проектного управления. А провал его осенью 2013 инициировал создание весной 2014 отдельного US Digital Service в аппарате президента, которое начало вводить нормы Agile для ведения IT-проекта и разбираться конкретно с проблемами проекта сайта страховок. Подробности можно прочитать https://en.wikipedia.org/wiki/HealthCare.gov и https://www.usds.gov/story
Далее, именно значительные успехи Agile, которые было невозможно игнорировать привели к тому, что держатели PMBOK были вынуждены включить эти практики в версию PMBOK-4 в 2008. Получилась эклектика. Впрочем, развитие идет, и стандарты подтягиваются вслед за практикой. А практика развивается в рамках Agile. При этом накопленный опыт прошлого - осмысляется и включается. Хотя держатели старых стандартов пытаются представить процесс другим образом - дескать, это Agile - лишь один из инструментов. Так что нет никакой панацеи. Есть разнообразно развивающееся, создающее практики новое - Agile, и есть старое, традиционное которое на это новое заглядывает и передовые практики оттуда забирает когда игнорировать становится невозможно. Нормальная эволюция.
А еще было конструктивное обсуждение с Екатериной Филатовой, с интересными ссылками на ролики.
Вопрос Екатерины подскажите, пожалуйста, где можно прочитать про принципы agile в более прикладном варианте? какая у него автоматизация, механизмы взаимодействия. Аллегория мне понятно - хотелось бы про механику прочитать (у меня IT проект)
Мой ответ тут вопрос сложный, в том смысле что ответ - очень объемный. Agile - это зонтичная конструкция, зонтиком являются ценности и принципы, сформулированные в Agile Manifesto http://agilemanifesto.org (там есть вариант на русском). Под этим зонтиком собираются многие методы, наиболее известные из которых - Scrum и Kanban, есть еще их комбинация Scrumban, Lean и другие. Про Scrum надо читать Сазерленда "Scrum - революционный метод управления проектами", хорошая для ознакомления (но старая, это надо учитывать) книга Книберга "Скрам из окопов" (Scrum from the Trenches), про Lean - "Lean Software Development" Мэри Поппендик. При этом, если говорить про IT-проекты, то к организационным методам надо добавлять технические - DDD, FDD, TDD, BDD, Continuous Integration и Continuous Delivery и многие другие. Автоматизируется все это в любом современном таск-трекере - Jira, TFS, есть специализированные инструменты для ведения досок, коллективной работы и много других. Потому что Agile в IT на западе - просто стандарт. При этом какие именно методы применять - сильно зависит от специфики вашего проекта. Для разных проектов подходят разные методы. Если Вы расскажете, я могу посоветовать подробнее. Можно здесь или в переписке.
Екатерина Про скрам и иже с ними знакома давно, а вот про DDD и прочими "DD" пока не понимаю их расшифровки) Про Agile нашла уже занятное видео, которое отвечает на мой вопрос. может быть будет интересно - делюсь. видео Про DDD можете расшифровку дать?
Еще видео
Мой ответ Первый ролик посмотрел, там понятная организационная конструкция в целом в рамках Agile (при условии, что механизмы, применяемые лидерами профессии и главой племени им соответствуют). Но пока эта конструкция - без организации процессов внутри, в рамках нее можно запускать Scrum или Kanban или другой вариант процесса, в зависимости от характера потока задач. Расшифровка xDD - Domain Driven Design, Feature Driven Development, Test Driven Development, Behavior Driven Development. И это далеко не полный список. А еще есть детальные практики, например. эталонный Scrum предполагает использование user story, однако они могут быть заменены на use case, если это уместно.
Второй ролик - это Книберг, один из мировых гуру, в переводе Вольфсона, который один из экспертов-практиков у нас. По книге Книберга я в 2008 знакомился с Scrum, а позднее - был на его тренинге. В ролике - классный ликбез и основы для знакомства с Agile. И от этого можно отталкиваться.
Продолжение обсуждения в комментариях на FB. Для меня много ценного, различные точки зрения. Сохраняю и для себя и для других читателей.
Комментарий Екатерина Филатова Все разговоры и непонимание происходит из-за того, что каждый по-своему видит Agile... Кто-то знает, что это манифест с 4-мя пунктами, а кто-то видит в этом целый инструмент. На сколько я понимаю, Agile - это религия) Люди знают, что убивать опасно, но им нужны были 10 заповедей. Мы все давно работаем по agile и вот только сейчас узнаём, как этот зверь называется)) (я про себя) теперь могу форсить, рассказывая "невеждам" про "Эджайл" )) Предполагаю, что ваши различия во мнениях имеют общую правду в корне, в глубине души.
Мой ответ Если б люди добирались до ценностей манифеста (которых 4) и принципов (их еще 12)... У очень многих цепочка рассуждений обрывается гораздо раньше: "непривычное -> много говорят -> фуфло" или "непривычное -> много говорят -> не для меня -> рационализируем". А потом другие читают подобную рационализацию, как в приведенной выше статье и получают подтверждение своей оценке. То есть срабатывает стереотип, отвергая непривычное. В принципе, хороший стереотип, позволяющий быстро принимать решения, особенно в современном мире.заполненном рекламой и информационным шумом. Только надо уметь во-время от него отказываться, чтобы не оказаться в прошлом. И начинать разбираться самому. А это было тяжело во все времена, люди часто глухи к новому. И, что интересно, даже реакция Грефа, который поглубже посмотрев на Agile почувствовал себя лузером(!) стереотипы многих людей не пробивает. Они ж лучше знают :) Вот так.
Так что правда - она есть, но не все включают ум, чтобы до нее докопаться.
Екатерина Филатова Максим Цепков )) у меня дилемма)) вы говорите справедливо, но я не понимаю, зачем вы это говорите. Всё правда.
Мой ответ Я это говорю чтобы побудить и автора комментария и, главное, читателей разобраться в Agile глубже, а не поверхностно отвергнуть непривычное.
Agile - это не религия. Это набор ценностей, позволяющих сотрудничать с миром и приносить ему пользу, и набор методов, способов и инструментов, позволяющих это сделать - первоначально в области IT, но сейчас это расширяется. Познакомившись с ними и начав применять можно работать лучше. Естественно, выбирая конкретные инструменты из большого набора, подходящие для конкретной задачи.
Екатерина Филатова Максим Цепков теперь поняла. Мне свойственно иронизровать. Иногда это приводит в замешательство. Религия - это метафора. Сам по себе "эджайл" не инструмент. Инструменты внутри этой красивой коробочки, как 10 заповедей внутри религии.. мы опять же говорим об одном и том же, но под разным углом. Мне метафора про карнавальную ночь понравилась. Она иллюстрирует эджайл.
Мой ответ Понятно. Просто сравнение Agile с религией я слышал от многих с негативными коннотациями - как тотальную догматичность мышления его сторонников. Догматичные сторонники, конечно, тоже встречаются. как у любой идеи, но их немного. Но к подобным сравнениям я поэтому отношусь настороженно. А мы с Вами действительно во многом говорим об одном и том же. И рад, что понравилась метафора.
И еще один содержательный тред комментариев Елена Верещага 25-28.12 (перенесено позже)
Максим, спасибо за столь подробный ответ на мой комментарий.
Признаюсь я несколько “утонула” в том объеме информации, которую Вы вытащили на поверхность данного контекста ))
Прежде всего, хочу сказать, что при углублении в тему - вижу довольно много общих точек соприкосновения - мысли, что Вы излагаете, мне также созвучны. И в этом права также Екатерина, которая заметила, что часто мы по-разному понимаем нечто или напротив - разными словами называем одно и то же.
Какие высказанные Вами идеи мне созвучны:
Далее под этим комментом я напишу еще несколько мыслей - в продолжение
С некоторыми суждениями я готова поспорить:
Максим, в любом случае, спасибо за Ваше неравнодушие, а также за стимуляцию лично моего развития в теме - Вы подняли достаточно большой пласт информации, куда стоит посмотреть.
Было бы интересно продолжить разговор предметно - разбирая конкретную практику из арсенала Agile и где она хорошо применяется, какие могут быть проблемы и почему.
Также замечу, что мы похоже, вышли за пределы круга Agile - все-таки не все *DD имеют к нему непосредственное отношение. По кр.мере, для меня эта связь на данный момент не очевидна.
Максим Цепков Елена, я очень рад, что мои комменты вызвали такой отклик. По пунктам, которые вы затронули в комментарии, я отвечу детально (только уже завтра), потому что их интересно разобрать конкретно. Но если говорить в общем, то у нас различается взгляд на логику развития ведения IT-проектов, которая породила Agile.
В Вашей логике Agile - преимущественно организационные практики (хотя не только они), которые родились как развитие проектных практик PMBOK и по мере вызревания были в него втянуты.
С моей точки зрения, Agile возник наоборот, как резкое отрицание PMBOK и вообще процессного подхода (который достаточно ярко проявился в RUP). Отрицание начал еще Том ДеМарко в 1987 "Человеческий фактор", и оно очень ярко выражено в первой редакции книги Бека Extreme Programming и Agile-манифесте, который как раз декларирует иные ценности. Далее он развивался, порождая собственные способы IT-разработки (Scrum - первый массово успешный из них), в том числе, используя ранее наработанные практики как источник идей, но сильно адаптируя их к собственным ценностям - в соответствии с диалектикой развития "тезис-антитезис-синтез". А когда успех стал очевиден - пошел еще обратный вектор.
При этом ряд людей восприняли Agile в конструкции ярко выраженного отрицания классического подхода и до сих пор это высказывают, возражая против синтеза.
Характерно, что наши различия во взглядах, как я вижу, больше касаются именно представлений о логике развития, а вовсе не взгляда на идеальное представление об IT-разработке, которое у нас обоих синтетично включает множество практик.
Елена Верещага Максим, спасибо за интересную дискуссию! Буду ждать Ваших детальных комментариев. А "свою историю" про Agile я напишу позже - уже видимо, послезавтра ))
Максим Цепков Елена Верещага Отвечаю по пунктам, как обещал.
1. Про Agile и PMBOK я уже написал в своем комментарии, они противопоставлены логикой развития, и тем, что для нас целое - Agile, втянувший лучшие практики классического подхода, или наоборот, классические подход, втянувший (с моей точки зрения - лишь попытавшийся) втянуть лучшие практики Agile. Для меня Agile и классика - это разные mindset, конструкции устройства мира. При этом я понимаю и могу рассуждать в обоих, но Agile считаю следующим этапом развития.
2. Долгосрочное планирование является проблемным независимо от Agile, про это есть множество исследований. И интеграционное взаимодействие тоже. Так что "а у нас Agile" - это просто очередная причина. Если смотреть глубоко, то Agile утверждает следующее: (а) долгосрочное планирование не должно быть фетишем; (б) трезво оценивайте свою способность к реалистичному планированию. И дальше как практический способ - держите product backlog на том горизонте, на котором можете, на коротком горизонте (1-3 месяца) он должен быть конкретным и пригодным для детального планирования спринта, а на длинном (полгода и более) - достаточно детальным для представлений о развитии продукта. Сроки - ориентировочные. В обучение Product Owner'а это входит (правда, я проходил тренинг Jeff Patton, он гуру, говорят, все бывает по-разному).
Что касается интеграции. в том числе от разных подрядчиков. то как только Заказчик жестко требует 2-3 недельного периода выпуска обновлений на пром, подрядчикам просто некуда деваться от налаживания интеграционного тестирования. На эту тему есть характерный кейс Ростехнадзора (там подрядчик у 17 подсистем был один, но команды разные). Классический выпуск приводил к тому, что после релиза раз в полгода комплекс 1-2 месяца приводили в чувство, а трехнедельные релизы это устранили. Кейсу уже 4 года, Заказчик счастлив. Подробности можно посмотреть http://mtsepkov.org/GosAgile-2015-11 (рассказывала Марина Макарчук, она - Заказчик).
Подводя итоги: трудности есть, но они не в методах, а в головах. Метод как раз жестко нацелен на то, чтобы проблемы были решены, ты не можешь выдать DoD "мы внедрили метод", не решив эти проблемы.
3. Я тут посмотрел автора поглубже. Если пойти на сайт компании, где автор - CEO, то компания ПРОДАЕТ Agile и DevOps крупным заказчикам. Либо автор продает то, во что не верит, либо журналист исказил его мысли до неузнаваемости. И получается. что к статье нельзя относиться, как к мнению эксперта. При этом, помимо CEO в компании два человека "старой школы"...
Конечно, Agile проще внедрять в маленьких компаниях, но это - вообще тривиальная мысль. Что, скажите, сложнее делать в маленьких компаниях. чем в больших? Разве что вести себя деструктивно и насаждать бюрократию :) Так что эта мысль не стоит большой статьи. Автор-то при этом ничего не пишет про то, как в больших компаниях это делать. А за развитие Agile тут наработаны практики и методы, например, SAF.
Xто касается "инноваций раде инноваций", то мы тут недавно обсуждали это дело, и возникла гипотеза, похожая на правду, что ряд менеджеров внедряет новое как приобретает новые гаджеты - все надо попробовать. При этом еще есть исследования, которые показывают. что регулярные изменения для компаний в целом очень полезны :)
4. Continuous Integration, на мой взгляд, must уже 10+ лет (хотя я понимаю, что есть реликты), с delivery сильно сложнее. Тем не менее, есть крупные компании (например, badoo), где это реально применяется. Есть много разных практик, как это делать, в том числе для разных сложных проектов. Включая DWH, такие рассказы я тоже слышал. Фишка в том, что при непрерывной поставки мы делаем малый квант изменений, который проверить и даже исправить гораздо проще, чем большой. И в некоторых компаниях именно так и делают. Если интересно, можно обсуждать уже технические задачи, опыт организации обновлений при том, что работа идет с большими массивами данных у меня есть.
5. Неправильно выстроенные процессы и отсутствие головы у тех, кто их выстраивал приводят к большим проблемам независимо от того, по какой методологии это все делается. А крики про то, что нельзя оперировать сроками больше 2 недель свидетельствуют лишь о незнании предмета кричащими.
На самом деле, в Agile есть довольно много практик работы с требованиями. Userstory с планированием релизов по MVP. Use case, как альтернативный вариант, при чем он не так давно был довольно интересно адаптирован Якобсоном для гибкого планирования (UseCase 2.0). Domain Driven Design для корпоративной разработки. Сложная архитектурная работа в SAF.
B при этом есть отдельные практики. касающиеся того. как предотвратить необоснованные метания, но сохранить требуемую гибкость. Ведь основная-то проблем - именно в тоем, что характерный временной лаг изменений бизнеса во многих областях - 2-4 недели. И IT должно успевать, иначе оно становится ограничением для бизнеса. Такой сейчас мир.
Елена Верещага Максим Цепков , спасибо! Как всегда - детально и обстоятельно.
Позже соберусь - и тоже приведу примеры.. А сейчас за неимением времени отвечу коротко.
В моем понимании "чистых методологий" не существует - ни Agile, ни RUP не внедряется в чистом виде - а "пилится под себя". То, что развитие состоит в том, что отрицаются некие предыдущие подходы - да, в этом собственно оно и состоит. Но никогда я не видела внедрение какой-то методологии "из коробки". А всякие попытки сохранить "чистоту подхода" как раз и приводят с высокой вероятностью к провалу. Однако соглашусь с Вами, что есть ключевые принципы - и их надо придерживаться - ради чего это и затевается (нужно понимать - какая проблема прежнего подхода решается и за счет чего). Вот тут как раз хотелось бы остановиться подробнее. Но не в этот раз ))
И в чем, мне кажется, мы с Вами сходимся, но как бы с разных сторон - это в том, что во многом все зависит от специалистов, применяющих метод, нежели от самой методологии. В хороших руках любая методология будет "жить". Проблемы провалов связаны как правило, не с методом ведения проекта - а как оно делается.
Долгосрочное планирование - всегда сложность и искусство. Проблема в том, что многие с криками "у нас Agile" на это забивают. Действительно - зачем, раз так сложно? Проще с шашками.
И поймите - я не против Agile. Я за! )) Я прекрасно вижу ограничения того же RUP. Там есть хорошие идеи и в этом есть развитие. НО! Меня коробит, когда это романтизируется, охватывается ореолом "инновационности" и преподносится как "серебряная пуля". К тому же он вовсе не в-новинку - об eXtreme Programming заговорили (а кое-где и внедрили, правда те еще приколы были) более 10 лет назад...
В любом случае - продолжаем беседу... Обменяться живым опытом (как + , так и -) всегда интересно! ))
Максим Цепков Про внедрение методологий подход классики (RUP, PMBOK) и Agile тоже кардинально отличается. Классика говорит - возьмите исчерпывающий многостраничный guide, вычеркните ненужное и используйте. Agile говорит другое - возьмите простой метод "из коробки" - Scrum, Kanban, внедрите "как есть", а потом - запустить совершенствование, точки, где это происходит процессно встроены в метод (ретро). При совершенствовании - используйте набор практик как готовый, а не подходит - придумывайте свое. Но при этом есть иерархия сверху-вниз, от ценностей и принципов к конкретным практикам, и трассировку надо сохранять.
В инновационности и романтике надо разбираться более конкретно - потому что в чем-то она есть, а в чем-то - нет. XP и Scrum появились 15 лет назад, но при этом продолжают развиваться, а применение Scrum вне IT, что сейчас делают - является определенной инновацией. То есть надо работать прагматично.
А те, кто продает серебряные пули и светлое будущее - они были, есть и будут, и будут продавать все новое, вернее, все КАК новое. Их породил маркетинг начала 20 века. Это не проблема Agile, это особенность развития современного мира. А он - таков как есть, другого у нас нет, живем в этом.
И да, продолжаем беседу!
Я, оказывается не рассказывал в блоге про песни, только в ЖЖ и на facebook. А было вот как. Когда я слушаю некоторые песни - то у меня в голове разворачивается цепочка образов. И у меня была давняя мечта - чтобы эти образы появились в виде мультика, стали доступны. На встрече ПИР, благодаря вечерним посиделкам с песнями под гитару и рояль, скрайбинг-летописи ПиРа, общению с Сергеем Гевличем, автором объясняшек, у меня сложилась мозаика и я понял, что технология, с помощью которой я могу осуществить свою давнюю мечту - увидеть мультики по некоторым песням - готова. Интересно, что про [http:xplainto.me объясняшки] я знал уже несколько лет, но вот все вместе сложилось только на ПиР.
Первая песня, которую я выбрал - "Дракон" Суханова. Я написал Сергею, он порекомендовал Елену Смирнову, художника - и получился прекрасный мультик. Я его выложил на youtube и рассказал об этом в ЖЖ и на facebook.
Думал, потом будет перерыв. Нет. Идея следующей песни пришла почти сразу и результат вы видели. Сохраняю тут ссылки youtube,ЖЖ, facebook. В процессе работы был альтернативный вариант, на совсем другое исполнение - Никитин и К, несколько голосов. Елена его тоже дорисовала.
Главная фишка состоит в том, что технология объясняшек - дешевая и общедоступная. Программа создавалась не как профессиональный инструмент для мультиков, а как широко доступный инструмент видеопрезентаций. Он такой получился, я сам видел, как ролики в нем делаются за пару часов, правда сначала надо придумать сюжет и текст, на это тоже пара часов уходит. И он доступен - я знаю, что некоторые учителя обучают детей на факультативах, и те дальше используют его как форму сдачи докладов и других школьных тематических работ. Так что мультик, получается, может нарисовать каждый. Правда, iPad нужен, но это не очень большая редкость.
А теперь - Дракон.
Публикация в FB вызвала довольно много репостов. В публикации в группе AgileRussia было интересное обсуждение - Алексеей Пименов, Слава Цирульник, Tony Granton, Владимир Каленов, Сергей Баранов.
Из отзывов ведущих
Запись видео
Войдите, чтобы комментировать.