Блог:Максима Цепкова
Профессиональный блог Максима Цепкова.
Ранее был на http://blogs.uml2.ru/blogs/maksiq и http://softwarepeople.ru/, затем на сайте компании http://lib.custis.ru/Blog-mtsepkov, а с 19.05.2014 переехал сюда.
Сейчас все посты из старых блогов скопированы на мой сайт, при этом восстановлены посты, утраченные при закрытии портала SoftwarePeople. Полный список статей можно посмотреть в оглавлении блога. Посты блога я обычно публикую на телеграм-канале https://t.me/mtsepkov, RSS блога
Последние посты
- 2013-11-08 - SQAdays - английский день
- 2013-10-26 - SECR удался
- 2013-10-24 - SECR. Мастер-класс Ивара Якобсона Use-Case 2.0
- 2013-10-18 - Спиральная динамика, 2018-08-20 — 6 комментариев
- 2013-10-12 - Впечатления с AgileKitchen
- 2013-06-10 - По следам MS DevCon-2013
- 2013-05-27 - AnalystDays-2013
- 2013-04-29 - SQAdays-13 (весна 2013)
- 2013-04-20 - Питер Друкер - Энциклопедия менеджмента
- 2013-04-14 - Конференция SoftwarePeople-2013
- 2013-04-10 - Мастер-классы Эдварда Йордана
- 2013-04-07 - Agile и классический менеджмент
- 2013-03-31 - AgileDays 2013 - между скрамом и будущим
- 2013-03-28 - Как появляется PBL - Jeff Patton на AgileDays, 2016-08-21 — 1 комментарий
- 2013-03-21 - Клуб директоров по разработке
2013-11-07: SQAdays - английский день
Сегодня прошло новое мероприятие в формате SQAdays-14 во Львове — английский день. Два трека докладов англоговорящих спикеров из разных стран Европы и США, многие из которых приехали с конференции EuroSTAR. И это важно, потому что дает возможность соотнести себя и свою компанию с мировым уровнем, понять свое место в глобальном сообществе. Отметим, что конференция шла на английском языке и без перевода, что было фишкой и служило тем же целям. И даже Влад Орликов открывал этот день по-английски.
Если говорить об уровне докладов, то он примерно соответствует тому, что я слышал на российском варианте SQAdays, и в этом смысле, соотнося себя с мировым уровнем, можно быть вполне спокойным. Более того, доклад от некоторых грандов — повышает самооценку. Потому что куча разработчиков почувствуют себя удовлетворенно — у них точно не хуже, а даже лучше, чем в Wikimedia. А у кого этого нет, тоже могут удовлетворенно подумать «ну, это ж вон кто, а мы — маленькие».
Тут надо отдельно сказать про позицию конференции. Она ориентирована не столько на лидеров отрасли, сколько на основную массу компаний. Потому что крупные компании, такие как Яндекс, Касперский или Luxoft, например, задают высокую планку и продукта, и сотрудников, и стоимости услуг, если говорить о сегменте заказной разработки того же уровня. И они не могут удовлетворить не то что все, а даже большинство потребностей рынка. И есть место для развивающихся, начинающих компаний, в которых сотрудники не столь квалифицированные, но своя ниша на рынке у них есть. Если говорить о мировом разделении труда, то эту нишу преимущественно занимают индийские разработчики, но для компаний стран СНГ и Восточной Европы место тоже есть. И для сотрудников этого сегмента тоже необходима площадка профессионального общения, роста.
Но это же сказывается и на докладах. Многое из того, о чем говорилось в них, для больших компаний и крупных проектов — вещи очевидные и, более того, в столь простом виде не применимые, там используются более сложные конструкции. Но для небольших компаний все это более чем уместно. И это надо учитывать, читая обзор докладов: когда я говорю, что в докладе были достаточно известные вещи, это вовсе не означает, что они реально применяются в вашей конкретной компании, и потому вам не стоит посмотреть этот доклад в записи. А еще надо учитывать, что на многих докладах я был кусочно, переходя между треками.
А из общего пожелания докладчикам и организаторам конференции я бы отметил две вещи. Во-первых, надо жестко запретить примеры про форму логина. Потому что она настолько тривиальна, что скучна. Во-вторых, смерть от PowerPoint докладчики изучили (не все, только продвинутые), и теперь им надо объяснять, что когда на слайде креативная картинка, под которую долго-долго что-то говорят, то это тоже плохо. Особенно, когда говорят монотонно. Мне лично слайды, где много букв даже больше нравятся — при условии, что докладчик их не читает — получается документ, который можно на досуге внимательно прочесть. Вот так.
Итак, обзор докладов.
2013-10-26: SECR удался
SECR-2013 определенно удался. Два дня я слушал доклады, практически на всех слотах были интересные мне доклады, и это замечательно. Более того, я совершенно точно пропустил много хороших докладов, и даже доклад JetBrains про Kotlin и мастер-класс Макса Дорофеева по оценке проектов, потому что приходилось выбирать между параллельно идущими треками, которых в первый день было 4, а во второй — 5(!). Да, как сопредседатель программного комитета, я знал про тезисы большинства докладов и участвовал в рецензировании. Но тезисы сильно отличаются от живого доклада, воспринимаются по-другому, и, послушав доклады на конференции, я достаточно много узнал. Появились новые мысли. И все это не означает, что на конференции были только хорошие доклады высокого уровня. Казалось бы, можно было уменьшить число треков и поднять уровень. Но по тезисам, даже развернутым, доклад оценить нельзя, кроме того, разным участникам интересны не только доклады на разные темы, но и доклады разного уровня — потому что для применения в практической деятельности доклад должен попасть и в тему и в уровень восприятия. Поэтому доклады были разные. И участники — могли выбрать, а докладчики — увидеть реакцию и в следующий раз — сделать новый доклад лучше.
А еще на конференции было замечательное общение и, собственно, в этом — профит участия в современной конференции, потому что все доклады — доступны. Презентации уже есть на сайте, а через месяц-другой появится видео докладов. Но вот пообщаться с докладчиками и другими участниками по свежим следам, по темам докладов можно только там. И такое концентрированное общение, выход их повседневной текучки позволяют почувствовать изменения, тренды отрасли. А это критически важно в такой динамичной отрасли, которой является ИТ.
И конференция сильно обращена в будущее, о грядущем было достаточно много докладов, причем не от очень разных спикеров. Ивар Якобсон рассказывал про SEMAT — Essence: это только в конце прошлого года появившаяся в относительно законченном виде конструкция. Вил ван дер Аалст рассказывал про Process Mining — свежее, но уже оформившееся течение, основателем которого он является. Джим Стайклетер, директор по стратегии и инновации из Dell, рассказывал про тот мир инноваций, которым он живет, и это очень концентрированная картина, которую получаешь за доклад. А у Дэйва Томаса в презентации и докладе было много парадоксальных трендов современности, над которыми лично я планирую еще внимательно подумать.
И в этом мире компаниям и разработчикам надо жить и развиваться, успевать за этим миром. И началась конференция докладом Дмитрия Лощинина, президента Luxoft, о стратегии успешной компании. И были доклады и дискуссии, направленные на развитие стартапа, превращение продукта или его идеи в успешное предприятие. Кстати, был забавный кейс: продажи одного продукта плохо шли. Сделали тот же продукт, но для юристов, внешняя адаптация, в 10 раз увеличили цену, запустили рекламу — продажи серьезно выросли, и при этом продаж вдвое больше, чем активаций.
А еще многие ведущие компании — JetBrains, Parallels, Дойче Банк, Luxoft, Яндекс и другие — делились своими процессами, рассказывали о них, и это были не выступления первых лиц, а рассказы сотрудников, работающих внутри разработки. И было замечательное шоу Свена Петерса из Attlassian про современную разработку.
Но при всем этом на конференции было очень много технических докладов, и это тоже правильно. Был Крис Латтнер, главный архитектор в LLVM Compiler и директор разработки в Apple, он рассказывал про принципы и архитектуру LLVM и Clang, которые являются основой многих промышленных решений. Были доклады JetBrains, доклады из Parallels, секция мобильной разработки, которую вел Дмитрий Мартынов из Google. Я был далеко не везде, но слышал много отзывов. Были качественные узкоспециализированные доклады, например, профессора Бориса Штейнберга по высокопроизводительным вычислениям, при этом я от нескольких участников слышал, что тема оказалась им очень вовремя.
Я надеюсь, что в следующем году получится сделать конференцию еще лучше, интереснее и шире. А сам перехожу к обзору тех докладов, на которых я был. Читая их, помните, что это меньше четверти всех докладов конференции, и среди остальных тоже наверняка есть много хороших докладов. Презентации всех докладов уже доступны на сайте конференции, а через месяц-другой там появится видео.
И до встречи на SQAdays, которая начинается через полторы недели во Львове и где, в дополнение к обычному формату, будет отдельный день с иностранными докладчиками.
2013-10-23: SECR. Мастер-класс Ивара Якобсона Use-Case 2.0
Очень понравился мастер-класс Use-Case 2.0, который проводили Ивар Якобсон (Ivar Jakobson) и Иэн Спенс (Ian Spence) в рамках SECR-2013. Ивар и Иэн рассказывали о развитии механизма Use Case, которое он прошел за более, чем 25 лет истории (первая идея — 1987), и расширившее его применение в разных направлениях так, что он по-прежнему адекватен современным потребностям разработки.
- Scaling Up with use cases. From small team to large project.
- Scaling out — not only req, also analysis, design, UX and so on.
- Zoom in — focused on essential, show big picture.
И это была не просто лекция, в которую иногда превращаются мастер-классы от мэтров. Был интерактив и практическая работа над заданиями в группах. Да, местами было повторение известных практик, знакомых большинству присутствующих, например, оценки, а местами достаточно сложные и интересные вещи были даны пунктиром из-за недостатка времени, но мастер-класс в целом я бы оценил высоко. Было последовательно показано применение Use Case при работе с требованиями.
Существенно новой для меня была конструкция Use Case Slice, деление Use Case в процессе работы. Суть в следующем. У нас есть цельный Use Case со всеми альтернативными сценариями. Естественным образом мы их приоритизируем, выделяя важные и примерно относя к релизам. Для этого можно использовать технику MoSCoW: Must/Should/Could/Want. Но вот когда мы говорим, что Use Case — must, это вовсе не означает, что таковыми являются все его сценарии. Мы делим Use Case на пакеты сценариев, кусочки, которые и называются slice. Они должны быть некоторым образом закончены, должна быть возможность их поименовать, их реализация должна давать некоторое business value и быть относительно независимой. И далее планирование релизов и итераций идет уже в терминах slice, которые приоритизируются и реализуются по отдельности. Естественно, с учетом зависимости, и в первый slice идет base flow, с учетом minimum viable value.
Но при этом Use Case сохраняется, он обладает целостностью более высокого порядка. А разработчики, проектируя реализацию (design), знают о других кусочках Use Case, которые надо будет сделать в будущем и учитывают их. Важно, что хотя декомпозиции на slice в конечном итоге подвергаются все Use Case, она выполняется по мере необходимости, а не изначально.
Вообще этот принцип детализации по необходимости применяется очень активно. И не только к декомпозиции Use Case, но и к различным артефактам, например, описанию Use Case и связанных с ним историй. И не в форме благих пожеланий к постепенной детализации, а через определение трех-четырех уровней детализации с формальными критериями и рекомендациями, для каких целей какие из них предназначены и на каких этапах появляются. При этом они не должны быть одинаковы по проекту, потому что Use Case и другие объекты имеют различную важность и сложность, и детализация должна быть им соразмерна.
В частности, была показана матрица техник для уровней описания Use Case в зависимости от критичности (относительно неверной работы) и частоты использования. Ожидаемо, что для критичных Use Case надо гораздо детальнее определять Test Case. А вот описание самого кейса больше зависит частоты использования: для ежедневных эффективнее краткое описание с активной коммуникацией, а вот для редко используемых, например, связанных с концом года, нужны подробные описания.
Помимо декомпозиции Use Case на slice были рассказаны следующие техники.
- Преобразование Use Case Slice в Test Case, которыми каждый slice снабжается и которые также могут иметь разный уровень детализации. Кстати, base flow может быть разложен на два или более slice, отличающихся именно Test Case: сначала делаем реализацию для единичных хороших данных, а потом — наращиваем вариативность и мощность.
- Преобразование нефункциональных требований в Use Case Slice со своими Test Case. При этом выбором Use Case, в которых это появится, заодно определяется область применения таких требований. Это можно делать не только с производительностью и масштабируемостью, но и с удобством использования (Test Case — 5 человек без обращения к помощи выполнили задание не более чем за…).
- Использование Use Case для больших компонентных систем, преобразование больших Use Case в соответствии с декомпозицией на Use Case для отдельных систем.
- Использование Use Case для требований на инфраструктурные аспекты кода, такие как аудит, лог изменений или безопасность.
А еще мастер-класс был элегантной демонстрацией Essence, разработанного SEMAT. Не в виде отдельных слайдов, а как практическое использование. Понятия — Use Case, Use Case Slice, Story — были представлены как альфы, для них описаны состояния, и уровни детализации для артефактов. Например, Use Case имеет состояния goal established → story structure understood → simplest story fulfilled → sugnificant story fulfilled → all stories fullfiled; а Use Case Slice — состояния scored → prepared → analyzed → implemented → verified, и для некоторых приводились checklist перехода. А уровни детализации, применяемые для историй и описаний, — sketch — base essential — enhansed — expanded — future expanded — с раскрытием каждого уровня и областями применения.
На этом я кончаю рассказ. Надо отметить, что на сайте Ивара доступна для скачивания после регистрации книга Use-Case 2.0 с материалами мастер-класса.
2013-10-18: Спиральная динамика
Если ты поумнел, поглупеть обратно волевым усилием нельзя. Получение нового знания — один из необратимых процессов в природе. Иногда об этом сожалеешь, потому что понимаешь, что теперь надо прилагать усилия и умнеть дальше по конкретному направлению. Вот так у меня получилось со спиральной динамикой: я хотел посмотреть, что это такое, посмотрел — и теперь придется разбираться, вписывать в картину мира. Потому что вещь — интересная, в нужной области и под ней есть годные основания и базовые положения. Только вот на них сейчас построено такое здание идеологизированных умозрительных конструкций, что продираться через них, чтобы увидеть основания, — тяжело, а здание целиком, с моей точки зрения, настолько мутно и умозриетнльно-идеологизированно, что взять «как есть» у меня не получится.
Этот пост — фиксация положения для себя, чтобы потом вернуться к разбирательству. А еще пишу его в надежде — вдруг кто уже разобрался, или заинтересуется, разберется и мне расскажет. Все-таки для меня эта область — не совсем профильная деятельность. Но обо всем по порядку.
Началось это во второй половине сентября, когда я был на тренинге института Адизеса по их подходам. В качестве бонуса по запросу аудитории нам за 10 минут рассказали, как они подходят к набору персонала. Одна из важных составляющих для них — система ценностей человека, поскольку в их подходах ценности и культура играют очень важную роль. И в качестве способа для работы и оценки системы ценностей кандидата они используют спиральную динамику, считая ее наиболее продвинутым на настоящий момент инструментом. Для меня это было достаточным, чтобы сделать заметку — посмотреть, что это за зверь, — спиральная динамика. Я там же поискал статьи, чтобы убедиться, что названия и имена — те, что надо, а дальше пару недель у меня это висело в браузере. И на этих выходных я добрался и прочитал.
Вот что я читал:
- Спиральная Динамика;
- Уровни Грэйвза. История возникновения;
- Типология систем ценностей Клэра Грейвза;
- Спиральная динамика - опасное знание;
- 7 стадий зрелости Лидера;
- Перевод на русский статьи из Википедии о теории Спиральной Динамики (оригинал).
- UPD 2018: статьи вики доступны только в archive.org: перевод, оригинал, статью в вики удалили в 2015 и потом сделали перенаправлением на Дока Бека
Читал я именно в этом порядке, и это во многом определило мой интерес и мою оценку вещи как годной. Потому что во второй статье был рассказ про исследования Клэра Грейвза.
Грейвз вел исследования в 60-70-х. Вообще это было время, когда зарождались многие теории — Друкер, Белбин, Майерс-Бриггс — это все та эпоха. Для Грейвз предметом были представления о модели нормального человека, а релевантной группой служили студенты, которых он обучал психологии. Для начала они описывали собственную модель нормального человека. Дальше — обсуждали ее с другими в произвольных группах (а Грейвз наблюдал из-за стекла). И писали, что изменилось, или, наоборот, не изменилось и почему. После этого их сталкивали с авторитетными моделями, и опять-таки они писали — изменилось ли что-то или нет, и почему. И вот так — 8 лет с каждым курсом. При этом все работы передавались внешним экспертам, каждый год — разным, задачей которых было провести кластеризацию и выделить принципы. В целом — хороший подход, мне нравится.
Так вот, в результате кластеризации получилась схема из 4 квадратиков: 4 отчетливых группы, разложенные по двум дихотомиям.
И, что интересно, переходы позиции в этих рамках были не произвольны, а шли по единственному пути развития.
Однако, были позиции, которые не совсем укладывались в эту картину, и они были статистически значимыми. И на основе этого Грейвс расширила эту классификацию, плюс связала ее с системами ценностей общества, сменявшими друг друга в ходе исторического развития. В результате получились следующие 8 уровней.
- Бежевый — автоматическое, инстинктивное мышление. Охотники-одиночки. Экспрессивный тип. Цель — биологическое выживание. Работают только базовые биологические инстинкты: голод, размножение и т.п.
- Фиолетовый — анимистичное, племенное. Племя. Жертвенный тип: индивидуальность приносится в жертву выживанию племени. Цель — безопасность, выживание племени, семьи. Мир воспринимается полным духов, загадочных сил, которые следует ублажать.
- Красный — эгоцентричное, силовое. Боги и герои. Экспрессивный. Попытка гиперреализации себя, импульсивно, любой ценой. Цель — личная власть, расширение сферы контроля. Мир — это джунгли, выживает сильнейший. Время великих путешественников и героев.
- Синий — абсолютистское, священное. Жертва ради идеи. Жертвенный. Пожертвовать чем-то, чтобы получить награду позднее. Свои желания приносятся в жертву идее, высшему порядку. Чувство долга. Цель — стабильность, порядок, соблюдение ритуалов. На этом уровне появляются крупные религии, преследование ересей и т.п. «Мыслить локально – действовать глобально».
- Оранжевый — материалистическое, ориентированное на достижения. Большая игра. Экспрессивный. Проявляю себя обдуманно, в том числе и за счет других. Реализация себя в конкуренции с другими, причем собственно процесс ценится выше результата. Проигравшему потом возвращают проигрыш, чтобы сыграть еще раз. Появляется профессиональный спорт, конкурсы красоты и т.п. Цель — успех, влияние. «Мыслить локально – действовать локально».
- Зеленый — социоцентрическое. Человек превыше всего. Жертвенный. Жертвую одним сейчас ради другого сейчас же. Жизненное кредо: бесплатных пирожных не бывает. Внимание к потребностям других людей. Появляется концепция экологии. Давайте лишимся завода, но будет чистый воздух. Цель — гармония, взаимный рост, сотрудничество. «Мыслить глобально – действовать глобально».
- Желтый — системное, интегрирующее. Интеграция. Экспрессивный. Выражаю себя, но не за счет других. Стремление к интеграции конфликтов, удовлетворению всех потребностей. Цель — независимость, свобода, достоинство, интеграция в глобальную систему. Системный подход, учет контекста. «Мыслить глобально – действовать локально».
- Бирюзовый — глобалистское, модернизаторское. Глобальное сознание. Пока что характер этого уровня не вполне ясен. Жертвенный тип. Приспособление себя к базовым принципам устройства мира. Глобальное сообщество, восприятие человечества как целого, интеграция на уровне культур.
Подробности желающие могут посмотреть по ссылкам или в других источниках, а здесь я это привожу, поскольку представление о них важно для дальнейшего.
Как легко увидеть, теория в целом не следует из экспериментального материала. Но это как раз нормально, между экспериментом и теорией лежит прозрение ученого — дуга Эйнштейна. Однако, приличные науки полагают правильным подвергать построенные теории дополнительной экспериментальной проверке, чтобы убедиться, правильно ли нас привела эта дуга. Однако, приличных наук сейчас почти нет, и, говорят, даже теоретическая физика перестала желать экспериментальной проверки. Впрочем, это уже другая история.
Если же говорить о Спиральной динамике, то проверкой пренебрегли. Более того, теорию начали строить дальше и дальше, и сейчас теория далеко обгоняет факты. Строит теорию уже не Грейвз, а последователи, и попутно грызутся — кто правовернее. Историю можно посмотреть в последней статье: это перевод английской вики (но я не проверял). Мне это напомнило историю с соционикой — там тоже сейчас несколько школ выясняют, кто из них правильнее понимает теорию, а общий уровень практики — весьма низок.
Но это — общая претензия к обоснованности. А теперь — конкретные претензии к той конструкции, которая сейчас получилась.
Это — явно оценочная конструкция. Да еще выделен принципиальный переход — второй ярус. Кстати, более политкорректное крыло последователей говорит, что второй ярус, возможно, был выделен основателем из маркетинговых соображений. А другое крыло на нем настаивает. И это при том, что сама конструкция — достаточно мутная. Тесты для определения уровней отсутствуют, и, более того, утверждают, что человек одновременно может быть на нескольких уровнях.
Кстати, если смотреть чисто на закономерности развития, как они выделены у Грейвса, то второй ярус, понимаемый как второй виток спирали развития, а не как качественный переход, явно имеется. Но начинается он не там, где его Грейвс выделил. На нынешнем уровне знакомства я могу обосновать, что гомология с бежевым начинается на оранжевом. Или, что интереснее, на зеленом, при этом по дихотомии я–мы получается движение в противофазе — умозрительно эта конструкция интереснее, хотя и сложнее. Естественно, я понимаю, что верно только одно, но для решения надо копать и нормально разбираться с бирюзовым: а говорят, что он мутный.
А еще есть неразбериха с движением по уровням. Исходные опыты были не про смену парадигмы, а про ее представление. Испытуемые — студенты, которые формулировали свою парадигму, а потом обсуждали ее. Понятно, что в процессе этого они ее и осознавали. Поэтому изменение может говорить не о развитии ценностей человека, а лишь об их вербализации и сложности формулирования определенных конструкций, а не об изменении самих ценностей. В то же время сейчас теоретики говорят, что движение строго последовательно и нельзя перейти через уровень. Как это сочетается с тем, что человек на нескольких уровнях одновременно, и может быть не только подъем, но и откат, — сильно непонятно.
А еще последовательное движение явно противоречит другим теориям, например MBTI. Поскольку последовательные уровни отличаются по дихотомии я–мы в смысле, очень близком к дихотомиям мыслящий–чувствующий и интроверт-экстраверт. А MBTI говорит, что позиционирование в типах личности стабильно и закладывается генетически или в раннем детстве.
Так что, в целом основания теории — довольно слабые, а пафос обобщений и оценочные суждения — весьма велики.
А еще наблюдается сильная аберрация близости и плюс влияние западной культуры в верхних уровнях, ибо все исследования были в Америке. И сами верхние уровни весьма малочисленны, что сказывается на достоверности. С другой стороны, историческая проекция основана на весьма схематичном, упрошенном понимании исторического процесса, который очень много схлопывает. А соответствие ценностей уровням исторического развития — одно из оснований теории.
Могут возразить, что претензии претензиями, но это же работает. На самом деле, я понимаю, почему это работает: любая разумная структуризация лучше, чем полное ее отсутствие. Ибо позволяет строить общие конструкции на основе обобщений, а не работать с конкретными фактами. Структуризация здесь в целом нормальная, дает достаточно многообразия, хотя местами и устарела. И с ней можно работать, особенно если игнорировать оценочную составляющую. А еще спиральная динамика опирается на сильные мемы, которые находят отклик, и это дает уверенность в правоте теории.
Итак, что я понимаю. Работать с системами ценностей — актуально. А говорят, что спиральная динамика — лучшее, что есть сейчас, и я склонен доверять авторитету института Адизеса. Хотя готов рассмотреть варианты. А пока — буду укладывать в картину мира и иметь ввиду.
Да, разбираясь со всем этим, я прошел тест на jobeq.net — его упоминают в одной из публикаций. Мои цвета — бирюзовый, желтый и оранжевый. В общем-то, бирюзовым я несколько удивлен, хотя про желтый и оранжевый соответствуют самоощущению. Но, значит, я продвинутее, чем думал, это — хорошая новость :)
2013-10-12: Впечатления с AgileKitchen
Серия осенних конференций началась с AgileKitchen. В конце месяца будет SECR с Иваром Якобсоном, потом — SQAdays во Львове с отдельным днем европейских докладчиков, а в начале декабря — SPMconf в Казани. Это — те, на которых я планирую быть, чтобы услышать, почувствовать новые тренды отрасли, узнать новые практики. И удачное начало этому было положено на AgileKitchen в эту пятницу, на территории Лаборатории Касперского.
Несмотря на название и позиционирование как обмен мнениями «на кухне», это было достаточно серьезное мероприятие. И по числу участников — думаю, было около сотни, хотя могу ошибаться, — которые сидели в большом зале, объединенном из трех переговорных с тремя большими экранами, и по уровню организации. И, главное — по характеру выступлений. На AgileKitchen выносятся темы, которые сейчас на острие развития, не успели обрасти серьезными теориями и практиками, но которые пробуют изучать и применять. И люди обмениваются опытом. А еще — там делятся практическим опытом решения задач, которые почему-то не становятся менее актуальными, несмотря на, казалось бы, давно известные подходы к решению. Их решают в конкретных условиях, и каждое новое решение имеет свои особенности, дает какой-то новый опыт, который тоже интересно обсудить.
Собственно, обсуждение практического опыта — самая важная составляющая мероприятия. И его было много: в перерывах между докладами, на OpenSpace, после конференции.
2013-06-10: По следам MS DevCon-2013
В конце мая я был на MS DevCon-2013, где весьма продуктивно послушал о трендах развития отрасли по версии Microsoft. К сожалению, сразу по возвращении возникло много работы, так что реплика по этому поводу появилась только сейчас.
Я уже писал осенью под впечатлением от Patterns&Practices: «Пока мы наступаем, Microsoft меняет рельеф местности». Это впечатление сохраняется, и, более того, изменения рельефа постепенно проясняются.
2013-05-27: AnalystDays-2013
Вторая конференция Analyst Days. Мне понравились все доклады на которых я был. Это не значит, что все они несли ценность и новые мысли для меня - все-таки у меня достаточно высокий уровень и большой опыт работы, однако они будут интересны и полезны многим аналитикам, и не только начального уровня. И это не только мое мнение, я разговаривал с другими участниками, слушал отзывы в перерывах между докладами. А я для себя - тоже вынес определенные мысли и идеи, которые буду применять в своей деятельности. Очень хорошая, может быть даже превосходная, Модель аналитика, которая была в докладе Димы Безуглого и Ирины Суровой. Идея Контекста проекта из доклада Кристины Ерофеевой, у нас есть аналогичные артефакты, но взгляд на них под этим углом зрения дает новые грани. Хороший практический доклад о применении Impact Mapping Дмитрия Петрашева. Книга Сэм Кеймер "Руководство фасилитатора", о которой рассказывал Саша Байкин. Хорошие метафорические названия - "метод соломенных чучел" Ани Абрамовой, для ситуации, когда для вытягивания информации представляешь на растерзание заведомо неполную модель, и схема "луна за облаками" Сергея Горицкого - "Руководство тоже озабочено проектом, если мы не сможем договориться - сходим к руководству".
На нескольких слотах я разрывался между параллельно идущими треками. А ряд докладов пропустил полностью, потому что параллельно шло более интересное для меня. И, по отзывам участников, среди них были хорошие. Так что если вы хотите посмотреть доклады в записи - а они будут выложены через некоторое время - то ориентируйтесь не только на мой обзор.
Местами конференция сумбурновата. И этому есть основания. Попытка построить стройные модели аналитической деятельности и проектирования, архитектуры и другие - кончились провалом в рамках отрасли. Получаются схемы верхнего уровня, наполненные общими рассуждениями и без строгих определений, трактуемые по-своему, или тяжелые запутанные конструкции описания процессов, слабую практическую пригодность которых знает каждый эффективный действующий аналитик. И поэтому в докладах приходится представлять частные схемы, или создавать свои. А многие аналитики-практики - сенсорики (по Майерс-Бриггс, не путать с соционикой), это очень эффективно в проектах, в которых дьявол в деталях, а деталей - много. Но концептуальные конструкции им создавать тяжело. А аналитики-интуиты - они часто берутся за достаточно глобальные построения, те самые, на которых в отрасли нет хороших моделей - меньший уровень не является для них вызовом - но модели не слишком получаются, потому как это дело реально сложное, я по себе знаю.
Прежде чем переходить к докладам, я хочу отдельно отметить высокий уровень организации. Потому что когда что-то сделано хорошо, то это как-то не замечают и не отмечают :) А вот когда что-то плохо - да, во всех отчетах напишут. А на этой, как и на других конференциях Влада Орликова уровень организации - очень высок. В фойе предусмотрены места для общения. В течении всего времени конференции, а не только в перерывах, есть чай кофе и плюшки, в этот раз добавился еще фруктовый лимонад. И это создает возможности, стимулирует общение участников с докладчиками и между собой. Создает особую атмосферу сообщества. Что замечательно.
А еще надо отметить, что многие докладчики на конференции звали на ЛАФ, Летний Аналитический Фестиваль, который несколько лет проходил в Иваново, а в этом году будет проходить в Этномире. И который, по опыту прошлых лет, собирает теплую компанию аналитиков с хорошими докладами и живым общением.
2013-04-29: SQAdays-13 (весна 2013)
Конференция SQAdays-13 в Питере в очередной раз дала новые мысли и заряд общения. На самом деле, я регулярно колеблюсь - ехать ли на конференцию или нет, потому что тестирование - это непрофильная для меня область, а время - единственный ресурс, который утекает безвозвратно. Но вспоминая мысли и идеи, полученные на прошлых конференциях, а так же большой заряд общения, которое давали прошлые конференции, решаю поехать.
С каждым разом на конференции все больше народа. Эта конференция проходила в Park Inn Прибалтийская и собрала больше 600 человек. Реально гигантские залы, и полные. С задних мест докладчик - где-то вдали, на горизонте, особенно в большом зале - поэтому стоят плазмы, идет трансляция и экрана и докладчика. Думаю, следующая конференция будет еще более многолюдная. Она состоится во Львове, будет 3 дня вместо обычных двух и там будет день западных спикеров.
Интересным на этой конференции была секция блицев с переполненным залом, правда самым маленьким. Вообще, это парадокс: в блицы выжимают не очень сильные доклады, а народ на них охотно идет, потому что жесткий таймбоксинг концентрирует изложение и повышает качество доклада. И даже если будет не очень удачным, то недолго :) Это, кстати, подтверждает опыт AgileDays, где под блицы был отдан главный зал. Некоторые опытные докладчики это уже поняли, и сами подают блицы. Кстати, после блицев получается своеобразное отравление, даже очень хороший по уровню доклад, но со спокойным изложением материала воспринимается не слишком хорошо, не хватает динамики.
Дальше я расскажу о том, что я вынес с конференции, какие тренды и практики увидел. Потом - немного о докладах вообще, и об образовании тестировщиков. И там - некоторая классификация докладов. А потом будет обзор докладов. Он не сгруппирован по приведенной классификации, хотя в начале доклада я ее часто указываю. Потому что конкретный доклад ищешь все-таки от проблем, а не от его уровня.
Естественно, я был не на всех докладах, и выбирал из своих профессиональных интересов. Но на многие я забегал, и их - тоже отмечаю в обзоре, особенно хорошего уровня - может, это побудит кого-то посмотреть этот доклад, хотя понимаю, что по краткому пребыванию вполне мог ошибиться с классификацией. И отмечу, что я сознательно не ходил на доклады Microsoft, потому что знаю этот материал из других конференций. Так что отзывы об этих докладах ищите у других, а я скажу, что в целом Microsoft старается не просто представить свои инструменты, а рассказать об их комплексном использовании, показывая прохождение процессов - в функциональном описании продуктов этого момента обычно нет.
2013-04-20: Питер Друкер - Энциклопедия менеджмента
Питер Друкер "Энциклопедия менеджмента". Как написано в предисловии автора, творчески собрана из его книг за 60 лет с участием его самого и представляет введение в теорию управления. Получилось емкое и концентрированное изложения, касающегося менеджеров и вообще работников умственного труда (оказывается, это - его термин, 1969). Но еще - получился обзор развития общества, начиная с середины 19 века (а местами и раньше), и до конца 20 века (книга издана в 2001, работы 1999 учтены). При этом материалы рассыпаны по тексту, что дает взгляд с разных сторон. А еще - свидетельствует о цельной картине у автора, который легко начинает с верхнего уровня и погружается в детали под уместным в конкретном месте углом зрения. И это - превосходно, потому что подобные картины - большая редкость.
И в этой картине - много о вызовах современного постиндустриального общества - общества, основанного на знаниях. Питер начал об этом писать в 60-х, в том числе - говоря о вызовах, стоящих перед людьми, живущими в этом обществе и о его противоречиях, требующих решения в развитии. И многое из того, что происходит сейчас - проявления этого развития, решение стоящих противоречий. Включая то, что происходит в мире с образованием, например. А также - с кризисом общества социальных пособий, распределяемых бюрократами - что мы видим в Европе. И, в общем, в свете этого как-то странно слышать стоны о неожиданности происходящего. Впрочем, на проблемы и противоречия, изложенные спокойным языком в конструктивном залоге обычно не обращают особого внимания, это вам не вопли о всеобщем крахе... Да, конкретно про Россию там не слишком много, но мир - он един, и это уже дело читателя - примерить изложенное к России.
А еще читатель может примерить изложенное к своей профессиональной деятельности и своей отрасли. Я тут понял, что Agile появился в IT вполне закономерно - как в ответ на неспособность менеджеров в своей массе отвечать тем новым вызовам современного общества знаний, о которых пишет Друкер. И естественным образом это проявилось наиболее сильно в той отрасли, которая развивалась интенсивнее всего, и где потому сильнее была потребность в новых менеджерах. Менеджеры же продолжали мыслить по-старому, пытаясь свести деятельность к процедурам. И потому возникли предпосылки к революции, "верхи не могут, низы не хотят" - и она произошла. Но она не просто произошла, она породила SCRUM - инструмент, во-многом отвечающий тем потребностям менеджера в освобождении себя от текучки, о которых говорит Питер. Правда, целью этого освобождения для многих из IT-менеджеров были вовсе не менеджерские активности, а проектирование и разработка софта, которой они предпочитали заниматься. А для тех, кто предпочитал именно менеджмент этот инструмент дал способ масштабирования своей деятельности - такой менеджер может управлять несколькими agile-командами, не имея внизу полноценных менеджеров с полным набором обязанностей и компетенций. Кстати, об этой проблеме, как о типичной и требующей решения - Питер тоже пишет. А дальше agile постепенно впитал в себя многие позитивные менеджерские практики - что и должно было случиться, в соответствии с естественной логикой диалектического развития, смотри закон отрицания отрицания.
Кстати, последний тренд, gamification - он тоже реакция на изменение ситуации, о котором говорит Друкер - когда не люди конкурируют за рабочие места, а организация выбирает, а наоборот, когда люди выбирают организацию, исходя из своей самореализации. И геймификация - конкурентное оружие организаций и менеджеров за кадры. Это общий тренд интеллектуальных отраслей, не только IT. Конечно, многием менеджеры понимают ее упрощенно, как еще один способ интенсификации труда и всяких KPI в новой форме. Но такое применение - точно проигрышно.
Есть и еще одна задача читателя, вернее, возможность - применить прочитанное к себе, к своему собственному развитию. Тут надо сказать, что многие известные практики, например GTD Аллена, являются как раз методами решения тех самых проблем, о которых Питер пишет как о стоящих перед работниками умственного труда. Но у Друкера проблемное поле - целостно, а не фрагментарно, что дает возможность лучше осозновать стоящие задачи и вызовы. И я думаю, это мне позволит лучше управлять собственным развитием.
Да, про agile - это, естественно, в мировых масштабах, а не про нашу компанию, и даже не про Россию - в России как раз было не так, поскольку в отрасль в 90-х во многом приходили из советской науки, а там нормально управляли интеллектуальными проектами.
2013-04-14: Конференция SoftwarePeople-2013
В целом конференция - удалась. За два дня было довольно много хороших докладов. Сергей Мартыненко в первый день трижды порвал шаблон, говоря об оценках проектов. Дима Безуглый рассказывал об эмоциональном интеллекте и управлении им как необходимых скилах руководителя, и о различных стилях управления. Максим Дорофеев устроил шоу аттестации с мат.моделью программиста на основе детского носка с цветными шариками, и практически показал влияние вариаций и использование карт Шухарта для работы с ними. Были и другие доклады хорошего уровня.
Еще были доклады практиков о своем реальном опыте. Да, многие грабли, которые они преодолевали - известны. Но, в конце концов, это очень программистский подход - пробовать самим, а мануал читать только в крайнем случае. Они так часто подходят не только к всяким программам, но и процесса и людям. Может, именно тут играет роль отличие практического знания от теории верхнего уровня, и вполне возможно, что именно через такие доклады можно, узнав в них свои проблемы, соотнести теорию со своей практикой.
Иностранные докладчики в этом году, увы, не порадовали. Они все в прекрасном и великом прошлом, которое знают энциклопедично. А настоящее - больше на уровне трендов и мемов. Ну, будем надеяться, что в будущем будет лучше - ведь был же в прошлом году Джефф Де Люка, а в позапрошлом - Нил Мейден и другие.
Сам я выступал на конференции, рассказывал об опыте применения Domain Driven Design. Прямое отражение модели в код на основе шаблонов Domain Model и Rich Objects, о котором говорят авторы подхода, вызывает в больших многолетних проектах определенные проблемы, и для их решения мы разрабатываем в проектах набор более сложных правил отражения, который назвали Технологическими рельсами. Доклад вызвал интерес, были вопросы. И еще из нашей компании выступал Коля Гребнев, рассказывал о создании самоорганизующихся процессов в командах. Его доклад тоже слушали с интересом.
А теперь о докладах подробнее. Надо учитывать, что я был далеко не на всех докладах. Я пропустил Кириленко потому что мой доклад стоял параллельно. Не был на Орлопанках, слушая параллельный трек - там были наши ребята и, я думаю, они донесут ценное, что там было. Еще был большой трек Microsoft ALM, о котором я знаю из других источников и трек мобильной разработки, которая (пока?) вне сферы моих профессиональных интересов, туда я зашел только на Дмитрия Мартынова из Google чтобы почувствовать тренды. А еще во второй день мне пришлось уехать в 15 часов, увы.
2013-04-10: Мастер-классы Эдварда Йордана
Перед конференцией SoftwarePeople прошли два мастер-класса Эдварда Йордана CIO’s at Work и IT Project Estimating. Я был на обоих. Первый из них был довольно дорогой - организаторы хотели камерности, и им эту удалось, я бы сказал даже более чем. Свою роль сыграла не слишком понятная программа мастер-класса: сама книга есть только на английском, а анонсе обещано обобщение опыта CIO различных крупных компаний. На втором же было более 50 человек.
На первый я пошел, надеясь получить видение уровня отрасли на мировом уровне. В этом был определенный риск, который, к сожалению, реализовался. Наиболее точной будет следующая аналогия. Если вы идете в лес смотреть животных в естественной среде, то сопровождающий может оказаться биологом, и тогда вы не только увидите внешние проявления, но и многое узнаете о внутреннем устройстве и его причинах. А в менее удачном случае вы увидите преимущественно внешние проявления, а внутреннее устройство будет на уровне общих рассуждений и примеров. Только вот редко хорошие биологи еще и водят группы по лесу. Так и в этом мастер-классе реализовался больше второй вариант, чем первый. Но показ внешних проявлений был на уровне. И, хотя я сам не новичок в этом лесу и многое знаю, представление в целом было полезным.
Мастер-класс был на хорошем английском, даже записывая, я продолжаю воспринимать то, что он говорит, а это - ценно. В электронных материалах - много линков. Сами материалы - это оглавление рассказа, каждый пункт был раскрыт и иллюстрирован историями, которые хорошо рассказаны. Йордан знает опыт в отрасли - середины 60-х. Технологии - меняются, а люди - не очень. Книга CIO’s at Work, на основе которой построен мастер-класс - реальные интервью, 16 штук. Я ее полистал, и по-моему не слишком интересно. А в мастер-классе - обобщение этого опыта. А я дальше немного расскажу об интересных для меня моментах, дополнив своим видением. Естественно, передать полностью не получится, даже опубликовав презентацию - потому что оглавление не передает содержание текста, и по нему вы можете лишь оценить - знаете ли вы об этих вопросах вообще, а никак не соотнести свое знание с позицией автора.
Что любопытно - далеко не во всех компаниях получается найти и идентифицировать CIO, несмотря на важность информационных технологий. А еще они часто довольно закрыты для внешних контактов в описании своей работы. В целом CIO компаний - относительно традиционные и консервативные менеджеры, не взирая на все громкие крики о быстрой динамике отрасли и высоких требований, предъявляемых к освоению нового. Не все осваивают - и работают.
С освоением технологий явно лучше, чем с освоением менеджерских аспектов. И те тренды ориентации на людей как ключевого фактора для успеха проектов, и которые, говорят, зародились в далеких 60-х в космической отрасли штатов, были, казалось бы, освоены IT-отраслью в изложении Peopleware Тома ДеМарко, а в последнее время воплотились в Agile-Lean процессы - остаются лишь баззвордом.
Был представлен список приоритетов CIO. Из него видно, что преимущественно они заняты текучкой, операционной работой. А стратегия - увы, даже не в верхней половине списка. Еще интересно сравнить списки приоритетов 2010 и 2011 года. Список 2010 года содержит вполне понятные цели и задачи - по поддержке основного бизнеса со стороны IT, по эффективности самой IT-работы. И довольно мало мемов, которые "должны волновать всех" (Cloud, broadband и connectivity), и это - не есть хорошо для жрецов соответствующих мемов. В списке 2011 содержательные пункты сгруппированы в 1-2 группы со своими баззвордами, и за счет этого освобождено место для мемов. В 2012 число мемов еще увеличивается - portal, mobile... Все это хорошо согласуется с еще одним трендом современного общества - переходом от содержательных понятий к мемам.
Поговорили также о мемах и баззвордах, не вошедших в список приоритетов, некоторые из которых обозвали tools, например, virtualization или social media :) К сожалению, форма представления в виде списков так же несет отпечаток консервативности. Здесь более уместны семантические сети или другие визуальные формы, потому что приоритеты и другие понятия перекрываются и связаны. Увы, этого не было.
Дальше были темы, вокруг которых CIO согласны, и темы, традиционно вызывающие холивары, такие как peopleware, наука против творчества или роль MBA и финансов. Да и согласие тоже относительно - все согласны, что социальные сети влияют сильно, но вот как. А еще - темы, по которым традиционно громкие слова не подтверждаются делами, как в контактах с подчиненными, отказ от жесткого иерархического контроля.
Дальше перешли к трендам развития в мире. Они известны, но тут получился обзор в комплексе, относительно интересный. В целом получается устойчивый тренд на совмещение рабочего и личного (семейного) пространства - через личные девайсы, совмещение календарей и систем индивидуального планирования, смешение в соцсетях рабочих и личных контактов с достаточно публичным общением. И в результате есть тренд к смене характера взаимодействия - взаимодействие фирм через взаимодействие людей. Впрочем, по-моему, если рассматривать в исторической перспективе, то в свое время личное взаимодействие и было основой взаимодействия фирм, а в Китае, например, оно до сих пор считается нормой, и некоторые западные исследователи рассматривают это как "незрелость" общества. А тут взаимодействие людей возвращается, на новом уровне, в полном соответствии с диалектикой развития :)
И в конце были достаточно интересные слайды про поколение F, от facebook, которое осваивает соцсети еще в школе. Штука в том, что достаточно много стереотипов поведения, приобретаемых при активном общении в соцсетях, противоречат стереотипам поведения, принятым в большинстве компаний. И есть опасение, что компании могут ждать большие потрясения, как только туда придет достаточно много сотрудников нового поколения. Потому что один из демонстрируемых стереотипов - легкая самоорганизация в группы, со своим лидерством, которое определяется поведением, а не назначается, с высокой мобильностью по этим группам. А еще один - активная публичность, открытость информации, использование ее чтобы приобрести последователей. При этом люди достаточно адаптированы, и умеют существовать там, где их меньшинство. А потом, вдруг - самоорганизуются и берут управление. На слайде выписано достаточно много факторов по этой статье, это любопытно.
Так что в целом получился довольно интересный, хоть и поверхностный обзор современного состояния и трендов. Второй же мастер-класс, посвященный оценке IT-проектов, обернулся большим разочарованием. Потому что 3/4 времени в нем говорили о проблемах и сложностях оценки, они были рассмотрены исчерпывающе и иллюстрированны примерами. Только вот эти проблемы - старые, известны много лет. А вот на позитивную часть осталась 1/4 времени, и потому докладчик начал просто читать оглавление на слайдах. Я думаю, это был сознательный шаг. Потому что решения у старой IT-школы - нет. Проблемность подходов, названных на слайдах второй части - хорошо рассказана в первой. И если сказать тоже самое в залоге "следует обратить внимание, учесть и избежать..." - то ведь решения не появится.
Надо сказать, что в отрасли ответ на задачи оценки проектов - появился, в рамках agile-практик. И там не два подхода к оценке (в попугаях и в размерах), а больше, различающиеся еще тем кто, когда и для какой цели оценку проводит. А в определенных процессах оценка признана ненужной, а предсказания делаются другим способом. Да, с этим тоже есть проблемы, но это - другие, новые проблемы, конечно, многие из них похожи на старые, но вот контекст - уже сильно другой. Все это старой школой не освоено, хотя слова - да, они их знают. И даже вписали их в PMBOK и SWEBOK как смогли, весьма эклектично. Собственно, в этой форме подходы к оценке во многом и были представлены на слайдах.
Может, оно и нескромно, но Эдвард показал мне то будущее опытного IT-шника, живущего представлениями прошлого и снисходительно смотрящего на современные подходы без глубокого погружения в них, которого я для себя - точно не хочу. Думаю, он вполне достойный эксперт, который помогает избежать конкретных ошибок в больших проектах, основываясь на своем опыте. Но вот понимания современных практик ведения IT-проектов у него, увы, нет. А значит организовывать их или обучать новое поколение - не получается. Жаль.
2013-04-07: Agile и классический менеджмент
В одной семье была стряпуха, которая готовила совершено замечательные блюда. По нынешним временам оно редкость и потому повадились к ним гости часто ходить, а хозяев это устраивало. только вот стряпуха не успевать стала - она обычно праздничную еду за день-два начинала готовить, чтобы спокойно все сделать, и обычной едой тоже кормить. а такой возможности не стало. Сначала хозяева попробовали ей помочь современными инструментами - кухонный комбайн, мультиварка и прочее. Но не прижилось: кухонный комбайн, конечно, режет быстро, но не так, как надо, и вообще - опасно это с ножами всякими. А мультиваркой вообще непонятно как пользоваться - туда же надо загрузить все продукты, а потом, когда готовиться - даже пробовать нельзя, а то вся жидкость паром выходит и подгорает оно.
Тогда решили хозяева нанять помощницу. Правда, с выбором тоже сложности возникли. Молодые - они как раз любили современные средства использовать, а не по-старинке готовить. Те же, кто соглашались всему учиться - ничего не умели и будет ли от них помощь - было непонятно. Еще были те, кто умел готовить традиционным образом, но они хотели много денег, а быть помощником - их не устраивало, хоть и не умели они готовить так вкусно. В результате наняли молодую и бойкую, велели смотреть и помогать новыми инструментами, ну и самой учиться, чтобы хотя бы простые блюда так же вкусно готовить.
Ну и началась у них совместная работа со всякими подколками. Стряпуха говорила, что вкус не получается потому что нарезано неправильно, сок не дает или наоборот, в кусочки в пюре превращаются. Или потому что кто ж кладет сразу все специи, как в мультиварке приходится, да не пробует пока готовит. А молодая - что копается стяпуха больно долго, вручную нарезая, а в комбайне все быстро, и сразу можно салат смешивать, хоть и не каждый. А в мультиварку загрузил продукты, поставил программу - и другим занимайся, а не помешивай да пробуй каждую минуту.
Быстрая нарезка в комбайне впечатление производила, так что начал стряпуха его использовать. Хотя и ворчала, что мало там ножей и терок, не получается как надо. Так и сказала представителю фирмы, который делал опрос потребителей. Тот заинтересовался, спросил, какие ножи добавить и та начала длинный список перечислять. Но когда тот поинтересовался, что не страшно ли, что тогда потребуется много места для хранения, сказала, что нет, так быть не должно, она уже со всеми инструментами много места занимает. Так и разошлись недовольные.
А молодая - присматривалась к стряпухе, чтобы ее рецепты перенять. Только вот готовить по ним, да при этом использовать новые инструменты, получалось плохо: тесто в комбайне не такое пышное выходило, некоторые салаты норовили в пюре превратиться. А с готовкой вообще сложно получалось: стряпуха добавляла ингридиенты последовательно, да еще помешивала и пробовала часто, а с мультиваркой так нельзя. Так что требовалось не просто сделать так же, а пробовать и адаптировать, понять. что можно положить вместе, а что - добавить потом и когда, все-таки один-два раза мультиварку открыть можно, только ненадолго и воды потом добавить - а то выходит она с паром. Постепенно успехи были - и с тестом, и с некоторыми блюдами.
Так и работали вместе. Во всяком случае, хозяева были довольны.
А при чем тут agile и менеджмент спросите Вы? А при том, что скрам и канбан - это современные инструменты управления IT-проектами. Которые сильно не похожи на ранее применявшиеся. И потому менеджеры, воспитанные в классической традиции, не спешат их осваивать, да и не так просто это. А в умелых руках - они эффективны, хотя, естественно, имеют свои ограничения и не обеспечивают весь спектр деятельности менеджера - как и любой инструмент. Но, что интересно, они настроены на те же ценности, что и классический менеджмент.
А рассказ - он не закончен. И хотя он из тех историй, в которых финал означает начало новой, в нынешнем текущем виде он совсем не завершен. Но я могу представить много финалов: с зародившимся сотрудничеством и без него, счастливых для обоих, или только для одной, или для обоих несчастных. А какой финал представили бы Вы? Напишите в комментариях. Или альтернативную историю, если это начало не вдохновляет, но метафора кажется удачной.
2013-03-30: AgileDays 2013 - между скрамом и будущим
Конференция AgileDays. Как всегда - на хорошем уровне, много общения и интерактива, живых докладов. Чувствуешь тренды отрасли, открываешь для себя полезные практики. Основных трендов два: разочарование в SCRUM-Канбан и gamification, о них далее. Мне они не так, чтоб нравились, но глупо обижаться на пейзаж за окном, и тем более на само окно, которое его показывает.
А сначала - пара слов о том, зачем я хожу на конференции. Живое общение позволяет реально увидеть и оценить тренды, соотнести между собой. А рассказы об использовании практик в реальных ситуациях, которые накладываются на твою, показывают неожиданные грани практик, о которых мог знать раньше, не предавая особого значения этому теоретическому знанию. А еще выключение из рабочего процесса и целенаправленное восприятие информации иногда производит инсайт, осознание или даже создание новых идей, которые ты решаешь претворять в практику почти немедленно.
Да, сама конференция - многолюдная. 667 участников, 54 доклада. Реально переполненные залы. Были косяки, но ко второму дню организаторы учли уроки, и, главное, организовали трансляцию из второго зала в холл, что позволило желающим слушать доклад хотя бы из-за двери. Как они шутили "fast fail у нас был - значит дальше будет хорошо".
И лично мне очень понравились блиц-доклады, по 15 минут в главном зале. Потому что когда время так сокращается, от доклада остается суть. И даже если она не очень актуальна, времени не так жалко. Так что я бы приветствовал этот формат и дальше.
А теперь - о трендах и обзор докладов, на которых я был.
2013-03-28: Как появляется PBL - Jeff Patton на AgileDays
Вчера и сегодня был на тренинге Джефа Паттона. Он рассказывал о том, откуда и каким образом получается самый важный артефакт SCRUM - Product Backlog, который является источником для всего остального. В описаниях процесса SCRUM об этом говорят реально мало, хотя практики известны. Джеф представил цельную конструкцию подходов к формированию продукта и его релизов, с фокусами ответственности и особым упором ценность продукта и user experience.
Хотя практические занятия были ориентированны именно на создание нового продукта, процесс и практики могут использоваться и при развитии продукта. Они сработают не только в продуктовой, но и в заказной и inhouse разработке - это я уже утверждаю из своего опыта. А еще - ряд из них, такие как сегментация и персонификация пользователей - может быть использована и при проектировании процессов разработки в компании.
А еще тренинг включал в себя обучение эффективным формам коллективной работы - collaboration. И, как сказал Джеф, "Collaboration - это не разговоры и обсуждения. Это - совместная работа, и желательно - молча."
Так что, хотя называется тренинг "Создание продуктов, которые полюбят ваши клиенты: Сертифицированный курс Product Owner", реально это - авторский тренинг, прочитанный звездой, как и тренинг Книберга два года назад. И я хочу сказать организаторам конференции спасибо за такие тренинги.
А я дальше не поленюсь и кратко раскрою содержание тренинга. К сожалению, кусок второго дня я пропустил, так что есть лакуны. Да. часть про SCRUM как сбалансированный процесс и agile как систему ценностей я опущу, потому что полагаю ее знакомой. Она не заняла много времени, но задала контекст для дальнейшего.
Замечу также, что изложение шло не с начала процесса и до конца, а от простого - к сложному. А наиболее сложной является формирование механизмов концептуальной части продукта - и именно они были ближе к концу тренинга, хотя при конструировании находятся ближе к началу процесса.
2013-03-21: Клуб директоров по разработке
Сегодня, 21.03, прошла очередная встреча Клуба директоров по разработке, посвященная эффективности внедрения ALM. На встрече получилось заглянуть в ведение проектов крупными компаниями разработчиками - KasperskyLab, который сейчас активно внедряет TFS, ABBYY, которая использует ALM на основе систем собственной разработки на пока на TFS переходить не собирается, и других разработческих компаниях. С другой стороны, был обмен мнениями и опытом по проблемам ALM в inhouse-разработке - в банках Райффайзен и ВТБ24, в ВымпелКоме, и других. И именно этим было интересно мероприятие. Понятно, что определенная маркетинговая составляющая, касающаяся TFS тоже имеется, поскольку встречи организует Microsoft. Однако прежде всего это площадка для общения и обмена практическим опытом. К тому же то, что Kaspersky выбрал именно TFS - тоже показатель уровня решения.
2013-03-16: Enterprise Developers Conference
В пятницу был на Enterprise Developers Conference, которую проводил CareerLab. Конференция была весьма нетипичная, участники преимущественно представляли inhouse разработку. Впечатления от конференции очень позитивные, на ней было несколько неожиданных докладов. Местами получилось заглянуть во внутреннюю кухню корпоративной разработки, которую не так часто представляют на конференциях, а еще - посмотреть на развитие тренда ALM-средств, которые предоставляет Microsoft не в виде презентаций самих средств (хотя это тоже было), а на опыте их внедрения в крупных разработческих компаниях.
Теперь подробности. Не полные - я был только на одном треке конференции, а их было два. Второй касался мобильной разработки, которая сейчас занимает важное место в отрасли, но все-таки находится вне сферы моих интересов. Пока?
2013-02-22: MODELSWARD - подвожу итоги
Конференция http://www.modelsward.org/ - International Conference on Model-Driven Engineering and Software Development - закончилась. Впечатления первого дня - здесь. Но второй день - изменил впечатления первого дня о преимущественно недоработанных прототипах или рассуждениях общего уровня от специалистов. Это просто первый день оказался так скомпонован. А во втором - пошли вполне себе нормальные доклады про модели, кодогенерацию по ним конечных приложений, а также верификацию и тестирование моделей, которые в этом случае реально нужны. И это продолжилось на третий день.
Кроме того, в конце второго дня была poster session. Она реально отличалась от стендовых докладов у нас на конференциях, аналогов я не видел и опыт можно использовать. Суть в том, что у автора есть плакат с достаточно подробным изложением идеи, а дальше - ты с ним можешь общаться, задавать вопросы. Этот формат хорошо подходит для представления новых идей и продуктов, которые в докладе объяснять не очень хорошо, потому что нужен интерактив и рефлексия по восприятию. А в таком формате - самое оно. Еще это хорошо подходит для представления идей, заложенных в большие фреймворки и inhouse разработку. В докладе этого не сделать - надо передавать много контекста, либо поднимать уровень абстракции так что получается рекламный доклад. А в этом формате основные идеи - пишешь на плакате, их видят. А в интерактиве собеседник расспрашивает о тех аспектах, которые именно его интересуют. Что интересно, на этой сессии были так же докладчики, которые делали доклад на основных сессиях - то же плакат с кратким изложением презентации, и дальше - общение. И это позволяет более подробно пообщаться с ними. У нас это во многом заменяет общение с докладчиком после его доклада, но, во-первых, ты теряешь следующий доклад, а, во-вторых, вопросы часто должны созреть. И за 1 час такой сессии пообщаться с 5-6 докладчиками - вполне успеваешь. В общем, надо брать на вооружение.
Общение на конференции - достаточно активное. Плюс, в среду был ужин, на котором тоже можно было пообщаться.
Из конференции я вынес для себя, что генерация по моделям сейчас является эффективным инструментом и ее надо осваивать. Собственно, отдельные фрагменты у нас используются, но как разовые вещи. Что характеризует ситуацию? Моделеров и генераторов реально множество. Видел сравнение из 20-30 наименований. При этом утверждается, что они работают над моделью с совместимым XMI-описанием, то есть можно использовать совместно: для бизнес-логики один, для интерфейса - другой, а диаграмму классов (например) можно свободно переносить. Наверняка есть open source разработки, от университетов - точно, их представляли. Они ограниченные по функционалу и могут быть сырые, зато в текстах, можно развивать и вносить вклад. Главное - не тотальная генерация конечного приложения, а только его однородной части. Да, казалось бы, с ней особых проблем нет - берешь и формально реализуешь. Но дальше каждое изменение - согласованные правки в 5+ местах - а это уже дорого, играет человеческий фактор. В общем, буду сюда активно смотреть.
Модели применяются достаточно широко. Конечно, это автомобильное, самолетное и прочее подобное обеспечение, которое работает на железе в жестких режимах, и где важна надежность и стабильность. Там модели были всегда. Для меня было определенной неожиданностью, что модели с кодогенерацией конечного приложения достаточно широко применяются в enterprise-разработке. Это inhouse, примером чего служит Tata. Но не только. Был доклад об испанском проекте, который первоначально делался при гос.поддержке, но сейчас решения на его основе применяются для реальных коммерческих фирм и банков. Был доклад об аналогичном мексиканском проекте. Это - что запомнилось и о чем я выяснял подробности. И это - не единичные вещи. Модель сейчас, как правило, имеет графическое представление. Но это не обязательно, бывают чисто метаданные, по которым идет генерация или интерпретация - как у нас в технологии ядра. Кстати, общаясь с заказчиками и разработчиками я это встречал и в России - и в inhouse, и в продуктовой разработке. При этом применение есть как для приложения в целом, так и для фрагментов, например, для интерфейса.
Если же говорить о конференции в целом, то да, это - научная тусовка. Там представляются идеи и прототипы, а коллеги - доброжелательно спрашивают. Прототипы - разного уровня есть и вполне работающие конструкции. А еще там предтавляют "методологическую" выжимку высокого уровня от inhouse, при этом в общения с докладчиками можно узнать много подробностей. Но надо понимать, что в Европе наука достаточно активно занимается заказами на индустрию, чего в России сейчас по-моему нет. Ну и совмещение преподавания с коммерческой разработкой тоже имеется.
Научное сообщество накладывает определенную рамку на доклад - упор делается на используемые методологии, обязательно сравнение с аналогами, прототип, очень желательны метрики. При этом многие части реально неуместны, но - положено, вот и делают с разным уровнем изобретательности. Это - та форма, которая вредит содержанию, особенно в докладах, где представляются идеи будущих диссертаций - а они составляют существенную часть. Не-докладываемые у нас варианты тут нормально докладываются. Можно представить незавершенную работу, или просто диаграмму классов кусочка своего проекта, например, описания cloud infrastracture - естественно, если правильно обернуты. Так что при желании - на этих конференциях вполне можно делать доклады, вопрос - нужно ли? Профессионалы формой не очень озабочены, но они часто слишком поднимают уровень абстракции, игнорируя необходимость примеров.
Несмотря на эти недостатки, я получил с конференции достаточно много полезного. Это и общее представление о моделях, и некоторые мысли о соотнесении классического моделирования с кодогенерацией и DDD. Но ими я поделюсь отдельно. На этом - все.
А еще - научный подход характеризует уважение к стандартам, общепринятым практикам и нежелание изобретать велосипеды. Поэтому столкнувшись, например, со сложностью UML, научное сообщество предпочитает выделить разумное подмножество, а не сделать альтернативу с нуля. Конечно, дальше бывает по-разному, но предпочтение по умолчанию, на мой взгляд - правильное.
На этом все. Обзора доклада не будет - все равно подробных публикаций материалов нет. В заключении поделюсь цитатой от Oscar Pastor (University Valencia, keynote): CASE tool should help designer to solve problem instead of adding new problem - how to use it properly! Очень характерно.
Я еще 3 дня в Барселоне, буду гулять по городу. Впечатления и фотки, кому интересно - в личном блоге.
2013-02-19: MODELSWARD - первые впечатления
Конференция http://www.modelsward.org/ - International Conference on Model-Driven Engineering and Software Development. О моделях, поэтому и поехал посмотреть.
Посмотрел. Это совсем другой формат конференций. Несколько довольно узких тематических конференций идут параллельно, каждая из них - 40-60 участников, почти все - докладываются, при этом время 20 или 30 минут. А на параллельной конференции можно быть слушателем. При этом оргвзнос платят все.
Основной состав - из университетов. И это сильно отличается от российских конференций, не в лучшую сторону. Консерватизм и академичность подходов, предпочтение теории перед практикой. При этом большой научной теории - тоже нет. В целом я это видел в научных докладах и заявках на SECR, поэтому новостью для меня оно не стало. Но и энтузиазма это не добавляет.
В целом, сегодняшние доклады можно разделить на две категории. Первые - это от профессионалов в которых уровень абстракции поднят настолько высоко, что остались общие тренды и рассуждения - которые мне и так известны. Надо сказать, что профессионалы часто работают в крупном inhouse - GM, Tata, NEC и другие - поэтому подробности им передать действительно трудно. А второе - это доклады о достаточно частных проблемах, решенных на модельных примерах, которые, тем не менее, позиционируются как какие-то достижения. Как пример - сегодня было несколько докладов о сравнении моделей. Понятно, что если вы работаете с моделью коллективно и храните их в системе контроля версий, то практически тема важная, а хороших средств - нет. Но ничего сильно нового тут нет. Есть такой Erwin, который очень давно сравнивал модель в нем со структурой БД. Сейчас это многие средства умеют. Так что для доклада - это не тема, по-моему.
На этом на сегодня все.
2012-12-20: Проектирование программ: мастера и самоучки
Пост http://a-str.livejournal.com/524554.html говорит об обучении творчеству, и автор имеет ввиду писателей, художников и другие аналогичные профессии. Но все это очень применимо к проектированию программ. Редко кому из нас удается встретить учителя, и поэтому мы - преимущественно самоучки. И проблема легкой выбраковки - реальна. В проект вкладываешь много своего умения, он - дорог, и критика слушается очень тяжело...
2012-12-02: SQAdays-12, день второй
Второй день SQAdays-12 в Минске - достойное продолжение первого. Темы докладов - развивались и продолжались. Включая тему архитектуры конструкции для автоматических тестов. Интересно, что на предыдущих двух конференциях эта тема не звучала, а на этой - сразу серия докладов, и представляемые конструкции - похожи. По-видимому, развитие автоматических тестов созрело для формулирования типовой архитектуры.
Кроме докладов был круглый стол о будущем профессии тестировщика. В формате выступление эксперта - выступление из зала. В общем, в том, что у профессии - большое будущее, и человека машина тут не заменит - никто не сомневался. Хотя тема замены человека роботами, которую ждали фантасты и которая не случилась - звучала активно. А еще обсуждали развитие разработки в сторону интерактивных приложений, работающих с голосом и жестами - которые тоже надо тестировать. И тема образования, обучения тестировщиков, в том чисое - в контексте работы с ВУЗами. Хочется отметить, что параллельно с обсуждением в зале шло активное обсуждение в твиттере на те же темы. Потому что в зале - микрофон у одного человека. А кинуть реплики - хочется. Компьютеры и планшеты - у многих, и некоторые эксперты тоже успевали следить и, кажется, вклиниваться в твиттер. В целом получается достаточно интересная конструкция, потому что твиттер как раз снимает ограничения на число одновременных реплик. Плюс возможность ответа, которую твиттер отслеживает - позволяет вести параллельные нитки обсуждений, что тоже интересно и полезно.
Правда, требует упаковывать свои мысли в 140 символов и для меня лично - это часто сложно. Даже отдельная мысль укладываетя не всегда, надо 200-250 символов, чтобы отметить нюансы и акценты. Но вообще для меня это - интересный опыт. На SPMconf я поймал мысль, что реплики по поводу выступления хочется бросить в твиттер. Или процитировать (но это-то как раз многие делают). Но - не успеваешь, вернее, это отвлекает внимание от восприятия доклада, а это - жалко. Особенно, когда мысль не влезает на десяток символов - их-то точно можно ужать. Но, думаю, это - тренируемый и полезный навык, так что буду практиковаться. Во всяком случае. на круглом столе у меня получалось :)
А еще - хочется отметить организаторов. Геометрия места проведения была не слишком удачная, только один большой зал. Но на второй день (после второго слота) организаторы поставили у зала Б не только монитор с камеры (он был сразу), но и монитор с презентацией, и доклад можно было слушать из коридора, получилось расширение зала. Еще не помешала бы такая же конструкция (монитор с презентацией) в залах С и D, но я понимаю, что ресурсы не безграничны.
А теперь - обзор докладов второго дня, начиная с тех, которые больше понравились.
Игорь Любин, News360. Тестирование по жесткой схеме! Или 27 + 2 фишки в построении процесса тестирования!
Великолепный доклад о проактивной позиция тестировщика.
Дальше - фактически содержимое слайдов. Я его переписал, потому что хочу иметь под рукой, а не лазить в презентацию.
- Тестирование начинается с прихода в компанию. Вопросы на интервью.
- Определить цели
- Задать как можно вопросов о проекте
- Узнать какие проблемы надо решить.
- Горячие точки. Поговорить с ключевыми участниками, составить список горячих точек
- Фишки. Пообщаться с командой, собирать идеи.
- SMART-анализ целей (горячие точки, фишки). Выписать цели, выбрать цели на месяц.
- Добиться прозрачности. TOP-5 задач на неделю. Таблица Задача, исполнитель, срок, комментарий.
- День золотого духа. Влиться в проект. Стать junior-тестировщиком на 1 день.
- feedback. Взять обработку отзывов от пользователей в свои руки.
- Разделение обязанностей. Мотивация: выявить склонности тестировщиков и предложить им задачи по специализации.
- Функциональные карты. Сделать тест-анализ по модели Объект-Действие-Параметр-Значение. Выявить основной функционал. Оценить покрытие.
- Особенности платформы. Усилить покрытие.
- Чит-листы (не чек-листы). Готовые проверки, их масса в сети - и не надо придумывать самим.
- sitechko.ru. Там много готовых листов. Руководитель Наталья Руколь.
- Понятие критического бага. Составить критерии, согласовать.
- Критерии выпуска версии. Процесс тестирования на выпуске. Когда надо выпускать. Набор чеклистов.
- Build Verification Tests. Составить, прогонять регулярно.
- Волны тестирования. Соорганизоваться, продумать итерации тестирования.
- Стратегия тестирования. Сделать документ на 1 (одну) страницу. Поддерживать его.
- Шаблон баг-репорта. Сделать. Научить всех пользоваться.
- Анти "Протестируйте". Организовать процесс передачи версии в тестирование. Антипаттерн: разработчик собирает билд, пишет "протестируйте" - тестировщик день нечто делал, пишет "протестировано" - получается "выпущено" и огребаешь баги. Нужны новости версии и понимание, что трогали.
- Ежедневные статус-репорты. Ежедневно. А еженедельно - сообщать об успехах.
- Post morten. После выпуска версии - провести анализ, выявить сильные и слабые стороны.
- Минтуки встреч. Вести протоколы-минутки, рассылать участникам и другим заинтересованным.
- Полчаса на автоматизацию. Выделять каждый день. Пусть одному человеку из команды. За это время - пишется один тест. И за мессяц - их уже 20.
- Все в teamcity (или аналог). Включить запуск автотестов на регулярной основе. А не хранить их где-то локально.
- Инженерные практики. Быть QA. Поговорить с разработчиками о качестве, об используемых практиках.
- Roadmap тестирования. Выписать даты выпуска версий, нарисовать карту.
- Трындеть. Никогда не кушать в одиночку. Ежедневно общаться с разными коллегами.
- Сплотить команду. Поддерживать ритуалы в команде.
- Начинаем рабочий день. Никогда с утра не открывайте почту! Первый час - для другого. Для разумного планирования и общения.
Михаил Субоч, ЭПАМ Системз. Построение Keyword-driven фреймворков. Это был доклад об архитектуре тестового фреймворка, воплощенного во фреймворке TAF Core. Фреймворк был создан в EPAM и выложен в open source под LGPL. Но рассказ был именно об общих принципах.
Основной принцип архитектуры - Keyword-Driven. Строгое отделение логики от реализации. Достижимо как на своих фреймворках, так и на готовых - Fitness, Cucumber. Только надо соотвествующим образом использовать, сохраняя указанное разделение. Оно дополняется отделением данных для теста от его логики. В результате получается архитектура с 5 слоями.
- Данные
- Логика
- Шаги
- Утилиты
- объекты (ui-локаторы, таблицы БД, web-сервисы)
В презентации есть конкретная схема: Ядро, инструменты, агент для распараллеливания и запуска. И так далее.
И в конце - были общие рекомендации.
- Быстрая смерть - программирование в Excel вместо шага проверки. Нарушение разделения.
- Незапускаемые тесты бесполезны.
- Ломаем утром, строим ночью. Утром - техническая реализация, вторая половина - дизайн. И лучше эти активности не смешивать - разное мышление
- Составление сложных шагов из базовых. CreateProduct и другие подпрограммы. Чтобы вспомогательные шаги, обвязку - убирать из теста. Например, просто Login всюду, кроме автотеста формы логина. И это должно быть доступно тестировщику, а девелопер - пусть ревьюит.
- Важна независимость от технологии. TAF Core - был до Selenium. Но может с ним интегрироваться, равно как с телериком. Низкий порог входа.
Максим Гриневич, Colvir Software Solutions. Промышленный подход к автоматизации тестирования или Keyword-driven testing в жизни. Рассказ был о внутреннем устройстве тестовых сценариев для тестирования большой банковской системы. Как я понял, это касается той же самой системы, о которой накануне говорил Алексей Надененко, впрочем, я могу ошибаться.
Тесты устроены так.
- Разработчики - предоставляют стандартные операции, действия и проверки, которые представляют шаги тестирования, реализуемые как банковские keyword
- На их основе тестировщики реализуют сценарии тестирования.
- Необходимо видеть, что именно делает автотест. По шагам. Для Заказчика и руководства. При этом то, что написано должно соответствовать. И это - важное требование у них. Хотя часто автотесты воспринимают как черный ящик.
- Тестовые сценарии - в xml. Версионность и прочее.
- Для работы используют ALTOVA. Отображение и редактирование в формах. При этом - несколько видов просмотра, из которых можно редактировать ограниченную информацию.
- Верхние узлы - дают пошаговую инструкцию тестирования, и руководители ее смотрят через xml/web
- При прогоне - лежат конкретные значения. Но подставляются они - отдельно.
- По xml - генерируется исполняемый сценарий. Его не правят, при изменении - меняют исходный xml
- Тестовый план или цепочка сценариев тестирования. На вход ему готовят данные. Первый из них - готовит данные - выводит документы в нужное состояние и прочее. Пускается параллельно. Распараллеливание надо учитывать сразу, тогда оно не составляет проблем.
- Ошибки теста бывают трех видов: Данных, Автотеста и Приложения. И с этим надо разбираться.
- Начальный въезд в xml - два дня, и уже может писать, пусть ошибаясь.
- Программисты планируют устроить перегенерацию на лету, или интерпретацию - чтобы исключить хранение сгенеренных автотестов.
- Будут расширять набор стандартных операций. Пока половина автотестов через операцию "другое", но они над этим работают.
- Хочется связать автотесты с функциональностью, чтобы понимать что прогонять. Сложно, потому как структура приложения непроста.
- Текущее приложение - desktop, будет версия под web.
- Вопрос про версии. Ответ: все очень сложно, у них около 30 клиентов, каждому из которых дано право вносить в код.
Артур Карабанов, Wargaming. Wargaming. Ни слова о танках. Это был первый доклад, и я пришел к середине, когда докладчик уже почти закончил и перешел к ответу на вопросы. Доклад был о процессе тестирования, в котором основную роль играют чек-листы взамен традиционных тест-кейсов.
Ирина Тузикова, Grid Dynamics. Простой взгляд на автоматизацию или Как не изобретать велосипед. Доклад о комплекте инструментов Web-тестировщика и особенностях установки и настройки их. Казалось бы, в чем проблема? Но тут - как с администрированием: у одних админов все настроено и тикает, а другие - непрерывно лечат. Так вот, были моменты, которые надо настроить сразу, чтобы не лечить потом. Может быть и очевидные, но наверняка на эти грабли наступает куча народа. В докладе упомянуты были Java, Maven, IDEA, Selenium, Thuсydides, Броузер и Web-драйвер к броузеру.
Из забавного. У Selenium есть один недостаток - он не умеет предсказывать будущее :) И поэтому он часто не совместим с версиями, которые вышли позднее. Так что броузеры должны быть нужных версий (надо смотреть на дату выхода, никаких таблиц совместимости нет) и обновления надо отключить.
И остальные доклады.
Дмитрий Маевский, Одесский политехнический университет. Прогнозирование процесса выявления дефектов при тестировании программного обеспечения. Рассказ о построении математической модели процесса тестирования, которая позволила бы получить предсказания относительно сходимости процесса, его сроков и количества ожидаемых багов. В основе модели - теория переноса. К сожалению, у авторов не получилось построить модель на реальных данных: все фирмы, к которым они обращались - им отказали. И они использовали открытые данные других исследователей. Хорошая манера изложения, отчасти академическая, но с шутками и живо.
Кстати, у Дорофеева на SPMconf была аналогичная модель, касавшаяся прогнозирования сроков завершения обработки. Тоже с обратным потоком дел от программистов в бэклог как одним из факторов. Но - посложнее (и изложена более живо).
Сергей Талалаев, Exigen Services. Oracle-based тестирование. Теория и практика. Это вовсе не про БД-Oracle. Это оракул, предсказания. Основанные на мнениях экспертов - людей, мнения которых близки к истине.
Вообще в основе доклада - реальный проект тестирования для системы, которая работает в области страхования с кредитными договорами. И, в числе прочего, она должна давать оценку, основываясь на большом количестве параметров договоров. И чтобы ее протестировать на достаточном количестве вариантов, был написан калькулятор в Excel, воспроизводящий логику, а дальше в процессе тестирования ответ системы сравнивали с тем, что дает Excel.
Так вот, Excel в данном проекте - и есть ото самый оракул.
Андрей Кузьмичев, Объединенная компания Афиши и Рамблера. Истории про перезапуск компании и тестирование. История реорганизация. Отдел тестирования - расформирован, но не полностью: тестировщики - стали работать в командах, но руководитель отдела тестирования - есть. Получается двойное подчинение, есть общие встречи и обмен информацией. И они при этом еще и связывают компанию, передают знания о технологии. Правда, не слишком понятно назначение доклада, он получился, скорее, в форме презентации устройства компании для потенциальных сотрудников, хотя задумывалась, наверное, поделиться опытом, пригодным для использования другими. Но для второго варианта - слишком много внутреннего контекста.
Виталий Шульга, EPAM Systems. Особенности автоматизации с помощью скриншотов на платформе .NET. Дальнейшее развитие темы автоматизации тестирования приложения, запускаемого под Citrix, для которого недоступна внутренняя структура объектов и потому надо опознавать элементы по их изображению. На прошлой SQA days рассказывали об успешном использовании Sikuli для этих целей. Но дальше они захотели интегрировать эти тесты с другими своими тестами, которые для WPF-приложений. Sikuli - это Java, стыковки с .Net не получалось. Они пару недель помучились, а потом за день написали мини-движок, который умеет опознавать картинки и дергать примитивный WinAPI для мыши и клавиатуры - и дальше можно писать тесты, основанные на скриншотах, однородно с другими на платформе .Net. Там пришлось помучиться с эффективной реализацией алгоритма опознания изображения - сначала сравниваются 5 точек, раскиданных по картинке, и только когда совпали - идем дальше. А первая версия с простым сравнением - была очень долгой.
[ Хронологический вид ]Комментарии
А взглянуть на страницу результатов теста можно? Еще хотелось бы услышать ваше мнение о времени первого появления достаточно крупных цветовых сообществ.
В общем, не проблема, ниже вырезка из результатов в части спиральной динамики. А про появление цветовых сообществ - я не понял. Где, в каком объеме. Потому что есть сильная неравномерность - в общественной жизни, в науке, в бизнесе (деловом сообществе). Отдельные представители были всегда (ну, с античности), и они объединялись в какие-то кружки. То есть нужен более развернутый вопрос.
Ага, спасибо.
Ваши тексты мне нравятся, хотя тема тимбилдинга не близка.
Мне кажется, ваша профориентация (на бизнес) несколько деформирует общее видение картинки (бизнес таки оранжевый мем). В частности, видится ошибочным представление, что "уровень понимания" начинается с оранжа. О попытке "отождествления" оранжевых с желтым неплохо имхо сказано в этом эссе (и вообще замечательный текст): 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 правильно расстаться с определенными типами людей, несмотря на профессионализм, для обеспечения перехода. При этом Дима подчеркивал, что после внедрения ценз снижается, потому что человек приходит уже в сложившуюся культуру.
Доклад Станислава Сажина на сайте конференции, там же видео. UPD 2025: ссылка не работает, видео на youtube https://youtu.be/RSVub5m-3DM, там ссылка на презентацию.
Для истории. Анонс 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, Владимир Каленов, Сергей Баранов.
Из отзывов ведущих
Запись видео
Войдите, чтобы комментировать.