Блог:Максима Цепкова
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 точек, раскиданных по картинке, и только когда совпали - идем дальше. А первая версия с простым сравнением - была очень долгой.
2012-11-30: SQAdays-12, день первый
Конференция SQAdays-12 в Минске - очень удачно. Много хороших и дельных докладов. Более 500 участников и много общения. Постоянный кофе и перекус в фойе также способствует общению. А вечером - затянувшееся afterparty. И все эти замечательные штуки - традиционны для SQA Days.
Общие темы, которые были в большом количестве докладов.
- Архитектура конструкции для автоматических тестов. Наиболее полно - в докладе Лянгузова, но у других тоже звучала. Отделение тестов от данных и так далее.
- Разделение уровней тестирования: UI - бизнес-логика комплексно (API сервисов) - unit-тесты отдельных частей. Выстраивание пирамиды.
- Доклады о распространенных ошибках и проблемах. Да, это все - известные грабли. Но почему-то по ним любят ходить.
- Об организации тестирования, сотрудничестве разработчиков и тестировщиков, которое необходимо.
Еще были вполне понятные на такой конференции темы об автоматических тестах, нагрузочном тестировании и многом другом.
Да, я не хочу сказать, что все идеально. Организаторы не всегда правильно угадывали с залом, и некоторые залы были переполненны. Плюс помещения Национальной библиотеки - не слишком удобны, два зала - длинные и узкие. А еще - были проблемы с инетом, но за первый слот его починили. Правда, инет по талонам - говорят, в Белоруссии доступ должен быть персонифицирован, поэтому каждому участнику выдают персональный логин и пароль, и фиксируют, кому выдали. Но это - вполне рабочие мелочи.
А теперь я быстро перейду к обзору докладов и начну, как обычно, с тех, которые больше понравились.
Алексей Лянгузов, Grid Dynamics. Архитектура автоматизированных тестов. Великолепный доклад про построение архитектуры автоматических тестов. О том, из каких составных частей это должно быть собрано, какие требования к отдельным компонентам и какие взаимосвязи допустимы, а какие - лишние, мешают развитию. С деталями и конкретными вариантами для каждой компоненты, который применяют они и какие еще возможны. При чем, в известных источниках описания такой конструкции - нет, ее продвинутые люди - сами создают, а не продвинутые - делают как получится. Зал сильно переполнен.
Телеграфные записи основных моментов, остальное - смотрите презентацию и видео.
- Библиотеки. Важно поставлять тех же версий, что и в проме. У них Мавен.
- Фреймворк. Обеспечивает отчеты. Определяет формат тестов, это надо учитывать при выборе. Обеспечивает запуск тестов. Обычно начинают с Junit, а так - Fitness и Cucumber совместно.
- У Fitness тесты - Fixture, в других - есть аналоги. Это привязка тестов к исполняемому коду.
- Тестовые данные. От тестов отделяются. Повторное использование, структурирование и систематизация.
- Окружения. Запуск тестов в разной среде - FF и IE
- Конфигуратор. В приложении обычно статические настройки. Но их не всегда достаточно. Например, при запуске тестов под виртуалками с динамическими ip-адресами может быть нужно разбираться с сертификатами и подхватывать эти адреса.
- Важно, чтобы вся внешняя среда ушла из fixture
- Менеджер данных. Тесты не должны говорить "дай мне данные из этого файла, они должны говорить "дай мне данные такого типа в таком количестве". У них совсем умный менеджер не получился, но они туда идут.
- Еще важно контролировать связи между разными компонентами, архитектура зависимостей показана.
- Пример-1. Структура каталогов. Для Java-компонентов. Это - отражение логической архитектуры в структуру реализации, и со своими дополнениями.
- Вопрос уровня тестирования. Можно работать на UI, можно на бизнес-логике. Тест нового пользователя. Запрос пользователя, которого нет - создание - проверка, что есть. Вообще говоря, этот тест можно пускать на UI, можно на веб-сервисах, можно глубже. И в идеале мы должны иметь возможность переключения уровней. В принципе, это не очень сложно - если заранее подумать. Тут что важно - если есть не UI-вход. Потому что UI не может подсунуть неправильные значения - ограничения сверху. А тестировать сервисы - надо.
- Признак нехороше архитектуры - появляются папочки "разное" или классы, которые некуда приткнуть. Я: очень правильно!
Игорь Хрол, ЭПАМ Системз. Автоматизация тестирования: почему умирают проекты? Очень хороший доклад о том, почему умирают проекты автоматизации тестирования, и как поступать, чтобы это не произошло. По его ощущениям 80% таких проектов - провальные, и его это очень волнует. А вспоминая первые проекты - сейчас он видит, что они были мертворожденные. Этим и вызван доклад.
Типичные причины провалов.
- Запись тестов (recording). Еще 5 лет назад была книга, что это не работает. Но до сих пор продают и покупают именно это.
- Перестает работать на чуть более сложных проектах, чем демо
- Невозможно поддерживать по изменениям. Представьте, что recording продают бухгалтеру.
- Простой выход - не используйте
- Чуть более сложный: обеспечьте, чтобы работало для вашего приложения. Это доработка. И смиритесь, что когда поменялось - надо перезаписать тест, не пытаемся читать и модифицировать. И под это - заточите методику.
- UI-автоматизация теста - медленная.
- Потому что поднять с нуля через интерфейс - тяжело. По данным. Плюс - мы работаем через посредника.
- Решение: Нормально пишите код. Не используйте sleep для синхронизации
- Решение: Запускайте тесты параллельно. И сразу стройте архитектуру для этого. Включая разделение данных.
- Фокусируйтесь на других видов автоматизации тестирования. Комплексно. UI-тесты - верхушка, а под ними - уровень бизнес-логики, API, там больше тестов. Под ними - unit-тесты (здесь: по логическим фрагментам).
- А еще - UI-тестирование нестабильно. 2-3% fail-тестов просто потому что асинхронно.
- Тоже не тестируйте все через UI. Я: из зала - неправда. Да, потому что там тоже может быть асинхронность
- А еще - перезапускать после падения, и анализировать только повторные падения.
- Слишком дорого разрабатывать и поддерживать.
- Потому что выполняются медленно, а тестировщик - просто ждет
- Потому что неверно выбран инструмент. Разработка тестов - тоже разработка ПО. И надо применять технологию.
- Потому что недостаточно знаний у команды. Для хороших тестов - нужно сотрудничество разработчиков и тестировщиков, по-отдельности получается хреново.
- Простой механизм от разработчиков, чтобы тест понимал, что все отрисовано
- Чтобы найти кнопку попросите разработчиков добавить id, а не ищите полчаса как обойти.
- Используйте хороший фреймворк
- Отделите фреймворк от скриптов
- Автоматизация не используется. И, блин это проблема
- Мы не доверяем автоматическим результатам, лучше проверим руками. - Надо учить работать по-другому, работа с людьми. Интегрировать автотесты с ручными, в общей системе. Userfriendly: ручные писали в Excelб а тут будет какой-то xml. И запуск одной кнопкой.
- Слишком долго и сложно анализировать автотесты. Это реально, и надо продумывать. Пример: (а) автотест упал - прогнали вручную - внесли дефект на систему при повторении, или на автотест, если ручной прошел.
Подводя итоги
- Выберите правильный фреймворк. Это - разработка
- Внимательно отнеситесь к организацию процесса и разделению обязанностей
- Налаживайте коммуникацию между командами.
Аяз Ашрапов, Fujitsu. Базы знаний на службе у IT-аутсорсеров. Про процессы ведения базы знаний в Fujitsu. Они включены в процесс работы над проектом. Между проектами идет обмен знаний, несмотря на потребность в дополнительном обезличивании для этого. Это касается, например, базы про KPI, например по времени вхождения человека в проект, эффективности выполнения проектных задач и т.п.
Про инструменты.
- Не нужно наворачивать, потому что с базами знаний должны работать все сотрудники компании. А не только продвинутые.
- Расширяемость. Потому что область использования будет расти, а инструмент - не сменишь.
- Поддерживаемость. За инструментом надо будет следить, делать расширения и прочее. И тут вопрос тяжести решения.
Рекомендации напоследок.
- Сделайте обязательным использование базы знаний. Чтобы в ней все было, искать в одном месте.
- Автоматизировать рутину. Ее все ненавидят. Например, поиск устаревших статей. Рейтинги. Поиск. Аудит - отчеты что плохо. У нас тут хорошо. Пример: как только в Project-сервере меняют проект сотрудника, он получает письмо со ссылками на статьи, и он - должен ознакомиться, это тоже контролируют.
По инструментам - они используют микс. Часть - требует заказчик. Используют медиавики. Где-то sharepoint.
Любовь Аверина, Ново-Плей. Пример эффективного управления тест-кейсами при помощи Google docs. Основная идея доклада в том, что Google Docs таблицы представляют собой коллективно и совместно используемый Excel. В таблицах - удобно вести тест-кейсы, но вот совместно работать с Excel-файлами тяжело. А google docs - позволил эффективно работать. И докладчица подробно показывала, как у них это сделано. К сожалению, не видя экрана (а он далеко) это посмотреть не получалось. Но я надеюсь на презентацию.
Елена Андреева, Grid Dynamics. Грабли автоматизации. Учимся на чужих ошибках. Либез по правильной организации кода. Популярные грабли. Коротко и по делу. И, вроде всем известно и очевидно. Но мусорные куски закомментированного кода при этом встречаются повсеместно. И у разработчиков тоже. Плюс - тестовые фенечки, например, логи вместо системного вывода. Великолепная фраза "Результаты проверяйте просто, иначе в проверках - будут ошибки".
Владимир Иванов, Александр Ильин, Oracle. Формальная верификация как средство тестирования (в Java). В общем, я боялся что это будет скучный доклад научный про доказательство правильности. А оказалось - весьма оригинальная конструкция, связывающая современные компиляторы и их расширения с гарантией правильности кода. На самом деле, компилятор многое проверяет, и если у нас язык со статической провркой типов, то компиляция уже обеспечивает многое.
Проблема в том, что в compile-time не достаточно информации. Например, cast object к конкретному типу. В общем случае - ошибка, но в конкретной программе архитектура может гарантировать, что на вход идут только объекты нужных типов. И чтобы преодолеть это - используют дополнительную разметку, и специальные тулы, которые, опираясь на эту разметку проверяют правильность. И таким образом можно гарантировать, что строка-номер кредитной карты по всей программе имеет правильный формат, который на входе из простой строки - будет проверен. Или поделить все строки, используемые для динамического sql на те, которые заведомо корректные, и те, где нужен контроль sql injection, и обеспечить, чтобы этот контроль был проведен до исполнения. Получаются Pluggable types, дополняющие систему типов. Как средство упоминали Checkit framework.
И это аналогично сложным доказательствам в математике, когда разрабатывают новый формализм, обеспечивающий простоту доклзательства. А практический выход - что после этого вам не надо гонять тесты на sql injection или неверный номер карты, разве что для того, чтобы убедиться в дружественной диагностике.
Рина Ужевко, SKAZKA. Тестирование и техподдержка брак или сотрудничество? В общем, название - странное, но сам доклад - хороший и правильный. О том, что логично возложить обязанности техподдержки на тестировщика, и о тех плюсах, минусах и особенностях, которые несет такое решение. В общем, в нашей компании все так и происходит, поэтому для меня лично нового не было, но ведь не везде так. А содержание - правильное. А еще - там было много историй из будней техподдержки по играм.
Виктор Гляненко, VIAcode. Анти шаблоны непрерывной интеграции. О дополнениях оргплана, которые надо накрутить поверх непрерывной интеграции. Например, если сборка по commit - то в пятницу последний час коммитить нельзя. Или если сборка не по коммит, а раз в полчаса - надо понимать, как разбирается ситуация падения билда. Много мелочей, которые очевидны когда на них наступишь, но есть и важные вещи. Одна из них - автотесты гарантируют ограниченную работоспособность и их надо сопрягать с ручным тестированием, включая его в непрерывную интеграцию в некотором объеме.
Алексей Емелин, Яндекс. Тестирование безDOMных объектов современных веб-интерфейсов на примере API Яндекс.Карт Интересный доклад, хотя и далек от меня, поэтому я слушал кусочки. Задача тестирования, когда внутри картинка, а не элементы. При этом там еще накладываются проблемы инструмента. Собственно, дается некоторый путь - как делать. Например, когда ставят метки и прокладывают пути. Там точки - это DOM-элементы, а вот пути - нет, это дополнительная линия. Можно делать API. Но вопрос что там. Второй вариант - пискельное считывание и анализ. Они - сравнивают с эталоном. Они генерируют эталон на продакшн и сравнивают с тестовым, проверяя, что ничего не сломали. Но! для нового функционала не годится.
Еще интересно про обработку ошибок. Есть onerror, но он не ловит на загрузке страницы. А еще - вопрос хостов. Для хостов можно делать доверенные узлы - если есть доступ. Второй метод - плагин JSErrorCollector, ловит ошибки браузера. И со списком можно взаимодействовать. Но только FF.
Илья Кацев, Яндекс. Проект Роботестер Робот как тупой юзер. Умный юзер - пусть будет тестировщик. Но тупая часть работы у него уходит. Краулер - ходит по сайту. По мотивам поиска, только внутри страниц, смотреть состояния и действия. Тут важно, что страницы очень динамические, содержимое сильно меняется. И надо заполнять формы и активировать. И там еще java-script логика, активизация кнопок. В целом интересно.
Наталья Руколь, Лаборатория качества и Андрей Мясников, Undev.ru. Диалектика созидания: курс на сотрудничество. Последний доклад дня, шоу с интерактивом. Четыре миниатюры взаимодействия тест-менеджера Наташи и тестировщика Андрея. Все идеи понятные, но сценки все равно классные, особенно вечером.
Миниатюра где "все не так" и разборка с мест - что именно не так. А потом - разбор ошибок. И рекомендации по исправлению.
- Собеседование
- Первый рабочий день
- Испытательный срок
- Рутина. В последней сценке менеджер окончательно демотивировал тестировщика, а потом - уволил.
Записывать не было смысла, так - отдельные фразы.
- Нет глупых вопросов, есть глупые люди, которые не задают вопросов.
- Нечеткое задание "познакомься с продуктом"...
- Если свободного времени нет сейчас, то его не будет и потом.
- Менеджер - не чайник, потому что его нельзя выключить.
- Соответствие слова и дела.
- Завел больше всех багов - к кулеру без очереди :)
А теперь - про остальные доклады, на которых я был.
Александр Андрущенко VIAcode. Тестирование производительности системы мониторинга на платформе Microsoft SCOM 2012. Доклад о том, что система мониторинга не должна напрочь перегрузить систему, вырубив приложение. Проблема в том, что мониторинг подключают далеко не сразу. Система уже написана и работает. И в этих случаях подключение мониторинга может быть чревато. Поэтому нагрузку самой системы мониторинга - тоже надо мерить и учитывать.
Михаил Матвеев, T-Systems. От ручного тестирования к автоматическому: опыт внедрения в крупном проекте. Была конкретная задача - перейти от ручного тестирования к автоматическому, без дополнительных требований к квалификации того, кто разрабатывает сценарии тестов. Ручные тест кейсы вели в Itorg. Для автоматических выбрали два продукта (от экрана далеко, поэтому не записал, но презентация - будет), один из которых обеспечивает визуальное конструирование тестов из набора шагов, а второй - генерит по этому некоторый исполняемый скрипт. Успешно.
Ольга Киселева, HFLabs. В моем коде багов НЕТ! Странный доклад. Про автотесты, которые делают большим количеством копи-пастов, и их надо вычитывать. И тесты, которые проверяют count, а не содержалку и так далее, слова правильные, но не структурировано. С другой стороны, проблемы-то воспроизводятся во многих случаях. В общем доклад про множественные проблемы плохоорганизованной разработки (тут - тестирования), и о частных решениях, которые надо обеспечивать через человеческий фактов (надо подумать, постараться...). Наверное, так бывает, но решения все-таки нужны более промышленные, процессные по-моему.
Алексей Надененко, Сбербанк Технологии. Автотестирование АБС. Конвейер разработки, конвейер данных, конвейер выполнения. Доклад был хороший по содержанию, но плохой по представлению. Он шел в обед, без альтернативы, и предмет - мне знакомый, так что я не ушел, а через некоторое время - форма перестала мешать восприятию содержания. Но это потребовало усилий.
А речь шла про очень большие системы и функциональные тесты в них. Которые сильно зависят от данных, и потому выстраиваются в цепочки, в каждой из которых 300-400 тестов. Про использование bankwords - предметно-ориентированные (банк) ключевых слов. Про отслеживание зависимостей цепочек для распаралеливания выполнения - чтобы уложить регресс в 6 часов вместо 12 (или больше, могу ошибаться). Про схемы обмена данными, на которых как раз основана зависимость тестов. Но все это, увы, без конкретики - как именно они поддерживают схемы обмена данными, как ведутся цепочки и так далее. На общем уровне.
Владимир Примаков. Мастер Тест План / Тестовая Стратегия К сожалению, доклад оказался методологической инструкцией в буллетах. Без кейсов, обучение истине от скучного лектора. Жаль.
Татьяна Зинченко, Inter Technology Group. MindMap - в мире интеллектуального тестирования. К сожалению, доклад не удался - потому что не получилось поставить тулу, которая рисует mindmap вживую, потребовалось обновить Java, что затянулось на неопределенное время. А доклад был про mindmap как средство работы для тесткейсов. Лично я - это слышал и, по-моему, именно от Татьяны. С другой стороны, на каждой конференции - много новых людей и они-то не слышали :) Зато я быстро нашел сервис http://drichard.org/mindmaps чтобы рисовать через web. Сохраняет в Json, на сайте написано, что может в googledocs но не работает.
2012-11-29: KM Russia-2012, день второй
Второй день KM Russia-2012 был практическим тренингом. Собственно, я уже писал вчера, что главной идеей организаторов было свести блогеров с бизнесом и властью, организовав взаимовыгодное взаимодействие. И в рамках России в целом, и в регионах. При этом не надо забывать, что KM Russia проводит СОМАР - СОюз МАркетологов России, у которого есть много действующих региональных отделений. Поэтому первая поляна взаимодействия достаточно очевидно: реклама, вернее, маркетинговые мероприятия, способствующие развитию бизнеса. Которые в настоящее время реализуются через совместную командную работу. Собственно, начавшаяся институализация и соорганизация блогосферы через сообщества и послов ЖЖ - инициировано во многом именно под эту задачу совместной деятельности. И командной работе был посвящен второй день.
Была большая лекция Стива (Stephen Mann) про командную работу, во многих аспектах.
- Коммуникация, включая язык тела - мимику и жесты. Которые часто не контролируются, а позволяют понять собеседника, плюс воспринимаются неосознанно и способны внести диссонанс в сообщения.
- Про Лидерство, которое может быть прирожденным, но у большинства - качество, приобретенное самовоспитанием.
- Про Лидера и Команду, ответственность Лидера, организацию работ, работу с развитием членов команды. При котором надо работать с сильными, а не слабыми сторонами человека, подбирая подходящую роль.
- Про мотивацию, для которой деньги - лишь гигиеническая составляющая. Зарплата должна быть достаточной, однако дальнейшая мотивация должна быть другими средствами. "Деньги могут заставить приходить на работу, но не могут заставить работать".
- Про Культуру, которая обеспечивает совместную работу и доверие в команде, а это - необходимо.
Тут надо отметить, что блогеры во многом - индивидуалы. Хотя у всех есть собственная работа, где они в коллективе, в блогосфере они сами по себе, сообщества - лишь начали организовываться. И командная работа - дело новое. Поэтому теория была в достаточно упрощенном варианте. Это естественно: сначала излагается основная канва, а уже потом - детали. И это потом - только когда основные аспекты прочувствованы на практике, иначе люди не готовы их воспринять.
Кроме того, нацеленность на практическую работу означает сознательный выбор одной из моделей команды - той, с которой проще начинать. Так что рассказывали модель команды, которую за собой ведет лидер, и которая работает совместно над общим делом, ведомая общими целями.
Кстати, дам некоторую врезку о тех самых деталях вариантах, которые упущены. Это полезно и мне самому - я их вспомню.
- Команды, ведомые лидером - не единственный вариант. Второй эффективный вариант - команды, руководимые опытным координатором. Просто он - существенно сложнее и требовательнее к составу. Согласно исследованиям Белбина, они обладают примерно равной эффективностью, и оба широко распространены. Собственно, эти варианты были сформулированы Белбиным в ходе своих исследованиях. Прочитать об этом можно в его книгах "Команды менеджеров Как объяснить их успех или неудачу" (это - первая, с нее стоит начинать) и "Типы ролей в командах менеджеров" (это - дальнейшее развитие). А две недели назад на SPM-conf-2012 я делал доклад с кратким изложением основных аспектов - что можно вложить в 40 минут. На сайте есть презентация, и скоро (в течении месяца, думаю) появится видео.
- Работать при развитии человека, конечно, надо с сильными сторонами, и надо подбирать ему позицию с адекватным кругом обязанностей. Однако, при этом организационное разделение обязанностей - штука весьма устойчивая, и важно, чтобы человек закрывал большинство аспектов определенной позиции. И если слабые стороны в этом мешают, то их надо подтягивать. Иногда можно сместить разделение обязанностей по позициям, но суть в том, что обязанности одной позиции часто сильно связаны между собой, и их перераспределение может сильно уменьшить эффективность. Можно, конечно, все организационное деление на позиции переиграть под способности конкретных людей, но это - сложная работа, потому что требует учесть много аспектов. Как в футболе - есть несколько типовых способов разделения обязанностей между игроками команды, роль игрока определяется его способностями, но слабые стороны для роли - надо подтягивать. А сделать полностью оригинальный рисунок взаимодействия могут только очень сильные тренеры.
- По Мотивации - есть разные люди. Теория мотивации Герчикова делит людей на пять категорий, в зависимости от типа их мотивации. И с разными людьми надо работать по-разному. Подробнее о теории почитать здесь, а здесь - пост практика на ту же тему (с продолжением). И это - не единственная теория. На ADD-2010 Антон Овчинников рассказывал о применении упрощенной модели Юнга для правильного донесения до сотрудников конструкции оплаты персонала.
- С формированием культуры компании проблема заключается в достаточно быстрой смене персонала в современных условиях. В основном человек работает на одном месте год, два, реже три. Привить культуру за это время - очень сложно. А дефицит кадров - не позволяет отбирать людей с учетом культуры. Плюс надо учитывать, что чрезмерная однородность - она ослабляет команду. Отчасти, ответ был дан - через формирования общей культуры в рамках сообщества, из которого набирается основной состав команды.
На этом про команды закончим.
Что касается собственно методов управления знаниями, то участники разбились на команды и придумывали совместные проекты для регионов. При этом были достаточно интересные методички по ведению коллективного обсуждения в целом и по методам мозгового штурма и 5 почему. А в группах были маркетологи из СОМАР, которые знакомы с практическим применением этих методов по своим мероприятием. И практически это было весьма эффективно, такое знакомство управление знаниями через практическое применение. Кстати. стоит отметить оригинальную интерпретацию метода Мозгового штурма, дополненную сокращенной ролевой моделью Белбина (7 ролей из 9, без Реализатора и Души компании, которые не нужны в коротких сессиях). Выглядит любопытно.
Кроме того, Маданмохан Рао учил часть участников методам управления знаниями. Правда, это было без меня, подробности - неизвестны.
Так что второй день был очень креативным и практически-нацеленным. А конференция в целом - прошла хорошо и лично мне дала новые знания о работе со знаниями :) Фотки - смотрите в ЖЖ, благо блогеров было много.
2012-11-27: KM Russia-2012, день первый
Сегодня в третий раз был на KM Russia-2012. В этом году мероприятие проходило в весьма любопытном формате, и концептуально и по исполнению. Если предыдущие два года это весьма напоминало обычные конференции с докладами спикеров и интерактивными мастер-классами, то в этот раз организаторы поставили весьма необычную и амбициозную цель - свести вместе бизнес, власть и блоггеров вокруг рамочной темы управления знаниями, и попытаться заложить предпосылки конструктивного сотрудничества. Надо сказать, что с профессиональной точки зрения эти цели - далеки от моей работы, однако на форуме ожидались эксперты мирового уровня, и в частности Рон Янг, а также выступления от крупных корпораций, применяющих у нас практики управления знаниями - IBM, JTI, Сбербанк, РЖД, что для меня - интересно. И ожидания тут оправдались. А еще - было просто любопытно, что выйдет из столь разнородной тусовки.
Но начну я свои впечатления именно с общих целей мероприятия, как я их воспринял. В настоящий момент блоги получают все большее значение как способ порождения и передачи информации. Они вытесняют традиционные СМИ, особенно для тех людей, которые имеют дело с созданием и порождением знаний - те все больше переходят в блогосферу. При этом эффективное управление знаниями сейчас - ключ к успеху любого сообщества, будь то клуб по интересам, профессиональное сообщество, коммерческая фирма или государство в целом. И управление знаниями - коллективный процесс. Поэтому государство, власть заинтересованы в освоении новой реальности, и на федеральном уровне, и на региональном. А блоггеры, представленные на встрече ЖЖ, в свою очередь, тоже институализируются - появляются послы ЖЖ и прочие признаки организации, пока достаточно неформальной. И обе стороны заинтересованы в налаживании сотрудничества, при этом естественной площадкой общих интересов является именно информация, знания. Тем более, что власть нуждается в идеях, она готова организовывать площадки для конструктивного обсуждения и совместной работы над законами - что гораздо сложнее, чем просто критика, и желающих - меньше. Блоги - один из способов привлечения активности людей в эту сторону. Об этом много говорил в своем докладе Руслан Гатаров (член Совета Федерации). Он, кстати, один из ответственных за модерацию интернета и на эту тему было много деталей и подробностей.
А бизнес здесь тоже имеет свой интерес. Методы коллективного разума, краудсорсинг доказал свою эффективность как способ решения сложных задач. И бизнес - организует площадки для этого. в том числе открытые. Теперь дело за привлечением большого количества людей. И здесь блоггеры здесь естественным образом тоже могут помочь.
Теперь подробнее о содержательной для меня части мероприятия, собственно об управлении знаниями. К сожалению, формат мероприятия предполагал достаточно поверхностное изложение. Доклад Рона Янга с обзором процессов управления знаниями в прошлом году был куда более глубоким и с большим количеством подробностей, интересующиеся могут посмотреть мой прошлогодний отчет. Зато в этом году в нем была дана впечатляющая картина наступления Эры знаний, сменяющей Эру информации, которая подходит к критической точке. Собственно, в IT эти изменения очень чувствуются, потому как мы тут во многом на переднем крае.
Кроме Рона был интересный для меня доклад Игоря Бреуса об устройстве управления знаниями в IBM, хотя и без подробностей - про то, что внутри IBM развернута отдельная социальная сеть для внерабочего общения, и еще несколько сетей, куда имеют доступ партнеры. И эти сети нацелены на коммуникации людей, а также на возможность высказывания ими своих идей.
Также интересны рассказы Дмитрия Мишустина и Алексея Емельянова об управлении знаниями и построении команд в JTI. Система управления знаниями во многом напоминает советскую систему работы с рацпредложениями, однако подвергнутую принципиальному редизайну. А именно, если советский рационализатор отвечал за изменения вплоть до внедрения, то здесь высказывание идеи разнесено от ее воплощения, и между ними стоят определенные этапы работы разных людей. И это правильно, не только в классическом случае, когда идеи топ-менеджера реализует вся компания, но и когда идея высказывается внизу, на уровне производства. Потому что для воплощения часто нужны менеджерские скилы, отсутствующие у автора.
Еще было интересно узнать, как продвигаются проекты в Сбербанке и корпоративном институте РЖД, и других, о которых я слышал в прошлом году.
Как всегда интересен был доклад Александра Сазановича из МИРБИС - об управлении знаниями в современном обществе. Обмен информацией вышел сейчас на принципиально новый уровень, и старая система управления неизбежно рухнет - как рухнуло рабовладение с массовым распространением письменности, а феодализм с книгопечатанием. При этом на смену простым решениям - приходят сложные, состоящие из набора согласованных идей, а не из одной. И надо уметь эти сложные решения создавать.
Что касается остального, то, к сожалению, доклад Стивена Манна о командах оказался несколько поверхностным, на уровне деклараций о командной работе. В IT тема команд раскрыта гораздо глубже, потому что мы имеем сложную коллективную разработку, в которой надо организовать работу креативных индивидуумов. И модель команд Белбина тоже сильно глубже. Доклад Маданмохана Рао тоже несколько разочаровал - это было больше представление успехов Индии, Сингапура и других стран Азии, в виде перечисления, без раскрытия механизмов, из которых упомянуты только сообщества знаний по регионам и городам.
Это - то, что наиболее запомнилось. Другие доклады - тоже были интересны, но наложившись на информацию прошлых лет - не несли для меня существенно нового. А интересующиеся - могут заглянуть в мои отчеты KM Russia-2010 - конференция по Управлению знаниями и KM Russia-2011 - конференция по Управлению знаниями.
Завтра - продолжение.
2012-11-19: SPMconf-2012 Минск - день второй
Второй день SPM conf-2012 в Минске был похуже первого. Зато вызвал побольше мыслей, о которых я напишу. А в конце был настоящий бриллиант - доклад Максима Дорофеева - с искрометным юмором и при этом на очень серьезную тему, статистического управления по показателям.
А еще - был приятный для меня сюрприз, мой доклад о командах Белбина вошел в тройку сильнейших вместе с докладом Николая Фролова "Gamification" и докладом Максима Дорофеева.
Подводя итоги конференции стоит выписать то полезное, что я для себя вынес так сказать к практическому использованию.
- Инструменты для GTD из доклада Татьяны Беловой. Саму методику я представляю и легкую ее версию в целом использую. Просто у меня не так много дел, и на оперативном уровне точно обходится простым текстовым списком. Но разнообразных активностей становится больше и, возможно, уже стоит перейти на более серьезные конструкции, например, Remember The Milk. А еще - подумать об использовании EverNote для фиксации идей и материалов, мысль о том, что идею можно просто продиктовать на телефон, и она запишется, да еще с распознаванием представляется заманчивой - в метро, вечером.
- Модель для видах обучения в зависимости от контекста, прозвучавшую у Дмитрия Башакина. Я понял, что стоит оценивать и позиционировать взаимодействие с другими, в котором есть аспекты обучения, передачи знаний относительно этой модели. Без этого способы могут переключаться, а это сильно снижает эффективность.
- А еще - знания и модели, полученные из докладов Максима Дорофеева и Дмитрия Безуглого останутся у меня в памяти и в деятельности по связанным темам будут использованы. Но это не к исполнению, а просто как накопление базового уровня картины мира.
- Еще я взял на заметку опыт hack days. У нас в компании были в эту сторону идеи, но не столь оформленные, и до практического применения дело не дошло. Организовывать я лично - не готов, но поспособствовать при случае - это да.
- Доклад Марии Бондаренко привел к мысли о сознательной работе в квадранте эмоций "Восхищение" - делать неожиданные вещи заказчику. На внедрении и обучении ГБК эта практика была, Алена держала фокус: мы делали разные недорогие, но важные заказчику вещи как реакция на замечания на обучение. Но есть подозрение, что как практика - она утеряна. Стоит ее пошевелить, наверное. И подумать о том, как вписать это в процесс в рамках проекта СУПП. В принципе, ответ есть - через список хороших практик относительно этапа проекта. Они не обязательны к использованию, но, подобно спискам GTD, "если ты что-то не делаешь, то хотя бы поступаешь так сознательно".
Теперь о мыслях. Я понял, что многие докладчики решают классическую задачу учителя, преподающего в разнородном классе - на каких учеников ему ориентироваться: сильных, средних или слабых? Ориентируясь на слабых, в данном случае - неопытных, не представляющих предмет. При этом статистически известно, что среди участников конференции новичков в излагаемом вопросе все-таки большинство, и докладчики делают выбор в их пользу. Но при этом ты делаешь доклад неинтересным для тех, кто имеет о предмете представление или опыт. Лично я об этом как-то не очень думал, потому что у меня в большинстве докладов излагаются достаточно сложные конструкции, и если начинать их излагать подробно - времени тупо не хватит. Поэтому доклад компонуется сам собой.
Второе соображение касается негативных кейсов, иллюстрирующих мысль доклада в контексте "с явлением надо бороться". Очень часто звучат вопиющие примеры, и всему залу понятно, что они - вопиющие, их не надо агитировать. Да, в жизни они встречаются, но те, кто так делает - на конференции отсутствуют, а присутствующих интересуют способы борьбы. Поэтому пример создает впечатление начального, поверхностного уровня докладчика. Иногда это так, но далеко не всегда, а причина такого кейса в том, что его просто привести и он всем понятен, более сложный - надо объяснять подробнее, а время - ограниченно. Вот выбрали такой простой. Но, учитывая побочное впечатление о поверхностности доклада - может, лучше вообще без кейса?
А третье - гораздо более интересно. На этой конференции достаточно много упоминались "витамины Адизеса", причем в весьма поверхностной конструкции. Это же касается и ряда других упоминаемых схем, но их просто меньше. При этом такой рассказ можно услышать и от менеджеров высокого уровня или владельцев небольших компаний, молодых и увлеченных. И можно говорить о том, что "они просто не понимают". Но они - успешно действуют, активно интересуются новыми концепциями, применяют их в своей работе, зовут других тоже применять. И действуют успешно. Все это наводит меня на подозрение, что им - и не нужно больше. Они воспринимают конструкцию как мем, и именно как мем ее используют. И это может быть характерно для современного общества, где именно мемы служат не только средством формирования общественного сознания, но и средством координации и согласования действий структур властного и экономического управления обществом - как на уровне государств, так и на уровне мирового сообщества. Сами мемы - представляют широкий спектр, от доктора Хауса, сформировавшего у громадного количества людей, включая детей выбирающих свое будущее, представление о содержании профессии врача, и кончая экологичным обществом с гримасами глобального потепления и вреда ГМО, которые оказывают реальное воздействие на глобальную экономику и служат орудием политической и экономической борьбы. Об этом говорил Песков на KMRussia-2011, желающие могут почитать мой отчет (к сожалению, публикации я не нашел). Так вот, возвращаясь к конференции. Вполне возможно, что для более молодых, выросших в обществе. управляемом мемами, восприятие таким образом и более сложных концепций и моделей, например, модели Адизеса - органично и достаточно для эффективного применения. И именно поэтому они транслируют вокруг - именно в виде мема. Это довольно спонтанно возникшая мысль, об этом мне еще надо подумать...
Ну и напоследок. Во многих докладах рассказывают о хороших идеях и практиках, и зовут попробовать. Часть людей - нормально воспринимает. А часть - становится в защитную позу, объясняет себе, почему они это не делают. И задает вопросы, которые должны подтвердить правильность их поведения - так не делать, и убедить других. Это не сомнения, оно видно по форме вопроса, который часто превращается в минивыступление. К сожалению, такие вопросы отнимают время у тех, кто заинтересовался и реально спрашивает. Потому что докладчик вынужден защищаться. Правда, я не знаю, что с этим делать, так что это так. плач о несовершенстве мира :)
А теперь - обзор докладов.
Начну я с замечательного, превосходного доклада Максим Дорофеев. Гигиена количественного управления.
Отправная точка заключалась в том, что при управлении по количественным показателям в большинстве случаев премии и взыскания получаются просто за вариации измеряемой величины: оказалась выше среднего - молодец, премия, ниже среднего - взыскание. Что превращает жизнь в азартную игру: там ты тоже получаешь и теряешь деньги из-за случайных вариаций.
И Максим рассказывал, доступно и на популярном уровне, и с роскошными афоризмами и шутками, как правильно строить управление по показателям, чтобы не оказаться в ловушке. Не по конкретным показателям, а по любым - потому что показатели следуют из целей и процесса, а он - различен. Я это кратко изложу, и надеюсь, что это послужит стимулом посмотреть презентацию и видео доклада, когда оно появится.
- Определяем цель. Цель должна быть одна, а не много - иначе ты в ситуации Буриданова осла.
- Строим или находим модель объекта управления. Модель явления обычно содержит множество показателей, но Цель позволяет нам отделить важное от неважного, и ограничится малым числом понятных параметров.
- Отделяем общее от особенного. Вариация показателей может быть системной, обусловленной общими причинами, и тогда надо работать с процессом управления или самим объектом. А может быть результатом влияния некоторого особенного фактора, вызывавшего провал или успех. Отличить это сложно, но есть модели. Карты Шухарта (6 сигма), критерий Бэрра, и правила Нельсона для тренда. Есть еще, но этих - хватает. А интересующиеся могут читать ГОСТ 50779.42 или ISO 8258 (если я верно списал номера).
Замечание про модель 6 сигма. Средняя линия там - не среднее арифметическое, а сигма - не среднее квадратичное отклонение. Там сложнее. А глубокий смысл модели - она устойчива к вариативному процессу. Если вы устраняете причины, вызывающие особенные выбросы, статистику можно продолжать наблюдать, а не собирать заново.
Этот процесс был показан на двух конкретных примерах
- Мониторинг срока в разработки. Цель - успеть к сроку. Модель - наблюдение за бэклогом в итеративном инкрементальном адаптивном процессе разработки. Модель была замечательно визуально нарисована! А еще - по ней есть программка, выдающая предсказание срока при загрузке среднего и среднего квадратичного отклонения по измеряемым величинам.
- Обеспечение максимальной производительности. Модель - на основе производительности по ролям, опять-таки в итеративном инкрементальном адаптивном процессе разработки.
Интересно, что хотя процесс в обоих случаях одинаков, модели и наблюдаемые показатели - сильно различны и это определяется целью. Да, процесс называется так длинно, потому что слово SCRUM - это запрещенный баззворд в серьезных докладах, а процесс - реально может быть различным.
И в заключении - шедевры, записанные за докладчиком. Можно также посмотреть твиттер - народ активно постил.
- Я надеюсь, что к концу доклада кто-то поймет, что все делал неправильно. Потому что, по моему опыту, почти все все делают неправильно.
- Цифры - это то что любят менеджеры. Люди, мотивация, креатив - сложно. Зато цифры - они говорят "сколько заплатить премию Коле". А это, по наблюдениям, главный вопрос менеджмента.
- Менеджеры верят, что если недовольным премией сотрудникам показать формулу расчета, то они поверят в справедливость и смирятся.
- Менеджеры любят цифры, только цифры их ненавидят.
- Буриданов осел. Много целей для проекта - то же. Не стесняйтесь ставить ОДНУ цель.
- АвтоВАЗ. Богаче комплектация - больше приключений! Кстати, их настоящий слоган.
- Ставьте цель. Например, скорость. Да, будут ныть про качество. Но реально я не видел ни одного удачного способа сделать быстро, принеся в жертву качество. Потому что чтобы быстро сделать проект - там надо мало багов и прочее.
- Менеджеры обожают графики больше, чем порнуху программисты.
- Картинка. Человек с завязанными глазами идет по граблям - общая причина. А если одна грабля с топором - там особая причина.
- Люди-снежинки. Руки из жопы. Дорофеев вместе с сыном - автор этой метафоры. Он - рисовал, сын - увидел и назвал.
- Если к людям относиться как к идиотам, они оправдывают ожидания.
- IT - единственная область, где с костылями мы только быстрее.
А еще - стоит отметить. что сложная тема была настолько хорошо изложена, что некоторым представлялась простой. Что снижало оценку доклада. Зато, наверное, повышает вероятность, что когда слушатель займется анализом каких-нибудь показателей он все это вспомнит. А ведь главное - именно это.
Алексей Харюков. Hack Days в рамках компании. Результаты эксперимента. Практический доклад. Как они устроили в компании Hack Days в мае и результаты превзошли ожидания. И они повторили в ноябре. Рамка: команде надо за краткое время (2 дня) выдать идею и с нуля сделать прототип. Они делали в выходные. Результат презентуем за 10 минут, голосование тайное по номинациям: Навороченность, Завершенность, Оригинальность, Лучшие презентации, Открытие HackDays, Best of the Best.
Участники: в первом 27 чел. 8 команд из 100, во втором - 40 чел 12 команд из 120 сотрудников из разных городов. Во втором участвовали дистанционно из штатов, невзирая на часовые пояса. Идею - подхватили. Сильно меняются представления о том, что можно сделать за два дня. А еще - были сделано два проект, которые будут пускать в промышленную разработку.
Понравилось и содержание доклада, и манера изложения и представления.
Дмитрий Башакин. Ситуационное управление или как правильно развивать ИТ-таланты. На этот полутора часовой доклад я заходил эпизодически несколько раз, потому что тема обучения развивалась крайне медленно, с большим количеством иллюстраций, на примере обучения сына езде на двухколесном велосипеде. Правда, лично я учил несколько по-другому, поэтому меня пример сбивал.
Но именно из этого доклада я вынес модель соответствия уровней обучаемого стилям обучения
- Уровни: Начинающий энтузиаст - Разочарованный новичок - Способный, но осторожный исполнитель - Профессионал.
- Стили обучения: Директивный - Наставничающий - Поддерживающий - Делегирующий
Правда, с уровнями - это умозрительная картинка, по-моему, которая реализуется далеко не для всех случаев, я имею ввиду стадию "Способный, но осторожный исполнитель". Ну и начинающий энтузиаст - это не всегда. И вообще, порядок другой может быть. Но, по-любому, правильно рефлексировать на тему соответствия своего поведения одному из стилей обучения и избегать переключать стили поведения в рамках одной коммуникации точно, и на кратких интервалах времени тоже.
Мария Бондаренко. Управление впечатлениями или как наладить контакт с клиентом. Мария в своем докладе говорила именно об эмоциональных впечатлениях клиента, а вовсе не ожиданиях. Рассказывала о модели Ожидания - Впечатления - Эмоциональный контакт - Доверие - Успех. Квадранты в осях Выполнено - НЕ выполнено; Ожидалось - НЕ ожидалось. Сознательная работа в этих квадрантах. На то, чтобы были точки "Не ожидалось, НО выполнено". Другое дело, что местами это манипуляция, и вопрос - насколько допустимо? А еще - нельзя с клиента требовать, чтобы он обязательно восхитился, тут риски. И нельзя, чтобы клиент привыкал. Об этом надо думать, но, в общем, это не повод для того, чтобы вообще отказываться от такого аспекта работы. А ряд вопросов задавали именно с таким настроем.
В докладе были практические советы, правда после такого уровня теории они для мной были восприняты как весьма поверхностные. Но это - мной, я не могу оценить, сколько человек на конфе восприняли их так, а для кого они были полезны. Впрочем, для себя я отметил идею подходящих визуальных фенечек в тех.доке - в xml-протоколе были тематические иконки по разделам протокола и статусы заказа в виде обезьянок.
Рекомендовала книги
- Джозеф Пайн "Экономика впечатлений."
- К.Сьюэлл "Клиенты на всю жизнь".
А еще был интересный эпизод, который стоит иметь ввиду, когда вы готовите доклад. При попытке выйти на интерактив, спросив о самых сильных эмоциях, и подсказке на экране, что речь пойдет о высоком качестве обслуживания - зал упорно говорил о впечатлениях от замечательной природы в горах. У докладчицы-то был кейс с личным опытом - гипермаркет на западе против советских магазинов западные отели и прочий культурный шок в первую поездку еще в школе. Но зал - он конкретно выдавал неправильный ответ. О возможной реакции зала надо думать, когда идешь на интерактив.
Николай Фролов. Gamification или Менеджмент 80го уровня. Доклад был признан лучшим на конференции. Актуальная тема, она интересует многих. Доклад был хорошо сделан. И был геймифицирован - в процессе доклада работал сайт, где сначала надо было регистрироваться и получать очки, а потом - задавать свои вопросы, на которые докладчик планировал отвечать в конце. Правда, оба раза сайт успевали сломать к тому моменту, как докладчик планировал использовать результаты.
Gamification - это проявление подходов и моделей, принятых при разработке компьютерных игр в реальном мире. Интересно, что сами подходы - во многом из реального мира пришли, еще из докомпьютерной эпохи - опыт организации деятельности бойскаутов и тому подобное.
Игра - идеальный менеджер: она дает конструктивную обратную связь, вовремя, на фактах, как исправить, положительную, с наградами, формируется поведение. Игра - реализация управления по целям. Игра спроектирована с учетом правильного роста и развития участника. Игра дает фан, при чем разных видов - чтобы вовлечь разные типы людей.
Только вот, по-моему, что реальный мир - это не игра ни разу. Поэтому мы имеем частное проявление старой идеи: пусть менеджеры как-нибудь экранируют реальный мир, чтобы программистам был фан. Было - через agile, сейчас - через gamification. И движение с двух сторон: программисты хотят фан, а менеджеры в очередной раз надеются на серебряную пулю, которая позволит простым образом заставлять программистов работать как одержимые. Я думаю, что ничего не получится - серебряной пули не существует. Но конкретные полезные средства и практики - безусловно появятся.
А еще в докладе шла речь про изменение культуры компании через игру. И рекомендации: нельзя переводить все в игру; не забывайте, что игра - дело добровольное и так далее. На мой взгляд - очевидные.
Алексей Курец. SAAS или «коробка»? Как мы делали революцию в бухгалтерском ПО. Алексей детально рассказывает свой процесс. Как есть. Он увлечен, строит продукт, процесс и команду, и увлеченно об этом рассказывает. Продукт - реализация бухгалтерии в облаке, и тут важна не только сама бухгалтерия, но и сопутствующее окружение - фишки на сайте, поддержка...
Я не могу сказать, что какие-то конкретные средства меня впечатлили и были открытием, они известны. Но я понимаю и эмоции рассказа - человек потому что когда выбираешь из большого множества имеющихся средств, объединяешь, и оно все вместе работает - это достижение. А еще - всегда полезно знать, какие тулы из множества имеющихся выбрали конкретные люди. Это в докладе тоже есть, по каждой задаче - online-консультант, email-поддежка, рассылки - есть список, а в докладе озвучено выбранное средство.
Павел Обод. Бизнес мышление у сотрудников IT сферы. Докладчик - увлеченный новым. Энтузиаст-новичок. Он сам это прошел и открыл, и несет в массы. При этом он - владелец небольшой компании. И честно признает, что у себя использует 15% рассказанного, но хочет - больше. А рассказ был про витамины Адизеса. И их мапинг на IT-роли в команде. И про непрерывное улучшение процесса. Про вебинары как инструмент.
С приличным количеством известных (мне) историй - про то, что некогда точить пилу, про решение задач со свечками (чем больше сумма, тем медленнее решали). Про культуру ошибок, о том, что американцы не боятся пробовать, хотя знают о возможном поражении, а наши- боятся. Но я лично думаю, что нет там особого различия: чиновники и бюрократы - везде боятся, а предприниматели - везде пробуют.
Было некоторое количество забавных тезисов.
- Процесс как ругаются программисты тоже можно улучшить.
- Ицхак Адизес в перепевке Панкратова.
- Когда дочка в три года плохо помыла посуду - вы же не будете ругать, а тихонько домоете. Так и с программистами - доделайте сами :)
А еще докладчик сказал, что результат каждой конференции надо обдумать в ближайшие 72 часа и решить, что применять на практике. И давал домашние задания - что стоит посмотреть, изучить, рассказать другим...
Валерий Бирин. Что тендер грядущий нам готовит Рассказ человека, который помогает заказчикам готовить тендеры. О правильных подходах и организации процесса, о том, как они к этому подходят. К сожалению, не попал в аудиторию: Заказчиков, которые готовят тендеры, тут нет, а разработчикам и менеджерам все-таки интересен взгляд на тендеры с другой позиции.
Сергей Бондаренко. Менеджеры хорошие и не очень – найдите 10 отличий. Сергей начал с того, чем отличается работа программиста от работы менеджера, а потом перешел к тому, как именно он менеджеров оценивает, рассказал о своих критериях. К сожалению, хорошо и структурно рассказать не получилось...
Владимир Горшунов. Смешиваем Scrum и Канбан Докладчик тролил аудиторию, а аудитория - наезжала на докладчика. Что оживляло, но особого интереса для меня - не добавляла. Потому что автор говорил о некотором виртуальном и жестком SCRUM, о котором думали, а на самом деле он не столь догматичен и его надо адаптировать под реалии, плюс местами упростить в сторону Канбан. Как пример такой псевдопроблемы: "Как заставить SCRUM работать, когда T&M а не Fixed - у нас же при этом нет Product Backlog". Я: T&M - это ж почти идеал. В общем, то на нынешнем этапе развития agile-практик мысль - очевидная. Но пока - не для всех, ибо лучшие практики развиваются быстрее, чем многие люди это воспринимают.
Виктория Придатко. Строгий и сердитый PM - не всегда приятно, но всегда полезно :) Очень динамичный и эмоциональной доклад HR о куче ее ошибок при взаимодействии с PM. К сожалению, большинство проблем сведено к различию между мужчиной и женщиной. А реально это не так. Более того, ряд ошибок, о которых шла речь в докладе совершают и мужчины. Они спокойно наступают на те же грабли. Что, конечно, не исключает различия психологии полов, но на эту тему есть куча книг, в основном по семейным отношениям, и если люди их налаживают (с книгами или без), то они и на работе это применяют, а если не налаживают, то доклад им все равно не поможет.
Константин Андрюнин. Продуктовый подход к разработке. На мой взгляд, доклад не получился. Потому что это на простом, доступном и сумбурном уровне то, о чем говорит Безуглый про разработку продукта. Но при этом - игнорируя ряд важных аспектов, увы.
На этом - все.
2012-11-17: SPMconf-2012 в Минске - день первый
Конференция SPMconf-2012 в Минске - ожидаемо хорошая. Это достаточно сложная конструкция, к хорошему ведь привыкаешь, и оно кажется не столь впечатляющим. Это как с отношениями с клиентами: если ты стабильно оправдываешь его ожидания, то он перестает испытывать тот восторг по этому поводу, который был вначале. Не потому, что стало хуже, а потому что привык. Так вот, с конференциями, которые проводит Влад Орликов - тоже самое, они ожидаемо, привычно хорошие.
На конференции - я выступал, рассказывал о модели командных ролей Белбина. В свое время мне эту книгу посоветовали, я прочел и проникся. Потому что это - качественная экспериментальная работа с командами, наблюдение за ними и выявление соответствия между позициями, которые занимают люди их умственно-психологическими характеристиками, определяемыми по тестам. И этим оно отличается от ряда других моделей, которые основаны больше на некоторой классификации деятельности, после чего заявляется: раз деятельность нужна - пусть ее выполняют. Здесь деятельность поделена и распределена не умозрительно, а на основе научно поставленных экспериментов и наблюдений. И, собственно, мне хотелось рассказать об этом людям, тем более, что модель применима для IT-команд и о ней явно пишет Йордан в "Смертельном марше". Если я вас заинтересовал - смотрите презентацию и доклад, а лучше - первоисточник, книги Белбина "Команды менеджеров. Как объяснить их успех или неудачу" и "Типы ролей в командах менеджеров".
После выступления посмотрел твиттер по своему докладу. Люди пишут заметки, как я на ноуте, только публично, в твите. Может, начать? Хотя резать на короткие сообщения - это очень сложно...
А теперь - обзор докладов первого дня, на которых я был. Начну с тех, которые больше понравились.
Безусловной звездой первого дня, по моему мнению, был Дима Безуглый. Сначала он экспромтом заменил заболевшую Наталью Руколь, прочитав доклад Кто такой менеджер продукта и что он может дать компании-разработчику. Содержание доклада сильно не соответствовало достаточно скучному названию, оно было гораздо шире и описывало роль и ответственность Product Manager и сопутствующие активности, много сопоставляло это с Project Manager'ом. Главное - что в продуктовой разработке классический треугольник Бюджет - Деньги - Сроки - сильно теряет значимость, хотя сами понятия остаются.
Важная мысль о грядущем принципиальном изменении рынка. Времена, когда каждый банк заказывал отдельную систему - давно прошли. Дорого и нерентабельно. Поэтому работу программиста - продает куча народа. Но, рынок мобильных устройств меняет ситуацию, потому что делаешь продукт на 0.5% рынка за 1$ - получаем огромные деньги.
Главный рынок для IT-компании - рынок рабочей силы. Если не найдешь персонал - вылетишь. Раньше разработчики гуляли между заказной (интересно) и внутренней (есть деньги) разработкой, все. А сейчас приходят продуктовые компании. Там хорошо с деньгами и неплохо с интересно. И они ломают рынок кардинально. Единственное, часть продуктовых компаний - они не разрабатывают сами. а заказывают разработку.
А после доклада Дима провел мастер-класс Тонкости проведения не технического интервью технического специалиста. Речь шла об интервью менеджером технического специалиста при приеме на работу. Замечательная смесь практической психологии, психолингвистики, компетенций Спенсера и многого другого в одном докладе. При том, что каждая тема - очень велика. Но Дима дает опорные точки, показвает как работает в комплексе. А если заинтересовало - копайте, изучайте. А еще - рассказывает как правильно нанимать на работу, если планируешь работать с человеком долго. Надо сопрягать базовые ценности - они не изменятся. А скилы - да, они важны, но их можно прокачать. Пересказывать - нереально, читайте, смотрите доклад.
Сергей Архипенков в своем докладе продолжал тему, которая у него звучит в последнее время. Начал он еще во вступительном слове на открытии конференции: "Программирование по ошибке отнесено к инженерной деятельности. У нас нет законов, нельзя доказать правильность. Разработка ПО - гуманитарная дисциплина, поэтому так сложно этим управлять и столько подходов." Я, правда, думаю, что он не прав - потому что так обстоит дело во всех областях, где много проектирования. А программирование - это именно проектирование.
В своем докладе Сергей собрал воедино известные мифы о программировании. В контрастном виде, очередной миф отвергает предыдущий. Правда, мифы - стары, и я лично не знаю, думает ли кто о них всерьез? Но, может, и есть такие динозавры... Но список - любопытен.
- Что разрабатывать просто, миф потому как много фейлов и нет уверенности результата.
- Что сложно. Потому что год поучил Java - и вполне способный программист. Не то, что в космической отрасли.
- Что разработка ПО прохожа на производство. Факт - разработка ПО это только проектирование. Говорит, что статистика по миру по НИР и ОКР примерно соответствует статистике Standish group по успеху программных проектов.
- Разработка ПО - инженерная дисциплина. Факт - гуманитарная. Я: он тут противоречит предыдущему факту. Ну или надо все НИР и НИОКР объявить гуманитарными.
- Говорит, что Коберн (Коуберн?) исследовал корреляцию между успехом проекта и применяемой методологии. Обнаружил, что корреляции нет.
- Миф. Разработку ПО можно ускорить.
- Реально есть формула расчета оптимальной длительности, и сократить можно только на 20% максимум.
- В ответах на вопросы он формулу продиктовал. Длительность проекта в месяцах = 2.5 * корень кубический из трудоемкости в человеко-месяцах.
- Миф. Проблему можно закидать денигами.
- Миф. Проблемы решаются процессом
- Миф. KPI мотивирует
- Миф. Работу программистов нельзя измерить.
- Миф. Незаминимых людей нет. Факт: есть цена замены. Выход нового - 2-12 месяцев. Цена замены порядка годовой зарплаты.
- Миф. Программисты антибюрократичны. Факт - они антиидиотичны.
- Миф о железном треугольнике. Опровергается разработкой Word :)
- Миф: программистами невозможно управлять. Факт - управлять можно, но не как МакДональдсом, а иначе.
Позитив. Правда тоже много известных тезисов.
- Теория W Барри-Боэма. Использовать теорию корпоративных игр с ненулевой суммой. Общение, взаимовыгодный процесс и взаимовыгодный продукт.
- Выбрать правильный продукт - тот что приносит 500% прибыли, а не 10%. Ссылка на Демарко. :) Я: это из серии, что правильный человек сидит на берегу и ждет, когда проплывет труп врага.
- Правильный персонал
- Маслоу в развитии. Первые 4 уровня - дефицитарные потребности, насыщенные на 80% они перестают интересовать. А потом, верхние, самореализация - идут бесконечно.
- Я: впрочем, тут вопрос сложный, есть противоречащие факты. Поэтому приходится объявлять тех, кто после удовлетворения не хочет самореализоваться недочеловеками. Но это сильно противоречит гуманистическим реалиям современного общества.
- Формула E=IQ*EQ*EQ и баян про IQ и EQ
- Эшби, Введение в кибернетику 1959. Для хорошего управления число состояний управляющего объекта должно быть не меньше количества состояний объекта управления. Я: следствие: население (государства), рассматриваемое как объект правления имеет очсень малое количество состояний.
- Цикл Наблюдать - Общаться - Анализировать - Синтезировать - Пробовать - Обобщать Я: сомнительно, если честно, что цикл такой.
Татьяна Белова. Как привести дела в порядок: применение методики GTD для менеджера проекта. Татьяна делилась своим практическим опытом использования GTD - она это делает уже два года, и именно этим доклад ценен. В докладе много вещей, знакомых из книги, но именно практический опыт - главное. И его я тезисно перечислю.
- Многие обламываются на внедрении сразу - не могут свести много своих списков в один. Не надо сразу. Главное - освободить голову от жужжания дел, а то, что в ежедневнике - не жужжит, его можно позднее перенести, работая пока на нескольких списках. Чтобы выписать все дела из головы, достаточно пары часов. Результат вас удивит - у нее получилось около 100 пунктов.
- Потом - сортировка на списки по Аллену и перенес в средство, где будем вести (если выписывали отдельно).
- А дальше - приучаем себя на регулярной основе совершать действия со списками.
- Раз в день, 10-20 минут, просмотреть список и выгрузить лишнее из головы. Она этим занимается в метро, по пути на работу и с работы. Еще иногда внутри дня выгрузку делает.
- Еженедельно - список отложенных и когда-нибудь. Вдруг пора переносить.
- Еще - приучила себя ловить идеи. Задачи - о них напомнят.
- Следующий этап, ТОЛЬКО когда предыдущий пройден, списки - ведутся и с ними работаешь. Тогда делаешь приоритеты, Напоминалки, делить списки по контекстам. У нее контексты конкретного человека - "заодно спросить, уточнить".
Грабли
- Есть грабли - начинаешь беспокоиться о системе дел. Постоянно. Это неправильно.
- Излишняя фокусировка на инструменте. Он должен быть удобным, но не должен брать много мыслей.
- Сложная система связей
- Внедрить сразу
- Два списка Рабочее/Личное
- Невнятная формулировка. Ловушка для тех. кто использует outlook - кидают письмо и не пишут. что по нему надо сделать. Надо писать, не не делают.
В докладе был краткий список инструментов. Она использует Remember The Milk. Плюс задачи из писем в течении дня - в Outlook. Но по концу дня - все переносится в Remember The Milk, послать можно Fwd письма.
Для идей использует EverNote, туда валится все, что хочет запомнить, но оно не является делом. Использует голосовые заметки - с телефона, когда засыпаешь. И фотки - когда увидел в книге - фотку, не переписываешь. Еще - голос с распознаванием, по-русски тоже работает. И можно сохранять документы и web-контекст.
Помимо прочего фиксация дел обеспечивает, что "если вы чего-то не делаете - вы точно знаете, что именно вы не делаете".
Алексей Кривицкий. Новейшая история менеджмента. От эры стагнации к периоду ренессанса. Доклад-объяснение для программистов, откуда вообще берутся менеджеры и почему, а не другие программисты управляют компаниями. Даже если компания выросла из маленькой, созданной программистами. Такая история развития, понятная, но упрощенная, местами сильно. С кейсами управленческих перегибов: "Есть проблема - назначим менеджера по ее решению, или отдел создадим". С афоризмами: "Даже если вы разрабатываете по agile, вам надо разрабатывать софт".
Любопытная моделька по видам управления.
- Поппендик: у каждого работника должно быть два менеджера: Профессор (do things right) и Предприниматель (do rights things).
- Product Owner = Product Manager. do rights things.
- do things right - команда, а для качества возникают менторы по ролевым специализациям (программирование, тестирование)
- А scrum master - это третье, сотрудничество, фасилитатор. Do things fast.
- Нужен баланс между всеми составляющими менеджмента. Если перекос к Предпринимателю - дерьмовый процесс и продукт, если к Профессору - хорошо делаем ненужное. И так далее.
Получился хороший рассказ как работает scrum of scrum и делится ответственность.
Интересно, что специализации менеджеров соответствуют корневым проблемам, как их выделяет Дениэль Пинк в книге Драйв или Мотивация 3.0.
- знание цели - PO
- автономность - SM
- мастерство - Mentor
Ирина Виноградова, Владимир Ли. Планируем релиз играючи. Игры не получилось, речь шла о средстве визуализации на Excel для планирования релизов, написанном под ту митодику, которая применяется в Касперском (оценка фич в разрезе ролей). Средство - хорошее и правильное, но игры - все-таки нет. А форма доклада - хорошая, местами как диалог между Product Manager и Project Manager + Team.
Александр Орлов, Слава Панкратов. Восприятие неконструктивной критики. Мастер-класс в большом зале на сотню с лишним человек. Через работу в парах, реально. Новые кейсы. Уважаю. Хотя Юра Юрченко сказал, что реальный Заказчик его троллил куда жестче, чем на тренинге, там очень интеллигентно было. Ну, не все ж с такими жесткими заказчиками работали.
2012-11-12: ReqLabs-2012 в Киеве
Конференция Req-Labs в Киеве прошла хорошо. Есть мелкие проблемы, которые я перечислю сразу - чтобы организаторы их учли, если прочтут мой отзыв. WiFi практически не работает, так что за докладчиков - я так и не голосовал. Залы - очень длинные и экран сзади видно плохо и мелко, можно, наверное, было попробовать повернуть расположение, повесив 2-3 экрана. А еще - не хватало указателей на улице к конференции для новичков в Киеве - в парк Пушкина в первый день и к нужной двери бизнес-центра во второй. А так - организация достойная. Два трека, большие перерывы для общения. Отдельный зал для общения с докладчиками, правда там было не слишком много народа.
А главное - достойное качество докладов. Много практических докладов, мало теоретиков. При этом, что характерно, эти авторы практических докладов теорию знают на высоком уровне. Поэтому рассказ практик идет в контексте современных теорий. Или наоборот, теории сильно иллюстрируются практиками. Что на современных конференциях встречается не так часто, как хотелось бы. О ценности докладов говорит то, что я очень много конспектировал на ноуте. Может быть, кончено, что я просто был на лучшей половине докладов. Но, с другой стороны, лучший по итогам голосования на facebook в день конференции докладе я пропустил. Это "Бизнес-аналитик или бизнес-синтетик? Или как сделать бизнес-анализ чуть менее унылым" Артёма Сердюка (ISM Ukraine, Украина), который шел параллельно с докладом Пола Тернера. Буду будет смотреть видео.
Что интересно - организаторы говорят, что при организации Конференции были воплощены многие идеи, высказанные участниками мозгового штурма на мастер-классе в рамках AnalystDays в Минске.
Дальше - краткий обзор докладов.
2012-11-03: SECR, день второй
Второй день SECR-2012 был не хуже первого, и это - очень радует. Я по прежнему ходил между 5 треками, чтобы охватить побольше докладов, хотя и не столь активно, как в первый день: наверное, устал. Были пересечения по интересным докладам, из-за которых несколько хороших докладов я точно пропустил. Кроме того, я не ходил на технологические доклады, близкие к железу, и на доклады по мобильным устройствам - потому что это - не мой профиль. А там тоже было много интересного. Так что не надо думать, что мои отчеты исчерпывающе описывают конференцию.
SECR уже второй год проводит голосование слушателей по докладам, ич ерез несколько дней результаты появятся на сайте конференции, и можно будет посмотреть на мнение участников о докладах. выбрать то, что интересует - и посмотреть презентации и записи, которые тоже появятся. В этом году запись проводил Стас Фомин, так что они будут качественные.
А еще - хорошо, что организаторы экспериментируют с новыми формами, было много дискуссионных сессий. Правда, на некоторых это было похоже на телеобсуждения - спикеры говорят общими фразами, а из зала идут общие вопросы, но других действительно получились дискуссии и обсуждения темы. Этот опыт показал, что нужна более жесткая модерация таких панелей, нужно направлять обсуждение, выводить его на конкретику и прерывать холиварные темы, по которым участники из зала почему-то непременно хотят высказаться, часто просто повторяя предыдущих, и надо жестко ограничивать время самих докладчиков, оставляя для обсуждения больше времени. Но, думаю, в следующем году эти уроки будут учтены.
После этого вступления - обзор докладов. Для начала - что мне особенно понравилось.
Практический опыт применения eye-tracking для оптимизации интерфейсов и сегментации аудитории. Сергей Котырев, Umisoft Любопытный доклад о практическом опыте - оценка usability сайта на основе движения глаз. при этом испытуемым давались конкретные задания, например, скачать демо-версию или добавить новость, а они сайт видели впервые. Из очень интересного - оказалось, что мужчины и женщины сильно по-разному себя ведут, если мужчины при скачивании демо сразу обнаруживали кнопку "Скачать" - (подсвеченную оранжевым, но в углу), то женщины уходили в описание функционала, и только там, другим путем доходили до скачивания демо. А про добавление новости - там была контринтуитивная засада, для появления этой функции надо было глобально перейти в режим редактирования, и эту кнопку находили не сразу. Но! когда ее просто контрастно подсветили черным вместо серого - время сократилось до приемлемого, так что даже при не слишком интуитивных решениях можно многого добиться простой работой с выделением элементов.
Взаимодействие с архитектором из команды заказчика: cвященная война? Александр Калугин, PMARCOR Доклады Александра я слышал несколько раз, у него интересные доклады. В этот раз у него был небольшой зал и активный интерактив с аудиторией - вопросы, фиксация вариантов на флип-чарте. Кейс - заказная разработка, небольшой проект, их привлекли не как ресурс, но и как опыт. И на стороне заказчика помимо менджера был архитектор, со своим видением задачи и своей активностью. В целом это встречается достаточно часто, у ситуации есть свои плюсы и минусы, которые надо представлять, чтобы воспользоваться плюсами, сгладив минусы. Если кратко, то плюс в том, что архитектор заказчика обычно источник хороших знаний о предприятии, что особенно важно при интеграции. что с ним можно обсуждать технические составляющие решения. А минусы - в том, что интересы архитектора и менеджера проекта не всегда совпадают, а архитектор тянет в свою сторону. И у него есть свои представления о хорошем решении, которые не всегда совпадают с тем, что предлагает компания-разработчик, и с этим надо работать.
Чего хотят Заказчики?… Или особенности национальных «внедрений». Валерий Бирин, IBA На большинстве проектов есть жесткая ситуация со сроками, бюджетом, ресурсами. И если Yordan в Death March видит в этом проблему, и говорит о выживании на таком проекте, то DeCarlo в eXtreme project management видит возможности. В любом случае, на таких проектах для успеха важна психологическая и коммуникативная составляющая, и направление потока мыслей и эмоций заказчика и команды.
И доклад - о тезисах, которые он зафиксировал для сотрудников из своего опыта. Тезисы, во многом очевидные. Но от того не стали не актуальными. И он довел их до уровня памятки.
- Все заказчики хотят чтобы проект прошел спокойно. Хотя тут я бы поспорил: заказчик он же не дурак, и часто понимает. что проект спокойно пройти не может потому что сроки и деньги. А если вдруг может - значит сроки и деньги можно уменьшить. То есть он готов к жесткому проекту, и встречаются менеджеры, которые от этого получают фан. Не от проблем, конечно, но от их решения.
- Нельзя говорить заказчику, что он тупой. В принципе.
- "Вы нас считаете дураками, как мы можем с вами работать?" Как реакция на фразу в пылу спора "Ну, наше же ПО - для умных людей"
- Нельзя оценивать своих программистов перед заказчиком - хорошие, плохие и прочее.
- Заказчики - ранимые. Нельзя показать его чувствовать как ребенка, который привлекает внимание.
- Нельзя: "Я не смогу сегодня поработать, потому что есть важная задача от другого клиента"
- Нельзя: "У вас должно работать так, потому что так работает у вашего конкурента"
- В обратную сторону - тоже нельзя. Нужно собственное достоинство.
- Заказчика надо активно информаировать - что для него сделано!
- Нельзя сильно приукрашивать - надо помнить, что за свои слова надо будет отвечать.
Практика - семинар в начале проекта про взаимоотношения с заказчиком.
Если есть вопросы и истории - пишите, я обязательно отвечу. Блог http://vbirin.blogspot.ru/ (правда, это я поискал, данные из презентации я не записал, но можно там посмотреть).
Обучение коду в мире онлайн. Бенджамин Б. Бедерсон, University of Maryland Рассказывал о современном дистанционном обучении. Его идеи и те изменения, которые оно вносит в процесс, например, возможность прервать урок и продолжить с места, перейти на другую тему при непонтках, быстро заполнить ответы - они понятны. Но при этом в целом происходит переход в другое качество, и это - правильно учитывать при создании программы.
А еще при обучении компьютеру дистанционное обучение с ильно меняет картину, ддавая такие возможности как live coding. И сейчас есть множество площадок для этого.
- khanacademy.org - Live Coding
- pthontutor.com - live diagramming
Ворчуны на проекте – положительные и отрицательные стороны. Как эффективно работать с такими людьми с учетом психологического климата в команде? Владимир Железняк, Дмитрий Снисар, IT-Boost.com Рассказ - case study. Психология по конкретному поводу. По делу, поскольку проблема распространенная - интересно. Ну и докладчик - говорит живо. Да, если бы психология входила в базовую вузовскую подготовку программистов и менеджеров, то такие доклады были бы не нужны. Но у нас же это не так, только ВШЭ пытается - о чем вчера рассказывала Елена Мандрикова.
И - остальные доклады.
Как реализовать себя на глобальном рынке? Александр (Sasha) Галицкий, Almaz Capital Partners Доклад открывал день, и начало диссонировало: "слайды просто картинки, я плохой докладчик". Но в целом доклад хороший.
О том, что мир сейчас глобальный, и надо настраивать себя на жизнь в нем, код перетекает в любое место. Прерогативы на изобретение нет, во всем мире многие изобретают и повторяются. Поэтому идея - ничего не стоит, стоит - реализация. Советская наука умела делать прототипы, единичные экземпляры, а это 20% затрат/усилий.
Работа - командная, надо работать на дело, а не на амбиции. А этого - часто не умеют. В России - особенно, и как пример - в Силиконовой долине не образовалось русского сообщества, в отличие от Ирландии или Китая. Как только маячат деньги - ругаются.
Инвесторы - это сервис, который помогает вам строить ваше дело. И ваша задача - своей активностью побудить его помогать вам.
Дальше были слайды о перспективных направлениях. которые они рассматривают. Их - реально много, поэтому интересующимся - надо будет смотреть презентацию.
Управление проектами 80-го уровня, или размер имеет значение! Возможности и ограничения применения статистических моделей для управления проектом. Юлиан Ларионов, Николай Сокорнов, Reksoft. В общем-то в докладе оставляет смутное впечатление. Идет некоторое наукообразие, для меня - очевидное, которое надо решать практически, а не заботится теорией. Понятно, что есть грабли, на которые не надо наступать. Но их надо предъявлять конкретно. А то доклад получается на том уровне абстракции, который не интересен совершенно. И это - обидно, потому что за докладом точно стоит практический опыт, который был бы интересен, даже если размер там не 80-й (это для меня когда сотни человеко-лет).
Моделирование и облачные вычисления. Ричард Соули, OMG Ричард выступал на SECR в 2010, о необходимости стандартов, осознанном еще в Балтиморском пожаре (1904) :) А теперь иллюстративный ряд теперь - на множестве электрических розеток и вилок. А множество usb-разъемов, питания для телефонов и ноутов, думаю, тоже нашло бы отклик.
В общем-то, тема доклада по-крупному не изменилась - о спецификациях, которые должны быть открыты, для которых существуют реализации, и которые контролируются некоммерческими организациями. Миссия OMG. Направления, в которых сейчас идет работа над стандартами. Но, к сожалению, на мой взгляд представлены списком, без подробностей. А мне по-прежнему хочется больше подробностей, не миссии - я ее и так понимаю, а конкретики переднего края. Правда, я ушел, до конца не дослушал, возможно дальше детали были...
Разработка распределенных отказоустойчивых систем на платформе Erlang. Андрей Смирнов, Николай Сокорнов, Reksoft В общем-то учебный доклад о реализации на Eglang конкретных шаблонов в асинхронной работе, распределенной между нодами. С диаграммами последовательностей, отражающими взаимодействие. Думаю, было интересно тем, кто начал работать с асинхронными системами, не только Eglang, чтобы перестроить свое мышление, это важно.
Дискуссионная секция. Инструменты оптимизации исходного кода программного обеспечения Это начиналась как активная дискуссия при переполненном зале, а потом постепенно сдулась :( Я заходил фрагментами. Было много по делу - о guideline, который способствует пониманию кода не только из-за единообразия, но и потому, что избавляя программистов от необходимости думать о деталях позволяет им больше думать об общей организации, и она становится лучше. О различных средствах, которые позволяют поддерживать соответствие guideline. Но были и холивары, участники из зала очень хотели высказать свои мнения, иногда - и научить в дидактическом стиле.
Дискуссия. Peopleware: какие навыки и квалификации требуются для создания идеальной команды программистов Очень напоминает TV-дискуссия. Общие вопросы, общие ответы. Вот, студенты хороши в науке, но непригодны к коммерческой разработке, что делать? Ответ - комбинировать, плюс сотрудничество, связи. Но вот что спрашивающий ожидал услышать? Но, надо отметить, ответы более профессиональные, с цифрами.
Все-таки форму тут надо искать. Потому что когда люди высказываются по поводу, каждый свою точку зрения - это почти ни о чем. Все же еще политкорректны. В принципе, для этой темы формат, можно сказать, напрашивался: нарисуйте эту команды в виде конкретных человечков, ее составляющих. И менеджера, который ее собирает.
О требованиях к средствам автоматизации приемочных тестов при использовании подхода «разработка, управляемая описанием поведения». Евгений Пышкин, Максим Мозговой, Михаил Глухих, СПбГПУ Доклад про BDD и полуавтоматическое построение тестов от сценариев поведения. Авторы провели сравнение различных средств по разным характеристикам, правда, больше по описаниям и материалам, а не практически. В этой области они новички, в чем сами признались, и целью было не только показать результаты, но и получить отклик от тех, кто использует, потому как раньше на SECR тема не поднималась. Зал - откликнулся. А сама тема - новая именно для SECR, на профильной конференции SQA days про тесты от BDD я слышал в нескольких докладах.
Эволюция процессных и продуктовых метрик на основе информационных потребностей. Сенклер Якин, STM В целом доклад про эволюцию метрик в контексте развития официальных методологий. Начинали они с формальной системы, как она есть в CMMI, и там возникали искуственные бизнес-цели, а самих метрик было очень много, 52. И они эту систему творчески переработали, проведя трассировку от реальных бизнес-целей с видоизменением метрик, и выкинули много ненужного. На слайдах были примеры конкретных преобразований и они любопытны. Однако, новые метрики получались более сложные и запутанные, хотя и лучше соответствуют целям. И, что важно, дают лучшие показатели при том же процессе.
Автоматизация миграции динамически формируемых запросов. Семён Григорьев, Яков Кириленко, LANIT-TERCOM Я слушал небольшой кусочек в конце - потому что был на других докладах, так что, возможно, недооцениваю доклад. И, по-моему, я это слышал, хотя, может от другой фирмы. Перенос MS SQL -> Oracle, в системе много кода, который вызывает SQL, а запросы строятся по-разному. При этом надо было встроиться на уровень обращений к БД, не трогая коды системы (как я понял). Идея - интересная, автоматизированное преобразование, половину удалось перевести автоматом, в остальных автомат дает хорошую обертку, даже если сам запрос преобразовать не получается. И там приходится конвертировать уже сформированный запрос динамически. Реализация - порядка 20К на F#. И получился хороший рабочий результат, хотя с формальной точки зрения безошибочность гарантировать и нельзя. Подход в принципе может быть применен не только для SQL, но и для разных DSL, генерации HTML и т.п., m4, eval jscript.
Дискуссия. Сохранится ли профессия программиста? Это была определенная разрядка в конце конференции. Тем более, что на сцене были люди существенно разных взглядов. Андрей Терехов отстаивал профессию системного программиста, которому требуется хорошее базовое образование, знание алгоритмики и математики, а Стас Фомин, наоборот, говорил о том, что эти знания бессмысленны для основной массы программистов. С чем, кстати, были согласны многие, хотя и не столь явно. Были предложения посмотреть на развитие hardware - не того, которое компьютеры, а того, которое скобяные изделия - где основное производство ушло в программистов и наладчиков станков с ЧПУ, а люди с напильниками остались фрагментарно. Хотя мне эта аналогия кажется сомнительной.
Интересна классификация программистов, как это видит Павел Ходалев из Deutsche Bank
- Яйцеголовые (у них - в inhouse)
- те кто им снаряды подносят;
- Commodity
- Support
Между первыми двумя и вторыми двумя - колебания, перераспределение ответственности туда-сюда, каких-то длительных изменений - невидно.
Классификация от Стаса:
- при харде - будет жить (драйверы и т.п.)
- комп-общество (финансы и т.п.) - будет жить
- комп-человек - интерфейс, usability, тоже будут жить
- системные программисты - фреймворки, языки, параллельность - тоже, наверное, будут жить, хотя есть сомнения.
На этом я закончу отчет о впечатлениях. С надеждой, что в будущем году конференция будет не хуже, а еще лучше. Как участник Програмного комитета я буду этому всячески способствовать.
2012-11-01: SECR, день первый
Первый день SECR. Конференция - очень живая, народа много больше чем в прошлом году, и в фойе идет постоянное общение. И при этом параллельно идет 5 треков. Конференция определенно удалась, хотя лично для меня открытий пока не было. Но при этом многие доклады я слушал фрагментарно, желая охватить как можно больше.
Нескромно начну с доклада от нашей компании Трансформируем автоформы в качественный интерфейс с помощью DSL. Иван Гаммель, CUSTIS. Предметом был достаточно оригинальный подход к построению интерфейсов, промежуточный между автоформами и ручным созданием: сначала порождаем автоформу на основе метаданных. которые и так обычно имеются, например, за счет применения ORM, а затем - трансформируем ее к хорошему виду с помощью DSL. Автоформа порождается в динамике, поэтому если модель изменилась - то изменения подхватятся автоматом, править надо будет только тогда, когда изменения затронут модифицированную вручную часть. Зал - слушал с интересом. Несмотря на накладку с головным микрофоном - докладчик не смог одеть, он не налез, и пришлось держать в руках - звук был очень тихий.
Новые языки программирования для JVM: Kotlin и не только. Светлана Исакова, JetBrains - самый яркий доклад первого дня. Вообще про Kotlin я слушал на ADD-2012, так что идеи мне известны. Но они интересны, так что я пришел послушать- и не ушел. Сначала смутила эмоциональность, она внушила ложное впечатление поверхностности доклада. Но оно быстро ушло - рассказ был хороший, структурированный. А языки, о которых шла речь - докладчица знала хорошо и уверенно отвечала на сложные и с подколками опросы зала.
А сама идея Kotlin - это язык для индустриальной разработки на Java-платформе, включающий все преимущества, которые появились в современных языках (C#, Scala и др), и которые в Java отсутствуют. Нацеленный на легкость чтения кода, потому что при коллективной многолетней разработке код больше читаешь, чем пишешь, при чем это чужой код. Полностью совместимый с Java и JDK в обе стороны - чтобы на нем можно было писать новые функциональные куски в старых проектах. Но обладающей отличающейся системой базовых типов, исправляющей косяки Java, например, решающий проблему null pointer и неизменяемых коллекций на уровне статического контроля.
В докладе не только рассказывали про Kotlin, но и сравнивали с альтернативами - Java8, Groovy, .xtext, Ceylon, Scala. Собственно там и было много вопросов, и ответы были - со знанием фактуры и деталей, свидетельствующие о профессионализме.
Язык доступен в OpenSource как prerelease, JetBrains планирует сначала использовать внутри, а потом выкладывать 1.0, но даже внутреннее использование пока не началось, увы. Ждем.
Интересные доклады
В первой половине дня очень большой интерес вызвали доклады про Agile, они были в переполненном зале, правда не самом большом - тот в это время почти пустовал, это не угадали с интересом с докладом, быть может, считая что тема agile - поднадоела. Так вот, это не так. Доклады:
- Epic перехода к Agile. Павел Ходалев, Deutsche Bank
- SCRUM vs. СКРАМ. Как вести Scrum-проекты с российскими заказчиками? Илья Блаер, First Line Software
Оба доклада - не теория и описание общих схем. В них - практика из больших компаний, которые выстроили адаптированный agile для в своей работы. Это доклады не для новичков, а для зрелого применения. Докладчики делятся своим опытом, и это - очень востребовано аудиторией.
Павел Ходалев в своем докладе ответил на основной вопрос - зачем он внедряет agile. Главная причина - он так сокращает свои издержки как менеджера. Ему важна прозрачность работы команды, а agile ее дает. А еще - руководители команд рассказывают ему о проблемах, и он по опыту знает, что многие из них решаются внедрением определенных agile-практик - и советует их руководителем команды. В вопросах спрашивали, есть ли у него в подчинении не agile-команды. а, например, waterfall. Ответ - есть, и они требуют очень много его времени, он много с ними общается, чтобы понять, что все-таки там происходит. А идеи распространяются быстро, как вирус. Но внедряются тяжеловато. Процесс идет, Epic - не зря, еще года на три по его оценкам.
Илья Блаер рассказывал, как быть с теми проектами, которые по отношению заказчика и процедуре не являются agile - тендеры, документация, ГОСТ и так далее. Практики - в принципе известны, proxy product owner и другие, и докладчик говорил о конкретных вариантах применения. Важно, что First Line Software - применяет agile на таких проектах, его преимущества больше, чем дополнительная работа по адаптации.
Стратегия Agile-трансформации крупных организаций. Асхат Уразбаев, ScrumTrek Последние доклады Асхата - просветительские, но не обучающие, а побуждающие найти информацию самому. Он рассказывает истории и примеры, и при этом дает ссылки на и ключевые слова, а дальше - можно самому изучать. Мне такой подход импонирует.
В этот раз Асхат рассказывал про шаблон менеджерского решения проблемы через усиление ответственность. Для этого - назначить ответственного. На стыках ответственности - назначить своих ответственных. Число ответственных растет, так что реально задача не решается.
А как решение - были отсылки на Модель Коттера. А еще - на способы проявления проблем, на управление через ограничения, а не через задания. На организацию мероприятий по улучшению через Inpediment Backlog. И так далее.
Еще важная идея - про культуры (control, collaboration, cultivation, competence). Реально культура должна быть сбалансирована. Agile тяготеет к collaboration и cultivation потому что их не хватает крупным организациям. Но чрезмерно - тоже вредно. И надо правильно заходить, например, если control-культура, то стоит говорить про burndown chart, как инструмент этого, а collaboration - оно само появится из соответствующих практик, его не надо продавать.
В конце, естественно. был вопрос, когда Agile вреден. Так вот, он вреден когда результат не нужен, а надо освоить бюджет. Ну и потом в фойе Асхат больше полутора часов отвечал на вопросы.
Эффективная разработка сложных облачных бизнес-приложений. Михаил Щелконогов, Acumatica. Интересный доклад, жаль что я пришел в самом конце. О разработке платформы для облачных enterprise-приложений, поверх MS. С девизом: используйте только базовый уровень библиотек, всю надстройку типа MVC - делайте сами. Иначе с очередного релиза у вас все рассыпется. Выбрали MS потому что там уровень ядра - развивается согласованно и централизованно, в отличие от Java, где пришлось бы использовать библиотеки от нескольких вендоров, и они бы рассыпались с новыми версиями. Сторонние библиотеки - не запрещены, но не в ядре, а в функционально изолированных фрагментах. например, построение графиков - они перешли уже на третью библиотеку, и без проблем. В целом обеспечить устойчивость им удалось.
Организационная метрическая программа: Как избежать измерения среднего цвета фруктов. Елена Беляева, Александр Бабкин, Motorola Mobilitу. Хороший доклад, в отличие от вчерашнего рассказа Кертиса про метрики - современно и по делу. Про то, как строили систему метрик, пригодную для весьма разнородных проектов Моторолы. Пока делили по типу проектов - число метрик сильно возрастало. Поэтому они перестали сравнивать проекты по типам. Выделили активности в проектах по типам деятельности, например, разработка фич или тестов; Запуск тестирования; Автоматизация тестирования; Bug fix; SCRUM как отдельный вид проектов :) И для каждой активности - использовали свой базовый набор метрик. Если активностей в проекте несколько -применяют все метрики. От базового набора - можно расширяться. Если базовый набор нельзя собрать (например, доисторический трекер) - обоснуйте. Надо будет посмотреть слайд с примерами метрик - на предмет идей практического применения у себя.
Размышления о программировании: от Аристотеля к Витгенштейну. Сергей Архипенков, Гильдия менеджеров программных проектов. Я слушал только конец - потому что был на рассказе про метрики в Мотороле. Сергей говорил о том, что ООП - он концептуально моделирует мир статических объектов Аристотеля, и этим ограничен. А правильно использовать более сложные концепции, в частности онтологию Витгенштейна. В целом идея понятна, о движении от объектных подходов много пишет пишет Левенчук, правда он опирается на более современные конструкции - ISO 15926 с факт-ориентированным описанием мира, современные направления лингвистики и философии, работающие в практической плоскости, для примера можно почитать это. Но у Сергея все это - гораздо более приземленно на программистские реалии, и в целом - более понятно.
Оптимизация защиты изобретений в программных продуктах. Дмитрий Платонов, Центр Интеллектуальной Собственности «Сколково» Неожиданно для меня, весьма содержательный доклад о патентной защите программных продуктов и связанных проблемах. Много конкретики и историй, хотя и зарубежных - но я только кусочек слушал. Полный зал, хотя и небольшой.
И кратко про остальные доклады, которые я слышал. Докладчикам же интересна обратная связь :)
Разработка ПО как бизнес — прошлое, настоящее, будущее. Аркадий Добкин, EPAM Systems. Вступительный доклад на открытие конференции. Это мог быть замечательный доклад. Но не получилось, сначала было слишком много цифр и статистики, причем не впечатляющей (6% роста отрасли - о чем оно), потом был рассказ про историю компании, это было веселее и более содержательно.
Отсылка к книге Yordan Decline and Fall of the American Programmers - которая подтвердила решение делать собственную компанию - очень интересно. Потому что это частный случай концепции посткапитализма, как общества, в котором конкурентное преимущество Запада обеспечивается знаниями, которые невозможно скопировать, об этом рассказывал Рон Янг на KMRussia-2011 (мой отчет). Думаю, надо будет почитать.
500-700 человеко-лет, вложенных в собственную экосистему - впечатляет.
Но все-таки, рассказ был не слишком системным. Я уверен, что тот же материал можно было подать гораздо лучше. Отдельных фактов.
Борьба за микросекунды. Дмитрий Труб, Deutsche Bank. Разочаровал. В 2010 на банковском дне SECR я слушал доклад Алексея Сприжицкого на эту тему. там было хорошее сочетание достижений и технологических аспектов, которыми это обеспечивалось. У Дмитрия технологий не было совсем, а без них достижения - не слишком интересны.
Прототипирование финансовой системы рассуждений для принятия решения о выдаче кредита. Юрген Хёнигл, JKU. Идея - понятна, выдавать решения на основе предыдущих кейсов. При этом используется открытый движок Waikato Environment for Knoledge Analisys? и это - тоже интересно. Но пока все это - лишь прототип.
Аналитический модуль автоматизированной системы управления инкассации коммерческого банка. Иван Кауров, DeCoSp LLC - реально только пополнение банкоматов. Уже вроде достаточно проработанная система, но пока - тоже не внедрена, и конкретного заказчика - нет. А идея сама по себе не слишком сложная - взять прогнозы, учесть остатки.
Командная разработка современных приложений с Visual Studio 2012. Александр Яковлев, Microsoft. Практически демонстрация TFS, в общем-то для новичков. Таковых среди слушателей было много, так что доклад, думаю, востребован. А я - так, зашел в серединке.
Взгляд со стороны на проблемы интеграции ПО в Банковском секторе. Александр Аристов, Auriga. Тоже кусочек. Понятный доклад об особенностях банковской разработки, взаимодействия с заказчиком - не только про интеграцию. Я это знаю, мы с банками работаем, но тем. кто не работает - наверное, интересно. В противоположность Дойчу, у Auriga нет SCRUM, XP и другим экспериментам. Промежуточные демоснтрации рулят, а остальное заказчик не понимает.
Круглый стол по электронной коммерции. Модератор: Адриан Хенни, EWDN Получилось кисло. Статистика, с повторениями - в стиле западного телевидиния для тупых :) Про великие перспективы российского рынка. Они - есть.
Мобильный банкинг — наступившее будущее банковских услуг. Дмитрий Лозенко, Auriga. По контрасту с круглым столом - куда более содержательно. И кроме статистики - пошли реальные скриншоты, отражающие развитие sms-банкинга с увеличением функционала и сложности по мере развития самих телефонов.
Поставка решений по дисциплинированному Agile в двух словах. Марк Лайнс, Scott W. Ambler + Associates. Рассказ - по книге Disciplined Agile Delivery, некоторая комбинация разных методов, ничего существнно нового. И мне - не понравилось, потому как теория - она известна, а сам рассказ - длинный на каждом слайде, не впечатляет совершенно, увы.
Однозначная интерпретация JSON. Милослав Средков, Sofia University JSON становится более и более популярным - много лучше XML. Но с ним есть неоднозначности по реализации. Они проанализировали спектр реализаций, и дают результаты, в том числе - выделили некоторое ядро. Вообще это забавная гримаса современного мира - ученые начинают изучать артефакты программирвоания подобно тому. как раньше изучали объекты неживого мира.
Круглый стол Российские компании-разработчики ПО в свете мировых трендов ИТ-рынка Интересно, потому что участники - руководители ведущих компаний. Но мутно, они были не слишком готовы к обсуждению темы.
Психологическая подготовка программных инженеров: миф или реальность? Елена Мандрикова, ВШЭ Рассказ о курсе ВШЭ, где они преподают программистам психологию. Там индивидуальная психология, взаимодействие, организационная психология. Учат анализировать фильмы, видеть в них шаблоны поведения, конструктивно давать обратную связь и так далее. На западе - есть, норма. У нас - они первые, и они - молодцы. Но как доклад - оно мне показалось не очень интересным.
2012-10-31: SECR, курс Билла Кертиса
Сегодня прошел день тренингов на SECR-2012 и я был на курсе Билла Кертиса "Современные методы измерения программных продуктов и процессов разработки ПО". Я пошел не него, потому как различные метрики для отражения хода разработки активно применяются сейчас и реально обеспечивают эффективность. Об этом рассказывают практики, в качестве примера можно привести доклад Максима Кузькина из Parallels Использование метрик в разработке ПО на прошлом SECR. B хотелось узнать, что думает по этому поводу современная наука.
К сожалению, меня ждало большое разочарование. Потому что рассказ был совсем не о современных методах измерения, а о классике времен становления CMMI, 90-х годах уже прошлого века. И основной массив графиков и историй был из той эпохи, когда была надежда обеспечить предсказуемость процесса разработки и успех проектов за счет регламентных процедур. включая различные измерения. Реальный результат, который был достигнут в то время - это осознание необходимости различных практик раннего обнаружения дефектов в виде проверки требований, design review, code review, раннего тестирования и многих подобных. Раннее обнаружение дефектов было показателем хорошего процесса. А метрики - ориентированы на мониторинг этого, включая сравнение различных проектов - для чего применяется нормировка по числу строк или другому измерению размера проекта.
Под это тогда была разработана определенная теория. А дальше она - законсервировалась, принимая новые понятия, методики и подходы разработки исключительно с целью обеспечить свое псевдосовременное брендирование. Поэтому число use case, story point, functional point - это просто альтернативные способы изменения размера, и вы можете мерить в них, а не в килостроках. А Lean - ну это процесс непрерывного мониторинга показателей (мы всегда говорили, что это нужно!), и их улучшения. И Lean излагается со ссылкой на книгу Поппендик (2007) и иллюстрируется графиками 1995 года. А Agile - это просто когда проект состоит из итераций, каждая из которых - отдельный проект. Список можно продолжать. При таком подходе новые идеи - неизбежно упрощаются и выхолащиваются, увы.
Надо отметить, что это - системная проблема, присущая части современной IT-отрасли, связанной со всякой стандартизацией и сертификацией. Достаточно почитать SWEBOK 3 версии (2004) и PMBOK 4 версии (2008), которые формально вписали agile в старый водопадный процесс, без реального согласования коротких итераций, практически непрерывности процесса, со старыми фазами. Кстати. у Билла на слайдах agile culture - это CMMI-5. Биллу задавали вопросы о том, изменилось ли что в мире, почему графики и примеры столь старые. В его мире - не изменилось.
А если подняться еще на один уровень, то этот процесс показывает проблемы глобальной бюрократизации общества. которая способствует образованию подобных регламентных наростов. Потому что институты, созданные в то время и в рамках той парадигмы - они продолжают существовать и имитируют развитие. При том что начальные идеи - были безусловно правильными и хорошими. Более того, большинство практик - восприняты в Agile и активно используются. Только метрики совсем другие: agile, объединив фазы и добавив принципы непрерывного рефакторинга, по-сути, уничтожил старое понятие re-work, сделав его слабо отлдичимым от work, основной работы.
Это же относится к статическому анализу кода, который измеряет интеллектуальная тула CAST (где Билл - Chief Scientist). Она анализирует код почти на любой платформе и ищет дефекты. Только, опять-таки, эти дефекты - из прошлого: buffer overflow, sql injection и подобные. Не в том смысле, что в современных разработках они не встречаются, а в том смысле, что сейчас их надо не измерять, а устранять, и там, где для этого есть желание - этот процесс организуют. Плюс современные платформы и фреймворки - просто обеспечивают на базовом уровне, в них проблемы статического анализа и сложности кода возникают совершенно на другом уровне - сложные generic-классы, лямбда-выражения с замыканием и тому подобное. B вокруг этого - разрабатываются современные средства, хотя они - четко не успевают за развитием мультипарадигмальных языков.
Однако, такие мероприятия напоминают нам о реальном мире и отличительных особенностях его устройства, в частности бюрократизации. Кроме того, из подобных обзорных докладов можно извлечь пользу в части взаимоотношений с бюрократизированной частью мира, особенно выступающей в роли заказчиков - крупных государственных или коммерческих структур. Например, продажа рефакторинга и реинжиниринга, который вроде как не имеет business value. На самом деле, в этом случае имеет место быть Real Option Valuation: вложи сейчас 100 рублей, чтобы не вкладывать через год 300. Правда. 300 еще надо показать, но это уже ловкость рук и никакого мошенничества :) Или метафора технического долга (technical debt) - способ объяснить менеджерам и финансистам, почему низкое качество кода является проблемой, подлежащей решению путем рефакторинга и реинжиниринга.
А еще - широкий и относительно плотный обзор на высоком уровне даже не концепций, а ключевых слов, мемов в их взаимосвязи - является полезным. Он добавляет в твой арсенал те концепции и ключевые фразы, которых там, возможно. раньше не было, например, концепцию Application Health, которая дополняет (должна дополнять) концепцию Business Value, и объясняет, почему работа над качеством - вовсе не waste и muda, а необходимая и полезная деятельность. На сей позитивной ноте я закончу свои впечатления о курсе.
2012-10-12: Гики и Менеджеры
Поднятый недавно пост Стаса Блог:Стас Фомин/2010-07-02 Бибичев жжот! (Стас туда дописал ссылки и он поднялся в вики-форуме) навел меня на забавную аналогию. Взаимоотношения гиков и менеджеров напомнили мне взаимоотношения певцов (музыкантов) и их продюсеров. И певцы и гики отличаются коммуникативными особенностями разной степени, с которыми менеджерам и продюсерам надо работать. А еще - отличаются талантом, который, собственно, и обуславливает стремление менеджеров с ними работать, не смотря на эти особенности. А дальше - понятно, что продюсер (менеджер) делает многокритериальный выбор. Учитывая талант и потенциальную выгоду, учитывая свои накладные расходы, учитывая возможность получения аналогичного результата от менее талантливых, зато менее особенных творческих людей.
Интересно, что в масс-культуре многие менеджеры пошли по пути явного предпочтения исполнителей с почти полным отсутствием таланта, зато покладистых, ибо понимают свою заменяемость. Раскручивают их пиаром и делают свои деньги. Первая аналогичная попытка в мире программистов провалилась - это был unify process и иже с ними, попытка получения гарантированного результата без особого влияния кадров. А вот вторая попытка, на agile-технологиях, похоже рискует оказаться удачной. Тем не менее, наличие таланта и способностей продолжает оставаться важным.
При этом, что интересно, в интересах менеджеров как социальной группы - пествовать такой образ исполнителей (певцов или гиков), который даст им возможность зарабатывать на их труде, поощряя и сохраняя коммуникативные проблемы до такой степени, чтобы соорганизоваться и самостоятельно продюссировать себя они не могли. И пиар-способом гнобить талантливых и вменяемых лиц, которые-таки смогли обойтись без менеджеров - потому что они составляют прямую конкуренцию. Что, впрочем, не исключает альтернативных способов донесения своего результата до людей - через интернет это достаточно просто, только денег там в среднем существенно меньше, хотя отдельные большие успехи безусловно имеются.
Какая-то такая конструкция получается...
А еще - каждый разработчик (как и любой человек) может сам выбирать, в какую сторону ему двигаться, как взаимодействовать с окружающим миром и какие свои стороны развивать. В наш век управления через мемы и масс-культуру самостоятельный и разумный выбор становится более важным, чем раньше, и пока этот тренд будет лишь нарастать.
2012-10-06: Пока мы наступаем, Microsoft меняет рельеф местности
В пятницу Microsoft проводил P&P Summit, посвященный разработке под Windows8, а накануне прошло заседание клуба IT-директоров по разработке, на котором также участвовали докладчики P&P от Microsoft - Эухиньйо Паче, Кристофер Бенаж, Блейн Вастелл. Впечатления от обоих событий я расскажу в этом посте.
Тема для заседания клуба директоров была обозначена как "эффективная и качественная разработка: использование формальных и гибких методов". Но на самом заседании речь шла о гибких методах, потому что, как выяснилось из опроса, формальные методологии не то, чтобы не пользуются популярностью, по ним ведут лишь отдельные проекты в паре организаций, объясняя причины для этого. И это интересно, особенно потому что в клубе принимает участие много inhouse-разработчиков, которая не стремиться к погоне за модой. Таким образом, agile, как процесс разработки - победил окончательно. И на встрече говорили больше о комбинации тех или иных практик agile для достижения результата, о преодолении конкретных трудностей. В целом формат этих встреч - ответы на вопросы, предложенные самими участниками. Ведущим был Асхат Уразбаев, который отвечал на вопросы, но его активно дополняли из зала.
А, кроме того, и это, на мой взгляд, самое ценное - в беседе участвовали докладчики из Microsoft, которые делились устройством разработки и практиками у них внутри. У них - agile и он разнообразен, и ответы были достаточно конкретными, с подробностями как вариаций практик, так и основаниями для этого. А посмотреть внутрь ведущей компании - это очень интересно и полезно. И, надо сказать, MS расценивает agile как средство обеспечения быстрой и качественной разработки, и ставит перед собой амбициозные задачи, исходя из этого. На будущий год эта задача - перейти от 2-летних релизов Visual Studio к квартальным, и она поставлена достаточно конкретно, в виде roadmap проектов - их на следующий день показывал Эухиньйо Паче на пленарном заседании.
И, собственно, тут мы вплотную переходим к теме поста, вынесенной в заголовок - как меняется рельеф IT-отрасли. А меняется он следующим образом. MS практически одновременно запускает два существенных изменения.
Во-первых, это VS ultimate с многочисленными архитектурными средствами проективрования и, что важно, средствами контроля за соблюдением этой архитектуры. А также средствами трассировки архитектурных артефактов в work items, что позволяет прослеживать их реализацию, а потом - позволяет найти соответствующий им код. Об этом рассказывали на прошлом заседании клуба директоров и были доклады на P&P. Конечно, VS ultimate стоит бешеных денег (300К рублей за 1 лицензию). Но, она не нужна всем - только архитекторам, а, по моим ощущениям, средства, заложенные в нее позволяют одному архитектору успешно контролировать разработку достаточно больших проектов, группой 30-40 человек, и если рассматривать стоимость в этом контексте, то она уже не выглядит запредельной. Кроме того, при успешном применении может существенно повысится эффективность разработки и снизится требования к квалификации части исполнителей.
Правда, следует подчеркнуть важную оговорку - VS ultimate лишь может это сделать, а вовсе не обязательно сделает - потому что дальше вопрос применения, организации процесса и разделения ответственности, которое заведомо представляет собой непростую задачу. Это - лишь средство, а не серебряная пуля. Тем не менее, MS играет всерьез и в июне получил первое место в магическом квадрате Гартнера для ALM-приложений, оттеснив с него IBM с линейкой Rational.
И, надо отметить, что MS в своей разработке эти средства применяет. А значит - они будут совершенствоваться. Надо сказать, что летом я попробовал посмотреть через призму этих средств на код наших существующих проектов. И обнаружил, в общем-то ожидаемо, что многие сложные конструкции языка не слишком хорошо пригодны для анализа, в частности лямбда-выражения, особенно с замыканием, и сложные генерики. Технически это понятно - они реализуются через анонимные классы, которые оказываются подвешенными в воздухе, не принадлежа конкретным архитектурным артефактам. Мне было интересно, как живет с этим Microsoft, и Эухиньйо Паче ответил, что применение подобных конструкций при разработке - вопрос guideline по кодированию, который ограничивает их использование, если оно делает код не пригодным для статического анализа в необходимом объеме. Так что надо понимать, что эффективное использование архитектурных возможностей VS потребует ограничения в части используемых языковых конструкций.
Второе принципиальное изменение местности, которое стоит на пороге - это сам Windows8. Здесь, помимо многочисленных технических докладов P&P о различных аспектах разработки, надо отметить доклад Константина Кичинского "Шаблоны дизайна новых типов приложений", в котором были не только общие положения, но и примеры, хотя не так много, как хотелось бы. А пример, если он противоречит тому, как ты каждый день поступаешь - хороший побудительный мотив для изменения мышления, в отличие от общих положений, с которыми куда легче прийти к согласию. Так вот, принципиальное изменение hardware состоит в том, что сейчас имеется непрерывная линейка устройств с диапазоном экрана от 5 до 30 дюймов, при этом больших экранов может быть несколько: смартфоны, планшеты, нетбуки, ноутбуки, десктопы. И эта линейка плохо кластеризуется, она непрерывна - шаг размеров экрана 1-2 дюйма, возможности тоже нарастают постепенно, просматривать почту, документы, интернет можно почти на всех, и с тем или иным удобством можно редактировать, использовать офисные приложения. И, самое главное, один человек в течении дня переключается между устройствами: на основном месте работает на десктопе или ноуте с подключенным большим экраном или без него, на совещание берет маленький ноут или планшет, где-то пользуется смартфоном - и набор любимых устройств у разных людей тоже различается. Все эти конструкции освоены не только IT-шниками, менеджеры всех уровней, включая топов, тоже ими пользуются. И потому задача разработки корпоративных приложений, создания корпоративного IT-ландшафта предприятия, способного успешно работать в столь гетерогенной среде, становится все более востребованной.
И MS в Windows8 делает два шага в этом направлении. Он радикально меняет шаблон приложения, переходя от классических десктоп-приложений к web-образной верстке, включая горизонтальные перемещения и многие наработки, примененные сейчас в планшетах. А, вдобавок, он, по-сути, объединяет web и desktop разработку, позволяя разрабатывать desktop приложения на HTML5 и JScript. При этом, пока ты используешь его шаблоны, библиотеки и следуешь его guideline, ты можешь быть уверен, что твои приложения будут более-менее адекватно работать на всей линейке устройств, пусть под Windows8, независимо от управления тачскрином с жестами, мышью, клавиатурой, документы и формы можно будет напечатать и так далее. Да, нестандартные решения будет сделать сложно, guideline наверняка будут жить и меняться, и в новой версии best practice может таковым не оказаться - но это нормальная жизнь. Зато ты получаешь достаточно много типовых решений с низким порогом входа, включая достаточно сложные конструкции, типа асинхронных решений, провязываемых в цепочку вызовов. Докладчики из MS показывали это в течении всей конференции, демонстрируя много примеров кода.
Надо отметить, что последние несколько лет отрасли прошли под знаком интенсивного развития web-разработки. И достижением были не только крупные проекты, но и повсеместная разработка, включая достаточно сложные заказные сайты. Это в целом научились делать быстро, дешево и удовлетворяя потребности клиента. И реализация в Windows8 шаблона приложения на основе web-образной верстки с реализацией HTML5 + JScript потенциально открывает этим компаниям дорогу на рынок desktop-приложений. А вместе с архитектурными возможностями VS ultimate, вполне возможно, позволит достаточно быстро и дешево делать корпоративные приложения среднего размера, при чем с эффективной интеграцией с другими приложениями на той же платформе за счет заложенных базовых механизмов, типа Windows Azure Service Bus. Реализуется ли эта возможность, пока, естественно, никому неизвестно, но она видна.
В свете всего этого мне очень интересна реакция мира Linux-Android-Java на такое развитие. Возникнут ли там какие-либо альтернативные подходы, или будет продолжаться лишь догоняющее движение. Потому что переход к desktop на html5+JScript потенциально (при условии, естественно, реализации соотвествующих библиотек и фреймворков) может дать новое дыхание нынешней серверной Java-разработке с web-клиентом, которая очень распространена - клиентом сможет стать уже desktop-приложение, но разработанное в аналогичном русле. Что будет с рынком Android-планшетов, если MS реализует-таки свою идею однородной работы с приложениями под Windows8 на всей линейке hardware? Вопросов тут много. Но про ответы и тренды лично мне пока ничего неизвестно.
И, завершая этот пост, я хочу подчеркнуть необходимость учитывать эти изменения в рамке текущих работ компании, как на тактическом, так и на стратегическом уровнях. Далее - тезисы.
- Сейчас активно идет разработка библиотек WinClient, в это - вкладываемся. Если делать это без учета Windows8, то срок жизни таких конструкций будет крайне невелик, они умрут не успев родиться. А, насколько я представляю, радикально в сторону Windows8 - не смотрят.
- Следует трезво оценивать перспективы альтернативной платформы на Java с desktop-клиентом, которая сейчас развивается в отдельных проектах. Существующие фреймворки desktop-приложений на Java практически не развиваются несколько последних лет, и потому их можно расценивать как технологии вчерашнего дня. Создание новых фреймворков для desktop-приложений если и произойдет, то явно не быстро. С другой сторон, вполне может оказаться жизненной конструкция, при которой Win8 desktop на HTML5+JScript общается с серверной Java по HTTP-протоколу.
- Надо оценивать возможность использования в нашей разработке архитектурных возможностей VS Ultimate. Тем более, что у нас есть достаточно устойчивая модель приложения, которая на этой платформе может быть реализована недорого. А с архитектурой технической реализации приложений в компании наблюдаются явные проблемы.
- Надо учитывать возможность выхода многих компаний, которые сейчас занимаются web-разработкой, достаточно эффективно и в высоко конкурнетной среде, на рынок заказной разработки корпоративных приложений. Вроде как нашу нишу разработчиков действительно сложных решений с глубоким погружением в бизнес это не затронет и, более того, третий автоматизатор окажется еще более востребованной ролью, но варианты могут быть всякие.
На этом все. Аннотации конкретных докладов - не будет. Разве то, в заключении, расскажу про конкретный маленький профит. Я узнал, что в составе VS появилась такая Storyboarding, которая является плагином к PowerPoint и позволяет визуально прототипировать интерфейс - внешний вид экранов, последовательность экранов и интерактив. Хотя и без данных. Надо будет посмотреть.
2012-06-25: ЛАФ-2012
Как обычно, в выходные в конце июня, двухдневный Летний аналитический фестиваль в Иваново. Организует сообщество системных аналитиков, площадку дает Консультант-плюс - поэтому в Иваново. Как обычно - это уже третий год, и в этом году было настолько много желающих, что регистрацию закрыли сильно рано, когда набралось 150 человек. Кстати, это становится тенденцией - рано закрывали регистрацию по переполнению на SQA days в Киеве, на devcon. Народ активно ездит общаться, обмениваться опытом. А ЛАФ выгодно отличается от всех конференций. И очень много людей ездят каждый год, а в промежутке - общаются на площадке сообщества, поэтому во многом - встречаются знакомые. Там очень теплая и своя тусовка, где люди друг друга знают и очень велика общность собравшихся. Поэтому на конференции очень много общения.
Традиционно, первый день конференции - доклады, а вечером конференция перемещается на базу отдыха Малинки, где общение продолжается и на второй день. Что интересно - несмотря на разнообразные возможности развлечений большинство участников предпочитает именно профессиональное общение, и во второй день происходит много интересного. Идут круглые столы, на которых можно реально предложить к разбору интересующий кейс и выслушать мнение экспертов. Или послушать что те рассказывают по каким-то интересным темам, при чем, опять-таки, эксперты предлагают варианты тем, а участники выбирают наиболее интересное.
В этом году было еще два сюрприза культурной программы. В первый день - вокальный концерт на площадке Консультанта, который регулярно организует культурные мероприятия, его директор Александр Иванников считает правильным поддерживать культуру. И в этот раз концерт был приурочен к первому дню, чтобы желающие могли послушать. Мне - понравилось. А второй сюрприз - в воскресенье в Малинках совершенно неожиданно выступала болгарская группа кантри-музыки Lilly of the West, которую случайным ветром занесло в российскую провинцию. И тоже было замечательно. Немного подробностей - в личном блоге, а здесь пора рассказать о докладах.
С докладами было несколько накладок, в основном из-за опоздания докладчиков, добирающихся из Москвы на машинах из-за пробок. Одного из них меня попросили заменить и совершенно неожиданно я сам оказался в числе докладчиков. Я рассказывал про Типы личности Майерс-Бриггс, семинар о которых читал в своей компании 2008 году, есть запись http://lib.custis.ru/2008-02-12-types-of-identity. И, забегая несколько вперед, во второй день я рассказывал про командные роль Белбина, тоже по мотивам семинара, который мы проводили в компании совместно с Аней Рид, и запись которого тоже опубликована http://lib.custis.ru/2010-01-19-belbin Оба рассказа были приняты хорошо, темы были актуальны и вызвали много вопросов и обсуждений.
Надо отметить, что два первых слота из-за своего выступления я пропустил, и жаль - по отзывам, там были хорошие доклады. Так что смогу рассказать только про то, что слушал.
2012-06-11: AgileKitchen
Сегодня был на AgileKitchen. Позитивно и весьма характерно: хотя я на подобных событиях бываю часто, и опыт у меня достаточно большой, три новые идеи - получены. Стоят ли эти идеи целого рабочего дня? Не знаю. Что они стоят моего выходного дня - я для себя решил.
А сами идеи вот.
- Из доклада Андрея Реброва об инструментах автоматизированного тестирования - о том, что VS Test использовать скорее не стоит, чем стоит. Потому что скрипты он записывает, но результат сопровождать и изменять - весьма дорого, он плохо читаем. В общем-то услышав это явно я как-то вспомнил, что VS как инструмент тестирования на конфах не слышно, пользуются другим. Теперь узнал почему. А в целом в докладе был хороший обзор средств автоматизированного тестирования. Для меня лично других открытий не было, но многие участники - узнали для себя новое.
- Из доклада Александра Тупикова узнал об интересном методе разбора фейлов - выученные уровки (не путать с вымученными уроками). Идея состоит в том, что в случае фейла он анализируется и формулируется как урок на будущее и фиксируется в определенном формате. И это - не наказание и не объяснительная, это именно уроки для предотвращения ситуаций. Ведется библиотека таких уроков, они классифицируются, выдаются новым сотрудникам и повторяются когда это уместно. А уж если люди упорно не учат уроки - тогда делаем выводы и наказания.
- Еще из доклада Александра Тупикова - интересная практика самооценки. Все сотрудники регулярно (ежемесячно) пишут своим руководителям и HR свою самооценку. А дальше - получают по ней обратную связь. Очень эффективный инструмент (при нормальном климате) - так как позволяет работать с ожиданиями и оперативно реагировать. Только обратная связь должна быть искренней, и обязательно объяснять, если ожидаемое сотрудникам при высокой самооценки вознаграждение почему-либо не следует.
А еще - был интересный доклад Асхата - работа как игра. С идеей, коль уж такой тренд явно присутствует и востребован - начать применять при организации работы все то, что наработано дизайнерами игр для того, чтобы сделать их интересными. Рассказ Анастасии Тарасенко о создании команды, которая не просто кодит, а решает реальные проблемы заказчика и увлечена этим, и потому работа приносит удовлетворение и счастье. Правда, как она сама говорит, именно описываемый способ она видит только для маленьких компаний - что практически означает, в числе прочего, ограничение на размеры проектов. И success story Михаила Новикова о полном рефакторинге проекта путем создания нового с другой архитектурой и переходе на него.
А еще была интересная интерактивная конструкция, когда люди предлагали темы, у каждой из них был владелец за отдельным столом, а остальные, тоже сев за столами обсуждали 10 минут, а потом - перемещались так что в конечном итоге каждый поучаствовал в обсуждении каждой темы. Результаты - презентовались владельцами тем. Формат - любопытный.
На этом отчет - заканчиваю. Я не буду агитировать приходить на такие встречи, пусть каждый решает сам - это же его время. Но хорошо, что есть люди, которые на них приходят.
2012-05-31: Заседание совета директоров по разработке - об архитектуре
Будучи на Atlantic Systems Guild, я и Игорь Беспальчук были приглашены в Клуб директоров по разработке, который собирает Microsoft. На первое заседание клуба, на котором речь шла о тестировании, мы не попали, а вчера было второй заседание. На нем шла речь об архитектуре. Вели заседание Сергей Орлик, который и начал рассказ, Евгений Злобин и Денис Пасечник.
Конечно, за два часа обсудить такой сложный и многогранный вопрос невозможно. Однако, участники клуба - профессионалы и практики, и их не слишком интересовали теоретические аспекты, поэтому обсуждение касалось обмена практическим опытом по решению задач построения архитектуры и, что более важно - описанию, поддержанию и сопровождению сложной архитектуры большого предприятия. Коснулись также вопроса поддержания архитектуры в разработке малых форм - небольших приложений, эксплуатируемых многими заказчиками, и сильно дорабатываемых для каждого.
Дальше - отдельные тезисы, которых касалось обсуждение.
- В архитектуре различают три уровня: Enterprise architecture, Software architecture и Infractructure architecture. Организация работы на этих уровнях идет сильно по-разному, но при этом необходимо обеспечивать гладкую сшивку между уровнями, в частности между Software и infrastructure и организовывать это при выполнении проектов. Infrastracture влияет на software, особенно, например, при размещении в облаке. И это необходимо учитывать и формализовывать, создавая SLA (service layer agreement).
- Важно работать с софтом на полном жизненном цикле, не ограничиваясь разработкой и внедрением, а рассматривая эксплуатацию и последующую замену. На современных предприятиях IT-ландшафт включает множество систем и одновременно идет несколько (иногда 10+) проектов изменения.
- На больших предприятиях и, особенно, в банках, в том или ином виде существует архитектурный комитет, или отдел архитектуры, или главный архитектор, который работают с архитектурой при осуществлении проектов. Типичный пример - enterprise архитектор, архитектор инфраструктуры и архитектор по безопасности. Архитекторы подчинены непосредственно CEO или CIO, то есть занимают высокую позицию и имеют большое влияние, но должность не управленческая, а техническая. С удивлением узнал, что Главный архитектор есть в ГПБ (кто - не сказали).
- В банках вообще распространена ситуация, когда о новых решениях конкурентов бизнес узнает от IT :)
- Востребованы схемы, отражающие все уровни архитектуры в комплексе и позволяющие визуально переходить между уровнями. В качестве возможного инструмента называли связку SharePpoint+Visio, при этом для отражения актуального состояния желательно, чтобы Visio-диаграммы получают данные из внешних источников, например, из баз данных, отражающих состояние серверов и используемых для мониторинга.
- Как способ представления упоминался Archimate (естественно, мной), но Орлик достаточно резко сказал что в нем очень сложная академичная модель. С моей точки зрения, это странно, потому как им же активно упоминался TOGAF - а он более академичен, а TheOpenGroup сейчас активно перекидывает между ними мостики. После заседания ко мне многие подходили, интересовались archimate.
- Востребована также трассировка между верхним уровнем архитектуры (enterprise architecture) и архитектурой приложений. VS (ultimate edition) сейчас включает много возможностей для работы с архитектурой приложения, но вот архитектуру IT-системы предприятия в целом на ней пока не опишешь, архитекторы верхнего уровня работают в системах типа Enterprise Architect, и хотелось бы иметь трассировку между ними, в том числе - чтобы при решении задач интеграции разработчики одного модуля могли легко найти и познакомиться с архитектурой другого в необходимых им аспектам. Готового решения тут нет, но как идея была предложена перегрузка из EA в VS данных, которые при этом становятся доступны для ссылок из уровня VS.
- С точки зрения управления отмечена хорошая интеграция между Project Server, обеспечивающим управление верхнего уровня, и TFS, используемой для управления на уровне команд. Правда сам TFS не без недостатков, например, при списывании времени на задачу, время разных участников суммируется и история в разрезе участников не ведется. А это важно - хотя у задачи правильно иметь одного основного исполнителя, время привлекаемых экспертов и других участников надо фиксировать и отделять. Но в принципе можно доработать - и Ситроникс это для себя сделал.
- В VS (правда многое в ultimate) есть много различных средств для архитектора. Часть из них обеспечивают восстановление из кода, например, диаграмм последовательностей, что позволяет проследить реализацию метода. Есть Layer-диаграммы, позволяющие описать структуру приложения и возможные обращения. Далее разные классы можно относить к конкретным уровням и при нарушении структуры разработчик получает предупреждение. Существуют также средства автоматического контроля при check-in в версию, описываемые через политику. И это не просто возможность - ряд компаний (Ситроникс, ГазЭнергоБанк, Лидер-Инвест) этим пользуются в своей разработке. Кроме того, на механизме DGML можно описывать собственные диаграммы, нагруженные определенным смыслом и реализовывать механизмы генерации или контроля, с этим связанные, layer-диаграммы - использование этого механизма.
В целом встреча была интересной и полезной, именно как обмен опыта между практиками.
Она безусловно перекликается с темой работы с архитектурой в нашей компании. Не в том смысле, что мы сейчас быстро и безусловно начнем внедрять упомянутые возможности VS и контролировать разработчиков. Но количество визуализированных на диаграммах способов реализации в наших проектах, на мой взгляд, недопустимо мало, слишком многое находится в головах разработчиков, что влечет трудности для их эффективного развития.
[ Хронологический вид ]Комментарии
А взглянуть на страницу результатов теста можно? Еще хотелось бы услышать ваше мнение о времени первого появления достаточно крупных цветовых сообществ.
В общем, не проблема, ниже вырезка из результатов в части спиральной динамики. А про появление цветовых сообществ - я не понял. Где, в каком объеме. Потому что есть сильная неравномерность - в общественной жизни, в науке, в бизнесе (деловом сообществе). Отдельные представители были всегда (ну, с античности), и они объединялись в какие-то кружки. То есть нужен более развернутый вопрос.
Ага, спасибо.
Ваши тексты мне нравятся, хотя тема тимбилдинга не близка.
Мне кажется, ваша профориентация (на бизнес) несколько деформирует общее видение картинки (бизнес таки оранжевый мем). В частности, видится ошибочным представление, что "уровень понимания" начинается с оранжа. О попытке "отождествления" оранжевых с желтым неплохо имхо сказано в этом эссе (и вообще замечательный текст): http://gregory.pp.ru/sd/main.html
О времени появления - ну вот тут примерно даны некоторые оценки: http://www.plot.su/other/166-spiral-dynamics.html
Мне эти оценки не нравятся. Считаю, что значимые проявления новых мемплексов связаны с качественными изменениями технологического развития общества. Эта мысль в отдельных материалах по СД проскальзывает, но конкретные точки перелома не описаны. Некоторые свои мысли (не слишком причесанные) по этой теме оформил тут, возможно, вам будет интересен еще один взгляд на модель: https://docs.google.com/document/d/11gJfUH7P2EIWslN848nVWeK138SSSaUCgJPAztKrxWc/pub
Ну и ссылку на страничку с результатами своего теста оставлю, тоже проходил его пару лет назад: http://www.jobeq.net/PPE/VSQ_UserFeedback.php?LANver=RU&XID=209897&TID=5464
зы Почему-то не получил уведомления о вашем ответе, хотя на комменты подписан.
Нет, если воспринимать бизнес как деятельность, то он есть на всех уровнях, при том разный. Я со времени поста, чтобы детальнее разобраться и как-то уложить свое понимание сделал пару докладов про спиральную динамику на ИТ-шных конференциях. И вроде как хорошо укладывается, что традиционный менеджмент (Друкер, Адизес) это красный + синий + оранжевый, и в жизненном цикле корпораций Адизеса эти составляющие хорошо видны. А текущее развитие менеджмента - Agile в ИТ - начинался как зеленый протест, ушел на желтый уровень, а сейчас пытаются строить бирюзовый, но успех пока не достигнут. Как статья это не оформлено, но тут Спиральная динамика - логика развития системы ценностей (Максим Цепков на AgileDays-2014) есть презентация и видео - если интересно.
И да, я окончательно пришел к выводу, что второй ярус начинается с оранжевого, но это - не "уровень понимания". вообще каждый уровень вносит что-то новое, что дальше сохраняется, это общий принцип. А ярус выделяется просто исходя из аналогии уровней. И поскольку сейчас движение общества уже хорошо видно, по сравнению со временем исследований Грейвса, то можно посмотреть на верхние уровни и сделать выводы про аналогию.
Да, эссе - смотрел, не понравилось - слишком поверхностно. И поэтому местами там, на мой взгляд, идет наклеивание ярлыков без достаточных оснований.
Вашу модель посмотрел, интересно. Во многом согласен. Но вот однозначное сопоставление уровней с формациями считаю неправильным, потому что надо расщеплять формацию на смесь деятельностей (государственное управление, общественное движение, бизнес, ...), переход по уровням переходит неравномерно и реально существует смесь. Когда же приписываешь уровень формации целиком, то это просто запутывает.
Про уведомления - я посмотрю. Возможно, чтобы они ходили, надо подтвердить адрес электронной почты, это в Настройках (придет письмо, кликнуть ссылку).
Английская статья "Spiral Dynamics" из википедии (http://en.wikipedia.org/wiki/Spiral_Dynamics) сейчас является перенаправлением на биографию Дона Бека. Оригинальную статью удалили 15.03.2015, а 10.08.2015 - сделали статью с перенаправлением. Основания для удаления - оценена как промо книги.
Я не нашел, как извлечь из википедии оригинальную статью, которую я читал в 2013, но archive.org все помнит. Я читал примерно вот это, а последняя версия перед удалением эта.
Я бы сказал, что логика очень странная. С другой стороны, на момент удаления в статье стало столько ссылок на книгу, что можно было так оценить, наверное. А в 2013 библиография была более сбалансирована.
Русский перевод тоже доступен только в архиве.
И, что интересно, эти изменения со статьей по Спиральной динамике - замена отдельной статьи на перенаправление на биографию Дона Бека произошли практически в момент смерти Криса Кована 15.07.2015. В в его некрологе рассказывается. в том числе, о расколе между соавторами книги.
Сохраняю для себя.
А это - ссылка на пост Макса Богуславского с впечатлениями о конференции, FB принес в ленте воспоминаний.
Есть книга-исследования "Введение в организации будущего" - Фредерик Лалу. Автор попытался найти работающие бирюзовые организации, и изучить их ценности и процессы изнутри. Некоторые организации в исследовании желтые, но некоторые и врпавду можно отнести к бирюзовым. Это к вопросу о переднем крае развития организаций
Большое спасибо! Я посмотрел ознакомительный фрагмент, купил электронную версию, буду читать. Для меня тут интересны не только механизмы управления внутри, но и масштаб и сложность достигаемых результатов и способ вписанности в экономику.
Тренинг не записывали, но кусочки техники ведения видны на видео доклада на сайте конференции или на youtube на 11 минуте (и на других тоже), а в начале доклада видна камера, подключенная к компу. В презентации кусочки 9-12 слайды, 88-91 слайды и еще разбросано внутри
Сохраняю ссылки.
История Денверского аэропорта - Демарко Том и Тимоти Листер "Вальсируя с медведями" Глава 3 .Пересмотр истории международного аэропорта в Денвере: здесь есть начало главы бесплатно, дальше просят денег за книгу.
Максим, интересно, что изменилось за 7 лет?
Изменилось довольно сильно, я как раз на РИТ вспоминал про этот пост в своем докладе про счастье на работе. Если в 2012 первый мир был в меньшинстве, хотя уже не был исключением, то теперь именно он - норма. И скепсис по отношению к нему со стороны второго мира сильно уменьшился. Выбор места работы поэтому происходит более сознательно. Третий мир в том виде, в котором был в 2012 - практически ушел в прошлое. Естественно, сейчас есть люди, которые прочитав этот пост говорят "понимаю, что я в третьем мире". Но при разборе фактуры оказывается, что условия все-таки сильно мягче. Идея штрафов за опоздание, например, воспринимается как явно нереалистичная, а тогда оно было.
Максим, поздравляю с выходом на новую платформу. Планируете ли прикрутить RSS-ленту, чтобы можно было удобно Вас читать?
Спасибо! А RSS-лента - есть, подписываться можно на Блог, на обновление отдельных Категорий и на все изменения (но все изменения - не слишком интересно). Правда, "из коробки" сделано не слишком удобно, кроме блогов.
Чтобы подписаться на изменение блога надо на странице блога (Блог:Максима Цепкова) нажать на значок Atom, который появляется в панели меню слева. А все остальное делается со страницы Свежие правки, тоже доступной из панели слева: по мере того, как фильтруешь запрашиваемый список правок, меняется url у значка Atom - получается нужная rss-лента.
Да, всё работает :)
Дополнение. Сейчас выложены все 8 частей, но, к сожалению, там уже pdf, а не rtf :(
Почти презентация, зато с задачами и упражнениями
К докладу "Слагаемые хорошего курса подготовки бизнес-аналитиков в среде Agile Scrum" попробовала собрать все по оценке БА на странице http://allbait.blogspot.com/2014/10/blog-post_47.html
Пост на FB - чтобы найти
Спасибо за интересное описание других докладов и хороший отзыв на мой! Я рад, что доклад был понят как описание "анти-догматичного процесса" - это действительно была одна из целей, о которых я думал при написании доклада. Любопытно, что про совместное использование обоих методов я говорил http://de.slideshare.net/AlexeiVinogradov/notestscases (слайд 17), и даже рекомендовал (в приемочном тестировании). И еще в самом конце (слайд 27) - говорил про то, что не призываю сломя голову использовать, я руководствоваться контекстом и учитывать особенности (там как раз не один Кэп, а сразу три на слайде:)). Я гляну еще, когда будет готово видео, потому что я это озвучивал голосом, на слайдах это может быть неоднозначно понятно.
Понятно. Значит момент про совместное использование я упустил. Поправлю.
А что учитывать особенности - это большинство докладчиков понимают и призывают, а слушатели почему-то часто воспринимают делай 1-2-3. Но я имел ввиду более подробное рассмотрение, для каких проектов и процессов такая замена разумна и в каком объеме, если такой опыт имеется, например, Вы пробовали в различных проектах и там оказалось несколько по-разному или на одном проекте границы нащупывали и двигали.
На совсем подробноее рассмотрение всего интересного не хватало времени доклада, но я тогда посчитаю эту фразу вопросом и отвечу в блоге, после того как вывесят видео. Такого рода вопросов есть уже много, это опять же радует. Сразу отмечу, что ответ не будет в стиле "это правильно, это неправильно", а будет описывать личный опыт и свои мысли по этому поводу и приглашать к дискуссии :).
Максим, спасибо за ссылку на книгу Левенчука! И за Ваш блог в целом.)
P.S. почему-то у меня не получилось зайти через OpenID аккаунт Google.
Максим, привет! Всегда приятно и интересно читать твои емкие обзоры. Спасибо.
Спасибо! А ты кто? А то по регистрации это нельзя понять.
К сожалению, сайт конференции gamefest.biz - был утрачен организаторами. На новом сайте конференции материалы и информация прошлых лет - отсутствует. Видео на сайте GameTrek http://gametrek.ru/archives/2175 - сохранилось.
Мне кажется что на эту тему надо смотреть шире, а именно попытаться понять почему принимается решение о взятии долга. Результаты разбора (статья, доклады) и много интересных ссылок можно посмотреть тут http://www.maxshulga.ru/search/label/техдолг. В том числе есть мнение, что не надо тратить время на отслеживание долга: http://swreflections.blogspot.ru/2015/02/dont-waste-time-tracking-technical-debt.html
Максим, спасибо за ссылки. А по отслеживанию долга все просто: любая практика (code review, парное программирование и другие) может быть уместной и лишней в конкретном проекте. Для нее надо понимать - какие цели мы через нее достигаем, являются ли они существенными и нельзя ли их достичь через более легкие практики.
Ссылки на материалы с обсуждения на Facebook
Алексей Шершнев опубликовал свою презентацию на встрече.
Массив схем развивается и можно посмотреть два текущих среза
Прочитав книгу Марка Розина "Успех без стратегии" добавил в набор схем типологию организаций 4F, тем более, что она сопрягается со Спиральной динамикой. Подробности Блог:Максима Цепкова/2016-08-01: Марк Розин "Успех без стратегии" как книга для бирюзовых организаций#Типология компаний 4F
В список не попали естественно-научные схемы устройства мира с соответствующим аппаратом рассуждений из математики и физики. Их наличие для меня очевидно, так что я не стал даже фиксировать. Сформировались в старшей школе, особенно математика - я уже тогда из интереса читал ВУЗовские материалы по матану и аналитической геометрии, решал задачки. А институт их расширил.
Навел фокус - Блог:Максима Цепкова/2018-01-09: Схемы, которыми я мыслю. Изменений немного.
Очередной фокус (2023-05).
При обсуждении мне рассказали, что в интегральной теории Уилбера, на которую тоже ссылается Лалу, различаются уровни teal, соответствующий желтому Спиральной динамике и turquoise, соответствующий бирюзовому. Среди российских специалистов по интегральной теории принято переводить teal как изумрудный.
Максим, добрый день. Большое спасибо за такое полное и структурированное изложение книги и идей Лалу.
Прочитала ее с большим удовольствием, но при этом не покидало странное ощущение, похожее на то, которое возникает при чтении различной эзотерической литературы - "прикольно, но разве так бывает?" :)
Встречали ли лично Вы в России организации, близкие по духу к "бирюзовым"? Есть ли среди них IT-компании?
Оксана, тут вопрос - насколько близкие. А главное - близкие по духу или по практике? Потому что наша компания по духу, по ценностям - достаточно близка, однако с практиками не экспериментирует, применяя наработанное в более ранней культуре.
На AgileDays-2013 был очень интересный рассказ Антона Волкова из «Танки онлайн» про эксперименты с их практиками, в 2014 он приезжал и в кулуарах рассказывал про развитие практик. На последней AgileDays был доклад Станислава Сажина "Зарплату мне назначают сотрудники" - там очень много близкой практики по самоорганизации. По частным разговорам я знаю, что в Киви двигаются в этом направлении. А в небольших ИТ-компаниях и стартапах такой дух вообще часто встречается, но по мере роста он может трансформироваться в разные стороны.
Про доклады можно почитать в моих отзывах на конференции Категория:Конференции
Максим, большое спасибо :) Обязательно почитаю. А вот про отрыв духа от практики - это интересно, неужели более традиционные практики не мешают ценностям более высокого уровня по спирали развития? А насколько практики Вашей организации более традиционные? Если говорить по классификации Лалу - они ближе к "зеленым" или еще более ранних уровней?
Нет, ближе к синим (по Спиральной динамике, по Лалу - янтарный) и оранжевым - классическая организованность. По спиральной динамике последующий уровень включает в себя предыдущие, так что если практики применять осмысленно и в уместном объеме, понимая их ограниченность, то они не мешают. Более того, отчасти становится проще, потому что внешний мир ждет от компании именно традиционного взаимодействия. Хотя есть опасность в том, что начнут работать стереотипы и осмысленность потеряется - это надо рефлексировать. При этом teal-практики agile в компании тоже есть и работают, так что организация смешанная.
Этот отзыв был снабжен иллюстрациями и опубликован на портале Спиральная динамика 21.06.2016.
Постом в Facebook об этой публикации: "Представляем вашему вниманию исключительно качественный конспект и блестящий анализ книги Фредерика Лалу от Максим Цепков" поделились более 30 раз. Мне запомнилась высокая оценка Максима Каленова "Кто слышал где-то про Лалу и разноцветные организации - найдите время прочитать анализ от Максим Цепков. ИМХО это лучшее дополнение к книге. Сильно снижает "миссионерское" настроение книги, чем переводит её в разряд полезных инструментов :)"
Добрый день, Максим. Прочел Ваши рефераты по книгам Розина и Лалу и появился вопрос. Бирюзовые организации отличаются от традиционных тремя вещами:
1) Социальная адаптивность - всякий может выбрать любое доступное ему занятие и роль.
2) Гибкость и самостоятельность решений - всякий может принять любое (в т.ч. и финансовое) решение, но существуют механизмы контроля: полная открытость информации, совет с теми кого это затронет, способы решения конфликтов.
3) Люди организованы не в процессную иерархию, а в набор более-менее самодостаточных команд.
И тут возникает проблема. Самоуправляемая команда может быть эффективнее многоступенчатой иерархии. Но увеличивая свою эффективность, самодостаточная команда рано или поздно придет к тому, что лучше генерировать доход себе, а не владельцу бизнеса. Противоречие эффективность/контролируемость традиционно решается в виде маятника централизации/децентрализации. А как насчет бирюзовых организаций?
На этот вопрос можно отвечать с нескольких точек зрения. Для начала, вот какой вопрос. Если самодостаточная команда может поставлять конечный продукт то чем. собственно, владелец бизнеса владеет? Каков его вклад? Если никакого - то команда замечательным образом уйдет. И это будет логично, вообще удивительно что она работала у какого-то там владельца. Но обычно владельцы бизнеса владеют какими-то конкретными вещами, которые у команды отсутствуют, и тем самым они нужны команде. То есть команда не является самодостаточной. Ну и достаточно часто маленькая команда не может выдать конечный продукт.
Опыт бирюзовых организаций показывает, что даже если на операционном уровне команды достаточно автономны, все равно есть аспекты, на которых сказывается эффект масштаба и для которых команда - слишком мала чтобы их осуществлять. Это касается инфраструктурных вещей типа бухгалтерии, юристов и управления финансами, хотя их можно аутсорсить в сервисные компании. И это касается развития бизнеса - обучения персонала, расширения сферы деятельности, и так далее - возникает внутреннее профессиональное сообщество и другие поддерживающие структуры. Роль центрального аппарата при этом сильно меняется. У Лалу это хорошо показано на кейсе медбратьейв Buurtzorg. Но я вижу примерно такие же вещи и в IT, хотя там много небольших компаний.
При этом жесткость границ организации действительно размывается, они становятся более подвижны и децентрализованы, их нельзя централизовать силой - однако в области разумной кооперации федерация сохраняется. Примерно так.
Можно попробовать рассмотреть это подробнее на кейсах.
И просьба - если можно, ссылку на Ваш профиль в соцсетях, хочется представлять, с кем я веду диалог.
Спасибо, теперь идея понятна. Ищутся не способы контроля, а построения культуры композиции долговременных интересов. При этом замковым камнем системы может быть что угодно: материальные активы, социальные связи, или даже умения фасилитации как у Семлера... ЗЫ. Давно хотел завести себе Фейсбук и, раз нашелся повод, то вот мой профиль https://www.facebook.com/and.kuzn
Да, именно так. Долговременные интересы для совместной деятельности, и кооперация вокруг них. При этом соблюдается автономность действующих агентов. особенно в принятии решений. А человек - вовлечен во много потоков такой деятельности. Это очень хорошо видно в холакратии с ее кругами.
Спасибо большое за статью, рекомендую ее моим студентам. Мы в Метаверситете какое-то время разглядываем спиральную динамику с разных сторон и даже положили ее в основу нескольких цепочек занятий. Все равно остается всегда много недоговоренного, и Ваша сборка дает хорошее целостное видение. Спасибо.
Рад, что оказалась полезной в образовании. А цепочка занятий по Спиральной динамике в Метаверситете - круто!
https://www.mann-ivanov-ferber.ru/books/otkryivaya-organizaczii-budushhego-illyustrirovannoe-puteshestvie - иллюстрированное издание для менеджеров и детей 8)
Да, видел эту книгу. Но внимательно с точки зрения содержания не разглядывал. Те, кто смотрели, говорят, что текст сохранен, только картинки добавлены. Получается развлекалка для тех, кто лонгриды не может осилить...
Facebook выдал в воспоминаниях фотку с конференции
Обнаружил, что забыл упомянуть интересный доклад Дмитрия Абрамова "Scrum не для всех. Люди, которые разрушат вашу команду" - о том, почему при начальном переходе на Scrum правильно расстаться с определенными типами людей, несмотря на профессионализм, для обеспечения перехода. При этом Дима подчеркивал, что после внедрения ценз снижается, потому что человек приходит уже в сложившуюся культуру.
Доклад станислава Сажина на сайте конференции, там же видео.
Для истории. Анонс 3 модуля был здесь. Помимо этих лекций есть достаточно много доступных лекций разных лет по этой же теме на сайте фонда Г.П. Щедровицкого http://www.fondgp.ru/lib/mmk/180
Для истории - пост в FB
Статья выложена у меня на сайте Проекты — для достижения результата, а не для освоения бюджета
Комментарий от Димы Безуглого при repost
Максим Цепков Опубликовал отличный обзор наших дискуссий и доклада на #AnalystDays. Часть комментариев на мой взгляд очень хорошо дополняют, то что прозвучало на докладе.
Однако он смягчил ряд тезисов.
Дальнейшее обсуждение читаем на FB.
Денис Бесков в комменте дал ссылку на русский перевод Александра Остервальде Построение бизнес-моделей. Я уже скачал с litres, читаю.
Схема переведена на английский с использованием оригинала из книги Бэкона Specialization of scientists by Francis Bacon
Осенью 2020 мне написал Yves-Michel Marti из The Baconian Company, что он нашел эту схему, она ему показалась интересной, и он хочет включить ее в статью для сборника (это анонс), который должен выйти в январе 2021. Позднее он прислал текст статьи «How Intelligence feeds Innovation. Merchants of Light of the Elizabethan Renaissance», принятый к публикации. В статье приведена эта схема и высоко оценена «An astute Russian researcher, Maxim Tsepkov, had the brilliant idea of describing the information processing process with process mapping software». Пользуясь случаем, я хочу поблагодарить Максима Осовского, который в свое время вдохновил меня на перевод.
Из комментариев Сергей Косовский: Огонь! Давно эта проблема у меня в голове висела! Спасибо за решение.
Из комментариев Эдуард Галиаскаров: Очень похожий подход я использую и студентам даю по use cases. А подсмотрел его у Арлоу и Нейдштадт в книге UML2 и унифицированный процесс. С другой стороны сам uml предлагает сворачивать каждый сценарий в отдельную деятельность.
Я: надо будет запомнить книгу
Еще обсуждения идут в группе Анализ в ИТ-проектах
Дополнение. При автоматизации важно предусмотреть в системе возможность зафиксировать результат разбора с кейсом-инцидентом. Например, если контрагент не согласен со стоимостью поставки и мы пошли на уступки - как это зафиксировать в системе? Это может быть отдельный документ о списании долга или возможность добавить скидку или изменить цену в старых накладных. Или если при проверке отчета обнаружена необходимость его исправить, при том, что документы нужным образом исправить нельзя. Впрочем, последний случай в принципе решается, если отчет можно экспортировать в Excel и исправить там - но хорошо бы, чтобы в системе оставались следы.
А регистрация и типизация инцидентов и автоматизация взаимодействия по ним - это уже следующий уровень.
Из поста на FB
В качестве ответа на статью Марк Мельник написал две статьи, в которых предлагаю термины, к которым мы более привычны: сценарий, типовой сценарий, рассматриваю ограничения нотации BPMN в моделировании сценариев. Там же я выдвигаю требования к ИС, которые хотелось бы видеть в реализации: https://habrahabr.ru/post/304242/ https://habrahabr.ru/post/305016/
Статьи интересные, мне понравились. На FB по ссылке можно посмотреть обсуждение.
Обсуждение на FB исторических примеров, которые я прописал весьма диагонально
Из комментов на FB
Игорь Беспальчук: Очевидное место исследований в ИТ - это исследования существующих продуктов, компонент, технологий. С целью изучения их свойств и границ возможностей.
Максим Цепков: Это интересная тема. Если быстро, то я подумал, что это получается как-то странно: изучаем отраслевой же искусственный мир. А потом вспомнил, что многие химические и фармацевтические компании изучают вновь синтезированные вещества для оценки потенциала применения в своей области. То есть получается цепочка R-D-R-D-...
Обсуждение на FB. Там несколько репостов, и в каждом - свои ветки дискуссий.
"По мере фокусировки на основном проекте семьи — рождении и воспитании детей, — будет происходить уже осознанная работа на желтом уровне и дальнейшее движение к бирюзовому во взаимодействии с новыми структурами образования." - самый спорный, на мой взгляд, пункт пересборок. Ибо самый базовый и самый мистический. Свыше показаны человечеству примеры "запрета", тормоза на размножение в истории нескольких тысячелетий и сотен поколений. Так что оптимистичная, на Ваш Максим взгляд, история не есть единственно верная из возможных историй. Хочется быть позитивистом, но здесь именно, в этом прогнозе мне предпочтительней осторожность. Моё предложение иметь выборку нескольких социальных уровней по этническому, социокультурному или территориальному признаку чтобы анализировать "пересборку семейного уклада", поскольку в этом вопросе однозначно присутствует функция фильтра и "за бортом" процессов останется колоссальное количество населения планеты.
Обсуждение на FB. В комментах есть интересная тема про вектора в сегменте малого бизнеса, я его не выделил отдельно, а, возможно, зря. И еще немного про blockchain
Сохраняю из комментариев facebook.
Елена Верещагина: Эх... не так страшен Agile, как эйфория вокруг него... https://vc.ru/p/agile-victims
С большим уважением отношусь к автору поста. Но не могу не заметить о странности противопоставления Agile и "всему остальному" опыту, накопленному в проектном управлении.
Успех того или иного проекта определяется, на мой взгляд, не сколько методологией, сколько профессионализмом участников, понятными целями и сыгранной командой. Разве не так?
И мой ответ.
Елена, к сожалению, статья тиражирует много ложных мифов. И, более того, пытается подкрепить их ложными фактами. Первое - о том, что Agile подходит только маленьким компаниям. Реально Agile подходит и большим компаниям, хотя с его внедрением есть определенные сложности (о которых я писал). Более того, Microsoft и IBM внедряют у себя Agile-подходы уже несколько лет. При чем начали это делать именно потому, что лишились лучших выпускников - они уходили в небольшие стартапы за той свободой самореализации и отсутствием регулирования, которое дает Agile. Далее, успех проектов по Agile в IT выше, чем успех проектов, сделанных в классической методологии. Хотя цифры для сложных проектов - невелики. При этом достигается кратно дешевле. Подробности можно посмотреть, например, в докладе Джефа Сазерленда на SECR-2011 (видео и презентация опубликованы) и в других источниках.
Один из известнейших провалов классической методологии - отсрочка запуска уже построенного нового Денверского аэропорта на полтора года (!) из-за того, что не смогли запустить софт управления доставкой багажа. И неудача американской системы страхования, на которую ссылается автор статьи - это тоже провал классического подхода, а не Agile. Ген.подрядчиком вроде был IBM, а разработка обошлась 1.7 млрд $, так что провал был впечатляющим. И именно после него Обама озверел и потребовал принять Agile-методологию как обязательную для ведения ИТ-проектов с для государства в штатах. Так что дело обстоит ровно наоборот, чем пытается представить автор статьи. Что касается классического проектного подхода, то о его провале говорит то, что начиная с 6 версии PMBoK авторы пытаются включить в стандарт Agile-подход. Получается печальная эклектика. Вот так.
Так что Agile не страшен, и за ним - будущее.
Елена
Максим, больше всего вокруг шумихи про Agile мне не нравится высокий эмоциональный тон дискуссии - в духе "кто не с нами - тот против нас". Вот и Вы не правы, утверждая, что автор говорит о неприменимости Agile к крупным компаниям, просто расставляет некоторые акценты - на что стоит обратить внимание.
Да и признаюсь, меня бы эта история не зацепила, если бы воочую не наблюдала провалы многих проектов и инициатив в ИТ (в основном, крупных компаний), связанных именно с "внедрением Agile".
Автор говорит о вполне конкретных вещах - необходимости интеграционного и регрессионого тестирования, об архитектурной целостности системы и т.п.
Там, где Agile внедряется - это как правило компромисс и микс, а не ортодоксальное отрицание накопленного опыта.
Методологии приходят и уходят, а инженерные практики остаются. На голом энтузиазме далеко не уедешь...
Как я знаю, многие ИТ специалисты, наевшись "гибких практик" ищут компании, где можно просто достойно делать свое дело, не гоняясь за всякими безумными нововведениями ради "красного словца" людей, которые делают на этом имя... Вопрос - правда, какое и для кого...
Мой ответ Дискуссии вокруг Agile могут быть с разным эмоциональным накалом, в зависимости от позиции участвующих. Так же как и все остальные дискуссии. Что касается данной статьи, то я указал на конкретные проблемы у автора приведенной статьи с пониманием темы и владением материалом. При том, что он позиционирует себя в качестве эксперта. Автор, с моей точки зрения, не расставляет акценты, а явно говорит о слабой применимости Agile. При том что в ряде крупных компаний он успешно используется. А статистика говорит о сравнительной успешности Agile-проектов. Провалы внедрения Agile, о которых я тоже знаю, связаны как раз со слабым профессионализмом тех, кто этим занимался. И это характерно не только для Agile, а для многих эффективных инструментов, ставших модными из-за своей эффективности - их пытаются внедрить не разобравшись.
И я отдельно хочу подчеркнуть, что Agile - это вовсе не энтузиазм, а как раз набор организационных и инженерных практик, которых в нем много. Включая интеграционное и регрессионное тестирование, которое автор почему-то выносит за пределы Agile. Ряд из практик Agile я перечислил, отвечая выше Екатерине Филатовой. И да, эти практики работают.
Ссылка на пост FB - репосты и обсуждения в комментах.
Историю про приписывание провала ObamaCare методологии Agile в статье на которую сослалась Елена Верещагина рассказал в группе GosAgile, которая началась чуть больше года назад с AgileKitchen в Аппарате правительства, на которой Асхат рассказывал, что провал сайта медицинских страховок инициировал как раз обязательное применение Agile вIT-проектах для государства в Штатах.
Коммент Дмитрий Синяев А пруфы привести сможете?
Просто обзор заметок по данной теме лично у меня сформировал следующее мнение (возможно ошибочное) 1. Когда при запуске начались проблемы, ряд СМИ написал, мол обгадились из-за того, что не использовали "современные подходы", то же New Yorker писал что вот Agile, Scrum.
Только вот потом другие порталы писали, что подрядчики по проекту (их было несколько), в частности, те кто пилил front-end и back-end использовали Agile. И что проблема глубже, а использование agile еще не гарантирует, что вы на проекте не обгадитесь.
ИМХО журналисты которые первыми написали, зарабатывали себе очков на неудачном запуске, не особо вникая в детали.
2. Что касается "послужила причиной перехода" - это тоже как-то не вяжется например с тем, что проекты по разработке ПО с использованием Agile реализовывались в 2012 году в FBI. А проблемный запуск Obamacare был в 2013 году. ИМХО параллельные активности, но консультанты Agile считают по-своему.
3. Для проекта, КМК, намного критичнее было, то что его республиканцы сливали, в сенате, в верховном суде и всячески вставляли палки в колеса, это в итоге привело к тому, что в 2014 году была проблема с согласованием бюджета.
4. Сейчас Трамп прикроет всю эту программу и тогда это будут просто выкинутые деньги на ветер, и будет не важно Waterfall, Agile или магия вуду использовались на проекте.
Мой ответ
Пруфы - легко. Тем более, что они есть в моем отчете с AgileKitchen http://mtsepkov.org/GosAgile-2015-11 Презентация Асхата http://www.slideshare.net/ScrumTrek/agile-55075828 История HealthCare.gov в вики https://en.wikipedia.org/wiki/HealthCare.gov, история US Digital Service на их сайте https://www.usds.gov/story
Из них видно, что фейл проекта произошел при запуске осенью 2013 года. Отдельные подрядчики могли работать как угодно, но в целом проект велся по классической водопадной технологии. Для меня достаточным признаком является обнаружение проблем с регистрацией практически перед запуском. Что означает отсутствие интеграционного тестирования, а возможно и вообще практики continuous integration в рамках проекта, и отсутствие итеративных поставок конечного продукта. То есть базовых практик Agile. Не говоря о многократном возрастании стоимости.
И поскольку облажались все регулирующие структуры, в которых, по-видимому, сидели апологеты проектного метода, то после этого фейла, в 2014, Обама организовал в составе аппарата Белого дома US Digital Service. Который занялся не только разработкой норм на ведение проектов, но и практической реанимацией HealthCare.gov.
А политика - она поверх этих технических фейлов наворачивалась, это производная. Как не валили проект в сенате, бюджет подрядчики освоили, шутка ли 1.7 млрд $ за сайт, пусть со сложным бэк-эндом.
Мое дополнение. Кстати, на той же AgileKitchen был интересный рассказ Марины Макарчук из Ростехнадзора - о том. что они уже два года перешли на Agile с 3-недельной поставкой релизов для своего основного комплеска из 17 подсистем. Чем избавились от конкретной боли. когда после очередного полугодового релиза всех подсистем 1-2 месяца шло утаптывание их интеграции в боевой конфигурации - при том, что установленные законом 2-недельные сроки для обработки Ростехнадзором обращений других организаций никто не отменял. Теперь все нормально. Правда, чтобы убедить подрядчика, который бsk сторонником классического подхода и уверял, что "Agile не работает" в таких проектах потребовалась эскалация до замминистра. Так вот, Agile работает.
Правда, мои ссылки Дмитрия не устроили, и там пошел разбор на тему качества и доказательности различных ссылок. Кому интересно - читайте, начиная отсюда
Для себя сохраню следующий собственный коммент
Печальный для сторонников классического проектного метода факт состоит в том, что проект разработки HelthCare.gov - государственный проект и он велся по тем методикам проектного управления, которые были приняты в США как стандарт. Там на эту тему есть регулирование. И блистательно провалился. И, более того, по результатам разбора и анализа этого кейса администрацией президента было принято решение не просто наказать виновных или изменить нормы, а создать отдельную организацию, не связанную с предыдущими, которая должна была построить новые нормы ведения IT-проектов. основанные на Agile. И именно этим она занималась как основной деятельностью, заодно работая по конкретным проектам.
Таким образом, провал ранее принятых стандартов проектного подхода был зафиксирован делом, а не словом.
Обсуждение в группе Бирюзовые организации продолжается.
Коммент Igor Panyuta Поддерживаю мнение Елены Верещаги. Во-первых, она практик и занимается реальным делом ежедневно. В вопросах IT её мнение для меня входит в пятёрку самых интересных. Наблюдаем ещё один пример перманентного конфликта между тем, кто делает и тем, кто учит. Воистину – “Кто умеет - тот делает, кто не умеет — тот учит” (Бернард Шоу). Подозрение вызывает уже сам по себе факт очередной активной шумихи. На этот раз это AGILE. Начинаешь разбираться и понимаешь, что по сути это один из инструментов в УП (Управлении Проектами) или PM (Product Management). Этих инструментов существует десятки и сотни. Почему вдруг один из них вдруг стал панацеей от всех бед? Это как если слесарь вдруг будет утверждать, что рожковый ключ на “17” самый главный и универсальный инструмент. И много он таким инструментом наработает? PM занимается не только IT. Круг использования инструментов PM достаточно широк и в бизнесе, и в быту. Во всех случаях инструментарий решения вопросов свой. Не представляю, как можно один единственный объявлять самым-самым? Если вернуться к аллегории со слесарем, то самыми универсальными инструментами являются молоток и зубило, древние и проверенные. Профессионализм связан со знанием как можно большего количества инструментов. Предлагать AGILE как универсальный инструмент? На все случаи жизни? Смешно, Максим. На мой взгляд, приведенная Еленой статья более объективная и взвешенная, упоминаются как достоинства, так и недостатки, ограничения AGILE. Доверия к приведенным фактам выше, чем к эмоциональным восторгам и опровержениям. Метафора с “Карнавальной ночью”? Всё это весело в кино или пока это тебя не касается лично в реальной жизни. А когда останавливается бизнес, останавливается денежный поток – это близко к катастрофе, а репутационные потери посчитать невозможно. Мой личный успешный опыт решения проблем в реализации проектов связан с высокой квалификацией исполнителей и здравомыслием, и никак не связан со знанием инструментария PM. ;-)
Мой ответ
Я тоже практик и занимаюсь реальным делом ежедневно. Коучингом и тренингами занимаются другие. Впрочем, у них - тоже реальное дело. А еще я вижу историю развития Agile и проектного менеджмента, и их взаимодействие. Так вот, в приведенной Еленой статье видно отсутствие владения фактическим материалом человеком, который полагает себя экспертом. И приписывание Agile тех недостатков, которыми он не обладает. Автор почему-то уверен, что практики тестирования в Agile отсутствуют. При этом все провалы из-за поставки некачественного ПО списывает на использование Agile-методов, не потрудившись разобраться. Особо ярким примером выступает история ObamaCare, проблемы с которой автор приписывает методологии Agile, в то время как проект велся именно по классической методологии проектного управления. А провал его осенью 2013 инициировал создание весной 2014 отдельного US Digital Service в аппарате президента, которое начало вводить нормы Agile для ведения IT-проекта и разбираться конкретно с проблемами проекта сайта страховок. Подробности можно прочитать https://en.wikipedia.org/wiki/HealthCare.gov и https://www.usds.gov/story
Далее, именно значительные успехи Agile, которые было невозможно игнорировать привели к тому, что держатели PMBOK были вынуждены включить эти практики в версию PMBOK-4 в 2008. Получилась эклектика. Впрочем, развитие идет, и стандарты подтягиваются вслед за практикой. А практика развивается в рамках Agile. При этом накопленный опыт прошлого - осмысляется и включается. Хотя держатели старых стандартов пытаются представить процесс другим образом - дескать, это Agile - лишь один из инструментов. Так что нет никакой панацеи. Есть разнообразно развивающееся, создающее практики новое - Agile, и есть старое, традиционное которое на это новое заглядывает и передовые практики оттуда забирает когда игнорировать становится невозможно. Нормальная эволюция.
А еще было конструктивное обсуждение с Екатериной Филатовой, с интересными ссылками на ролики.
Вопрос Екатерины подскажите, пожалуйста, где можно прочитать про принципы agile в более прикладном варианте? какая у него автоматизация, механизмы взаимодействия. Аллегория мне понятно - хотелось бы про механику прочитать (у меня IT проект)
Мой ответ тут вопрос сложный, в том смысле что ответ - очень объемный. Agile - это зонтичная конструкция, зонтиком являются ценности и принципы, сформулированные в Agile Manifesto http://agilemanifesto.org (там есть вариант на русском). Под этим зонтиком собираются многие методы, наиболее известные из которых - Scrum и Kanban, есть еще их комбинация Scrumban, Lean и другие. Про Scrum надо читать Сазерленда "Scrum - революционный метод управления проектами", хорошая для ознакомления (но старая, это надо учитывать) книга Книберга "Скрам из окопов" (Scrum from the Trenches), про Lean - "Lean Software Development" Мэри Поппендик. При этом, если говорить про IT-проекты, то к организационным методам надо добавлять технические - DDD, FDD, TDD, BDD, Continuous Integration и Continuous Delivery и многие другие. Автоматизируется все это в любом современном таск-трекере - Jira, TFS, есть специализированные инструменты для ведения досок, коллективной работы и много других. Потому что Agile в IT на западе - просто стандарт. При этом какие именно методы применять - сильно зависит от специфики вашего проекта. Для разных проектов подходят разные методы. Если Вы расскажете, я могу посоветовать подробнее. Можно здесь или в переписке.
Екатерина Про скрам и иже с ними знакома давно, а вот про DDD и прочими "DD" пока не понимаю их расшифровки) Про Agile нашла уже занятное видео, которое отвечает на мой вопрос. может быть будет интересно - делюсь. видео Про DDD можете расшифровку дать?
Еще видео
Мой ответ Первый ролик посмотрел, там понятная организационная конструкция в целом в рамках Agile (при условии, что механизмы, применяемые лидерами профессии и главой племени им соответствуют). Но пока эта конструкция - без организации процессов внутри, в рамках нее можно запускать Scrum или Kanban или другой вариант процесса, в зависимости от характера потока задач. Расшифровка xDD - Domain Driven Design, Feature Driven Development, Test Driven Development, Behavior Driven Development. И это далеко не полный список. А еще есть детальные практики, например. эталонный Scrum предполагает использование user story, однако они могут быть заменены на use case, если это уместно.
Второй ролик - это Книберг, один из мировых гуру, в переводе Вольфсона, который один из экспертов-практиков у нас. По книге Книберга я в 2008 знакомился с Scrum, а позднее - был на его тренинге. В ролике - классный ликбез и основы для знакомства с Agile. И от этого можно отталкиваться.
Продолжение обсуждения в комментариях на FB. Для меня много ценного, различные точки зрения. Сохраняю и для себя и для других читателей.
Комментарий Екатерина Филатова Все разговоры и непонимание происходит из-за того, что каждый по-своему видит Agile... Кто-то знает, что это манифест с 4-мя пунктами, а кто-то видит в этом целый инструмент. На сколько я понимаю, Agile - это религия) Люди знают, что убивать опасно, но им нужны были 10 заповедей. Мы все давно работаем по agile и вот только сейчас узнаём, как этот зверь называется)) (я про себя) теперь могу форсить, рассказывая "невеждам" про "Эджайл" )) Предполагаю, что ваши различия во мнениях имеют общую правду в корне, в глубине души.
Мой ответ Если б люди добирались до ценностей манифеста (которых 4) и принципов (их еще 12)... У очень многих цепочка рассуждений обрывается гораздо раньше: "непривычное -> много говорят -> фуфло" или "непривычное -> много говорят -> не для меня -> рационализируем". А потом другие читают подобную рационализацию, как в приведенной выше статье и получают подтверждение своей оценке. То есть срабатывает стереотип, отвергая непривычное. В принципе, хороший стереотип, позволяющий быстро принимать решения, особенно в современном мире.заполненном рекламой и информационным шумом. Только надо уметь во-время от него отказываться, чтобы не оказаться в прошлом. И начинать разбираться самому. А это было тяжело во все времена, люди часто глухи к новому. И, что интересно, даже реакция Грефа, который поглубже посмотрев на Agile почувствовал себя лузером(!) стереотипы многих людей не пробивает. Они ж лучше знают :) Вот так.
Так что правда - она есть, но не все включают ум, чтобы до нее докопаться.
Екатерина Филатова Максим Цепков )) у меня дилемма)) вы говорите справедливо, но я не понимаю, зачем вы это говорите. Всё правда.
Мой ответ Я это говорю чтобы побудить и автора комментария и, главное, читателей разобраться в Agile глубже, а не поверхностно отвергнуть непривычное.
Agile - это не религия. Это набор ценностей, позволяющих сотрудничать с миром и приносить ему пользу, и набор методов, способов и инструментов, позволяющих это сделать - первоначально в области IT, но сейчас это расширяется. Познакомившись с ними и начав применять можно работать лучше. Естественно, выбирая конкретные инструменты из большого набора, подходящие для конкретной задачи.
Екатерина Филатова Максим Цепков теперь поняла. Мне свойственно иронизровать. Иногда это приводит в замешательство. Религия - это метафора. Сам по себе "эджайл" не инструмент. Инструменты внутри этой красивой коробочки, как 10 заповедей внутри религии.. мы опять же говорим об одном и том же, но под разным углом. Мне метафора про карнавальную ночь понравилась. Она иллюстрирует эджайл.
Мой ответ Понятно. Просто сравнение Agile с религией я слышал от многих с негативными коннотациями - как тотальную догматичность мышления его сторонников. Догматичные сторонники, конечно, тоже встречаются. как у любой идеи, но их немного. Но к подобным сравнениям я поэтому отношусь настороженно. А мы с Вами действительно во многом говорим об одном и том же. И рад, что понравилась метафора.
И еще один содержательный тред комментариев Елена Верещага 25-28.12 (перенесено позже)
Максим, спасибо за столь подробный ответ на мой комментарий.
Признаюсь я несколько “утонула” в том объеме информации, которую Вы вытащили на поверхность данного контекста ))
Прежде всего, хочу сказать, что при углублении в тему - вижу довольно много общих точек соприкосновения - мысли, что Вы излагаете, мне также созвучны. И в этом права также Екатерина, которая заметила, что часто мы по-разному понимаем нечто или напротив - разными словами называем одно и то же.
Какие высказанные Вами идеи мне созвучны:
Далее под этим комментом я напишу еще несколько мыслей - в продолжение
С некоторыми суждениями я готова поспорить:
Максим, в любом случае, спасибо за Ваше неравнодушие, а также за стимуляцию лично моего развития в теме - Вы подняли достаточно большой пласт информации, куда стоит посмотреть.
Было бы интересно продолжить разговор предметно - разбирая конкретную практику из арсенала Agile и где она хорошо применяется, какие могут быть проблемы и почему.
Также замечу, что мы похоже, вышли за пределы круга Agile - все-таки не все *DD имеют к нему непосредственное отношение. По кр.мере, для меня эта связь на данный момент не очевидна.
Максим Цепков Елена, я очень рад, что мои комменты вызвали такой отклик. По пунктам, которые вы затронули в комментарии, я отвечу детально (только уже завтра), потому что их интересно разобрать конкретно. Но если говорить в общем, то у нас различается взгляд на логику развития ведения IT-проектов, которая породила Agile.
В Вашей логике Agile - преимущественно организационные практики (хотя не только они), которые родились как развитие проектных практик PMBOK и по мере вызревания были в него втянуты.
С моей точки зрения, Agile возник наоборот, как резкое отрицание PMBOK и вообще процессного подхода (который достаточно ярко проявился в RUP). Отрицание начал еще Том ДеМарко в 1987 "Человеческий фактор", и оно очень ярко выражено в первой редакции книги Бека Extreme Programming и Agile-манифесте, который как раз декларирует иные ценности. Далее он развивался, порождая собственные способы IT-разработки (Scrum - первый массово успешный из них), в том числе, используя ранее наработанные практики как источник идей, но сильно адаптируя их к собственным ценностям - в соответствии с диалектикой развития "тезис-антитезис-синтез". А когда успех стал очевиден - пошел еще обратный вектор.
При этом ряд людей восприняли Agile в конструкции ярко выраженного отрицания классического подхода и до сих пор это высказывают, возражая против синтеза.
Характерно, что наши различия во взглядах, как я вижу, больше касаются именно представлений о логике развития, а вовсе не взгляда на идеальное представление об IT-разработке, которое у нас обоих синтетично включает множество практик.
Елена Верещага Максим, спасибо за интересную дискуссию! Буду ждать Ваших детальных комментариев. А "свою историю" про Agile я напишу позже - уже видимо, послезавтра ))
Максим Цепков Елена Верещага Отвечаю по пунктам, как обещал.
1. Про Agile и PMBOK я уже написал в своем комментарии, они противопоставлены логикой развития, и тем, что для нас целое - Agile, втянувший лучшие практики классического подхода, или наоборот, классические подход, втянувший (с моей точки зрения - лишь попытавшийся) втянуть лучшие практики Agile. Для меня Agile и классика - это разные mindset, конструкции устройства мира. При этом я понимаю и могу рассуждать в обоих, но Agile считаю следующим этапом развития.
2. Долгосрочное планирование является проблемным независимо от Agile, про это есть множество исследований. И интеграционное взаимодействие тоже. Так что "а у нас Agile" - это просто очередная причина. Если смотреть глубоко, то Agile утверждает следующее: (а) долгосрочное планирование не должно быть фетишем; (б) трезво оценивайте свою способность к реалистичному планированию. И дальше как практический способ - держите product backlog на том горизонте, на котором можете, на коротком горизонте (1-3 месяца) он должен быть конкретным и пригодным для детального планирования спринта, а на длинном (полгода и более) - достаточно детальным для представлений о развитии продукта. Сроки - ориентировочные. В обучение Product Owner'а это входит (правда, я проходил тренинг Jeff Patton, он гуру, говорят, все бывает по-разному).
Что касается интеграции. в том числе от разных подрядчиков. то как только Заказчик жестко требует 2-3 недельного периода выпуска обновлений на пром, подрядчикам просто некуда деваться от налаживания интеграционного тестирования. На эту тему есть характерный кейс Ростехнадзора (там подрядчик у 17 подсистем был один, но команды разные). Классический выпуск приводил к тому, что после релиза раз в полгода комплекс 1-2 месяца приводили в чувство, а трехнедельные релизы это устранили. Кейсу уже 4 года, Заказчик счастлив. Подробности можно посмотреть http://mtsepkov.org/GosAgile-2015-11 (рассказывала Марина Макарчук, она - Заказчик).
Подводя итоги: трудности есть, но они не в методах, а в головах. Метод как раз жестко нацелен на то, чтобы проблемы были решены, ты не можешь выдать DoD "мы внедрили метод", не решив эти проблемы.
3. Я тут посмотрел автора поглубже. Если пойти на сайт компании, где автор - CEO, то компания ПРОДАЕТ Agile и DevOps крупным заказчикам. Либо автор продает то, во что не верит, либо журналист исказил его мысли до неузнаваемости. И получается. что к статье нельзя относиться, как к мнению эксперта. При этом, помимо CEO в компании два человека "старой школы"...
Конечно, Agile проще внедрять в маленьких компаниях, но это - вообще тривиальная мысль. Что, скажите, сложнее делать в маленьких компаниях. чем в больших? Разве что вести себя деструктивно и насаждать бюрократию :) Так что эта мысль не стоит большой статьи. Автор-то при этом ничего не пишет про то, как в больших компаниях это делать. А за развитие Agile тут наработаны практики и методы, например, SAF.
Xто касается "инноваций раде инноваций", то мы тут недавно обсуждали это дело, и возникла гипотеза, похожая на правду, что ряд менеджеров внедряет новое как приобретает новые гаджеты - все надо попробовать. При этом еще есть исследования, которые показывают. что регулярные изменения для компаний в целом очень полезны :)
4. Continuous Integration, на мой взгляд, must уже 10+ лет (хотя я понимаю, что есть реликты), с delivery сильно сложнее. Тем не менее, есть крупные компании (например, badoo), где это реально применяется. Есть много разных практик, как это делать, в том числе для разных сложных проектов. Включая DWH, такие рассказы я тоже слышал. Фишка в том, что при непрерывной поставки мы делаем малый квант изменений, который проверить и даже исправить гораздо проще, чем большой. И в некоторых компаниях именно так и делают. Если интересно, можно обсуждать уже технические задачи, опыт организации обновлений при том, что работа идет с большими массивами данных у меня есть.
5. Неправильно выстроенные процессы и отсутствие головы у тех, кто их выстраивал приводят к большим проблемам независимо от того, по какой методологии это все делается. А крики про то, что нельзя оперировать сроками больше 2 недель свидетельствуют лишь о незнании предмета кричащими.
На самом деле, в Agile есть довольно много практик работы с требованиями. Userstory с планированием релизов по MVP. Use case, как альтернативный вариант, при чем он не так давно был довольно интересно адаптирован Якобсоном для гибкого планирования (UseCase 2.0). Domain Driven Design для корпоративной разработки. Сложная архитектурная работа в SAF.
B при этом есть отдельные практики. касающиеся того. как предотвратить необоснованные метания, но сохранить требуемую гибкость. Ведь основная-то проблем - именно в тоем, что характерный временной лаг изменений бизнеса во многих областях - 2-4 недели. И IT должно успевать, иначе оно становится ограничением для бизнеса. Такой сейчас мир.
Елена Верещага Максим Цепков , спасибо! Как всегда - детально и обстоятельно.
Позже соберусь - и тоже приведу примеры.. А сейчас за неимением времени отвечу коротко.
В моем понимании "чистых методологий" не существует - ни Agile, ни RUP не внедряется в чистом виде - а "пилится под себя". То, что развитие состоит в том, что отрицаются некие предыдущие подходы - да, в этом собственно оно и состоит. Но никогда я не видела внедрение какой-то методологии "из коробки". А всякие попытки сохранить "чистоту подхода" как раз и приводят с высокой вероятностью к провалу. Однако соглашусь с Вами, что есть ключевые принципы - и их надо придерживаться - ради чего это и затевается (нужно понимать - какая проблема прежнего подхода решается и за счет чего). Вот тут как раз хотелось бы остановиться подробнее. Но не в этот раз ))
И в чем, мне кажется, мы с Вами сходимся, но как бы с разных сторон - это в том, что во многом все зависит от специалистов, применяющих метод, нежели от самой методологии. В хороших руках любая методология будет "жить". Проблемы провалов связаны как правило, не с методом ведения проекта - а как оно делается.
Долгосрочное планирование - всегда сложность и искусство. Проблема в том, что многие с криками "у нас Agile" на это забивают. Действительно - зачем, раз так сложно? Проще с шашками.
И поймите - я не против Agile. Я за! )) Я прекрасно вижу ограничения того же RUP. Там есть хорошие идеи и в этом есть развитие. НО! Меня коробит, когда это романтизируется, охватывается ореолом "инновационности" и преподносится как "серебряная пуля". К тому же он вовсе не в-новинку - об eXtreme Programming заговорили (а кое-где и внедрили, правда те еще приколы были) более 10 лет назад...
В любом случае - продолжаем беседу... Обменяться живым опытом (как + , так и -) всегда интересно! ))
Максим Цепков Про внедрение методологий подход классики (RUP, PMBOK) и Agile тоже кардинально отличается. Классика говорит - возьмите исчерпывающий многостраничный guide, вычеркните ненужное и используйте. Agile говорит другое - возьмите простой метод "из коробки" - Scrum, Kanban, внедрите "как есть", а потом - запустить совершенствование, точки, где это происходит процессно встроены в метод (ретро). При совершенствовании - используйте набор практик как готовый, а не подходит - придумывайте свое. Но при этом есть иерархия сверху-вниз, от ценностей и принципов к конкретным практикам, и трассировку надо сохранять.
В инновационности и романтике надо разбираться более конкретно - потому что в чем-то она есть, а в чем-то - нет. XP и Scrum появились 15 лет назад, но при этом продолжают развиваться, а применение Scrum вне IT, что сейчас делают - является определенной инновацией. То есть надо работать прагматично.
А те, кто продает серебряные пули и светлое будущее - они были, есть и будут, и будут продавать все новое, вернее, все КАК новое. Их породил маркетинг начала 20 века. Это не проблема Agile, это особенность развития современного мира. А он - таков как есть, другого у нас нет, живем в этом.
И да, продолжаем беседу!
Я, оказывается не рассказывал в блоге про песни, только в ЖЖ и на facebook. А было вот как. Когда я слушаю некоторые песни - то у меня в голове разворачивается цепочка образов. И у меня была давняя мечта - чтобы эти образы появились в виде мультика, стали доступны. На встрече ПИР, благодаря вечерним посиделкам с песнями под гитару и рояль, скрайбинг-летописи ПиРа, общению с Сергеем Гевличем, автором объясняшек, у меня сложилась мозаика и я понял, что технология, с помощью которой я могу осуществить свою давнюю мечту - увидеть мультики по некоторым песням - готова. Интересно, что про [http:xplainto.me объясняшки] я знал уже несколько лет, но вот все вместе сложилось только на ПиР.
Первая песня, которую я выбрал - "Дракон" Суханова. Я написал Сергею, он порекомендовал Елену Смирнову, художника - и получился прекрасный мультик. Я его выложил на youtube и рассказал об этом в ЖЖ и на facebook.
Думал, потом будет перерыв. Нет. Идея следующей песни пришла почти сразу и результат вы видели. Сохраняю тут ссылки youtube,ЖЖ, facebook. В процессе работы был альтернативный вариант, на совсем другое исполнение - Никитин и К, несколько голосов. Елена его тоже дорисовала.
Главная фишка состоит в том, что технология объясняшек - дешевая и общедоступная. Программа создавалась не как профессиональный инструмент для мультиков, а как широко доступный инструмент видеопрезентаций. Он такой получился, я сам видел, как ролики в нем делаются за пару часов, правда сначала надо придумать сюжет и текст, на это тоже пара часов уходит. И он доступен - я знаю, что некоторые учителя обучают детей на факультативах, и те дальше используют его как форму сдачи докладов и других школьных тематических работ. Так что мультик, получается, может нарисовать каждый. Правда, iPad нужен, но это не очень большая редкость.
А теперь - Дракон.
Публикация в FB вызвала довольно много репостов. В публикации в группе AgileRussia было интересное обсуждение - Алексеей Пименов, Слава Цирульник, Tony Granton, Владимир Каленов, Сергей Баранов.
Из отзывов ведущих
Запись видео
Войдите, чтобы комментировать.