Викилоги

Сегодня прошел день тренингов на 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, а необходимая и полезная деятельность. На сей позитивной ноте я закончу свои впечатления о курсе.

Поднятый недавно пост Стаса Блог:Стас Фомин/2010-07-02 Бибичев жжот! (Стас туда дописал ссылки и он поднялся в вики-форуме) навел меня на забавную аналогию. Взаимоотношения гиков и менеджеров напомнили мне взаимоотношения певцов (музыкантов) и их продюсеров. И певцы и гики отличаются коммуникативными особенностями разной степени, с которыми менеджерам и продюсерам надо работать. А еще - отличаются талантом, который, собственно, и обуславливает стремление менеджеров с ними работать, не смотря на эти особенности. А дальше - понятно, что продюсер (менеджер) делает многокритериальный выбор. Учитывая талант и потенциальную выгоду, учитывая свои накладные расходы, учитывая возможность получения аналогичного результата от менее талантливых, зато менее особенных творческих людей.

Интересно, что в масс-культуре многие менеджеры пошли по пути явного предпочтения исполнителей с почти полным отсутствием таланта, зато покладистых, ибо понимают свою заменяемость. Раскручивают их пиаром и делают свои деньги. Первая аналогичная попытка в мире программистов провалилась - это был unify process и иже с ними, попытка получения гарантированного результата без особого влияния кадров. А вот вторая попытка, на agile-технологиях, похоже рискует оказаться удачной. Тем не менее, наличие таланта и способностей продолжает оставаться важным.

При этом, что интересно, в интересах менеджеров как социальной группы - пествовать такой образ исполнителей (певцов или гиков), который даст им возможность зарабатывать на их труде, поощряя и сохраняя коммуникативные проблемы до такой степени, чтобы соорганизоваться и самостоятельно продюссировать себя они не могли. И пиар-способом гнобить талантливых и вменяемых лиц, которые-таки смогли обойтись без менеджеров - потому что они составляют прямую конкуренцию. Что, впрочем, не исключает альтернативных способов донесения своего результата до людей - через интернет это достаточно просто, только денег там в среднем существенно меньше, хотя отдельные большие успехи безусловно имеются.

Какая-то такая конструкция получается...

А еще - каждый разработчик (как и любой человек) может сам выбирать, в какую сторону ему двигаться, как взаимодействовать с окружающим миром и какие свои стороны развивать. В наш век управления через мемы и масс-культуру самостоятельный и разумный выбор становится более важным, чем раньше, и пока этот тренд будет лишь нарастать.

В пятницу 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 и позволяет визуально прототипировать интерфейс - внешний вид экранов, последовательность экранов и интерактив. Хотя и без данных. Надо будет посмотреть.

Как обычно, в выходные в конце июня, двухдневный Летний аналитический фестиваль в Иваново. Организует сообщество системных аналитиков, площадку дает Консультант-плюс - поэтому в Иваново. Как обычно - это уже третий год, и в этом году было настолько много желающих, что регистрацию закрыли сильно рано, когда набралось 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 Оба рассказа были приняты хорошо, темы были актуальны и вызвали много вопросов и обсуждений.

Надо отметить, что два первых слота из-за своего выступления я пропустил, и жаль - по отзывам, там были хорошие доклады. Так что смогу рассказать только про то, что слушал.

→ продолжить чтение…

Сегодня был на AgileKitchen. Позитивно и весьма характерно: хотя я на подобных событиях бываю часто, и опыт у меня достаточно большой, три новые идеи - получены. Стоят ли эти идеи целого рабочего дня? Не знаю. Что они стоят моего выходного дня - я для себя решил.

А сами идеи вот.

1. Из доклада Андрея Реброва об инструментах автоматизированного тестирования - о том, что VS Test использовать скорее не стоит, чем стоит. Потому что скрипты он записывает, но результат сопровождать и изменять - весьма дорого, он плохо читаем. В общем-то услышав это явно я как-то вспомнил, что VS как инструмент тестирования на конфах не слышно, пользуются другим. Теперь узнал почему. А в целом в докладе был хороший обзор средств автоматизированного тестирования. Для меня лично других открытий не было, но многие участники - узнали для себя новое.
2. Из доклада Александра Тупикова узнал об интересном методе разбора фейлов - выученные уровки (не путать с вымученными уроками). Идея состоит в том, что в случае фейла он анализируется и формулируется как урок на будущее и фиксируется в определенном формате. И это - не наказание и не объяснительная, это именно уроки для предотвращения ситуаций. Ведется библиотека таких уроков, они классифицируются, выдаются новым сотрудникам и повторяются когда это уместно. А уж если люди упорно не учат уроки - тогда делаем выводы и наказания.
3. Еще из доклада Александра Тупикова - интересная практика самооценки. Все сотрудники регулярно (ежемесячно) пишут своим руководителям и HR свою самооценку. А дальше - получают по ней обратную связь. Очень эффективный инструмент (при нормальном климате) - так как позволяет работать с ожиданиями и оперативно реагировать. Только обратная связь должна быть искренней, и обязательно объяснять, если ожидаемое сотрудникам при высокой самооценки вознаграждение почему-либо не следует.

А еще - был интересный доклад Асхата - работа как игра. С идеей, коль уж такой тренд явно присутствует и востребован - начать применять при организации работы все то, что наработано дизайнерами игр для того, чтобы сделать их интересными. Рассказ Анастасии Тарасенко о создании команды, которая не просто кодит, а решает реальные проблемы заказчика и увлечена этим, и потому работа приносит удовлетворение и счастье. Правда, как она сама говорит, именно описываемый способ она видит только для маленьких компаний - что практически означает, в числе прочего, ограничение на размеры проектов. И success story Михаила Новикова о полном рефакторинге проекта путем создания нового с другой архитектурой и переходе на него.

А еще была интересная интерактивная конструкция, когда люди предлагали темы, у каждой из них был владелец за отдельным столом, а остальные, тоже сев за столами обсуждали 10 минут, а потом - перемещались так что в конечном итоге каждый поучаствовал в обсуждении каждой темы. Результаты - презентовались владельцами тем. Формат - любопытный.

На этом отчет - заканчиваю. Я не буду агитировать приходить на такие встречи, пусть каждый решает сам - это же его время. Но хорошо, что есть люди, которые на них приходят.

Будучи на 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 и контролировать разработчиков. Но количество визуализированных на диаграммах способов реализации в наших проектах, на мой взгляд, недопустимо мало, слишком многое находится в головах разработчиков, что влечет трудности для их эффективного развития.

В пятницу был на первой конференции аналитиков AnalystDays в Минске. Конференция определенно удалась. Было более 250 участников, 4 трека и многие из них очень интересны, а залы — переполнены. Так что я думаю, что за первой конференцией последуют другие, конференция AnalystDays продолжит работу.

Отдельной фишкой был начатый ремонт во втором зале, о котором организаторов просто поставили перед фактом. И предложили замену — шатер во дворе. С погодой — повезло, поэтому он оказался, скорее, фишкой, чем неудобством. Хотя Саша Байкин, который докладывал там первым, пострадал сильно — как оказалось, проектор там не виден совершенно, и приходилось делать доклад фактически без слайдов, переключая их для записи. Между слотами вместо проектора поставили телевизор, так что Дима Безуглый читал уже с приемлемым показом слайдов.

Обзор докладов в отзыве будет несколько ущербным, потому что являясь вдохновителем двух докладов от нашей компании, я считал необходимым поддержать докладчиц и быть на их докладах. Все-таки, это — их первая конференция и они очень волновались. А еще — участвовал в Круглом столе по работе с гос.органами. Итого — про 3 слота из 10 я ничего не знаю, а еще на некоторых — общался вместо того, чтобы слушать. Потому что доклады можно послушать и посмотреть в записи, которую уже больше полутора лет обеспечивает Стас Фомин на конференциях Влада, благодаря чему конференции живут и после окончания. Кстати, под влиянием этого и другие конференции задумались о проведении записи. Но вот возможность общения — она не предоставится. Тем не менее, о тех докладах, на которых я был — расскажу.

Начну я с докладов Ани Рид и Вали Ломаевой из нашей компании, CUSTIS. В обоих основной темой является DDD (domain driven design), но под совершенно разными углами зрения. Аня — HR и она рассказывала, как связаны практики DDD и развитие аналитика, включая набор персонала, начальное погружение в проект и процесс дальнейшего развития. Аня очень волновалась, потому что когда HR рассказывает аналитикам о методике их профессиональной деятельности — можно ожидать всяких сюрпризов. В общем-то волнение ее отчасти подвело — доделывая презентацию перед самым докладом она переписала на комп конференции не последнюю версию, но обнаружила это только в середине доклада. Несмотря на это, в целом доклад, на мой взгляд, удался и вызвал интерес. А Валя рассказывала об опыте применения DDD для работы с требованиями на примере конкретного крупного проекта для Росатома в условиях постоянного и изначально заложенного в проект их активного изменения из-за параллельно выполняющейся доработки законодательной и нормативной базы. Идея — показать, как применяя DDD можно вселить в заказчика уверенность, что разрабатываемая система удовлетворит их требованиям, даже в условиях, когда эти требования с определенностью неясны, а имеются только общие представления или многие варианты решений и бизнес-процессов, которые лишь предстоит согласовать. Если я Вас заинтересовал — смотрите видео.

Дальше хочется отметить доклад Пола Тернера The impact of Systems Thinking on the Business Analyst role. Пол говорил о ментальных моделях и о мышлении. О тех изменениях, которые меняют верхнеуровневую картину системы и потому подлежат особому контролю. О малых решениях из локальной оптимизации, за которые приходится платить большую цену, потому что они ломают цельность. К сожалению, на мой взгляд, в докладе не хватает более конкретных примеров, потому что на уровне слов и общеизвестных историй про слепых, осматривающих слона это понятно, а в практике, тем не менее, возникают проблемы. Однако, я по своему опыту знаю, как сложно такие реальные примеры делать — потому что для понимания они часто требуют большого контекста из конкретного проекта, а его у аудитории, естественно, нет

В конце доклада Пол рассказал метафору о пути: для успеха надо знать где сейчас, куда хотим, как пойдем и как узнаем, что дошли. И она хорошо легла на мои мысли об отличиях между японским и европейским подходам к процессам, о которых я писал в посте про SQA days. Описанный европейский подход хорош, когда у нас есть карта, а местность — предсказуема. Тогда можно замечательно спланировать маршрут и ему следовать. А вот если мы идем по болоту, то все сложнее: карта не говорит, на какие кочки можно встать, а сами кочки еще и норовят провалиться, так что шаг надо делать быстро. Или, другой вариант — переход по сложным горам: из карты неизвестно, насколько конкретные склоны проходимы, а еще — ночевать можно лишь на относительно ровных площадках, тоже особо на картах не обозначенных. В обоих случаях локальный выбор пути является актуальной задачей с временными ограничениями, и ошибка в этом может вполне провести к провалу в крупном. Так вот. поскольку бизнес-процессы тоже сами произвольно портятся или несогласованно изменяются, акцент на важности текущих решений уместен. Впрочем, я об этом, наверное, напишу отдельную статью.

А после обеда Пол Тернер и Адриан Рид проводили большой мастер-класс Practical Techniques for early use in BA cycle на 4 слота. У меня получилось быть маленьком кусочке и надеюсь, что посмотрю запись полностью. Они рассказывали большое количество техник, по которым группы последовательно шли по разным проектам, выполняя задания. Среди них: PESTLE analysis; five forces analysis; MOST; Resource audit; SWOT analysis; kind business problem — actualy, risk, opportunity; способы визуальной работы над решением проблем — rich picture, mind map, fishbow; работа со stakeholder в зависимости от их роли… И это — сильно неполный список.

Дальше пойдем по порядку докладов.

Вадим Мустяца, Deeplace. Живые вики как оперативные базы знаний. Рассказ был основан на опыте внедрения на конкретном большом проекте вики как системы ведения материалов. При этом докладчик пришел на проект, которому было уже два года, и получил на входе файловое хранилище документов различного качества и слабой систематизации, и задачу — закрыть аналитику и сделать еще 160 отчетов. Он поставил использование rizzoma.com, которая тогда была еще google wave. В докладе Вадим не просто рассказал об использовании, он сопоставил вики с общим контентом верхнего уровня — онтологию представления знаний. А вот сопоставления с другими вики-системами и практиками их использования — нет. Это определенный недостаток для тех, кто этого контекста не знает — потому что по ряду пунктов будет смещенное знание. Но для итого, кто контекст представляет, такой взгляд показывает неожиданные грани предмета. Как пример такого взгляда — вики как месседжер, что достигается через совместное редактирование.

Оксана Сергеева, EPAM. Специфика работы бизнес-аналитика в зависимости от типов проектов и методологий (мастер-класс). Я заглядывал кусочками, зал мастер-класса был переполнен. Основная мысль была очень правильная — процесс управления должен быть адекватен потребностям конкретного проекта, и процессы могут быть сильно различны, в то время как на практике об этом задумываются редко, менеджеры предпочитают использовать знакомые процессы. Но вот позиционирование практики в теорию — оно забавно: «возьмем итеративный процесс, например RUP». Ему противостоит Agile, о котором сказано «наверное, доморощенный», и без деталей «каждый проект что-то свое придумывал». С моей точки зрения, это — еще одно свидетельство того, что практики — не слишком склонны разбираться в тонкостях теории, применяя слова как мемы, за которыми стоит не определение, а набор ярлыков-ассоциаций. Это явление хорошо известно по массовому сознанию и, собственно, мемы и являются способом управления современным обществом (доклад Дмитрия Пескова на KM Russia-2011), и оно же работает в профессиональной среде.

Юлия Михайлова, EPAM. Записки аналитика: как бежать впереди паровоза и не попасть под него. Хорошая и понятная success story с выводами. Аналитик доказывал нужность и роль — на входе его воспринимали как технического писателя, по опыту предыдущих аналитиков. А проект — большой, с внешним большим заказчиком, у которого некоторые фичи не имеют единого владельца. Контент мне лично понятный, но наверняка очень полезный для людей с меньшим опытом, и не только начинающих.

Мария Бондаренко, Generation_P Consulting. Анти-паттерны аналитика: Как «провалить» продуктовую разработку. Был на кусочке доклада, потому что не совсем моя тема, мы не занимаемся продуктовой разработкой, но опыт такой — был, мы делали тиражируемую систему. Доклад хороший и качественный, о тех ошибках, которые может совершить аналитик, когда компания решает на основе заказной разработки сделать тиражируемый продукт. С конкретными примерами ошибок аналитика: ориентация продукта на одного клиента, ориентация на дозапросов текущих клиентов в ущерб развитию и так далее. Ошибки все сложные потому что в них надо искать правильную точку баланса интересов, а это — сложная задача.

Николай Киреев, ИИТ БГУИР. Практический анализ по RUP (мастер-класс) Сюда я тоже зашел на маленький кусочек, и зал тоже был переполнен. На примере конкретного проекта докладчик рассказывал, как проводить анализ, создавая модель из обычного текстового описания, получаемого из заказчиков. Как правильно классифицировать сущности, отличать важное от неважного в контексте конкретного проекта, избегая, например, излишне подробного атрибутного описания, не соответствующего роли объекта, а это типичная ошибка. Целевой рамкой модели выступала модель с точки зрения RUP и, с моей точки зрения, в этом есть определенный недостаток — потому что RUP-модель сама по себе сложна и многообразно, и требует хорошего владения. Но все равно, конкретные примеры анализа с примерами — они ценны и, думаю, не только для начинающих аналитиков, но и для более опытных.

Денис Гобов, Арт-мастер. Выстраиваем процесс управления требованиями. Перед организацией стояла вполне конкретная задача — выстроить свою систему управления требованиями таким образом, чтобы проходить аудит соответствия CMMI и RMM-6. И они сделали систему управления требованиями на базе Jira, которая это обеспечивала? выдавая нужные отчеты с трассировкой и детализацией. О которой и было рассказано в докладе. Очень полезно для тех. перед кем стоит задача сертификации, но и остальным может быть интересно потому что управление на основе интегральных показателей из системы ведения дел — в любом случае актуальная задача и опыт — полезен.

Денис Бесков, Школа Системного Анализа. Управление требованиями VS Разработка требований. Принципы и инструменты Основная мысль доклада состояла в том, что управление требованиями, в отличие от их разработки, является не аналитической, а менеджерской задачей. Потому что включает вопросы границ проекта, а это бюджет, scope против денег. И вопрос релизов, приоритеты требований — тоже связаны с управленческими согласованиями. Поэтому когда управление требованиями полностью передают аналитикам без соответствующих полномочий, оно не работает. Хотя аналитическая часть работы безусловно присутствует.

Александр Кондаков. Оценивания по CMMI как… источник вдохновения. Неожиданно интересный доклад, что не предвещалось ни названием, ни аннотацией. Он наполнен историями, с которыми автор сталкивался, проводя оценки по CMMI и gap-анализ перед оценкой. О том, почему не делают те или иные практики: некогда, работу делать надо; у нас люди умные — им не надо учиться. О том, какие практик обычно есть и в каком виде. О результатах хорошей оценки, которая обычно стимулирует реальный рост компании, а не просто выдает гору бумаг. А еще — о графике роста профессионала-аналитика и новой интересной позиции CPO, Chief Process Officer, которая появилась недавно.

Екатерина Макаренко, TEAM International. Техники аналитика — CATWOE, H-METHOD, MOSCOW, SQUARE. Начало доклада я пропустил, а зря. Екатерина рассказывала о большом количестве конкретных методов аналитика, которые, собственно, перечислены в названии доклада. Например, MOSCOW, который по ее опыту позволил обеспечить реальную приоретизацию требований в контексте релизов. А SQUARE представляет собой фреймворк для требований по безопасности, который позволяет перевести эти требования в разряд функциональных. Эта часть рассказа была на примере конкретного проекта, который изначально был сделан вообще без требований по безопасности, а потом оказалось что они есть и жесткие, проект — банковский. Что ценно — это не методика, а фреймворк, имеющий шаблоны и поддерживающие средства, что позволяет пользоваться даже новичками, набираясь опыта. А еще в методе есть довольно много практик, которые применимы не только к требованиям по безопасности, а могут использоваться для других видов требований. А еще — был рассказ про способ трейсинга требований и их изменений по функциям, причем в условиях. когда за время развития проекта было использовано несколько вики-систем и систем ведения дел, и там были конкретные приемчики, сильно облегчающие работу. Например, при изменениях не только ссылаться в новом деле на предыдущее, но и цитировать формулировки — чтобы поиск это подхватывал.

На этом — все.

Был на ADD-2012. Посмотрел на передний край разработки. Не на тот, где гиганты презентуют новые решения, и не на высокую науку, а на тот, где практики работают и мыслят о движении вперед. Где рассказывают о своих идеях.

Вообще тут нужно отступление об устройстве мира разработки. Многим представляется, что там есть форпост в лице известных и успешных гигантов разработки, таких как Microsoft, Google, Oracle и им подобных,откуда исходит все новое, а остальные - они просто этим пользуются. Как источник новых идей еще рассматривают науку, из которой тоже могут приходить новые идеи, которыми эти гиганты тоже пользуются. Но не нашу науку, а западную, естественно.

Так вот, реально дело обстоит совсем не так. Причина этому - в творческом характере разработки. Я вполне согласен с достаточно старой и известной теорией Jack W.Reeves What is software design (Корешков/Продукт_инженерной_деятельности_(в_разработке_ПО) русский вариант), что разработка ПО соответствует проектированию в других отраслях. А потому все, кто занимаются разработкой - они порождают новые оригинальные идеи, а вовсе не следуют чужими путями. Естественно, при этом идет массовое заимствование, использование чужих идей в своих разработках - но комбинации тоже являются оригинальными. Если смотреть на аналогии вне IT, то ближайшей, на мой взгляд, является рынок бытовой электроники, на котором сотни фирм производят множество мобильников, телевизоров, пылесосов и других разнообразных вещей, каждая из которых спроектирована более или менее уникальным образом, чем-то отличается от других, и потому идеи, которые при ее проектировании были придуманы - могут представлять интерес. А в IT это же можно сказать про каждую разработку, потому что программный продукт - это индивидуальное, а не массовое производство.

Интересно, что заблуждение об отсутствии интересных идей в повседневной работе разделяется и большой частью самих разработчиков. И не только теми, кто реально воспроизводит в своей работе чужие идеи, или просто делает рутинную работу, решая в моменте сиюминутные задачи - это заблуждение разделяют и те, кто порождает новые идеи в своей работе. Они не кажутся им интересными и стоящими внимания других, стоящими рассказа на конференциях. Такой вот парадокс.

Но - не все таковы, и ADD - это площадка для тех, кто хочет рассказать о своих новых разработках и идеях, часть из которых еще только предстоит реализовать. И они, кстати, совсем не боятся, что эти идеи кто-то украдет. Потому что если идеи сильно понравятся - то люди, наоборот, придут к ним, чтобы участвовать в реализации совместно. А если идеи окажутся уместными в другом продукте, другой области, то это тоже хорошо и сделает мир лучше. А еще, что важно - это идеи практиков, работающих и выпускающих реальные продукты. И они обычно представляют - чего стоит довести эти идеи до практической реализации. И это придает их выступлениям вес.

Еще там рассказывают об опыте использования совсем новых или даже разрабатываемых продуктов. И это - тоже очень ценно, потому что применение нового продукта для решения практических задач - это совсем не то, что презентация продукта, там вскрывается множество нюансов и особенностей. К тому же, если продукт открытый, первые пользователи часто становятся со-разработчиками. А продуктов - их появляется много, потому как разработка сосредоточена не только в фирмах-гигантах, она сейчас распределена по площади, и многие программисты, делая свои заказы, создают также инструменты для себя, делая их общедоступными.

Ну а участники - они слушают. Но слушают активно - обсуждая в перерывах, подавая активные реплики во время выступлений, высказывая альтернативные точки зрения. Кстати по высказыванию альтернативных идей в репликах из зала эта конференция - наиболее живая.

Сам я в этот раз не выступал - потому что сейчас занимаюсь проектированием систем, а не разработкой и потому мои идеи более уместны на других конференциях. Так что я был просто в роли наблюдателя, смотрел, что происходит на переднем крае разработки. К сожалению, только второй день - в первый была несдвигаемая встреча на работе, увы. Поэтому мои впечатления явно неполны. Что делать...

Так вот, если говорить об основных темах и впечатлениях для меня, то это новые языки и NoSQL базы данных. Темы не новые, но они интенсивно развиваются, и это развитие - интересно смотреть. Об этом было много докладов. Если говорить об языках - то это новый язык Kotlin, который делает JetBrains для JVM, это развитие Groove, Scala, Nemerle, отчасти F#. И это только в один день конференции. Интересно, что в рассказе про Kotlin сказали, что новый язык для JVM независимо начали делать JetBrains, RedHat и Eclipse. А на докладе про Groove докладчика спрашивали - стоит ли сейчас начинать его использовать, или лучше дождаться Kotlin.

А еще - если в одних докладах про Scala учитывают, что часть аудитории ее не знает и делают приличное введение, то в других - уже используют Scala как общеизвестный язык, на котором удобно давать компактные примеры для пояснения мыслей докладчика. Это как раз то самое движение переднего края отрасли в ощущениях.

Про NoSQL базы данных - рассказывали об опыте использования конкретных баз, которых много, со своими плюсами и минусами, область интенсивно развивается и безусловных лидеров там нет.

Еще есть все более развивающаяся тема принципиально другого подхода к разработке, при которой принципиально учитывается ненадежность железа и его сбои - речь идет о высоконагруженных приложениях, работающих в распределенной среде, в кластерной архитектуре, в которой отдельные узлы статистически могут выйти из строя, и выходят. А еще - они могут падать из-за ошибок программистов разных уровней. На работу именно в такой среде ориентированы как многие NoSQL базы данных, так и архитектуры на основе модели акторов - Erlang, Akka. Что интересно, когда на подобном железе работают и традиционные промышленные базы данных, например, Oracle, то вопросы надежности и замены узлов они берут на себя, обеспечивая дублирование или подобные вещи и выдвигая требования к конфигурации. И программист может работать в парадигме абсолютно надежной среды, о которой позаботятся админы. А вот сейчас от такого подхода начинают отказываться. Такая надежность оказывается несоразмерно дорогой по сравнению с ущербом от потерь. Поэтому разработчику предлагается самому о ней позаботится на верхнем или среднем уровне. Например, заказать дублирование некоторых данных на нескольких узлах. Или для критичных входящих запросов - позаботится о проверке, что запрос был принят и обработан, а не пропал по причине крэша ноды системы, а если нет - запустить еще раз. И эта парадигма начинает распространятся из социальных сетей, где надежность, в общем-то, не слишком важна, в область таких приложений как, например, электронные аукционы. Кстати, разработка в облаке тоже не дает надежности - в датацентры амазона, например, попадают молнии, выводя их из строя вместе с данными, и оказывается, что такие кейсы в модель надежности заложены не были.

Еще было две актуальные темы - разработка мобильных приложений и разработка в облаке, но на эти доклады я не ходил - потому что из 3 треков надо было выбирать. Так что тут рассказать не могу, кроме очевидной вещи, что мобильная разработка все больше сближается с обычной, благодаря распространению планшетов и нетбуков устройства образуют практически непрерывный спектр...

Общаясь с программистами и менеджерами на SPM-conf в Питере, я первый раз четко для себя сформулировал, что есть два мира программистов, отличающиеся духом фирм, в которых они работают. Под программистами я дальше буду понимать всех сотрудников в IT-разработке, чем бы они не занимались - разработчиков, тестировщиков, аналитиков, менеджеров. Так, для большинства современных программистов работа имеет смысл не только как способ зарабатывания денег, но и для самореализации. И самореализация часто даже важнее. И есть фирмы, которые это понимают, и создают обстановку, в которой эта самореализация является частью работы программистов. Там держат фокус на связанных с этим вопросах, обсуждают, ищут компромиссы и баланс интересов. Понимая, что хотя это и влечет определенное беспокойство, на выходе мы имеем заинтересованность сотрудников и их лучшую работу. А есть другие фирмы, где самореализация оставлена на личном уровне для сотрудников. А фирма с ними общается исключительно в терминах производственных интересов. Соответственно, самореализация там происходит не так чтобы совсем вопреки, но трения - присутствуют. Все это хорошо проявляется в оценке руководства. В первых фирмах руководство - тоже часть коллектива, "мы". А во вторых - некие "они", с которыми надо взаимодействовать весьма аккуратно.

Так вот, это разделение образует два мира, которые слабо понимают друг друга. Первые - не очень понимают, зачем работать в таких фирмах, где руководство - "они". А вторые - убеждены, что большинство фирм устроено как у них. Разве что какие-нибудь сияющие высоты типа Google или Яндекс, и еще какие-то странные фирмы устроены иначе. Но по-любому таких мало, а доклады про иное отношение - больше пиар, чем правда. Хотя мой опыт говорит о том, что первых фирм сейчас - достаточно много.

Надо отметить, что есть люди из первого мира, сознательно работающие в фирмах второго типа, понимающие почему они так делают. Обычно это связано с определенными профессиональными возможностями и интересами, которые можно достичь только в конкретных фирмах, например, в крупных государственных организациях или узкоспециальных областях.

В общем, это наблюдение подтвердилось и на последующих конференциях. Но на SoftwarePeople-2012 из общения в кулуарах я понял, что есть еще и третий мир. Там программисты работают по 60-80 часов в неделю, прихватывая выходные. И они свято уверены, что так обстоят дела во всех фирмах, так что искать альтернативы нет особого смысла. Еще они обычно считают, что они получают хорошо для своей работы, иногда сравнивая зарплаты с интернетом. О разнице между их фирмой и другими местами, где эту зарплату платят за нормальную рабочую неделю - они не подозревают. Так что на собеседования они не ходят, пока не припрет - потому как при такой рабочей неделе времени на это просто нет. Собственно, на конференции я услышал историю, как кандидат просто заснул на собеседовании, объяснив, что устал сильно - пару недель пришлось работать по 80 часов. Я вспомнил ранее слышанные подобные истории, в том числе от тех, кто пришел к нам работать. Поговорил с нашими HR - они подтвердили, есть соискатели которые несколько недель не могут дойти до собеседования потому как работают с 9 до 21, а иногда и выходные прихватывают. Так что третий мир - он есть. И люди в нем - не подозревают не только о первом мире, но и о втором. Потому что по конференциям не ходят, в интернете особо не сидят - им некогда, они работают.

Но мне кажется, что правильно найти способ рассказать этим людям о существовании других миров. Чтобы дальше они уже сознательно выбирали - где и как они хотят работать. Но я не сильно понимаю - как, по каким каналам. Разве что через личные связи. И для начала я решил рассказать о наличии этого третьего мира у себя в блоге. Потому что когда я поделился этими наблюдениями на кухне у нас в компании, то оказалось, что большинство разработчиков не знают о существовании третьего мира, и не верят в его возможность. Хотя ссылки на конкретные истории - их убедили. В общем, по моему это достойная гуманистическая миссия просвещения :) И я призываю всех принять в ней участие.

Второй день весенней SQA Days 2012 в Киеве был достойным продолжением первого. Было много достойных докладов, о которых я напишу. Правда, после обеда я три слота пропустил - Susumu Sasabe и Yaron Tsubery, чьи выступления мне очень понравились в субботу отвечали на вопросы и это надо было слушать: доклады можно посмотреть в трансляции, а это - нет.

Слушая Susumu, я осознал принципиальное отличие японского способа мышления от западного (американского и европейского) в представлении процессов. Западный человек представляет процесс как объект, статически - картинка as is. Если его зачем-то надо изменить - ставим цель, рисуем картинку to be. И меняем. Если изменения велики, то ищем траекторию as is ⇒ to be, вырабатываем план и меняем по плану. Японцы же знают, что процесс сам по себе изменчив и всегда держат в голове траектории их изменения. Когда Susumu говорил о разных процессах, а он в своих ответах описывал их несколько, он всегда держал эту траекторию изменения, представлял их. И, собственно, японский подход непрерывного улучшения - он как раз опирается на это представление, работает на сознательный выбор траектории, ведущей к улучшению.

Надо сказать, что это не имеет никакого отношения к локальной оптимизации, о которой можно услышать при обсуждении подхода постоянного улучшения. Является ли ваша оптимизация локальной, или преследует более отдаленные цели зависит от того, сколько факторов вы учитываете, проводя выбор конкретной траектории развития. Важно, что у вас всегда есть семейство траекторий, и в моменте вы выбираете одну из них, которая далее - разветвляется. И имея ввиду эти разветвления - нельзя сказать к какому именно состоянию вы придете через некоторое время - это зависит от последующих выборов, которые вы сделаете в свое время, и с учетом изменившихся к тому времени условий. Сейчас же выбор делается на один шаг, и этот выбор - важнее четкого понимания цели, которая вполне может быть размытой. И в этом отличие от западного подхода, ориентированного прежде всего на видение цели, путь к которой представляется несколько вторичным.

Надо отметить, что практически различие в подходах невелико. Потому что цель в обоих, и траектория - тоже. И везде есть выбор следующего шага. А мир изменения процессов - не движение по городу, где можно выбрать неверный шаг и зайти в тупик, и хотя вы в целом двигались к цели, придется возвращаться. Тут проблема в другом - некоторые изменения требуют времени и подготовки, и уделяя внимание локальным или очевидным улучшениям, упускаешь шаги, необходимые для более долговременных изменений - потому что в каждый момент делаешь только один шаг.

Оговорюсь, что все это - сугубо мое осознание, полученное по осмыслению описания Susumu разных процессов, на контрасте вопросами и ответами Yaron. Я не обсуждал его с Susumu и могу ошибаться. Но оно хорошо соотносится с моей картиной мира. А еще - несмотря на малую практическую разницу, это отличие, думаю, имеет очень большое значение для понимания японских методик изменения процессов, прежде всего kaizen и lean, которые сейчас очень распространены. Преломляясь в западном сознании они теряют восприятие процесса вместе с траекториями его изменения. Я еще буду осмысливать это. Понимание не значит, что я научился мыслить по-японски, я всего лишь понял, в чем отличия.

А сама беседа была в совершенно неформальной обстановке стендовой секции, на шарах-креслах. Yaron сел сразу, а Susumu долгое время отвечал стоя, но потом - тоже присоединился к сидящим, это был определенный разрыв шаблона. Посмотрите потом фотки.

А теперь, после такого размышления о японском способе мышления, перейдем к описанию докладов. Я не буду их делить по категориям как вчера - все доклады, о которых я пишу мне понравились. А еще они сформировали некоторую целостную картину в части автоматического тестирования, которую я изложил сегодня. И дали много информации о всяких инструментах для этого, которую я не буду приводить в описании докладов - для этого надо смотреть презентации, а они не выложены. Но готов рассказывать заинтересованным лицам при обсуждении конкретных проектов.

→ продолжить чтение…

В этом посте речь пойдет о критериях, которым должна, с моей точки зрения, удовлетворять организация любых автоматических тестов. Картинка сложилась на SQA days под влиянием выступлений и соотнесения их с положением с тестами в компании. Поэтому приводимый дальше список критериев и положений может быть несколько перекошен в отрицательную сторону, то есть на те составляющие, которых у нас нет. Но это - дело поправимое.

Не секрет, что с автоматическими тестами есть определенные разногласия и проблемы, в частности касающиеся их необходимости. Которые обсуждаются много лет. Но обсуждение носит, по-моему, сильно теоретический характер, в целом, не касаясь конкретных тестов и их организации. А в этом время реализуются конкретные тесты. Так вот, я не считаю, что необходимо общее согласие на тему того, каковы должны быть тесты. Это - методологические споры, а мы - не вырабатываем методологию отрасли. Должна быть лишь выработана оценка для тех конкретных тестов, которые реализуются, а также - направления действий по их изменению, если оно признано необходимым. Вместе с тем, безусловно правильно, если каждый из участников процесса обнародует позицию, с которой он подходит к оценке.

А еще при обсуждении тестов полезно вести в формате рассмотрения конкретных кейсов. Применять положения к этим кейсам и показывать, какие из этого вытекают следствия, правильные или неправильные в контексте проекта. И когда Вы даете интерпретацию применения чьего-либо положения к конкретному кейсу, то полезно удостовериться, что интерпретация правильна. Очень часто оказывается, что в оценке-то разницы нет, просто формулировки критериев недостаточно ясно сформулированы, и тогда кейс послужит их уточнению и лучшему пониманию. Хотя, конечно, могут быть и расхождения в оценках, и их можно обсуждать, но именно в контексте конкретного кейса.

Итак, после вступления - начинаю.

Для начала - два совершенно общих принципа.

1. Следование методологии не может быть оправданием конкретных предпринимаемых действий.
2. При реализации чего-либо правильно опираться на распространенные практики отрасли в этой области и соотносить свои действия с ними.

Сначала про первый принцип. В любой методологии предполагается некоторое дерево целей, достижение которых обеспечивается практиками или процедурами, предлагаемыми методологией. Это дерево должно быть переформулировано в контексте конкретного проекта, проверена его уместность, включая ограничения по ресурсам. А если применение признано уместным - то еще необходимо проверять. что ваша реализация процедур и практик методологии в процессе достигает поставленных целей. Без этого получаем формальное следование, которое легко превращается в waste, ненужные церемонии.

Второй принцип, казалось бы, противоречит первому. Однако, это не так. Следовать практикам отрасли нужно с учетом первого принципа - понимая уместность практик и целей, достигаемых ими, и проверяя, достигаете ли вы этих целей. При этом, однако, распространенность практик свидетельствует о том, что за ними стоят адекватные цели и у многих компаний получается эти цели достичь таким образом. И если у вас в проекте дела обстоят не так - это повод задуматься, оценить и обосновать неуместность применения, или изменить к лучшему.

Мое представление о хороших автоматических тестах, на соответствие которым я предполагаю смотреть при оценке. В виде некоторой цепочки положений, которые вытекают одно из другого. Они касаются не столько самих тестов и применяемых технических средств, сколько процесса создания тестов. При описании применяется термин тестировщики, роль которых у нас играют аналитики и инженеры, в соответствии с принятым в отрасли.

1. Business value автоматических тестов - сокращение усилий на выпуск продукта надлежащего качества. Следование этому принципу должно быть доказательным и признанным заказчиком.
2. Люди, отвечающие за выпуск продукта - тестировщики (у нас - аналитики и инженеры) и представители заказчика - доверяют автоматическим тестам. Без этого business value не достижимо. Поэтому тестировщики играют роль непосредственных заказчиков для любых автоматических тестов, и именно они - оценивают их целесообразность.
3. Доверие результатам автоматических тестов повышается, если тесты представлют собой белый ящик - последовательность выполняемых действий видна тестировщикам, и они могут в нее вмешиваться. В отрасли является нормой, когда автоматические тесты реализуются на некоторых скриптовых языках в терминах модели. Они понятны тестировщикам, которые часто их разрабатывают и почти всегда - могут доработать и изменить. Тесты на верхнем уровне джолжны быть компактны.
4. В отрасли применяется подход Data-Driven тест, в котором в составе теста отделены входные и проверочные данные. Данные написаны компактным, легко понимаемым и модифицируемым образом. Это позволяет легко создавать множество прогонов одного теста на разных данных, тестируя сложные случаи, например, данные на границе допустимого диапазона или спецсимволы в строках. И это точно доступно тестировщикам и IT-службы представителям заказчика.
5. Тесты выполняются в рамках фреймворка, который собирается на основе одного (или даже нескольких) из большого количества стандартных.
   • Фреймворк обеспечивает взаимодействие с программой на нескольких уровнях - UI, веб-сервисы, процедуры базы данных, интеграция через MQ, файлы или другим образом. При этом тест может предполагать взаимодействие разных видов. А конкретные процедуры интеграции и взаимодействия реализуются на основе стандартных библиотек.
   • Фреймворки также обеспечивают логирование, включая внутренний лог теста на уровне белого ящика, и отчеты разного уровня - для тестировщиков, разработчиков и менеджеров.
   • Фреймворк обеспечивает ведение тестов и данных для них, запуск тестов в ручном режиме или при сборке, подключаясь к серверу непрерывной интеграции. Хорошие фреймворки на основе BDD позволяют связывать тесты с тест-кейсами.
   • Предпочтительны фреймворки с открытым кодом, и их - тоже много. Для тестирования Web-приложений стандартом де-факто является Selenium, который также подключается к большинству фреймворков (взаимодействие с базой данных и интеграция - они вне Selenium). Рассказыввали также Auto IT X и Robot Framework, но приводились и большие списки, включая композитные конструкции. Есть способы тестировать продукты-черные ящики, включая приложения, запускающиеся под Citrix или закрытые flash-апплеты в броузере - ориентируясь на графические картики, и это можно применять вместе с другими методами. Выбирать надо с учетом специфики проекта - интерфейсы, интеграция и прочее.
   • Над фреймворком прорабатывается некоторая надстройка, ориентированная на конкретный проект. Обеспечивает интеграцию, ведение тестов как белого ящика. А иногда - и представление дополнительных отчетов или макроуправление тестами. Средства для всего этого - имеются (НР QTP не любят потому, что он сам - черный ящик).
6. Тестов у проекта - много. И выполняются они - долго. Поэтому они требуют структуризации. И это - нормально.
   • Применяется выделение Build Acceptant Test (BAT). Они выполняются после каждого билда в первую очередь, и остальные запускаются только когда эти - не прошли. Прочие автоматические тесты могут выполняться реже, в том числе - только при регрессионном тестировании.
   • Применяется деление тестов по функциональным областям. Тогда запускаются сначала BAT-тесты, потом тестирование функционала тех областей, которые затронуты разработкой, и лишь потом, если предыдущие этапы завершены - все остальные. С учетом появления времени новых изменений кода.
   • Применяется приоритезация тестов по критичности функционала и рискам, связанным с его утратой. С соответствующей настройкой исполнения тестов.
   • Тестирование через конечный UI тяжело сопровождается и часто медленнее. Поэтому его применяют ограниченно, например, для одного документа, проверяя остальные варианты на уровне прямого взаимодействия через данные. И пренебрегая связанными с этим рисками, полагаясь на дешевое устранение чисто UI-ошибок.
7. Тесты требуют внимания и дизайна.
   • Если пренебрегать тестами и их дизайном - они превращаются в дорогой, слабополезный и несопровождаемый код, становятся обузой.
   • Разумное применение тестов, наоборот, приносит измеримый эффект в виде экономии усилий на разработку проекта в целом и удовлетворенности заказчика качеством.
   • Организация процесса может быть различной, но в любом случае он встраивается в процесс разработки как одна из составляющих и предполагает совместную деятельность и взаимодействие разработчиков, тестировщиков и аналитиков. Границы ответственности между ними также могут быть разными, при том что за конечное business value автоматических тестов отвечают тестировщики - автоматическое тестирование является частью тестирования в целом.
   • Unit-тесты применяются многими как составляющая часть автоматических тестов (часть людей используют это как синонимы, но многие - разделяют). Формальная граница проводится по-разному, но по-любому они встроены в общий процесс как составляющая, организуются и оцениваются соответственно.

Вот, собственно, и все. Как я уже писал, этими положениями я собираюсь руководствоваться при работе с темой автоматических тестов, ибо дизайн тестов - часть архитектуры. Автоматические тесты - должны быть, но они - должны приносить измеримый и признанный эффект в рамках проекта.

Первый день весенней SQA Days 2012 не просто оправдал ожидания - он их превзошел. Я знал, что конференция - очень живая, а тестировщики - активно общаются поэтому на конференции много практических рассказов, из которых можно почерпнуть идеи - и ожидал этого. Но получилось больше. За счет иностранных докладчиков, которые много работают с качеством продукта и сделали хорошие и неожиданные для меня доклады. Конференция реально становится интернациональной, при чем широко - Германия, Нидерланды, Израиль, Япония. Единственное - мне по-прежнему сложно одновременно слушать доклад по английски и записывать его, так что о них будет несколько в телеграфном стиле.

А теперь, прежде чем перейти к обзору докладов - интересное наблюдение. Это - конференция практиков, причем тестировщики-практики - значительно более конкретны, чем разработчики. Они знают теоретические понятия - как слова. Они не слишком доверяют теориям, потому как не понаслышке знают, насколько слова, теория отличаются от реального мира. И, в общем, потому они не слишком вникают в теорию - если это не описания тех программ, которые им надо протестировать. Waterfall, Agile, Lean для них - теория. У которой есть предельно конкретное воплощение в собственной жизни. А вот обобщенного понимания - часто нет. Потому как не нужно. И оно - домысливается по месту, иногда адекватно, иногда - не очень.

Хочу отметить, что такая работа со словами, понятиями - характерна для современного мира, хотя и вызывает определенное неприятие и даже отвращение у представителей научной школы. Это работа с мемами. Мем - не имеет четкого определения. Мемы понимаются аудиторией очень широко, а границы - нечетки. Разделяя мемы, человек проводит для себя некоторые фантазийные границы. Это особенность современного восприятия. И она объективна. Она может не нравится, но она - присуща миру, и максимум что можно сделать - это создавать закрытые клубы с четким определением тех или иных слов, отгораживаясь от мира. Но мир-то от этого - не изменится.

А сейчас - обзор докладов.

→ продолжить чтение…

Этот пост посвящен теме, которую я давно для себя знал, но доклад Василия Малинова на SoftwarePeople пробудил ассоциативный ряд и я решил об этом написать.

Речь идет о том, что Ваша Желание, или Потребность нечто сделать, и Возможности, которые предоставляет для этого реальный мир - они сформулированы на разных языках. И потому задача найти для своего Желания подходящую Возможность реализации - она требует определенных усилий и не всегда тривиальна. И часто кажется, что реализация Желания - невозможна в этом мире, только потому, что вы не опознаете Возможности как подходящие. Правда, для справедливости надо сказать, что часто требуется некоторая трансформация Желания под открывающуюся Возможность. но тут уж вопрос свободного выбора: можно воспользоваться этой, а можно - поискать следующую.

Впервые я это понял еще в институте, размышляя о пути после окончания. Тогда я понял, что деление по профессиям - оно сформулировано на одном языке, по областям знаний, а желания и способности человека - на другом. Человек имеет склонность и желание заниматься определенными видами деятельности - конструирование нового с придумыванием идей, или организацией работы других людей, или обучение, передача своих знаний. И эти деятельности - есть в любой профессиональной области, и надо лишь найти в вашей профессиональной области такое место, организацию, где ваши склонности будут востребованы. Это - не всегда просто и можно, но Вам же нужно всего одно рабочее место - для себя :)

А в докладе эта же мысль формулировалась на совсем другом материале. Авторы сделали хорошую систему резервирования через интернет. И дальше, несколько лет - искали, где именно ее применить, где она окажется востребованной. В результате, перебрав несколько возможных ниш - билеты, тур.пакеты, гостиницы - нашли ту, где система резервирования будет востребована на российском рынке и сейчас проект - успешен. В ходе этих поисков саму систему. конечно, тоже пришлось адаптировать под бизнес-области, но не сильно. А если бы они остановились после первых неудач - успешного результата не было.

Это же касается не только бизнес-целей, но и личных. Например, Вам интересно заниматься автоматическими тестами. Или способами организации знаний. Или способами эффективных коммуникаций. Или научиться хорошо выступать перед большим количеством лиц. Идеально, когда где-то рядом, например, внутри вашей организации кому-то именно это и требуется. Но так бывает далеко не всегда. И многие люди на этом этапе решают - ладно, буду заниматься этим в свободное время. А вот потом, достигну успехов - и всех поражу :)

Однако, на самом деле стоит посмотреть вокруг, поискать - какие реальные проблемы, задачи или трудности стоящие в рамках производственных процессов вы могли бы решить, если бы достигли этих умений. И, найдя - предложить тем лицам, которые за эти проблемы отвечает: "Я хочу попробовать это, думаю, это решит такие-то твои проблемы, давай попробуем?" Чаще всего ответ будет положительный - если усилия, затраты на "попробуем" будут разумны. Даже если проблема не находится в списке первоочередных, но актуальна: потому что без Вас о ней думает ответственный, а так - будете думать Вы как заинтересованный человек.

Правда, это ставит в позицию, когда это уже не режим хобби, а режим работы. Но если Вы действительно хотите нечто сделать, а не порассуждать об этом - оно даже хорошо. При этом обе стороны понимают. что успех - не гарантирован, Вы же - пробуете. Так что излишних надежд не будет, если, конечно, Вы сами их не дали. Справедливости ради, однако, надо отметить, что решение реальной проблемы - оно может сильно изменить способ осуществления Желания, который Вам представлялся изначально. Например, автотесты могут оказаться вовсе не такими интересными, а гораздо более сложными или противными, и решать при этом придется какие-то организационные или технические проблемы, а не только кодировать и создавать инфраструктуру тестирования. Или коммуницировать придется в рамках производственных совещаний или другой не слишком интересной рутины. Но это - реальный мир. И, в любом случае, за этим можно следить и управлять степенью своего участия. Плюс известно, что любое обучение - это и этап преодоления труднеостей до того, как научишься нечто делать хорошо.

Собственно, почему я это написал? Потому что лично я - всегда ищу возможности, и, как правило - их нахожу. Иногда мир вообще их преподносит совершенно неожиданно. Например, несколько лет назад у меня возникла идея попробовать преподавать, я ее летом высказал - и осенью меня позвали читать курс в институте, я 2.5 года это делал. Правда, не совсем туда, не совсем то, и не во-время - но так оно всегда почему-то бывает. И в целом - я не жалею. Но почему-то далеко не все люди так поступают. Многие - лишь сожалеют, что мир глух к их желаниям. Или - что гораздо лучше, но все равно не совсем то - реализуют их лишь как хобби. А Возможности - они есть. Их лишь надо увидеть. Потому что они - совсем не на том языке, на котором сформулированы Желания.

Удачи!

Вчера был второй день конференции SoftwarePeople-2012, мне он показался хуже первого. Может быть потому, что на этот день пришлось больше докладов на те темы, которые мне хорошо знакомы. И тут дело не в том, что какие-то авторы повторяют свои доклады из конференции в конференцию. Авторы как раз новые. Просто ситуации в разработке — они повторяются, и слушая чей-то личный опыт или идеи — понимаешь, что это тебе знакомо — из других выступлений. А вот тем, кто не ходит столь активно по конференциям или не работает в отрасли так давно — выступления интересны. И, в любом случае — впечатление именно по сравнению с первым днем, а в целом доклады на хорошем уровне.

Зато после конференции было общение участников в соседнем баре, поговорили много и содержательно, и, что не часто получается, не только на профессиональные темы, но и шире, об устройстве мира в конкретных его аспектах.

А сегодня я был на мастер-классе Джеффа Де Люка о Feature Driven Developer (FDD). И с пользой послушал изложение методологии от его автора, который создал ее не теоретически, а обобщая собственный опыт ведения проектов. Опыт от мэтра — это всегда интересно, особенно если он методично изложен. И в целом он окрасил теоретически известную мне методологию практическими аспектами. Часть из которых мы применяем, а другие — точно стоит попробовать использовать и, может быть постепенно возьмем все…

В целом я продолжаю оценивать эту конференцию очень высоко. Спасибо организаторам!

→ продолжить чтение…

Сегодня был первый день конференции SoftwarePeople-2012. Конференция - определенно лучше, чем в прошлом году. Очень много интерактива, общения. Много интересных докладов, и среди них - есть новые имена, а это - важно. Так что в целом - превосходно.

Теперь - подробности. Для начала - об общем тренде, который я явственно зафиксировал на этой конференции. Это - работа как fun, а не как необходимая деятельность. Конечно, об этом я слышал и раньше, но это было где-то в теории, прекрасном будущем. А теперь, похоже, оно входит в жизнь, становится ее частью. Об этом говорили минимум в трех докладах: Дэниэл Льюис "Мотивация — залог успеха", Асхат Уразбаев и Дмитрий Евтеев (Positive Technologies). И, как сказал Асхат "не то, чтобы это мне нравилось, но это входит в жизнь и с этим надо считаться".

Кстати, если говорить о нашей компании (CUSTIS), то с этой точки зрения дело обстоит хорошо. Правда, вместо модного слова fun мы говорим о самореализации, что вносит свои оттенки, включая определенную сдержанность. Но тезис, что "Компания объединяет людей, самореализующихся в творческой практической инженерной работе в области информационных и бизнес технологий" (Володя Рахтеенко на стратегической сессии 2011) - звучит адекватно духу времени, хотя и не использует модных мемов.

Теперь про отдельные доклады.

Сергей Высоковских. Альтернативный метод визуализации хода IT-проектах. Блестящая, оригинальная идея по визуализации хода проекта через представление его в виде областей, подобно карте. Каждая область - задача, площадь пропорциональна трудоемкости, по цвету различаются задачи разных типов. По ходу проекта - закрашиваем: пунктирная граница - начали постановку, сплошная граница - можно реализовывать, заштриховали все - готово к тестированию, закрасили - протестировано. Новые задачи - дополнительные области, а вот доработки в ранее имевшихся - через закрашивание более темным тоном области пропорционально дополнительной трудоемкости. Плюс - звездочка с текущей оценкой ожидаемого срока завершения. И стрелки, показывающие порядок выполнения, на которых можно подписывать отдельных исполнителей - как на военных картах. Понятно, что тулы для рисования под это нет, потому - наняли студента, он рисует (в числе прочего).

В целом - эффективная и интуитивно понятная визуализация. Показывающая некоторые проблемы. Наглядная в динамике. Эффект - ход проекта в таком виде понятен не только ему как ведущему проект, но и руководству. В отличие от старых способов - диаграмм ганта, burndown chart, доски - они все их использовали. может быть потому, что студент рисует творчески - они пробовали сделать тулу, но там получились прямоугольники, и это совсем не то. Но в принципе в играх сейчас же замечательно порождаются карты местности, так что, глядишь - и тула получится :) А тогда это сопрягается с системой ведения дел, любой. Потому как это не способ организации работы, это просто визуализация. Но - полезная, я знаю цену хорошим визуальным образам. И я буду пробовать использовать эту идею в своей работе.

Влад Балин. Разработка как процесс коллективного решения проблем. В прошлом году на Software People Влад рассказывал о методиках управления проектами, заимствованных и разработок германского генерального штаба 19 века - когда радио и телефонов не было, решения принимал командир на местности, и потому ему надо было ставить задачу так, чтобы прибыв на место он мог оценить обстановку и принять самостоятельно верное решение - с учетом других частей, которые действуют одновременно. Все это хорошо, по мнению автора, хорошо подходит для IT - там тоже важно, чтобы сотрудник принимал решения самостоятельно, но при этом они действовали согласованно.

Но это было в прошлом году. А в этом Влад рассказывал о другой методике. Начал он, собственно, с того, что в современных книгах рассказывая об архитектуре и проектировании IT, а также при построении процессов приводят разные не слишком уместные аналогии - про архитектуру зданий, проектирование ракет, производство автомобилей и так далее. Как будто авторы пришли из этих областей. А эти аналогии - неуместны. Как человек, знакомый с производством печатных плат, он показал это вполне предметно. Вывод - разработка в IT больше всего напоминает процесс конструирования в других областях.

Что замечательно - совсем недавно Рома Корешков рассказывал о статье 1992 года на ту же тему - Jack W.Reeves "What is software design. По ссылке - оригинал, а здесь - русский перевод. Через 13 лет Ривз вернулся к тезисам статьи и нашел, что они сохранили справедливость.

Таким образом, в разработке мы имеем дело с процессом конструирования, причем в условиях высокой неопределенности и изменчивости внешнего мира - требования-то меняются. К счастью, есть область, в которой проработаны методы такой работы. Это - ведение следствия, раскрытие преступлений. И Влад рассказывал о конкретных способах действий, оттуда позаимствованных - создание и проверка версий, обязательно нескольких, а не первых попавшихся, о различии между фактами и предположениями и так далее. О сессиях проектирования, в ходе которых ищутся решения, а потом, в ответ на вопрос "что мешает сделать это прямо сейчас?" появляется список открытых проблем. Который и является основой работы.

Вообще список проблем - может применяться в очень многих случаях. Например, для наблюдения за деятельностью человека. Подходишь утром поздороваться, говоришь о погоде, потом спрашиваешь - какие проблемы? Он рассказывает. Потом - то же через неделю. Если проблемы изменились - значит все нормально, работа идет. А если те же - или у человека затык и надо помогать, или он ничего не делает. Могут возразить, что, дескать, сотрудник может просто выдумывать новые проблемы, но Влад говорит, что по его опыту легче начать работать, чем выдумывать каждый раз новые проблемы, сложно это :) В общем, хороший доклад, надо смотреть презентацию и видео.

Остальные доклады - коротким списком, что запомнилось

• Асхат Уразбаев "Лидерство в стиле Lean". Говорил о 3 видах развития команд. Первые - идут вверх. Вторые - попробовали, но не сложилось, и тут - понятно, усилия оказались чрезмерными, но прорыва не принесли. А третьи - вышли на некоторый уровень и там колеблются. И таких много. Почему? Потому что у них кончились проблемы, работа пошла "хорошо". Если проблема возникает - они с ней борются. Но вот чтобы идти дальше, надо уже говорить не о проблемах, а о возможностях. Пробовать, экспериментировать. А без этого - не получится. Дальше речь шла о различных способах - что и как можно пробовать, но это - примеры, а не руководства. Но примеры - полезные, так что презентацию я тоже буду смотреть.
• Джефф Де Люка "Почему мы терпим неудачи. Разработка ПО в наши дни". Джеф дал авторское видение современного состояния. Там не было открытий, но это не было и изложение от капитана Очевидность. Это было авторское видение с полутонами и деталями, и от мэтра оно - интересно. Из неожиданного: изменения он видит всегда революционные, через хаос. А я так не хочу.
• Дэниэл Льюис. Мотивация — залог успеха. В докладе был список буллетов - что мотивирует английских разработчиков сегодня. Утверждалось, что не только английских. Размер зарплаты там очень далеко не наверху (но он должен восприниматься как справедливый). В целом - любопытно.
• Вадим Митякин "Путешествие по изведанному. Чем ваша компания является на самом деле". На этот доклад я не попал, пошел на Джефа. А, говорят, он был весьма интересным - о компании из позиции генерального директора, это редко бывает на конференциях.
• Василий Малинов (Oktogo.ru) "Роль продукта в успехе привлечения инвестиций" - об успешном стартапе, интернет-проект по резервированию отелей в России, взгляд на развитие изнутри. Как менялась бизнес-идея при сохранении в целом технологической платформы резервирвоания - они искали нишу рынка. Любопытно.

Я тоже выступал, рассказывал о DDD на конкретных кейсах из практики - как это происходит и какой дает эффект. В целом приняли позитивно и, мне кажется, получилось пробудить интерес к методу, в том числе среди практиков, которые давно работают. А это - немало.

И выступал Коля Гребнев. Тоже рассказывал о DDD, но под другим углом зрения. Я говорил больше о постановках, аналитической работе а он - о трансляции модели в код, о границах применимости подхода.

Завтра - второй день и, надеюсь, тоже будет интересно.

Последующие дни Atlantic Systems Guild, увы, не принесли ничего нового. Второй день был сильно гнилой, третий - повеселее, но все равно, информация, которую я услышал - это прошлое, она была бы мне интересна в 2005-2007 году. А с тех пор на проблемы были получены ответы, которые естественно, дали крен в другую сторону, это было осознано, и выработаны какие-то практики поиска баланса. Все это в докладах отсутствовало.

Наверное, это объясняется высоким уровнем самих докладчиков. Потому что когда люди успешно применяют достаточно тяжелые практики за счет личных способностей - им легкие практики не слишком актуальны, тем более, что они видят их ограниченность. Они сосредотачиваются на том, чтобы выделять, раньше обнаруживать неправильные ситуации. И антипатернов было действительно много. Но, опять-таки, во многом прошлые. А еще - успешные люди не слишком понимают, за счет чего они сами успешно это делают. За счет чего держат в голове и обеспечивают те самые checklist'ы из 20 пунктов, которые показывались - они просто делают это. Они выдают этот список, они умеют находить баланс, чтобы не слишком закапываться - и все.

Подробный отчет - Atlantic Systems Guild 2012

Статья была опубликована на softwarepeople.ru (портал закрыт) и перепечатана на interface.ru
Статья получила развитие Agile в контексте большого менеджмента – тренды развития (SPMconf-2013)

Прошедшая конференция AgileDays-2012 естественным образом сфокусировала мои мысли на теме Agile-практик как таковых, их развития и соотнесения с традиционным менеджментом.

Практики менеджмента безусловно следует рассматривать в контексте тех способов производства, тех организаций, на основе которых они выработаны. При этом надо понимать, что это естественным образом реактивный процесс. То есть сначала некоторые практики складываются, потом - анализируются и описываются, потом они транслируются и применяются более осознанно. Но при этом за время анализа и описания жизнь уходит вперед.

Так вот, традиционный менеджмент вырос в условиях больших предприятий, в которых путь наверх был статистически доступен немногим. Соответственно, этот шаг делали люди, имеющие достаточно высокие способности в том, что составляло суть менеджмента. Такие люди достигали успеха, за ними наблюдали другие люди, учась у них непосредственно или публикуя книги, предназначенные для тех, кто хочет стать успешным менеджером. И сами успешные менеджеры тоже писали книги - как был достигнут успех. Таким образом формировался стереотип успешного менеджера, по которому производился отбор, и к которому стремились желающие, вырабатывая у себя соответствующие качества.

Однако, важным является тот факт, что способных успешных менеджеров, а также желающих, готовых на достаточно большие усилия, чтобы стать успешным менеджером, было не так много. И пока организация производства могла обходиться таким количеством менеджеров, система более-менее работала. Это, по моим ощущениям, 60-70-е годы. А затем произошло следующее. Повышение потребности в квалифицированном труде позволило достаточно большому количеству людей подниматься вверх альтернативным путем. Не стремясь стать успешным менеджером ценой больших усилий. В ответ на это - появилась идея обучения регулярным образом, без существенных затрат собственной энергии, которая, в конце концов, вылилась в идею MBA. Теоретически там учат тех же самых успешных менеджеров на основе анализа опыта и методов. Но практически тех самых менеджеров, которые служили образцом - не получается, потому что составляющие самомотивации и самореализации в должной мере не присутствуют у всех обучающихся. Хотя тем, у кого он присутствует в силу личных склонностей, такое обучение безусловно помогает.

Аналогичная проблема, кстати, с воспроизводством советских управленцев, которые проводили развитие промышленности и науки. Эти руководители формировались в условиях жесткого давления при Сталине. Когда давление упало, то процент людей, избиравших такой путь и шедших по нему с большими личными усилиями - сильно уменьшился. И хотя ряд механизмов, обеспечивающих давление, таких как конкуренция нескольких предприятий в каждой из оборонных областей, сохранился, следствием стала общее снижение уровня руководителей. Были попытки изучить стиль работы управленцев и на основании его выработать методы работы. которые затем сознательно применять. К ним относится и СМД-подход. Но, несмотря на построение теории, практическое восприятие такого подхода среди руководителей - невелико. Оно определяется количеством людей, для которых достижение целей является важным с точки зрения самореализации, и которые согласны на большую внутренюю работу ради этого. А их количество при отсутствии большого внешнего давления - невелико.

Возвращаемся в область IT. Она отличается от других материалом, из которого изготавливаются конечные изделия. Он имеет преимущественно нематериальную природу, так как изделие - исполняемая программа, написанная на некотором языке. В этом смысле IT ближе к научной области - НИР и НИОКР, однако требуется от нее производственная деятельность. Менеджмент пытался решить эту потребность через все большую и большей регламентацией. К началу 2000-х этот путь достиг своего апогея в виде unify process, но требуемый результат в виде гарантированного завершения, пусть даже ценой больших денег - достигнут не был.

А сама потребность - многократно возросла с наступлением эры персональных компьютеров. Все-таки, до 80-х годов нематериальная природа компьютерных кодов, отличающая отрасль, нивелировалась тем, что для кода нужен-таки был материальный носитель в виде компьютера, который присутствовал только в достаточно крупных организациях. Персоналки качественно изменили ситуацию, потребность в реализации IT-проектов с их распространением выросла многократно. И выработка способа управления ими, обеспечивающая результат стала насущной необходимостью. Это был вызов эпохи.

И в 90-х решение было найдено - Agile-технологии. Возникнув первоначально как протест против доведенных до абсурда процедур регламентации в виде XP, они с появлением SCRUM дали легкий и эффективный способ управления IT-проектами, обеспечивающий приемлемое качество и при этом сделавший управление IT-проектами доступным достаточно широкому кругу людей в отрасли без чрезмерных усилий по освоению. И этот способ завоевывал мир де-факто. При этом первоначальная цель XP - вытеснить за рамки IT процедурное администрирование и вообще классических управленцев - также была во многом достигнута за счет внедрения собственной, оригинальной терминологии и практик. В результате IT-шники получили возможность самостоятельно управлять своими проектами или, во всяком случае, обрекли менеджеров на разбор со спецификой отрасли. Хотя сами практики, если разобраться внимательнее, впитали в себя позитивный опыт "обычного" менеджмента который тоже интенсивно развивается.

После успеха де-факто началось признание де-юре. Артефактами этого являются SWEBOK 3 версии (2004) и PMBOK 4 версии (2008) в которых явно упоминаются agile- методологии и сделана оговорка, что структура самого документа повторяет стадии классической (водопадной) модели лишь по совпадению. PMBOK-4 читать особенно забавно - итеративность новые веяния вписаны в книгу явно на живую нитку, точки сшива и провалы целостности, возникшие из-за этого - видны. И этот процесс завершается сейчас понятийной сшивкой с менеджментом вне IT, которая необходима для Agile-управления IT-проектами в мегакорпорациях. Проявления этой сшивки - доклад Dan Rawsthorne. Scrum: the Big Picture на AgileDays-2012, в котором показана реализация в Agile "общепринятой" иерархии уровней Software Development - Product Development - Project Management - Portofolio Management. И доклад Джефа Сазерленда на SECR-2011, в котором правильный SCRUM позиционирован как высшая и последняя стадия CMMI-5.

Если же говорить о широких массах, то IT-шники относятся к управлению так же как к технологиям. Они знают, что серебряных пуль - нет. Они знают, что новые идеи могут давать много полезного, и за ними надо следить. И чтобы их использовать вовсе не обязательно углубляться в теорию - можно применять на практике и без этого. Хотя если интересно - то почему бы не разобраться в теории - это прикольно, полезно и поучительно. Но во всей теории разбираться - никакого времени не хватит. Поэтому новые идеи вспыхивают, оказавшись удачными - распространяются, становятся общеизвестными, в их ограничениях разбираются, после чего они осыпаются в багаже полезнымии практиками. Так же и в технологиях: вспыхивает функциональное программирование, F# и Haskel, обретает последователей, интенсивно развивается, а потом опадает новыми элементами в C# или занимает подобающую, хотя и неожиданную нишу как Erlang. И практики управления и технологии по пути могут обрастать евангелистами и ярыми сторонниками. А сам цикл от прихода до обретения места - стремителен, порядка полутора лет.

Как я уже говорил, оригинал управленческих практик часто приходит извне. Но попав в IT - он сильно изменяется. Например, Канбан в IT обернулся тремя практиками ведения проекта: доска, ограничения на ней, измерение скорости потока. Который сосуществует в сознании с "большим" Канбаном как методом оптимизации процессов. Схема формирования команды - стадии Storming-Forming-Norming-Performing тоже стали более простыми и формальными, скрестившись по пути с IT-командами. Поэтому многие говорят об отсутствии принципиально нового или искажении оригинальных, якобы правильных идей и процессов. Но это неправильно. Потому что реально процессы впитывают специфику IT-разработки. А еще - приобретают нужный уровень легкости и схематичности, который и обеспечивает их успешное применение в проектах.

Ну и в заключении - отрасль меняется очень быстро. Тезис о том, что "в ней надо очень быстро бежать, чтобы оставаться на месте" - уже давно является самоочевидным. И использование схем, облегченных практик там, где они подходят, без вникания в теоретические детали как раз и обеспечивает способ быстро бежать, оставляя время для того, что интересно - для решения сложных задач и создания новых проектов. На мой взгляд, это - данность, объективная реальность. И если ее игнорировать - то тебя обгонят.

Сегодня был первый день Atlantic Guild. Кажется, я нашел-таки конференцию, которая мне не понравилась. Хотя - это не совсем конференция, это обучение от мэтров. Так вот, выход сопоставим с выходом от обычных конференций. Не то. чтобы мыслей не возникает совсем, но их в сухом остатке - не больше, а местами - меньше. А вот интереса к содержанию - почти нет, увы. Текущее объяснение таково: мэтры - они в отрасли с 80х. Они пережили пришедшее стремительное изменение 2000-х, осознали его. И сейчас - транслируют это осознание другим людям своего уровня. Проблема в том. что в России отрасль сформирована в конце 90-х - в 2000-х. И поэтому тех самых традиций - нет. Люди живут в стремительно изменяющейся отрасли и как-то умеют это делать. Так что когда докладчики говорят. о том, что есть проблема и нечто нужно менять - слушатели уже знают. какие ответы на это даны, в том или ином виде пробовали и знают о следующем шаге - о проблемах, которые порождены этими ответами. А в докладах - только первый шаг. А он - очевиден.

Попробую на примерах. Что у проекта должны быть цели, и желательно их выразить в измеримых индикаторах - знают все. От мэтров ожидают следующий шаг - как работать в ситуации, когда на индикатор влияет несколько одновременно идущих проектов, плюс события внешнего мира. В эту сторону - были вопросы из зала и не было внятных ответов.

Еще вопрос. То, что у проектов есть стейкхолдеры, у них есть интересы, они конфликтуют и работа с этим - часть IT-проекта сейчас знают все, кто ведет проекты, да и другие - слышали. И людей интересует конкретные практики и кейсы. Поэтому когда на практику дают кейс - выявить конфликты, то люди с этим справляются элементарно. И, более того. большинство знает, что дальше надо группировать и приоритезировать. плюс докапываться до реальных причин, придумывать варианты. А когда вместо этого берут первый попавшийся конфликт и просто "говорят вокруг" его решения - это, в общем, антипаттерн. Увы.

И вообще, в докладах очень много об антипатернах. о неправильных ситуациях. И мало о том, как это исправить. Пока виден один предлагаемый способ исправления - навесить отрицательный эмоциональный ярлык. Проект "дохлая рыба" - не делай такие. Но, с моей точки зрения, уровень детского сада - младшей школы: не нравится, как ведет другой - придумай дразнилку и дразни.

Хотя, может, они пойдут дальше в последующие дни, или будет больше конструктива. Но пока не похоже - судя по уровню ответов на вопросы.

Чтобы не заканчивать на этой грустной ноте. Первая часть - о том, что мир меняется - хорошая, концентрированная. Что полезно. В общем, об изменениях знаешь, но когда их выдают кучей - это дает определенную концентрацию, это полезно. Плюс я узнал любопытную вещь. Как известно, современная молодежь может за компом кодировать, смотреть почту, реагировать в социальных сетях и так далее, и все это одновременно. Оказывается, на Западе существуют две оценки этого у психологов. Одни оценивают отрицательно - синдром неполного внимания, молодежь неспособна сосредоточиться. Другие - положительно, как способность мозга держать несколько параллельных потоков этим неполным вниманием, достигая местами синергетического эффекта - людям не надо переключать контекст, они могут работать в нескольких параллельно. Да еще получать выгоду: на совещании возникла проблема - не отключаясь связался, или поискал, нашел ответы, выдал и все это - не выходя из режима текущего обсуждения. Так что нас всех ждет великое будущее.

Пока все.

Закончилась конференция Agile Days-2012. Второй день был определенно не хуже первого. В нескольких докладах я услышал конкретные идеи, которые можно применить на практике, другие - влекли размышления. Так что, если говорить о конференции в целом - она удалась. И по реакции других участников, они почерпнули для себя много нового. Потому что в целом конференция предназначена все-таки для более молодых, ищущих новые пути и осваивающих новые идеи. Это было видно и по реакции зала на доклады, и по активному общению.

Сегодня был доклад Коли Гребнева из нашей компании про эффективные обсуждения. Доклад был в тему, слушали, задавали вопросы, обсуждали. Потому что тема эффективного проведения совещаний, включая те которые входят в SCRUM - ретро, планирование, DSM - она актуальная.

Дальше про доклады, разделенные, как и вчера, на две категории - что особенно понравилось и все остальное. Пара последних слотов отсутствует, потому как сам продуктивно общался по разным темам.

→ продолжить чтение…

В целом конференция ожидаемо живая. К сожалению, активное посещение конференций и долгая работа в IT имеет оборотной стороной то, что содержание многих докладов себе представляешь, они рассчитаны на людей с меньшим опытом. Тем не менее, доклады будят размышления, как частным образом, так и в целом.

→ продолжить чтение…