CustisWiki - Вклад участника [ru]

Reeves

2018-10-18T08:13:55Z

MaksTsepkov: Перенаправление на Блог:Роман Корешков/Продукт инженерной деятельности (в разработке ПО)

#REDIRECT [[Блог:Роман Корешков/Продукт инженерной деятельности (в разработке ПО)]]

Блог:Максима Цепкова/Software Quality Days 2014

2017-01-25T08:13:43Z

MaksTsepkov:

В январе я съездил в Вену на [http://2014.software-quality-days.com/en/conference/overview/ Software Quality Days 2014]. Конференция немецкая, но в программе было много английских докладов, иногда параллельно на нескольких треках, а темы были заявлены интересные. И в целом я доволен тем, что съездил, хотя все-таки незнание немецкого сказывалось сильно - ты не можешь принимать полноценное участие в общении: хотя английский все участники знают, разговор идет на немецком и послушать и включиться, как я делаю у нас - не получается.

Я получил впечатление об общем уровне и организации конференции, сравнил ее с отечественными. Наши в целом не хуже. Услышал несколько интересных докладов.
* обзорный доклад Hermann Sikora, открывающий конференцию
* доклад Tom Gilb про недостатки моделирования, хотя он был про проблемы и не рассказывал о решении
* и неожиданный доклад Stefan Holtel про использование LEGO для визуальных метафор
А еще - посмотрел на вендорский софт, представленный на конференции, которого было довольно много. В отличие от наших конференций, на которых участвуют преимущественно крупные фирмы - Microsoft, IBM, HP - там было представлено довольно много разного софта от более мелких фирм.

А еще - узнал про идею [http://en.wikipedia.org/wiki/Resource-oriented_computing Resource Orienter Computing], в которой архитектуру приложения предлагается строить аналогично архитектуре интернета - на основе совокупности множества сервисов, для доступа к объектам которых используются адреса, аналогичные URL. Под эту архитектуру фирма [http://1060research.com/ 1060research] предлагает свою платформу NetKernel, на которой много что реализовано. За счет этого там хорошо решаются вопросы масштабирования. Тут интересно, что в рассказе о заложенных в архитектуру принципах я опознал много конструкций, которые слышал в рассказе Microsoft об архитектуре Windows8 - я писал об этом в [http://softwarepeople.ru/blog/2013/06/11/ms-devcon-2013/ отчете о DevCon-2013]. Так что, вполне возможно, это один из источников идей для архитектуры. И это - интересно.

= Сравнение с нашими конференциями =

Теперь о впечатлении в целом, сравнивая с нашими конференциями. По сравнению с [http://secr.ru SECR] уровень ключевых докладчиков пониже, все-таки на SECR приезжают гуру мирового уровня, таких как Ивар Якобсон или Джеф Сазерленд. А вот уровень основной массы докладов повыше. Именно уровень изложения - спикеры понимают не просто место своей работы, но и позиционируют ее относительно других работ и вообще текущего положения в отрасли, а на наших конференциях часть докладчиков (не все) на это не обращают особого внимания. Примерно тоже можно сказать, сравнивая с другими нашими ведущими конференциями с приглашенными иностранными спикерами - [http://softwarepeople.ru SoftwarePeople], [http://agiledays.ru AgileDays].

Думаю, основа этого различия лежит в развитии отрасли как таковой - там не было разрыва, который у нас ИТ пережила в 90-е, когда прервалась преемственность, а новую отрасль создавали во многом практики. Но при этом конференция Software Quality Days - не научная, как [http://modelsward.org MODELSWARD], на которой я был в прошлом году ([http://blogs.uml2.ru/node/266 мой отчет]), а практическая, и доклады посвящены практическим проблемам, и есть доклады со спорными размышлениями о новых идеях, которые на научных конференциях не проходят.

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

Особенно интересно сравнить Software Quality Days с нашей профильной конференций [http://sqadays.com SQA Days], у которой даже название очень похоже - Software Quality Assurance Days. Немцы шире смотрят на свою поляну. Все-таки у нас темой преимущественно является тестирование, а там оно - одно из, наряду с поставкой новых версий, требованиями и организацией эксплуатации. У нас это тоже присутствует, но меньше. Общий уровень докладов - вполне сопоставим, просто у немцев получше с теоретической составляющей, а у нас - с практической. А еще у нас много докладов, сделанных растущими специалистами и для новых растущих, а там доклады делают более состоявшиеся специалисты. Потому что у нас конференции занимают еще и образовательную нишу, дают направления для роста специалистов, в отличие от Европы, где для этого есть институты.

= Участники - вендоры =

Еще отличием конференции является довольно большое количество участников-вендоров, производящих ПО для тестирования, работы с требованиями, установки версия и так далее. Список гораздо более длинный, чем я обычно слышал на конференциях. Обычно упоминают монстров, у которых есть комплексные решения - HP, MS, реже IBM - и легкие свободные фреймворки - Selenium, Robot Framework, JUnit и другие. А здесь, кроме монстров, было большое количество компаний, занимающих промежуточное положение - и с комплексными решениями, правда, обычно выросшими из чего-то более специализированного, и с отдельными, такими, как распространение новых версий и патчей в гетерогенной среде. Называть компании я не буду, желающие могут посмотреть список спонсоров на странице конференции, и посмотреть что у них есть.

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

Было даже довольно интересный конкурс среди вендоров на "Лучший софт для обеспечения качества", в котором, правда, участвовали не все, а только 6 компаний - Microsoft, IBM, Polarion, Tricentis, Imbus, Ranorex. Каждой было дано 7 минут на презентацию, потом ответ на 3 вопроса жюри по минуте на каждый. А потом - голосование профессионального жюри и голосование всех участников по результатам. По голосованию зала победил Microsoft, и это довольно ожидаемо - у них и софт с низким порогом входа, и презентации они хорошо умеют делать. А профессиональное жюри выбрало Imbus - молодцы. Как и я :) Софт Imbus - наиболее полный из представленных, во всяком случае на уровне презентации, позволяет описывать модель от требований до тест-кейсов, сам порождает наборы тестовых данных по заданным характеристикам и прогоняет тесты. При этом, да он уступает Microsoft по графическому представлению и красивостям, но функционально, по-моему, полнее, и, наверное, более адекватен с точки зрения сопровождения развития продукта.

А еще, наблюдая за вендорами и их презентациями, я понял, для каждого хорошего продукта должен быть свой гартнеровский квадрат - надо только его придумать - это позиционирвоание - а потом уговорить Гартнера сделать такой рейтинг :) MS полтора года назад стало лидером в квадранте ALM, и я не смог тогда найти предыдущую версию квадранта, без MS. Compuware показывает гартнеровский квадрант где он лидер по мониторингу (и второй рядом)...

= Подробнее про доклады =

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

Открывал конференцию хороший доклад '''Top Executives, Software and Quality: A Hard Coded Conflict? Hermann Sikora''' (GRZ IT Group, AUT). Основная мысль - в том, что software занимает ключевые позиции в современном мире, как на уровне отдельных компаний, так и мира в целом. Из вспомогательной инфраструктуры он превратился в основную обеспечивающую. И поэтому его возможности и ограничения необходимо учитывать в "общем" управлении, которое от инфраструктуры обычно дистанциируется. Проблема в том, что софт - устроен довольно сложно, помимо возможностей имеет много ограничений, и чтобы все это учитывать - надо в этом хорошо разбираться. Что присуще далеко не всем топам. Возникают конфликты, между бизнесом и ИТ (или между CEO и CIO). Которые, независимо от результата, приводят к неполному использованию потенциала развития. И к том случае, если ИТ имеет неадекватно-подчиненное положение, и когда ИТ получает незаслуженно много привилегий относительно основного бизнеса. Тут была моделька с матрицей 3х3 формальная (организационная) позиция против внутреннего влияния, адекватной диагональю и разбором конфликтов.

Естественно, в докладе было про современные вызовы ИТ, но там ничего нового: privacy, security, transparancy for private life in internet era. Особая сложность в том, что по всем этим вопросам нет и не может быть общего мнения, хотя требуются общие решения - because of culture politics and other differences - but internet is global worldwide.

'''What is drastically wrong with most software engineering modeling languages and approaches, and 10 necessary principles for a really good modeling language. Tom Gilb''' (Result Planning Limited, Kolbotn, NOR). Мэтр, 1940 года рождения, работал в IBM, с 1960 - независимый консультант. И сейчас вместе с сыном продвигает свою модель, детали можно посмотреть у него на сайте http://www.gilb.com/.

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

У него есть идеи собственный подход, который отвечает всем этим требованиям. Там есть язык Planguage и ряд других составляющих ведения проекта. Но этого он в выступлении не рассказывал - это есть у него на сайте и [http://tinyurl.com/QWGILB в материалах]. На русском можно немного посмотреть [http://www.comprice.ru/articles/detail.php?ID=246065 здесь]. А в реализации он предлагает использовать ROC architecture model, о которой я писал в начала отчета.

'''Measuring And Implementing Sustainable Business Practices For Competitive Advantage. Ralph Jocham''' (Effective agile. GmbH, Munsingen, CHE). О том, что Scrum не делает организацию гибкой, Agile, автоматически. Возникает Water-Scrum-Fall, в которой Scrum служит формой для жесткой конструкции. И дальше - идеи про гибкость, которая дает реальные преимущества, со слайдами о том, что agile more successfull then waterfall.

'''Dealing with Technical Debt in Agile Development Projects. Harry Sneed''' (ANECON GmbH, Wien, AUT) Доклад был в академическом стиле, со слайдоментами. Вообще технический долг - плата за быструю поставку. За костыли, с которыми быстрее. Он связывает его с Agile, но я бы так не рассматривал. И приводит две причины: Incompleteness and Sloppiness с длинным списком примеров и категорий.

И как выход предлагает некоторый контракт с командой по уровню качества и скорости... По-моему, формально оно не сработает.

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

'''The Top Reasons Why Applications are slow or fail. Wolfgang Gottesheim''' (Compuware GmbH). Сообщение доклада непонятно. Просто набор причин, по которым может быть медленно, при этом большинство, по мысли автора, не должно быть - ибо известные грабли. Может быть, смысл доклада - просто дать список? Но примеры - чудесны! Пример сайта, где дофига JS - 1.7М против 800К картинок и копеек основного контента. А основной объем JS - документирующие комментарии! Или утечек памяти в самописном фреймворке логгирования. Но местами быстро уходят в технику, настройки JVM и БД.

'''Challenges and Solutions in Global Requirements Engineering. Klaus Schmid''' (University of Hildeshiem, Hildesheim, DEU). Хотя в докладе был подзаголовок literature survey, обзора как такового я не услышал, были размышления на тему про разные аспекты глобализации и кросскультурных взаимодействий: и внутри команды разработки, и между разработчиками и заказчиками при аутсорсе в другую страну, и просто между пользователями одного софта в разных странах мира, где один бизнес устроен по-разному. Например, автозаправка - в одних странах самообслуживание, на других - мальчики бегают. И софт должен нормально работать в обоих случаях, обеспечивая отпуск и оплату бензина. И это культура, а не только язык, у UK и New Zeland язык один, а культура сильно разная, потому как разная история и размеры страны.

Размышления любопытные, но принципиально ничего нового я не услышал, эти проблемы я знал по многим другим докладам, в том числе с практическими деталями и особенностями - и это интереснее. Это как раз пример, когда ширина темы послужила в ущерб содержанию, потому что получилось сказать только общие вещи.

'''What is model-based testing all about - the quest for simplicity. Dragan Pazin''' (ComTrade d.o.o, Ljubljana, SVN). Доклад про разные уровни эмуляции внешних систем: mock - emulation - production emulation - production в процессе тестирования. На нескольких практических кейсах, с техническими подробностями.

[[Файл:SQdays-2014-MattiHjelm-ProductCanvas.png|right|400px]]

'''Improving Quality using Personas and the Product Canvas style of a Product Backlog. Matti Hjelm''' (SmartBear Software AB, Stockholm, SWE). Для начала был доклад о том, что графики исполнения проекта дают не дают понимания о продвижении к цели, особенно для тех, кто вне контекста проекта. Поэтому предложена доска с некоторой стандартной разметкой, которая не только дает представление о ходе, но и помогает этот контекст быстро поднять.

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

'''Agile testing – tips & tricks. David Janota''' (CN Resources International (CZ), AUT). Вещи частично правильные, частично экстремисткие, но все - очевидные. В целом доклад - про этап перестройки от ситуации, когда тестеры сидели отдельно и были отгорожены от остальных организационной стеной, и на этом этапе экстремизм уместен, чтобы преодолеть инерцию старого.

'''Pragmatic agile model driven development using smart use cases. Sander Hoogendoorn''' (Capgemini, Utrecht, NLD). Начиналось с того, что подход usecase отличается от userstory и лучше подходит для моделирования. Потому что можно сделать модель в простых диаграммах - диаграмма классов, диаграмма usecase. И далее модель, во-первых, используется для оценивания, а, во-вторых - в генерации на их основе приложения, включая интерфейсы для типовых usecase. Схемки рисуются в Enterprise Architect или Visual Studio, говорит, что по его опыту EA предпочтительнее, особенно в части описания генерации кода. Для оценки и представления как dashboard используется Speedbird9.com.

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

'''Secure your Software with Source Code Analysis. Steve Howard''' (AUT) Рассказ про плугин klocwork для Eclipse и IntelliJ IDEA статического анализа кода, который выполняет анализ на лету, в процессе редактирования, а не на этапе компиляции - и потому позволяет раньше обнаруживать ошибки и так далее. Профит понятный, но слишком абстрактный. Было бы интересно еще содержательный рассказ, что именно появляется, относительно работы без этого плугина - потому что обе среды, особенно IDEA, содержат весьма навороченные редакторы, также осуществляющие анализ кода на лету.

'''Isolated Testing of Software Components in Distributed Software Systems. Francois Thillen''' (LYCEE PRIVE EMILE METZ, Junglinster, LUX). Доклад про тестирование распределенной системы управления электрикой. При этом многие процессы проходят насквозь через несколько компонентов. Традиционные пути - эмуляторы (моки) для компонент и изолированное тестирование, либо комплексное тестирование со всеми запущенными компонентами - им не очень подходили, первый - потому что много эмуляторов, а второй - потому что сложно запускать, а еще - сложно локализовывать ошибку. Вместо этого они написали свой специализированный эмулятор сетевого протокола, через который все системы взаимодействуют, и с его использованием делают тесты, тестируя компоненты независимо, но без эмуляторов.

'''How to Improve Requirements Elicitation by LEGO™ Bricks (Literally)? Stefan Holtel''' (brightONE GmbH, Munich, DEU). Неожиданный доклад. О том, что для создания визуальных образов и метафор можно использовать модельки из LEGO, которые ты собираешь, а потом - презентуешь и объясняешь. Отчасти это похоже на известные приемы - нарисовать карту или нарисовать человечка, но использование LEGO тут дает достаточно необычную окраску. Во-первых, потому что собираешь руками, и при этом можешь легко переделать. Во-вторых, элементы достаточно примитивные, и это хорошо - можно состредоточиваться на сути, а не на красоте рисования. Ну и непривычно это - то есть лучше расшатывает мозги. Что, собственно, и нужно при придумывании метафор. Кстати, в ходе рассказа автор давал модельки нескольким участникам, правда не собирать, а интерпретировать - чтобы почувствовали метод.

И, говорит, можно так с требованиями работать. Только подробности не рассказывает - ссылки на статьи и выступления. А презентации его на сайте нет, так что искать надо (и быстро у меня не получилось).

'''Coaching improvements in Requirements Engineering Step-by-Step Mr Deming was right, Plan, Do, Study, Act. Colin Hood''' (Colin Hood Systems Engineering Ltd, Northampton, GBR) Докладчик - автор нескольких книг по требования, например [http://bookre.org/reader?file=656501 этой]. Но доклад был про другое, про изменения мелкими шагами. При этом стандартный цикл Шухарта-Деминга Plan-Do-Check-Act он преобразовал в Plan-Do-Study-Act, и на шаге Act выполняется улучшение по результатам Study. Преврашщая цикл в спираль развития. А основная мысль - когда люди готовы к изменениям - надо поддержать их обучением. Что, в общем, воспринимается как тривиальная вещь.

'''Performance Testing: Respect the Difference. Alexander Podelko''' (Oracle, Stamford, USA) В докладе не было какой-то методологии, просто длинный список пунктов, о которых надо думать когда говоришь о производительности. Включая конкурентную работу. А так - стандартный цикл, тестирования и оптимизации и методы анализа - как непосредственно по тесту, так и через анализ логов сервера, что позволяет детальнее разобраться в задержках.

'''Works on my machine, your problem now? – Improving Collaboration between Dev, Test and Ops. Wolfgang Gottesheim''' (Compuware GmbH). Для начала была некоторая проводка по тулам работы с логами и мониторингом - куда смотреть, на что обращать внимание. А потом разговор переключился на совместную работу Dev и Ops. И фокусом на автоматизацию тестирования, в том числе - по производительности. А закончил все на оптимистичной ноте "Проводите выходные с друзьями за пивом вместо пиццы с коллегами на работе" :)

{{replicate-from-custiswiki-to-lib}} [[Category:Конференции]]
{{wl-publish: 2014-02-09 19:56:53 +0400 | MaksTsepkov }}

Файл:БиК Цепков.pdf

2016-06-04T01:00:13Z

MaksTsepkov: MaksTsepkov загрузил Файл:БиК Цепков.pdf

Когда всем понятно

2016-06-03T14:39:07Z

MaksTsepkov:

;[[:Категория:Максим Цепков (Статьи)|Максим Цепков]]: главный архитектор компании CUSTIS

[[Файл:БиК Цепков.pdf|page=1|right|500px]]

Опубликовано в журнале [http://www.buhcomp.ru/ Бухгалтер и компьютер], № 5(май), 2011
Журнал закрылся, архив недоступен

== Когда всем понятно. Диаграммы учета: мост между бухгалтером и разработчиком ==

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

<blockquote>
'''Эффективное представление информации'''

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

Развитие науки показало, что многие виды информации можно эффективно представлять в виде диаграмм, а достижения информационных технологий позволили эти диаграммы быстро и легко строить и изменять. В настоящее время представление данных в виде диаграмм является общепринятым и интенсивно развивается, поскольку даёт компактную и наглядную целостную картину, с которой можно эффективно работать, обращаясь к детальной информации только по необходимости. Множество графических решений используется и для описания бизнес-процессов.
</blockquote>

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

=== Диаграммы учета: простой пример ===

В качестве иллюстрации использования диаграмм учета приведём простой пример учёта личных финансов. Хотя он носит достаточно умозрительный характер, его безусловным достоинством является простота.

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

Все эти операции можно изобразить на неформальной схеме, чтобы получить хороший визуальный образ (рис. 1).

[[Файл:Рис_1.jpg|thumb|300px|center|Рис.1. Неформальная схема учета личных финансов]]

Система должна давать возможность получить ответы на следующие вопросы: сколько у меня денег и где; кому я должен и сколько; кто мне должен и сколько; на что я трачу деньги; какие у меня есть доходы и из каких источников.

Для этого нужно спроектировать учетные регистры и изобразить их на той же схеме (рис. 2).
[[Файл:Рис_2.jpg|thumb|300px|center|рис.2. Схема учета личных финансов с выделенными учетными регистрами]]

Овалы, обозначающие учетные регистры, можно разделить на три группы.

#'''Зеленые''' («Наличные», «Карточка» и «Мне должны») — средства, на которые можно рассчитывать.
#'''Желтые''' («Кредит в банке» и «Я должен») — отрицательные ресурсы.
#'''Изображенные пунктиром''' — «Доходы» и «Расходы».

Как легко заметить, эти группы оказались соответствующими разделам бухгалтерского баланса: зеленые — активы, желтые — пассивы, а стрелки между ними отражают проводки, приводящие к их изменению. При этом стрелка на проводке направлена к счету дебета.

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

Далее нужно определить аналитические признаки учетных регистров, которые позволят отвечать на поставленные вопросы. Например, чтобы можно было узнать, кто мне должен, счет «Мне должны» должен иметь аналитику «Кто», обозначающую человека, которому я дал в долг. А чтобы давать информацию о том, на что я трачу деньги, счет «Расходы» должен иметь аналитику «На что», обозначающую статью расходов.

Теперь можно изобразить все на формальной схеме (рис. 3).

[[Файл:Рис_3.jpg|thumb|400px|center|Рис.3. Диаграмма учета личных финансов]]

На диаграмме овалами изображены синтетические счета и для каждого счета указаны его название и аналитики. Пассивные счета выделены оранжевым, а активные — зеленым цветом. Проводки изображены стрелками, направленными к счету дебета, а надписи на них обозначают порождающие их хозяйственные операции. Счета «Наличные» и «Карточка» удобно рассматривать как субсчета общего счета «Деньги», потому что часть операций может осуществляться с любым из них. Отношение субсчетов к основному счету показано треугольной стрелкой.

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

Ответы на поставленные вопросы можно получить путем анализа остатков и оборотов по учетным счетам. Например, ответом на вопрос «Сколько у меня денег и где?» будут остатки на счетах «Наличные» и «Карточка» в разрезе аналитики «Банк» и т. д. Собственно говоря, ответы на вопросы и есть отчеты, а учет конструируется исходя из того, какие отчеты понадобятся.

Достоинством таких диаграмм является то, что они показывают связь между учетом и потоками материальных ресурсов. Кроме того, диаграммы учета помогают бухгалтеру и финансисту в общении с разработчиком: им достаточно просто нарисовать соответствующую стрелку — и операция будет реализована в системе. А для простых операций разработчик (или аналитик) и сам может Диаграмма учета личных финансов, исходя из смысла учета, который он благодаря диаграммам, может представить достаточно четко.

=== Диаграммы учета в реальной ситуации ===

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

Холдинг из нескольких юридических лиц продает товары и оказывает услуги физическим и юридическим лицам, в том числе другим холдингам. В рамках управленческого учета необходимо обеспечивать ведение расчетов с нужной степенью подробности, ограничивать отгрузку без оплаты установленными лимитами, контролировать своевременность оплат и обеспечивать выполнение сверок с клиентом. Бухгалтерский учет предполагает ведение счета 62 «Расчеты с покупателями и заказчиками» и счета 90 «Продажи», но с меньшей подробностью, чем ведение управленческих расчетов.

Для решения этой задачи имеет смысл разработать два плана счетов — отдельно для управленческого и отдельно для бухгалтерского учета.

Зачем это нужно? Дело в том, что у каждого вида учета свои заказчики. Управленческий учет ориентирован на потребности менеджеров по продажам и отражает их представление о состоянии расчетов, давая необходимую информацию для управленческих отчетов. В нем и названия счетов, и движение ресурсов по ним имеют понятный для менеджеров смысл. Бухгалтерский же учет ведется в терминах бухгалтерских счетов и отражает все особенности бухгалтерского учета. При этом в случае изменения правил учета или появления потребностей в новых отчетах каждый из планов счетов можно изменять независимо, обеспечивая требуемый функционал и не боясь нарушить работу другого учетного контура.

=== Управленческий учет ===

Диаграмма учета для управленческого плана счетов изображена на рисунке 4.

[[Файл:Рис_4.jpg|thumb|600px|center|Рис.4. Диаграмма учета для управленческого плана счетов]]

На ней присутствуют новые элементы — черные точки, которые отражают места незамкнутого учета: в рамках данного примера не ведутся текущие остатки товара на складе, расчетные счета и касса. Соответствующие операции отражаются в учете полупроводками.

<blockquote>
'''О направлении стрелок'''

Направление стрелки проводки к счету дебета соответствует естественному движению ресурса при участии в проводке активного счета. Однако в проводке между двумя пассивными счетами (в нашем примере это счета «Депозит», «Оплачено по контракту» и «Признанные обязательства») возникает одна нелогичность: перенос остатка происходит со счета дебета на счет кредита, т. е. в направлении, противоположном стрелке. Эта особенность требует привыкания, но, как показывает опыт, не мешает восприятию диаграммы. Альтернативные нотации (в которых, например, направление стрелок зависит от активности счетов в проводке) оказались менее удобными.
</blockquote>

Представленная схема управленческого учета имеет весьма сложный характер, что обусловлено многообразием различных сделок и правил расчета. Например, обязательства клиента разбиты на две части («Отгружено» и «Долг»): при проверке лимитов отгрузки используется общая сумма, а в сопоставлении участвует только «Долг». При появлении новых видов сделок или сложных операций зачета финансовому специалисту достаточно указать, по каким правилам пойдут проводки, после чего эти сделки автоматически начнут участвовать как в системе взаимозачетов, так и в отчетах.

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

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

=== Бухгалтерский учет ===

Диаграмма учета для бухгалтерского плана счетов другая. Она изображена на рисунке в упрощенном виде, без контура учета НДС (рис. 5).

[[Файл:Рис_5.jpg|thumb|600px|center|Рис.5. Диаграмма учета для бухгалтерского плана счетов]]

Здесь все сосредоточено вокруг нескольких субсчетов счета 62 «Расчеты с покупателями и заказчиками», на которых и ведется учет. При этом бухгалтерский учет на большинстве субсчетов ведется с меньшей подробностью, чем управленческий, а часть проводок получается из управленческого учета путем исключения лишних аналитик.

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

=== Соответствие управленческого и бухгалтерского учета ===

Типичной проблемой, возникающей при одновременном ведении нескольких видов учета, является их несоответствие. Многим знакома ситуация, когда менеджер по продажам имеет одно представление о задолженности клиента, а бухгалтер — совсем другое, и им сложно прийти к пониманию. Для устранения этой проблемы в рассматриваемой ситуации можно построить диаграмму, показанную на рисунке 6.

[[Файл:Рис_6.jpg|thumb|800px|center|Рис.6. Диаграмма соответствия управленческого и бухгалтерского учета]]

На ней изображено соответствие между управленческим (диаграмма слева) и бухгалтерским учетом (диаграмма справа). Различными цветами на диаграммах показаны области, поток ресурсов между которыми должен совпадать.

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

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

=== Заключение ===

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

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

----
<references/>

[[Категория:Максим Цепков (Статьи)]]
[[Категория:Бухгалтер и компьютер (Публикации)]]
[[Категория:2011 год (Статьи)]]

{{replicate-from-custiswiki-to-lib}}

Файл:БиК Цепков.pdf

2016-06-03T14:37:52Z

MaksTsepkov:

Блог:Максима Цепкова

2016-05-07T13:36:04Z

MaksTsepkov:

'''С 19.05.2014 профессиональный блог [[User:MaksTsepkov|Максима Цепкова]] переехал на личный сайт http://mtsepkov.org'''

Ранее блог был на http://blogs.uml2.ru/blogs/maksiq и http://softwarepeople.ru/, потом жил здесь, на сайте компании.

Оглавление (на момент переноса) [[Блог Максима Цепкова - оглавление]]

Другие мои публикации: [[:Категория:Максим Цепков|Выступления]] и [[:Категория:Максим Цепков (Статьи)|Статьи]]

{{replicate-from-custiswiki-to-lib}}

Разделение ответственности в заказной разработке (Максим Цепков на AnalystDays-2015)

2015-05-04T15:58:22Z

MaksTsepkov:

Доклад сделан 18.04 на [http://analystdays.ru/ru/program/31238 AnalystDays-4] в Минске
[http://www.slideshare.net/mtsepkov/responsibilities-in-software-development-tsepkov-analyst-days-2015-47277868 Презентация на slideshare]
[https://vimeo.com/125908126 Видео на Vimeo] (в статье тоже есть)

== Аннотация ==

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

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

== Annotation ==
Division of responsibilities in software development process is one of the most popular topics for discussions and chats. Participants are usually confident about other persons' misunderstanding of their responsibilities, although the issue of responsibilities division is certainly known. However, there's no the only true division of responsibilities in software development, because the boundaries depend on certain project aspects and special kinds of performed work: analysis, design, development, testing.

The presentation considers schemes of management and shared responsibility in software development: responsibilities and roles in the development team, division of responsibilities from the Company and the Customer and different stakeholders on the Customer's side. We are to discuss the origination of some schemes of shared responsibility, kinds of project characteristics, which affect design of project roles and those effects, which cause slack in different places of these schemes.

== Краткое изложение доклада ==

# Не существует единственно правильного разделения ответственности, его надо проектировать с учетом специфике проекта
# Для проектирования разделения ответственности нужна схема.
## Используем [http://en.wikipedia.org/wiki/V-Model_(software_development) V-диаграмму], так как на ней процесс изображен непрерывно - что позволяет двигать границы при проектировании.
## Принимать во внимание необходимо не только процесс в Компании-разработчике, но и Заказчика.
# Простой кейс: разработка по спецификациям.
## Разделение ответственности и способы передачи между заказчиком и разработчиком
## Деление ответственности в компании-разработчике
## Проблемы в разработке по спецификациям: передача через артефакты не работает, необходимы перекрывающиеся зоны ответственности и коммуникации. Причина - в природе ИТ-разработки [http://www.developerdotstar.com/mag/articles/reeves_design.html Jack W. Reeves «What is software design»] (1992), [http://lib.custis.ru/Блог:Роман_Корешков/Продукт_инженерной_деятельности_(в_разработке_ПО) перевод статьи]
# Заказчик и компания-разработчик: разделение ответственности и взаимодействие
## Для коммуникаций надо понимать структуру Заказчика.
### Разделение на Бизнес и ИТ.
### Проектированием и эксплуатацией занимаются разные подразделения.
### ИТ-проект, как правило, является частью бизнес-проекта.
## Передача ответственности от Заказчика к Компании выполняется не через артефакт - ТЗ, а через позицию Product Owner. Заказчик не всегда готов обеспечить эту позицию, в этом случае компании-разработчику надо быть готовой ее занять.
# Ответственность в компании-разработчике
## Аналитики. Поддержка Product Owner, закрывают разрыв между Заказчиком и Разработчиками. В части работы с требованиями - всегда, а в части сдачи внедрения есть два варианта: может быть сдача разработчиками, особенно при хороших автотестах, или модель внутреннего заказчика в лице аналитиков.
## Разделение ответственности между ролями Аналитик, Product Owner и Менеджер (он же Team Lead или Scrum Master). Не забывать - это - роли, им не обязательно соответствуют позиции, возможно совмещение.
## Тестировщик - младший аналитик или отдельная позиция в зависимости от организации процесса. Работа с тестировщиками, но без аналитиков.
## Артефакты на проекте поддерживают коммуникации и передачу ответственности. Их тоже надо проектировать, разделяя долговременные и временные.
## Архитектор, он же TechLead. Поддержка и Внедрение.
## Ответственность за управление - Менеджер и Product Owner. Для описания удобно использовать не V-диаграмму, а альфы OMG Essence.
## Ответственность за технологизацию: Product Owner, Архитектор и Менеджер. Тоже на диаграмме альф OMG Essence.
## Размер команды. Варианты масштабирования на большие и малые проекты.

= Видео =

Это видео снято Владом Марковым из нашей компании на конференции. Официальное видео конференции будет позднее.

{{vimeoembed|125908126|800|500}}

= Полная презентация =

<div style="text-align:left;">[[File:Responsibilities in software development Tsepkov AnalystDays-2015.pdf|page=-|400px|border]]</div>

[[Category:Максим Цепков]][[Category:Менеджмент (доклады)]]{{Replicate-from-custis-wiki-to-lib}}

Файл:Responsibilities in software development Tsepkov AnalystDays-2015.pdf

2015-05-04T15:49:35Z

MaksTsepkov:

Развитие управления проектами и критериев качества в ИТ (Максим Цепков на AgileDays-2015)

2015-04-05T22:47:32Z

MaksTsepkov:

[http://msk15.agiledays.ru/members/profile/898/#report-19 Доклад на сайте AgileDays], прочитан 19.03.2015.
По тем же слайдам был доклад на [http://2015.codefest.ru/lecture/1056 CodeFest] в Новосибирске 29.03
[http://www.slideshare.net/mtsepkov/big-picture-of-it-project-managerment-tsepkov-agile-days-2015 Презентация на slideshare]
[https://vimeo.com/123181695 Видео на Vimeo] (в статье тоже есть)

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

В докладе сделана попытка представить если не цельный концепт, то систематичное изложение, Big Picture с позиционированием примеров в общем поле. По опыту выступления, попытка удалась.

= Аннотация =

Управление проектами и критерии качества в ИТ прошли долгий путь исторического развития, сменив несколько моделей. Начиналось все с совершенного программного обеспечения (software system) как результата качественного проектирования, свойственного НИОКР. Далее был период всеобъемлющего нормирования процессов по их разработке (PMBoK 3, RUP), сменившийся, отчасти революционно, гибкими подходами к разработке (SCRUM, Kanban), которые сделали упор на сроки и предсказуемость поставки. А сейчас фокус сместился на удовлетворенность стейкхолдеров и достижение бизнес-целей (OMG Essence of Software Engineering).

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

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

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

= Видео =

{{vimeoembed|123181695|800|500}}

= Краткое содержание =

== Моды ведения проектов - исторический обзор ==

[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=18|400px|border|right]]

# Исторически ИТ-разработка выросла из норм ведения НИОКР, к которым термин "услуга" применим в значительной степени условно. Ситуация изменилась с появлением персональных компьютеров, достаточно мощных для автоматизации предприятий, которые сделали востребованной осуществление этой автоматизации как услугу. Оказание этой услуги методами НИОКР оказалось невозможным из-за кадрового голода: формат НИОКР предполагает достаточно квалифицированный персонал, которого в необходимых объемах просто не существовала. Первый подход к решению этой задачи заключался в нормировании процессов.
# На первую половину 2000-х нормой оказания ИТ-услуги является ведение проекта по разработке (внедрению) ИТ-системы, которую необходимо спроектировать, а затем изготовить и внедрить с заданными критериями качества. Этот подход зафиксирован в PMBOK 3 версии (2004), на него же ориентирован RUP (2003). При этом упор делался на правильную организацию и надлежащее исполнение процессов. Далее я буду это называть "классическим подходом".
# Проекты, не смотря на тяжелые процессы, не приводили к результату. Проблемы касались качественного планирования и проектирования, которое разбивалось об изменчивость мира. На уровне стандарта (PMBOK) было зафиксировано, что даже тщательное исполнение процессов и реализация в соответствии не дает гарантии достижения целей проекта.
# Как ответ на вызов - появился Agile и SСRUM внутри него.
## SСRUM во главу угла поставил наблюдение за движением по проектной траектории. При этом было сформулировано, что задачу планирования решать бесполезно, надо определить цель и мерить до нее расстояние. А двигаться - итерациями, корректируя план.
## Нормировка качественного проекта изменилась, теперь в основу ставят адекватность оценки расстояния до цели и соответствие продвижения в итерацию предварительным оценкам. Для целей мониторинга движения к цели в отрасль втянута концепция SMART-целей, характеризующихся, в частности, измеримостью (Measurable). Сама концепция была известна в менеджменте с 60-х, приписывается то ли Друкеру (английская вики), то ли другим основателям.
## SCRUM позволил существенно снизить планку требований к младшему управленческому персоналу в ИТ с сохранением приемлемого уровня исполнения проектов, чем и объясняется его успех.
## После успеха SCRUM в отрасли итерационность разработки попробовали заложить в PMBOK 4 версии (2008), но по факту получилась эклектика. Там же попробовали нормировать проектирование (аналитическую работу), но через организацию процессов это тоже не получилось. Отмечу, что в RUP итерационность была изначально, а в другом стандарте, SWEBOK появилась в версии 3 (2004), однако там по факту речь шла о тяжелых итерациях, которые не возможно прокрутить быстро, как того требовал Agile. Таким образом, в стандарте уровня отрасли нормы Agile проявлены не были.
# Это путь развития в масштабе мира. В России на этот тренд накладываются события 90-х, в результате которых обеспеченность ИТ-отрасли квалифицированными кадрами, вышедшими из науки и способными оказывать ИТ-услугу методами НИОКР была существенно выше, чем в мире. В результате использование процессного нормирования оказалось существенно менее выражено. В настоящее время эффект в значительной степени размыт, и отличие России от всего мира - нивелируется.

== Современное состояние и вектора развития ==

# Agile и SCRUM сдвинули норму оказания отрасли от проектной деятельности к непрерывной, процессной. Такую организацию можно применять не только для начальной разработки или существенному реинжинирингу, но и к текущему развитию и доработке систем. Следующим шагом на пути в этом направлении стал ИТ-вариант Kanban-процесса. Это примерно 2010. Дальнейшее развитие этого сдвига - тренд DevOps.
# Ортогональная сдвижка, произошедшая в отрасли примерно в то же время - смещение фокуса от качества ИТ-системы (во всех смыслах, включая функционирование) к удовлетворенности стейкхолдеров проекта. Это смещение отчасти отразилось в PMBOK 5 версии (2013).
# Еще одно направление сдвижки - фокус на достижение возможностей для бизнеса, которые должны обеспечить ИТ. Эта сдвижка видна преимущественно в стартап-проектах и в продуктовой разработке, особенно в производстве игр. Сдвиг произошел после 2010.
# Произошедшие сдвижки нормирования зафиксированы в The Essence of Software Engineering, выдвинутой SEMAT и принимаемый сейчас OMG (beta1 - july 2013, beta2 - may 2014). В процессе работы из стандарта тщательно вычищали слово "проект", обеспечивая применимость на всех стадиях жизненного цикла. А в основные альфы включены стейкхолдеры, с которыми идет работа и возможности для бизнеса, которые желают получить.
# Проблема правильного проектирования систем и нормировки в этом поле не решена в отрасли по-прежнему. Лучшее известное мне решение для процесса управления проектом - FDD (Джефф де Люка), а для способа разработки проекта - DDD (Эрик Эванс)

== BigPicture методов ведения проектов ==

[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=19|400px|border|right]]

Историческая картина есть. Можно применять на практике? Нет, сначала нужно положить это на схемы, сделать Big Picture, на которых можно об этом рассуждать.

# Эпохи в историческом развитии - самый простой способ. Но лишь показывает историю, а не дает возможность конструирования своего.
# Вектора развития. Все они сохраняют актуальность, так как следующий этап - дополняет и расширяет предыдущий. Похожая, но отличающаяся картина - [http://lib.custis.ru/Культуры_программных_проектов_(Энтони_Лаудер) Энтони Лаудер "Культуры программных проектов"].
# История развитие как смещение фокусов внимания на схеме OMG Essence.
# Изменения на V-диаграмме: ИТ-проект как интегрированная часть бизнес-проекта, раньше их рассматривали достаточно изолировано.

== Применение на практике ==

[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=32|400px|border|right]]

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

{{----}}
= Полная презентация =

<div style="text-align:left;">[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=-|400px|border]]</div>

[[Category:Максим Цепков]][[Category:Менеджмент (доклады)]]{{Replicate-from-custis-wiki-to-lib}}

DDD - эффективный способ работы в условиях системной сложности (Максим Цепков на SECR-2011)

2015-04-05T22:26:07Z

MaksTsepkov:

Доклад сделан на [http://secr.ru SECR-2011] 02.11.2011
Презентация [http://www.slideshare.net/custisppt/custis-tsepkovsecr2011 на slideshare]

<big>'''DDD — эффективный способ работы в условиях системной сложности'''</big>

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

<big>'''DDD as an effective method of work in conditions of system complexity'''</big>

The report describes application of DDD methods to development of complex IT systems. The essence is to construct the single model of company and system described with ubiquitous language clear for all project participants, including business-specialists.

{{remark|Из отзывов [http://twitter.com/#!/avivanov/status/131638880150634496 Понравился доклад Макса Цепкова на #secr2011. Вернул мне веру в то, что кто-то до сих пор серьёзно применяет моделирование и с пользой)] Твиттер от [http://twitter.com/#!/avivanov Андрея Иванова], COO JetBrains}}

=Краткие тезисы=

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

Эффективно работать в условиях системной сложности помогает применение принципов DDD — построение единой модели предприятия и системы, описанной на едином языке, понятном всем участникам проекта: бизнес-экспертам, аналитикам, разработчикам и пользователям. Это позволяет бизнес-специалистам верифицировать модель и самостоятельно проектировать изменения в системе без привлечения высококвалифицированных архитекторов и бизнес-аналитиков.

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

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

=Annotation=

The presentation describes application of the Domain-Driven Design (DDD) methods to software design and development for large companies, which possess system complexity. In this case business model of company, model of IT system and system itself are inevitably very complex and it is practically impossible to guarantee their correspondence. In addition, these models and consequently the structure of the system could be hardly understood by business specialists. This causes additional risks for software company (because the model could not be entirely verified by business) and makes further work with such system more complicated for business specialists.

Application of the DDD principles helps to work effectively in conditions of system complexity. It means constructing the single model of company and system and describing it with ubiquitous language, which could be easily understood by all the participants of the project: business experts, analysts, developers and end-users. This enables business specialists to verify the model and to plan changes in the system independently, without attraction of highly skilled architects and business analysts.

We successfully apply described approach for development of corporate applications. Constructing single model we use diagrams of three types (of classes, of accounting and of states) and describe them using business terms. These diagrams are transparently reflected in the system, up to the use of the same terms in the interface.

Thus, DDD makes possible successful work in conditions of system complexity due to the use of ubiquitous language and construction of the single model, which is understandable for all participants of the project, including specialists from the business side.

=Развернутое изложение=

==Проблема==

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

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

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

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

==Решение==

Какие же способы позволяют если не решить, то существенно уменьшить проблемы, возникающие при проектировании ИТ-систем для больших предприятий? Как работать с системной сложностью?
Перспективным и активно применяемым в настоящее время подходом является Domain-Driven Design (DDD, предметно-ориентированное проектирование). Основополагающими принципами этого подхода являются проектирование по модели (что само по себе не является чем-то принципиально новым) и использование для описания этой модели единого языка (ubiquitous language), понятного всем участникам проекта: бизнес-экспертам, аналитикам, разработчикам и пользователям. Применение этих принципов позволяет бороться со многими сложностями.

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

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

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

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

==Практика==

Как бы ни были важны теоретические подходы, гораздо большее значение имеет их успешное применение в практической деятельности. Как говорится, «теория без практики мертва». Мы успешно применяем методы DDD к разработке корпоративных приложений. При этом для построения единой модели мы используем:
* диаграммы классов (для представления объектной структуры документов и справочников);
* диаграммы учета (для отражения учета в системе);
* диаграммы состояний (для представления документооборота как основы реализации бизнес-процессов и связи документов с учетом).

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

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

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

= Об авторе =

[[Категория:Максим Цепков]]
;Докладчик: [[:Категория:Максим Цепков|Максим Цепков]]

Максим Цепков – соучредитель и главный архитектор компании CUSTIS, в которой работает со дня основания (1996). Закончил с отличием Факультет управления и прикладной математики Московского физико-технического института, имеет авторские свидетельства. Основная область профессиональных интересов – создание архитектуры корпоративных и банковских информационных систем, поиск баланса между общими архитектурными подходами и реализацией специфических требований заказной разработки для поддержки уникальных бизнес-процессов клиентов.

Максим Цепков является экспертом в области бизнес- и системного анализа, занимается развитием шаблонов и технологий проектирования, разработкой методик применения диаграмм. Под руководством Максима и при его непосредственном участии разработано несколько технологических платформ, на которых строятся проекты CUSTIS. Максим выступает основным идеологом и создателем архитектурного шаблона для информационных систем – «Учетной машины» и диаграмм планов счетов для отображения и проектирования учета. Эти технологии применяются во всех проектах компании для банков и предприятий.

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

Максим активно участвует в развитии внутренних процессов и совершенствовании практик применения гибких методологий разработки и коллективного проектирования в CUSTIS.

Максим Цепков – участник различных профессиональных конференций и автор ряда публикаций в профильных журналах.

'''In english'''

Maxim Tsepkov is a co-founder and the chief software architect of CUSTIS since 1996, he has master degree from Moscow Institute of Physics and Technology, Control/Management and Applied Mathematics department, has many author’s certificates. The main author’s area of interests is the architecture of enterprise information systems, especially searching for balance between the common architecture patterns and practice of specific customized development for unique business processes.

Maxim Tsepkov is an expert in business and system analysis, deployment and development architecture patterns, models and diagrams. Many CUSTIS projects based on several frameworks that developed under the guidance of Maxim Tsepkov. He is the main designer of the application patterns for information system named as Accounting Engine and accounting diagrams, used for visualization and desining of accounting. This technologies used in all company’s projects for business. In fact, Maxim contributes to most of company’s projects. He is competent in design of distributed systems, system integration, and graceful deployment process, when new system gradually replaced the old system without any business-process disturbance.

Maxim contributes to evolution of agile software development process in company and practice of team software design. He is an active of professional conferences and author of various publications in CIO magazines.

{{replicate-from-custiswiki-to-lib}}
[[Категория:Аналитика (доклады)]]
[[Категория:Архитектура (доклады)]]
[[Категория:Открытые Семинары]]

Развитие управления проектами и критериев качества в ИТ (Максим Цепков на AgileDays-2015)

2015-03-22T09:42:52Z

MaksTsepkov:

[http://msk15.agiledays.ru/members/profile/898/#report-19 Доклад на сайте конференции]
[http://www.slideshare.net/mtsepkov/big-picture-of-it-project-managerment-tsepkov-agile-days-2015 Презентация на slideshare]
{{red|Видео ожидается}}

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

В докладе сделана попытка представить если не цельный концепт, то систематичное изложение, Big Picture с позиционированием примеров в общем поле. По опыту выступления, попытка удалась.

= Аннотация =

Управление проектами и критерии качества в ИТ прошли долгий путь исторического развития, сменив несколько моделей. Начиналось все с совершенного программного обеспечения (software system) как результата качественного проектирования, свойственного НИОКР. Далее был период всеобъемлющего нормирования процессов по их разработке (PMBoK 3, RUP), сменившийся, отчасти революционно, гибкими подходами к разработке (SCRUM, Kanban), которые сделали упор на сроки и предсказуемость поставки. А сейчас фокус сместился на удовлетворенность стейкхолдеров и достижение бизнес-целей (OMG Essence of Software Engineering).

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

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

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

= Краткое содержание =

== Моды ведения проектов - исторический обзор ==

[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=18|400px|border|right]]

# Исторически ИТ-разработка выросла из норм ведения НИОКР, к которым термин "услуга" применим в значительной степени условно. Ситуация изменилась с появлением персональных компьютеров, достаточно мощных для автоматизации предприятий, которые сделали востребованной осуществление этой автоматизации как услугу. Оказание этой услуги методами НИОКР оказалось невозможным из-за кадрового голода: формат НИОКР предполагает достаточно квалифицированный персонал, которого в необходимых объемах просто не существовала. Первый подход к решению этой задачи заключался в нормировании процессов.
# На первую половину 2000-х нормой оказания ИТ-услуги является ведение проекта по разработке (внедрению) ИТ-системы, которую необходимо спроектировать, а затем изготовить и внедрить с заданными критериями качества. Этот подход зафиксирован в PMBOK 3 версии (2004), на него же ориентирован RUP (2003). При этом упор делался на правильную организацию и надлежащее исполнение процессов. Далее я буду это называть "классическим подходом".
# Проекты, не смотря на тяжелые процессы, не приводили к результату. Проблемы касались качественного планирования и проектирования, которое разбивалось об изменчивость мира. На уровне стандарта (PMBOK) было зафиксировано, что даже тщательное исполнение процессов и реализация в соответствии не дает гарантии достижения целей проекта.
# Как ответ на вызов - появился Agile и SСRUM внутри него.
## SСRUM во главу угла поставил наблюдение за движением по проектной траектории. При этом было сформулировано, что задачу планирования решать бесполезно, надо определить цель и мерить до нее расстояние. А двигаться - итерациями, корректируя план.
## Нормировка качественного проекта изменилась, теперь в основу ставят адекватность оценки расстояния до цели и соответствие продвижения в итерацию предварительным оценкам. Для целей мониторинга движения к цели в отрасль втянута концепция SMART-целей, характеризующихся, в частности, измеримостью (Measurable). Сама концепция была известна в менеджменте с 60-х, приписывается то ли Друкеру (английская вики), то ли другим основателям.
## SCRUM позволил существенно снизить планку требований к младшему управленческому персоналу в ИТ с сохранением приемлемого уровня исполнения проектов, чем и объясняется его успех.
## После успеха SCRUM в отрасли итерационность разработки попробовали заложить в PMBOK 4 версии (2008), но по факту получилась эклектика. Там же попробовали нормировать проектирование (аналитическую работу), но через организацию процессов это тоже не получилось. Отмечу, что в RUP итерационность была изначально, а в другом стандарте, SWEBOK появилась в версии 3 (2004), однако там по факту речь шла о тяжелых итерациях, которые не возможно прокрутить быстро, как того требовал Agile. Таким образом, в стандарте уровня отрасли нормы Agile проявлены не были.
# Это путь развития в масштабе мира. В России на этот тренд накладываются события 90-х, в результате которых обеспеченность ИТ-отрасли квалифицированными кадрами, вышедшими из науки и способными оказывать ИТ-услугу методами НИОКР была существенно выше, чем в мире. В результате использование процессного нормирования оказалось существенно менее выражено. В настоящее время эффект в значительной степени размыт, и отличие России от всего мира - нивелируется.

== Современное состояние и вектора развития ==

# Agile и SCRUM сдвинули норму оказания отрасли от проектной деятельности к непрерывной, процессной. Такую организацию можно применять не только для начальной разработки или существенному реинжинирингу, но и к текущему развитию и доработке систем. Следующим шагом на пути в этом направлении стал ИТ-вариант Kanban-процесса. Это примерно 2010. Дальнейшее развитие этого сдвига - тренд DevOps.
# Ортогональная сдвижка, произошедшая в отрасли примерно в то же время - смещение фокуса от качества ИТ-системы (во всех смыслах, включая функционирование) к удовлетворенности стейкхолдеров проекта. Это смещение отчасти отразилось в PMBOK 5 версии (2013).
# Еще одно направление сдвижки - фокус на достижение возможностей для бизнеса, которые должны обеспечить ИТ. Эта сдвижка видна преимущественно в стартап-проектах и в продуктовой разработке, особенно в производстве игр. Сдвиг произошел после 2010.
# Произошедшие сдвижки нормирования зафиксированы в The Essence of Software Engineering, выдвинутой SEMAT и принимаемый сейчас OMG (beta1 - july 2013, beta2 - may 2014). В процессе работы из стандарта тщательно вычищали слово "проект", обеспечивая применимость на всех стадиях жизненного цикла. А в основные альфы включены стейкхолдеры, с которыми идет работа и возможности для бизнеса, которые желают получить.
# Проблема правильного проектирования систем и нормировки в этом поле не решена в отрасли по-прежнему. Лучшее известное мне решение для процесса управления проектом - FDD (Джефф де Люка), а для способа разработки проекта - DDD (Эрик Эванс)

== BigPicture методов ведения проектов ==

[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=19|400px|border|right]]

Историческая картина есть. Можно применять на практике? Нет, сначала нужно положить это на схемы, сделать Big Picture, на которых можно об этом рассуждать.

# Эпохи в историческом развитии - самый простой способ. Но лишь показывает историю, а не дает возможность конструирования своего.
# Вектора развития. Все они сохраняют актуальность, так как следующий этап - дополняет и расширяет предыдущий. Похожая, но отличающаяся картина - [http://lib.custis.ru/Культуры_программных_проектов_(Энтони_Лаудер) Энтони Лаудер "Культуры программных проектов"].
# История развитие как смещение фокусов внимания на схеме OMG Essence.
# Изменения на V-диаграмме: ИТ-проект как интегрированная часть бизнес-проекта, раньше их рассматривали достаточно изолировано.

== Применение на практике ==

[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=32|400px|border|right]]

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

{{----}}
= Полная презентация =

<div style="text-align:left;">[[File:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf|page=-|400px|border]]</div>

[[Category:Максим Цепков]][[Category:Менеджмент (доклады)]]{{Replicate-from-custis-wiki-to-lib}}

Файл:Big Picture of IT project managerment Tsepkov AgileDays-2015.pdf

2015-03-19T22:29:46Z

MaksTsepkov:

Разделение ответственности в заказной разработке (Максим Цепков на SPMconf-2015)

2015-02-03T15:40:52Z

MaksTsepkov: MaksTsepkov переименовал страницу Разделение ответственности в заказной разработке (Максим Цепков на SPMconf-2015) в [[Разделение ответственност…

#перенаправление [[Разделение ответственности в заказной разработке (Максим Цепков на AnalystDays-2015)]]

Когда всем понятно

2015-01-23T10:31:56Z

MaksTsepkov:

;[[:Категория:Максим Цепков (Статьи)|Максим Цепков]]: главный архитектор компании CUSTIS

<html><div style="float:right; margin:1em;"><a href="http://www.buhcomp.ru/htm/new_namb/arhive_2011/05/arhive.shtml"><img width="350px" src="http://www.buhcomp.ru/htm/new_namb/arhive_2011/05/images/BK05-2011_Total.gif"></a></div></html>

Опубликовано в журнале [http://www.buhcomp.ru/ Бухгалтер и компьютер], № 5(май), 2011

== Когда всем понятно. Диаграммы учета: мост между бухгалтером и разработчиком ==

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

<blockquote>
'''Эффективное представление информации'''

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

Развитие науки показало, что многие виды информации можно эффективно представлять в виде диаграмм, а достижения информационных технологий позволили эти диаграммы быстро и легко строить и изменять. В настоящее время представление данных в виде диаграмм является общепринятым и интенсивно развивается, поскольку даёт компактную и наглядную целостную картину, с которой можно эффективно работать, обращаясь к детальной информации только по необходимости. Множество графических решений используется и для описания бизнес-процессов.
</blockquote>

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

=== Диаграммы учета: простой пример ===

В качестве иллюстрации использования диаграмм учета приведём простой пример учёта личных финансов. Хотя он носит достаточно умозрительный характер, его безусловным достоинством является простота.

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

Все эти операции можно изобразить на неформальной схеме, чтобы получить хороший визуальный образ (рис. 1).

[[Файл:Рис_1.jpg|thumb|300px|center|Рис.1. Неформальная схема учета личных финансов]]

Система должна давать возможность получить ответы на следующие вопросы: сколько у меня денег и где; кому я должен и сколько; кто мне должен и сколько; на что я трачу деньги; какие у меня есть доходы и из каких источников.

Для этого нужно спроектировать учетные регистры и изобразить их на той же схеме (рис. 2).
[[Файл:Рис_2.jpg|thumb|300px|center|рис.2. Схема учета личных финансов с выделенными учетными регистрами]]

Овалы, обозначающие учетные регистры, можно разделить на три группы.

#'''Зеленые''' («Наличные», «Карточка» и «Мне должны») — средства, на которые можно рассчитывать.
#'''Желтые''' («Кредит в банке» и «Я должен») — отрицательные ресурсы.
#'''Изображенные пунктиром''' — «Доходы» и «Расходы».

Как легко заметить, эти группы оказались соответствующими разделам бухгалтерского баланса: зеленые — активы, желтые — пассивы, а стрелки между ними отражают проводки, приводящие к их изменению. При этом стрелка на проводке направлена к счету дебета.

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

Далее нужно определить аналитические признаки учетных регистров, которые позволят отвечать на поставленные вопросы. Например, чтобы можно было узнать, кто мне должен, счет «Мне должны» должен иметь аналитику «Кто», обозначающую человека, которому я дал в долг. А чтобы давать информацию о том, на что я трачу деньги, счет «Расходы» должен иметь аналитику «На что», обозначающую статью расходов.

Теперь можно изобразить все на формальной схеме (рис. 3).

[[Файл:Рис_3.jpg|thumb|400px|center|Рис.3. Диаграмма учета личных финансов]]

На диаграмме овалами изображены синтетические счета и для каждого счета указаны его название и аналитики. Пассивные счета выделены оранжевым, а активные — зеленым цветом. Проводки изображены стрелками, направленными к счету дебета, а надписи на них обозначают порождающие их хозяйственные операции. Счета «Наличные» и «Карточка» удобно рассматривать как субсчета общего счета «Деньги», потому что часть операций может осуществляться с любым из них. Отношение субсчетов к основному счету показано треугольной стрелкой.

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

Ответы на поставленные вопросы можно получить путем анализа остатков и оборотов по учетным счетам. Например, ответом на вопрос «Сколько у меня денег и где?» будут остатки на счетах «Наличные» и «Карточка» в разрезе аналитики «Банк» и т. д. Собственно говоря, ответы на вопросы и есть отчеты, а учет конструируется исходя из того, какие отчеты понадобятся.

Достоинством таких диаграмм является то, что они показывают связь между учетом и потоками материальных ресурсов. Кроме того, диаграммы учета помогают бухгалтеру и финансисту в общении с разработчиком: им достаточно просто нарисовать соответствующую стрелку — и операция будет реализована в системе. А для простых операций разработчик (или аналитик) и сам может Диаграмма учета личных финансов, исходя из смысла учета, который он благодаря диаграммам, может представить достаточно четко.

=== Диаграммы учета в реальной ситуации ===

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

Холдинг из нескольких юридических лиц продает товары и оказывает услуги физическим и юридическим лицам, в том числе другим холдингам. В рамках управленческого учета необходимо обеспечивать ведение расчетов с нужной степенью подробности, ограничивать отгрузку без оплаты установленными лимитами, контролировать своевременность оплат и обеспечивать выполнение сверок с клиентом. Бухгалтерский учет предполагает ведение счета 62 «Расчеты с покупателями и заказчиками» и счета 90 «Продажи», но с меньшей подробностью, чем ведение управленческих расчетов.

Для решения этой задачи имеет смысл разработать два плана счетов — отдельно для управленческого и отдельно для бухгалтерского учета.

Зачем это нужно? Дело в том, что у каждого вида учета свои заказчики. Управленческий учет ориентирован на потребности менеджеров по продажам и отражает их представление о состоянии расчетов, давая необходимую информацию для управленческих отчетов. В нем и названия счетов, и движение ресурсов по ним имеют понятный для менеджеров смысл. Бухгалтерский же учет ведется в терминах бухгалтерских счетов и отражает все особенности бухгалтерского учета. При этом в случае изменения правил учета или появления потребностей в новых отчетах каждый из планов счетов можно изменять независимо, обеспечивая требуемый функционал и не боясь нарушить работу другого учетного контура.

=== Управленческий учет ===

Диаграмма учета для управленческого плана счетов изображена на рисунке 4.

[[Файл:Рис_4.jpg|thumb|600px|center|Рис.4. Диаграмма учета для управленческого плана счетов]]

На ней присутствуют новые элементы — черные точки, которые отражают места незамкнутого учета: в рамках данного примера не ведутся текущие остатки товара на складе, расчетные счета и касса. Соответствующие операции отражаются в учете полупроводками.

<blockquote>
'''О направлении стрелок'''

Направление стрелки проводки к счету дебета соответствует естественному движению ресурса при участии в проводке активного счета. Однако в проводке между двумя пассивными счетами (в нашем примере это счета «Депозит», «Оплачено по контракту» и «Признанные обязательства») возникает одна нелогичность: перенос остатка происходит со счета дебета на счет кредита, т. е. в направлении, противоположном стрелке. Эта особенность требует привыкания, но, как показывает опыт, не мешает восприятию диаграммы. Альтернативные нотации (в которых, например, направление стрелок зависит от активности счетов в проводке) оказались менее удобными.
</blockquote>

Представленная схема управленческого учета имеет весьма сложный характер, что обусловлено многообразием различных сделок и правил расчета. Например, обязательства клиента разбиты на две части («Отгружено» и «Долг»): при проверке лимитов отгрузки используется общая сумма, а в сопоставлении участвует только «Долг». При появлении новых видов сделок или сложных операций зачета финансовому специалисту достаточно указать, по каким правилам пойдут проводки, после чего эти сделки автоматически начнут участвовать как в системе взаимозачетов, так и в отчетах.

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

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

=== Бухгалтерский учет ===

Диаграмма учета для бухгалтерского плана счетов другая. Она изображена на рисунке в упрощенном виде, без контура учета НДС (рис. 5).

[[Файл:Рис_5.jpg|thumb|600px|center|Рис.5. Диаграмма учета для бухгалтерского плана счетов]]

Здесь все сосредоточено вокруг нескольких субсчетов счета 62 «Расчеты с покупателями и заказчиками», на которых и ведется учет. При этом бухгалтерский учет на большинстве субсчетов ведется с меньшей подробностью, чем управленческий, а часть проводок получается из управленческого учета путем исключения лишних аналитик.

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

=== Соответствие управленческого и бухгалтерского учета ===

Типичной проблемой, возникающей при одновременном ведении нескольких видов учета, является их несоответствие. Многим знакома ситуация, когда менеджер по продажам имеет одно представление о задолженности клиента, а бухгалтер — совсем другое, и им сложно прийти к пониманию. Для устранения этой проблемы в рассматриваемой ситуации можно построить диаграмму, показанную на рисунке 6.

[[Файл:Рис_6.jpg|thumb|800px|center|Рис.6. Диаграмма соответствия управленческого и бухгалтерского учета]]

На ней изображено соответствие между управленческим (диаграмма слева) и бухгалтерским учетом (диаграмма справа). Различными цветами на диаграммах показаны области, поток ресурсов между которыми должен совпадать.

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

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

=== Заключение ===

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

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

----
<references/>

[[Категория:Максим Цепков (Статьи)]]
[[Категория:Бухгалтер и компьютер (Публикации)]]
[[Категория:2011 год (Статьи)]]

{{replicate-from-custiswiki-to-lib}}

Блог:Максима Цепкова/SPMconf-2013

2014-10-19T20:09:22Z

MaksTsepkov:

[[Файл:SPMconf-2013-1.jpg|right|300px]]
[[Файл:SPMconf-2013-2.jpg|right|300px]]
Третья конференция [http://spmconf.ru/ru/index-news.sdf/spmconf/spmconf3 SPMconf] проходила в Казани. Она явно высветила современный тренд в управлении — работу с людьми. Было много мастер-классов и докладов по психологии, работе с ценностями и другими аналогичным вопросам, и они вызывали очень большой интерес. Собственно, на первом слоте я недоумевал: почему в залах с докладами так мало народа. Пока не поднялся на второй этаж, где проходил мастер-класс Дмитрия Лазарева по принятию решений в командах, — участники были там (смотри фото справа). И это был не единственный доклад по психологии общения. Правда, остальные не включали практику, а это куда менее интересно.

Был интересный доклад Димы Безуглого с мощным троллингом Agile-подходов, у которых не получилось сделать гибкое ПО, - софт получается жесткий, под конкретный случай. Только, к сожалению, у других подходов часто вообще не получается сделать ПО: мир и требования к софту меняются быстрее, чем успевают провернуть тщательный процесс. По факту, то, что работает, — это симбиоз из подходов гибкой разработки и хорошо проработанных раньше подходов к проектированию, и сейчас их в больших проектах снова «извлекают из шкафов» и экспериментируют. В общем, закон отрицания отрицания в действии. А еще метод Fail Fast: прототипируйте, проверяя критичные ограничения. Как Google Glass: до него куча дорогостоящих фейлов по аналогичным устройствам была потому, что получались недопустимо тяжелые вещи. И они начали с того, что определили предельный вес устройства, что можно сделать почти бесплатными экспериментами, а уж потом придумывали начинку в этом жестком ограничении. И в целом доклад — фейерверк троллинга («Видели мы ваш Захман-фреймворк, утопитесь сами»), его стоит послушать.

Еще был любопытный доклад Асхата про культуру, с Schneider Culture Model. И о том, что основная проблема изменений в большой компании — это масса менеджеров среднего звена. Они пережили CMMI, пережили Agile, и все остальное — переживут, они это умеют. И впрочем, на мой взгляд, тут было много поверхностного, включая методы работы.

Неожиданно содержательный получился круглый стол «Образование и ИТ», о котором я написал отдельный отзыв. Особенно в контексте открытия в Казани университета, который будет давать ИТ-программу Карнеги-Меллона и в котором будет преподавать западный штат профессоров. Для него строится отдельный город-спутник — Иннополис. Правда стоимость обучения зашкаливает. Ректор Саша Тормасов переехал в Казань из Москвы и сейчас поднимает это дело.

Я сам тоже неожиданно выступил с докладом [http://spmconf.ru/talk.sdf/spmconf/spmconf3/talks/15073 Agile в контексте большого менеджмента]. Один из докладчиков неожиданно отказался, и меня позвали заменить. Но была интересная тема, по которой хотелось поделиться мыслями, и как раз уместная на этой конференции. Сопоставить Agile, как способ менеджмента в ИТ, и «большой менеджмент», способ управления деятельностью в других отраслях. У меня есть мнение, что Agile представляет собой продвинутый способ менеджмента, и в других отраслях к этому постепенно приходят. Но при этом первоначальный импульс Agile-методов, который дал достаточно интенсивное развитие, сейчас исчерпан, поэтому лидеры строят сложные продвинутые конструкции, противники говорят, что давно ожидали, когда оно выдохнется, а любители серебряных пуль жалуются, что их опять обманули. Об этом был доклад и обсуждение потом.

Так что в целом конференция прошла ожидаемо хорошо.

'''UPD''' Отзыв на круглый стол '''об образовании в IT''', опубликованный мной во время конференции на сайте SoftwarePeople исчез вместе с сайтом - восстанавливаю здесь.

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

Дальше тезисы без авторства в некотором логическом порядке.
* Бизнес к образованию относится как к данности: какое есть, такое есть. Знает качество вузов. Где-то помогает, основывает кафедры, сотрудничает с преподавателями. Где-то закрывает проблемы сам.
* ВУЗам нормальное образование для бизнеса по большому счету не нужно. У них - другие KPI. И там где идет - оно, скорее, на личном факторе, вопреки.
* Центры образования ряда крупных ИТ-компаний готовят кадры не только внутрь, но и для отрасли, вопросы конкуренции тут не играют.
* Некоторые ИТ-компании готовы отказаться от своих корпоративных университетов, если ВУЗы начнут выдавать адекватных специалистов. mail.ru, Itransition. Сейчас готовы, потому что образование - непрофильная деятельность, отвлекает. Но они вынуждены ее развивать и через несколько лет ВУЗы им просто станут не нужны, они будут уверены, что сделают все лучше.
* Основная претензия к ВУЗам - даже не плохое образование. Нынешние ВУЗы калечат людей: если на первом курсе глаза горели, то к пятому они потухают. Способные просто уходят работать и для них ВУЗ становится обузой - для корочки и армии.
* Программы в ВУЗах устарели безнадежно. Архитектура и прочие программы ИТ-шных инженеров написаны в 70-х(!) На Западе лучше не сильно: программа Карнеги-Мелон, которую тиражируют по миру и сейчас в Казани, Иннополисе - это конец 90-х :(
* В теории ВУЗ должен давать базовое образование, это все признают. Это нужно бизнесу и это как раз то, что он не дает в своих центрах. Только вот для него достаточно двух семестров, 3-4 года не нужно. Ну и по факту дают его плохо.
* На Западе ВУЗы передовые не за счет программы. Просто рядом с каждым ведущим Университетом есть сильный Research-центр. При чем туда уходят люди, проработав в индустрии лет 15, чтобы реализовать силами студентов и аспирантов свои идеи. Часть из которых стреляет - Oracle, Linux, VMWare - зарождалось так. Карнеги-Мелон - не исключение, более того, у него - один из самых сильных центров.
* А у нас ИТ-шник из бизнеса не может уходить в ВУЗы. Задают вопросы про степень и прочее. Предлагали - а давай оформим другого, а ты будешь работать. И прочие дурацкие вещи. В результате ИТ-шники уходят в тренера - Дорофеев, Куприянов...
* И мы так и не выяснили, кому нужно, чтобы ВУЗ поставлял бизнесу нормальные кадры. Бизнес - приспособился. Над ВУЗами - не каплет. Государство как заинтересованную сторону никто не рассматривает, во всяком случае его методы вызывают общий скепсис.
* На глобальном уровне может сыграть конкуренция с Китаем, когда он мощно выйдет на глобальный рынок. Индусов не боятся.
* А еще все позитивные примеры - из советского времени. А это - "прошлая война". Надеяться будущую войну выиграть старыми методами - глупо, мир - изменился.

{{wl-publish: 2014-01-09 00:50:10 +0400 | MaksTsepkov }}
[[Категория:SPMConf-2013]]
{{replicate-from-custiswiki-to-lib}}

DDD - модель вместо требований (Максим Цепков на AnalystDays-2014)

2014-06-24T12:06:59Z

MaksTsepkov:

[[Категория:Максим Цепков]] [[Категория:Аналитика (доклады)]] [[Категория:Архитектура (доклады)]] {{replicate-from-custiswiki-to-lib}}

Этот доклад был рассказан на конференции [http://analystdays.ru/ru/index?eventId=16339 AnalystDays – 2014]. Он сделан на основе одноименного [[DDD - модель вместо требований (Максим Цепков на HappyDev-2013)|доклада на HappyDev – 2013]], при этом дополнительно рассмотрены варианты разделения ответственности между аналитиком и разработчиком в разных проектах и позиционирование проектирования по моделям в этих вариантах, а также тема разделения контекстов в DDD.

[http://analystdays.ru/ru/talk/21107 Доклад на сайте конференции]
[http://www.slideshare.net/mtsepkov/ddd-requirementsanalyst-days2014custistsepkov Презентация на Slideshare]
[http://vimeo.com/97294563 Видео на vimeo]

= Аннотация =

Есть много подходов к работе с требованиями — user story, use case и т. д., — но все они описывают в основном поведенческие аспекты. А что делать, если мы работаем в сфере, где бизнес-требования достаточно сложны и объекты меняют поведение в зависимости от контекста?

Domain-Driven Design — подход, превращающий предметную область из «темного леса» в прозрачную систему. Единый язык устраняет трудности перевода между заказчиками, аналитиками, командой разработки и тестировщиками. Это позволяет модели, описанной на этом языке, заменить традиционные требования, которые служат лишь для построения модели, а затем теряют актуальность. Такой подход качественно упрощает процесс проектирования и значительно снижает риски IT-проектов, позволяя бизнес-специалистам заказчика полноценно верифицировать модель системы. А в процессе эксплуатации модель обеспечивает возможность эффективного развития системы на протяжении многих лет вслед за развитием бизнеса заказчика.

= Annotation =

There are many methods to develop requirements (user story, use case and so on), but all of them mainly describe behavioural aspects. But how to work in the sphere of complex business requirements where objects change their behaviour as the context may admit?

Domain-Driven Design (DDD) is an approach that allows to create clear and clean vision of domain area. Ubiquitous language gives ground for communication between customers, analytics, developers, testers and end-users. And we can use models developed in this language instead of traditional requirements, which are used only to build models in this process, and then they lost their actuality. This approach significantly simplifies design process and reduces risks in complex IT-projects enabling business professionals to fully verify Models. And then, while in operation, Models allow to develop and expand software system efficiently for many years following changes of customer’s business processes.

= Видео =

{{vimeoembed|97294563|1280|408}}

= Презентация =
[[Файл:DDD-requirements-AnalystDays-2014-CUSTIS-Tsepkov.pdf|left|page=-|256px]]
{{----}}

Блог:Максима Цепкова

2014-06-22T15:55:55Z

MaksTsepkov:

'''С 19.05.2012 профессиональный блог [[User:MaksTsepkov|Максима Цепкова]] переехал на личный сайт http://mtsepkov.org'''

Ранее блог был на http://blogs.uml2.ru/blogs/maksiq и http://softwarepeople.ru/, потом жил здесь, на сайте компании.

Оглавление (на момент переноса) [[Блог Максима Цепкова - оглавление]]

Другие мои публикации: [[:Категория:Максим Цепков|Выступления]] и [[:Категория:Максим Цепков (Статьи)|Статьи]]

{{replicate-from-custiswiki-to-lib}}

DDD - модель вместо требований (Максим Цепков на AnalystDays-2014)

2014-05-25T21:26:24Z

MaksTsepkov:

[[Категория:Максим Цепков]] [[Категория:Аналитика (доклады)]] [[Категория:Архитектура (доклады)]] {{replicate-from-custiswiki-to-lib}}

Этот доклад был рассказан на конференции [http://analystdays.ru/ru/index?eventId=16339 AnalystDays-2014]. Он сделан на основе одноименного [[DDD - модель вместо требований (Максим Цепков на HappyDev-2013)|доклада на HappyDev-2013]], при этом дополнительно рассмотрены варианты разделения ответственности между аналитиком и разработчиком в разных проектах и позиционирование проектирования по моделям в этих вариантах, а также тема разделения контекстов в DDD.

[http://analystdays.ru/ru/talk/21107 Доклад на сайте конференции]
[http://www.slideshare.net/mtsepkov/ddd-requirementsanalyst-days2014custistsepkov Презентация на slideshare]

= Аннотация =

Есть много подходов к работе с требованиями — user story, use case и т. д., — но все они описывают в основном поведенческие аспекты. А что делать, если мы работаем в сфере, где бизнес-требования достаточно сложны и объекты меняют поведение в зависимости от контекста?

Domain-Driven Design — подход, превращающий предметную область из «темного леса» в прозрачную систему. Единый язык устраняет трудности перевода между заказчиками, аналитиками, командой разработки и тестировщиками. Это позволяет модели, описанной на этом языке, заменить традиционные требования, которые служат лишь для построения модели, а затем теряют актуальность. Такой подход качественно упрощает процесс проектирования и значительно снижает риски IT-проектов, позволяя бизнес-специалистам заказчика полноценно верифицировать модель системы. А в процессе эксплуатации модель обеспечивает возможность эффективного развития системы на протяжении многих лет вслед за развитием бизнеса заказчика.

= Annotation =

There are many methods to develop requirements (user story, use case and so on), but all of them mainly describe behavioural aspects. But how to work in the sphere of complex business requirements where objects change their behaviour as the context may admit?

Domain-Driven Design (DDD) is an approach that allows to create clear and clean vision of domain area. Ubiquitous language gives ground for communication between customers, analytics, developers, testers and end-users. And we can use models developed in this language instead of traditional requirements, which are used only to build models in this process, and then they lost their actuality. This approach significantly simplifies design process and reduces risks in complex IT-projects enabling business professionals to fully verify Models. And then, while in operation, Models allow to develop and expand software system efficiently for many years following changes of customer’s business processes.

= Презентация =
[[Файл:DDD-requirements-AnalystDays-2014-CUSTIS-Tsepkov.pdf|left|page=-|256px]]
{{----}}

Файл:DDD-requirements-AnalystDays-2014-CUSTIS-Tsepkov.pdf

2014-05-25T21:24:16Z

MaksTsepkov:

Участник:MaksTsepkov/Выступление AnalystDays-2014 DDD requirements

2014-05-25T21:09:22Z

MaksTsepkov: Перенаправление на DDD - модель вместо требований (Максим Цепков на AnalystDays-2014)

#REDIRECT [[DDD - модель вместо требований (Максим Цепков на AnalystDays-2014)]]

Категория:Максим Цепков

2014-05-25T21:02:55Z

MaksTsepkov:

{{----}}
[[Файл:MaksTsepkov-1.jpg|right|thumb|200px]]

Записи докладов Максима Цепкова (http://mtsepkov.org и http://www.facebook.com/mtsepkov).
Смотри также [[:Категория:Максим Цепков (Статьи)|публикации Максима в СМИ]].

[[Категория:Известные докладчики|Цепков]]
{{replicate-from-custiswiki-to-lib}}

Блог:Максима Цепкова

2014-05-19T15:23:48Z

MaksTsepkov:

Блог Максима Цепкова - оглавление

2014-05-19T15:20:27Z

MaksTsepkov:

* Первоначально я вел [http://blogs.uml2.ru/blogs/maksiq блог на uml2.ru] и продолжаю постить туда ссылки на новые статьи
* Потом больше года публиковался на [http://softwarepeople.ru/ SoftwarePeople] <font color="red">Доступ утрачен с закрытием портала</font>
* Потом был здесь, на сайте компании [[Блог:Максима Цепкова]]
* А с 19.05.2014 переехал на личный сайт http://mtsepkov.org/Blog и туда скопированы посты с данного сайта, восстановлены посты с SoftwarePeople и будут скопированы с uml2.ru

В этой статье собраны оглавления всех моих блогов до пенезда на личный сайт.

'''[[Блог:Максима Цепкова]]'''
{{#templatedpagelist:
namespace = Блог
parent = Максима Цепкова
level = 0..1
order = creation DESC
}}

Мои посты на '''[http://softwarepeople.ru/ SoftwarePeople]''' (и немного на uml2)
* 2013-06-11 [http://softwarepeople.ru/blog/2013/06/11/ms-devcon-2013/ По следам MS DevCon-2013]
* 2013-05-28 [http://softwarepeople.ru/blog/2013/05/28/analystdays-2013/ AnalystDays-2013]
* 2013-04-30 [http://softwarepeople.ru/blog/2013/04/30/sqadays-13/ SQAdays-13 (весна 2013)]
* 2013-04-15 [http://lib.uml2.ru/SoftwarePeople-2013 SoftwarePeople-2013]
* 2013-04-11 [http://lib.uml2.ru/Yourdon-2013 Мастер-классы Эдварда Йордана перед SoftwarePeople-2013]
* 2013-03-31 [http://softwarepeople.ru/blog/2013/03/31/agiledays-2013/ AgileDays 2013 - между скрамом и будущим]
* 2013-03-29 [http://softwarepeople.ru/blog/2013/03/29/pbl-jeff-patton-agiledays/ Как появляется PBL - Jeff Patton на AgileDays]
* 2013-03-22 [http://softwarepeople.ru/blog/2013/03/22/rnddirmeeting/ Клуб директоров по разработке встреча 21.03]
* 2013-03-16 [http://softwarepeople.ru/blog/2013/03/16/enterprise-developers-conference/ Enterprise Developers Conference]
* 2013-03-10 [http://blogs.uml2.ru/node/267 OMG Essence]
* [http://blogs.uml2.ru/node/266 2013-02-22: MODELSWARD - подвожу итоги]
* 2013-02-20 [http://blogs.uml2.ru/node/264 MODELSWARD - первые впечатления]
* 2012-12-20 [http://blogs.uml2.ru/node/263 Проектирование программ: мастера и самоучки]
* 2012-12-02 [http://softwarepeople.ru/blog/2012/12/02/sqadays-12-02/ SQAdays-12, день второй]
* 2012-12-01 [http://softwarepeople.ru/blog/2012/12/01/sqadays-12-01/ SQAdays-12, день первый]
* 2012-11-29 [http://softwarepeople.ru/blog/2012/11/29/km-russia-2012-02/ KM Russia-2012, день второй]
* 2012-11-28 [http://softwarepeople.ru/blog/2012/11/28/km-russia-2012-0/ KM Russia-2012, день первый]
* 2012-11-19 [http://softwarepeople.ru/blog/2012/11/19/spmconf-2012-02/ SPMconf-2012 Минск - день второй]
* 2012-11-17 [http://softwarepeople.ru/blog/2012/11/17/spmconf-2012-01/ SPMconf-2012 в Минске - день первый]
* 2012-11-13 [http://softwarepeople.ru/blog/2012/11/13/reqlabs-2012/ ReqLabs-2012 в Киеве]
* 2012-11-03 [http://softwarepeople.ru/blog/2012/11/03/secr-2012-02/ SECR-2012, день второй]
* 2012-11-02 [http://softwarepeople.ru/blog/2012/11/02/secr-2012-0/ SECR-2012 - день первый]
* 2012-10-31 [http://softwarepeople.ru/blog/2012/10/31/secr-2012-bill-kertis/ SECR-2012, курс Билла Кертиса]
* 2012-10-25 [http://softwarepeople.ru/blog/2012/10/25/geeks-and-managers/ Гики и Менеджеры]
* 2012-10-25 [http://softwarepeople.ru/blog/2012/10/25/microsoft-changes-the-landscape/ Пока мы наступаем, Microsoft меняет рельеф местности]
* 2012-08-07 [http://softwarepeople.ru/blog/2012/08/07/west-and-east-business-processes/ Запад и Япония: два взгляда на бизнес-процессы]
* 2012-05-01 [http://softwarepeople.ru/blog/2012/05/01/agile-as-it-management/ Agile как IT-форма современного менеджмента]

'''[http://blogs.uml2.ru/blogs/maksiq Блог на uml2.ru]'''
* 2012-06-25 [http://blogs.uml2.ru/post/LAF-2012 ЛАФ-2012]
* 2012-06-11 [http://blogs.uml2.ru/post/AgileKitchen-11062012 AgileKitchen 11.06.2012]
* 2012-06-01 [http://blogs.uml2.ru/post/Zasedanie-Kluba-direktorov-po-razrabotke-ob-arhitekture Заседание Клуба директоров по разработке об архитектуре]
* 2012-05-28 [http://blogs.uml2.ru/post/AnalystDays-1 AnalystDays-1]
* 2012-05-13 [http://blogs.uml2.ru/post/ADD-2012-peredniy-kray-razrabotki ADD-2012 - передний край разработки]
* 2012-04-29 [http://blogs.uml2.ru/post/Izmenim-mir-k-hudshemu Изменим мир к худшему!]
* 2012-04-29 [http://blogs.uml2.ru/post/Tri-mira-programmistov Три мира программистов]
* 2012-04-24 [http://blogs.uml2.ru/post/SQAdays-vesna-2012-den-vtoroy SQAdays весна 2012 - день второй]
* 2012-04-22 [http://blogs.uml2.ru/post/SQAdays-vesna-2012-pervyy-den-prevzoshel-ozhidaniya SQAdays весна 2012 - первый день превзошел ожидания]
* 2012-04-18 [http://blogs.uml2.ru/post/Zhelanie-i-Vozmozhnost-formuliruyutsya-na-raznyh-yazykah Желание и Возможность формулируются на разных языках]
* 2012-04-13 [http://blogs.uml2.ru/post/SoftwarePeople-2012-prodolzhenie SoftwarePeople 2012 - продолжение]
* 2012-04-10 [http://blogs.uml2.ru/post/SoftwarePeople-2012-den-pervyy SoftwarePeople 2012 день первый]
* 2012-04-01 [http://blogs.uml2.ru/post/Vpechatleniya-Atlantic-Systems-Guild Впечатления Atlantic Systems Guild]
* 2012-03-28 [http://blogs.uml2.ru/post/Agile-kak-IT-forma-sovremennogo-menedzhmenta Agile как IT-форма современного менеджмента]
* 2012-03-25 [http://blogs.uml2.ru/post/Agile-Days-2012-den-vtoroy Agile Days-2012, день второй]
* 2012-03-24 [http://blogs.uml2.ru/post/Agile-Days-2012-den-pervyy Agile Days-2012, день первый]
* 2012-01-18 [http://lib.uml2.ru/KM_Russia_2011 Отчет Управление знаниями - KM Russia 2011]
* 2011-12-25 [http://blogs.uml2.ru/post/Kultury-IT-kompaniy Культуры IT-компаний]
* 2011-12-12 [http://blogs.uml2.ru/post/KMrussia-obyasnyashki KMrussia - объясняшки]
* 2011-12-03 [http://blogs.uml2.ru/post/10-ya-konferenciya-SQA-Days-den-vtoroy 10-я конференция SQA Days - день второй]
* 2011-12-02 [http://blogs.uml2.ru/post/10-ya-konferenciya-SQA-Days-den-pervyy 10-я конференция SQA Days - день первый]
* 2011-11-28 [http://blogs.uml2.ru/post/Konferenciya-SPM-Conf-2011 Конференция SPM Conf 2011]
* 2011-11-24 [http://blogs.uml2.ru/post/Biznes-forum-upravleniya-znaniyami-den-vtoroy Бизнес-форум управления знаниями - день второй]
* 2011-11-23 [http://blogs.uml2.ru/post/Biznes-kongess-upravleniya-znaniyami Бизнес-форум управления знаниями KMRussia-2011]
* 2011-11-20 [http://blogs.uml2.ru/post/Agile-i-CMMI Agile и CMMI]
* 2011-11-06 [http://blogs.uml2.ru/post/Karta-kompetenciy-SFIA Карта компетенций SFIA]
* 2011-11-03 [http://blogs.uml2.ru/post/SECR-2011-zavershilsya SECR-2011 завершился]
* 2011-11-03 [http://blogs.uml2.ru/post/SECR-2011-Promezhutochnye-itogi SECR-2011. Промежуточные итоги]
* 2011-10-31 [http://blogs.uml2.ru/post/SECR-2011-den-pervyy-banki SECR-2011 день первый - банки]
* 2011-10-26 [http://blogs.uml2.ru/post/Snova-ob-Archimate Снова об Archimate]
* 2011-10-15 [http://blogs.uml2.ru/post/Osen-vremya-konferenciy Осень - время конференций]
* 2011-06-28 [http://blogs.uml2.ru/post/Posleslovie-k-LAF-2011 Послесловие к ЛАФ-2011]
* 2011-06-11 [http://blogs.uml2.ru/post/Rol-analitika-v-razrabotke Роль аналитика в разработке]
* 2011-05-22 [http://blogs.uml2.ru/post/Chernyy-lebed-Taleba Черный лебедь Талеба]
* 2011-05-13 [http://blogs.uml2.ru/post/O-razrabotki-freymvorkov О разработки фреймворков...]
* 2011-05-06 [http://lib.uml2.ru/ADD-2011_-_Макс_Цепков ADD-2011 - Макс Цепков]
* 2011-05-03 [http://blogs.uml2.ru/post/Konferenciya-ADD-2011 Конференция ADD-2011]
* 2011-04-09 [http://blogs.uml2.ru/post/2011-04-09-Trening-Nila-Meydena-na-SoftwarePeople-2011 Тренинг Нила Мейдена на SoftwarePeople 2011]
* 2011-04-08 [http://blogs.uml2.ru/post/Vozvrashchayas-k-REQ-labs Возвращаясь к REQ-labs]
* 2011-04-08 [http://blogs.uml2.ru/post/2011-04-08-SoftwarePeople-2011-den-vtoroy SoftwarePeople 2011 - день второй]
* 2011-04-07 [http://blogs.uml2.ru/post/2011-04-07-SoftwarePeople-2011-den-pervyy SoftwarePeople 2011 - день первый]
* 2011-04-04 [http://lib.uml2.ru/Впечатления_о_REQ-Labs_2011_-_Макс_Цепков Впечатления о REQ-Labs 2011 - Макс Цепков]
* 2011-03-13 [http://lib.uml2.ru/Тренинг_Книберга_по_Agile_-_Макс_Цепков Тренинг Книберга по Agile - Макс Цепков]
* 2011-03-13 [http://lib.uml2.ru/AgileDays-2011_-_Макс_Цепков AgileDays-2011 - Макс Цепков]
* 2011-02-23 [http://blogs.uml2.ru/post/Getting-Things-Done Getting Things Done]
* 2011-01-27 [http://blogs.uml2.ru/post/Konferenciya-i-ee-rezultaty Конференция и ее результаты]
* 2011-01-21 [http://blogs.uml2.ru/post/Trebovaniya-i-standarty-na-nih Требования и стандарты на них]
* 2011-01-13 [http://blogs.uml2.ru/post/Standarty-predstavleniya-znaniy Стандарты представления знаний]
* 2011-01-07 [http://blogs.uml2.ru/post/O-standartah-arhitektury О стандартах архитектуры]
* 2011-01-05 [http://blogs.uml2.ru/post/ArchiMate ArchiMate]
* 2011-01-02 [http://blogs.uml2.ru/post/Arhitekturnye-metafory-stroitelstva-v-IT Архитектурные метафоры строительства в IT]
* 2010-12-21 [http://lib.uml2.ru/Макс_Цепков_-_отчет_о_SECR-2010 Макс Цепков - отчет о SECR-2010]
* 2010-12-14 [http://blogs.uml2.ru/post/O-dorogoy-avtomatizacii О дорогой автоматизации]
* 2010-12-09 [http://blogs.uml2.ru/post/Kak-borotsya-Analitiku-s-rutinoy Как бороться Аналитику с рутиной]
* 2010-11-29 [http://blogs.uml2.ru/post/Mysli-imeyut-prodolzhenie Мысли - имеют продолжение]
* 2010-11-12 [http://lib.uml2.ru/Конференция_Управление_знаниями_-_10.2010 Конференция Управление знаниями - 10.2010]
* 2010-11-01 [http://blogs.uml2.ru/post/Reynvoter-Kak-pasti-kotov Рейнвотер. Как пасти котов]
* 2010-10-26 [http://blogs.uml2.ru/post/Konferenciya-Upravlenie-znaniyami Конференция Управление знаниями]
* 2010-10-25 [http://blogs.uml2.ru/post/Osen-vremya-konferenciy-Upravlenie-znaniyami Осень - время конференций. Управление знаниями.]
* 2010-10-15 [http://blogs.uml2.ru/post/SECR-2010-zakonchilsya SECR-2010 закончился]
* 2010-10-14 [http://blogs.uml2.ru/post/SECR-2010-pervye-vpechatleniya SECR-2010 первые впечатления]
На этом мой внешний блог заканчивается.

{{replicate-from-custiswiki-to-lib}}

Блог:Максима Цепкова/2014-05-18: Мой новый сайт - mtsepkov.org

2014-05-19T15:09:02Z

MaksTsepkov:

Последние годы я, кроме основной профессиональной деятельности, активно участвую в ИТ-конференциях (в частности, в [http://secr.ru SECR] как сопредседатель ПК), и спектр моих интересов расширяется, заметая такие относительно далекие области, как спиральная динамика или образование в ИТ. И, само собой, я хочу делиться мыслями по этим и многим другим темам в открытых публикациях, которых становится все больше.

Пообщавшись с коллегами из отдела внешних связей, мы решили, что было бы круто завести мне личный профессиональный блог. Это позволит собрать все мои посты в одном месте, не опасаясь, что внешний ресурс (вроде блога Software People) однажды умрет вместе со всем моим контентом, и одновременно даст мне больше свободы в выражении личного мнения, ведь публикация на корпоративном ресурсе, например на [http://lib.custis.ru lib.custis.ru], — дело ответственное, и подготовка выверенных и согласованных с позицией компании материалов занимает много времени, как моего, так и сотрудников PR-службы. С другой стороны, наличие у сотрудника компании собственного относительно популярного профессионального блога — свидетельство высокого уровня компании и ее экспертов.

Так появился http://mtsepkov.org, который я с радостью вам представляю. Сейчас туда скопирована часть старого контента, включая последние пару лет моего блога, и наполнение будет продолжаться. Кстати, выяснилось, что примерно год публикаций моего блога, которые я вел на портале [http://softwarepeople.ru SoftwarePeople], утрачены из общего доступа в связи с закрытием портала. Пришлось мне их восстановить, при этом я обнаружил что некоторые статьи расползлись на другие сайты, и не везде с авторством — будем с этим бороться.

Технически сайт поднят на базе сборки MediaWiki, созданной и используемой в нашей компании Стасом Фоминым и развиваемой Виталием Филипповым, а также выложенной для свободного использования на http://4intra.net. Поэтому для меня накладных расходов по ведению собственного блога относительно публикации на корпоративном не возникает.

Итак, добро пожаловать на мой новый сайт http://mtsepkov.org, где я буду вести блог, публиковать доклады и другие материалы. Я буду рад обсуждению и комментариям и не возражаю против публикации на нем материалов коллег, если они, конечно, соответствуют тематике.

{{replicate-from-custiswiki-to-lib}}

{{wl-publish: 2014-05-19 19:02:32 +0400 | MaksTsepkov }}

Блог:Максима Цепкова/2014-05-18: Мой новый сайт - mtsepkov.org

2014-05-19T15:08:20Z

MaksTsepkov: Новая страница: «Последние годы я, кроме основной профессиональной деятельности, активно участвую в ИТ-к…»

Последние годы я, кроме основной профессиональной деятельности, активно участвую в ИТ-конференциях (в частности, в [http://secr.ru SECR] как сопредседатель ПК), и спектр моих интересов расширяется, заметая такие относительно далекие области, как спиральная динамика или образование в ИТ. И, само собой, я хочу делиться мыслями по этим и многим другим темам в открытых публикациях, которых становится все больше.

Пообщавшись с коллегами из отдела внешних связей, мы решили, что было бы круто завести мне личный профессиональный блог. Это позволит собрать все мои посты в одном месте, не опасаясь, что внешний ресурс (вроде блога Software People) однажды умрет вместе со всем моим контентом, и одновременно даст мне больше свободы в выражении личного мнения, ведь публикация на корпоративном ресурсе, например на [http://lib.custis.ru lib.custis.ru], — дело ответственное, и подготовка выверенных и согласованных с позицией компании материалов занимает много времени, как моего, так и сотрудников PR-службы. С другой стороны, наличие у сотрудника компании собственного относительно популярного профессионального блога — свидетельство высокого уровня компании и ее экспертов.

Так появился http://mtsepkov.org, который я с радостью вам представляю. Сейчас туда скопирована часть старого контента, включая последние пару лет моего блога, и наполнение будет продолжаться. Кстати, выяснилось, что примерно год публикаций моего блога, которые я вел на портале [http://softwarepeople.ru SoftwarePeople], утрачены из общего доступа в связи с закрытием портала. Пришлось мне их восстановить, при этом я обнаружил что некоторые статьи расползлись на другие сайты, и не везде с авторством — будем с этим бороться.

Технически сайт поднят на базе сборки MediaWiki, созданной и используемой в нашей компании Стасом Фоминым и развиваемой Виталием Филипповым, а также выложенной для свободного использования на http://4intra.net. Поэтому для меня накладных расходов по ведению собственного блога относительно публикации на корпоративном не возникает.

Итак, добро пожаловать на мой новый сайт http://mtsepkov.org, где я буду вести блог, публиковать доклады и другие материалы. Я буду рад обсуждению и комментариям и не возражаю против публикации на нем материалов коллег, если они, конечно, соответствуют тематике.

{{wl-publish: 2014-05-19 19:02:32 +0400 | MaksTsepkov }}

Справка:Шаблоны

2014-05-14T07:08:20Z

MaksTsepkov:

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

== Общая информация ==
Статьи-шаблоны располагаются в специальном пространстве имен «Template», т. е. они имеют префикс «'''Template:'''».
Содержимое каждой такой статьи (вне зависимости, фиксировано ли оно, или зависит от некоторых переменных параметров) предназначено для удобства включения в другие статьи, т. е. для создания составных документов.

Для того, чтобы включить статью «Template:''name''», нужно использовать следующий синтаксис (так называемый тэг шаблона) <nowiki>{{</nowiki>''name''<nowiki>}}</nowiki>. Тогда при показе статьи будет подставлено содержимое ссылаемого шаблона. Терминологически, этот процесс можно также называть
* вызовом шаблона;
* ccылкой на шаблон;
* включением шаблона;
* использованием шаблона; — в любом из перечисленных вариантов, речь идет об одном и том же.

Если страница «Template:''name''» еще не существует, то <nowiki>{{</nowiki>''<nowiki>name</nowiki>''<nowiki>}}</nowiki> будет работать как <nowiki>[[</nowiki>Template:''name''<nowiki>]]</nowiki>, т. е. как ссылка на несуществующую статью, которую можно редактировать. Таким образом, шаблоны также удобно заводить, сначала сделав на него ссылку, а затем проследовав по ней.

Если статья ''name'' уже существует в обычном (не шаблонном) пространстве имен, или начинается с двоеточия (что означает ссылку на основное пространство имен), то ссылка не будет автоматически направлятся в шаблонное пространство имен «Template:». Таким образом, любую страницу можно использовать как шаблон. (Примечание: если вызывать так картинку или категорию — то будет подставлена описательная часть картинки и категории соответственно).
Таким образом удобно
* экспериментировать с шаблонами (не залезая в пространство шаблонов);
* «вытаскивать» подписи и описания картинок;
* изготавливать специальные составные статьи (например для печати).

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

Возможно также рекурсивное включение.

Переменные шаблона вычисляются после вставки шаблона в «вызывающую» статью, т. е. если в шаблоне содержится подстановка <nowiki>{{PAGENAME}}</nowiki>, то она будет развернута в имя вызывающей статьи, а не имя шаблона.

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

== Параметры ==

Параметры шаблона могут быть поименованные или пронумерованные.
Синтаксис использования может быть
* <tt><nowiki>{{templatename|parname1=parvalue1|parname2=parvalue2}}</nowiki></tt>, тогда в теле шаблона надо ссылаться на <tt><nowiki>{{{parname}}}</nowiki></tt>;
* <tt><nowiki>{{templatename|parvalue1|parvalue2}}</nowiki></tt> тогда в теле шаблона нужно использовать <tt><nowiki>{{{1}}}</nowiki></tt>, <tt><nowiki>{{{2}}}</nowiki></tt>.

Лишние (не используемые в теле шаблона) параметры игнорируются.
Имена параметров чувствительны к регистру, пробелы, подчеркивание и остальные символы не из набора <nowiki>[a-z\-A-Z0-9]</nowiki> недопустимы.

:Обратите внимание на тройные фигурные скобки при использовании параметров!

Т.е. механизм шаблонов выполняет два типа подстановок:
* вызов шаблона (двойные фигурные скобки) заменяется содержимым шаблона;
* параметры шаблона (тройные фигурные скобки) заменяются параметрами шаблона.

Параметром шаблона может быть ссылка на другую статью. Пусть например у нас есть Шаблон:
<nowiki>
Начало {{{1}}} Конец.
</nowiki>

Тогда
<nowiki>
{{Шаблон| [[Main_Page|Главная страница]]}}
</nowiki>
будет развернуто в

Начало [[Main_Page|Главная страница]] Конец.

Если какой-то параметр «someparameter» не задан, то он остается нераскрытым текстом <nowiki>{{{someparameter}}}</nowiki>, что позволит раскрыть его, если вызвавшая шаблон статья, также включается куда-то, где этот параметр задан.
:Заметим, что вызов <nowiki>{{Шаблон||a}}</nowiki> делает первый параметр определенным, но равным пустой строке. Если нужно задать второй параметр, не определяя первый, то нужно использовать вызов <nowiki>{{Шаблон||2=a}}</nowiki>. Этот синтаксис нужно использовать также, когда параметр вызова содержит знак "=", например "a=b", т.е. <nowiki>{{Шаблон|a=b|c}}</nowiki>, не определит параметр "1", зато определит параметр "a", зато <nowiki>{{Шаблон|1=a=b|2=c}}</nowiki> сделает все как надо.

== Просмотр содержимого шаблона ==

Чтобы правильно увидеть содержимое шаблона, нужно смотреть на шаблон в режиме редактирования, т. к. некоторые подстановки, типа <nowiki>{{PAGENAME}}</nowiki>, могут раскрыться.

== msgnw ==

Для показа содержимого шаблона (без wiki-интерпретации) можно использовать кодовый «волшебный» префикс u «msgnw:». Т.е. <nowiki>{{en}} и {{msgnw:en}}</nowiki> будут показаны как {{en}} и {{msgnw:en}} соответственно.

== Ссылка на редактирование шаблона ==

«Редактирующая» ссылка на каждой странице-статье не позволяет редактировать текст используемого шаблона, а иногда желательно иметь такую ссылку (приглашающую поправить шаблон, например, если шаблон еще не устоялся, или если его содержимое может часто изменяться). Такую ссылку можно «зашить» внутрь самого шаблона, даже более того, сделать шаблоном, который можно использовать внутри других шаблонов.
См. [[template:edit]].

== Ограничения и возможности ==

=== Использование вложенных двойных или тройных фигурных скобок внутри двойных вложенных скобок ===

Не получиться вызывать шаблоны в зависимости от содержимого других шаблонов.
Допустим, у нас есть шаблон «tctc» с содержимым «tc», и шаблон «tc» с содержимым «Ура».

Тогда вызов <nowiki>{{{{tctc}}}}</nowiki> даст текст {{{{tctc}}}}, а не «Ура».

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

== Тэг категории в шаблоне. Проблема с кэшированием ==

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

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

== Кэширование ==

Правка шаблона автоматически сбрасывает кэширование всех статей, напрямую использующих этот шаблон. Однако в случае с косвенными зависимостями (шаблоны зависящие от параметров и т. п.), внутренний кэш системы не сбрасывается и стандартный «Refresh» броузера может не помочь.
В таких случаях используйте «action=purge», т. е. вызывайте URL типа
{{SERVER}}{{LOCALURL:{{SITENAME}}|action=purge}}

== subst ==

Используя «subst:» после двойных фигурных скобок заставляет выполнять подстановку
текста шаблона или даже переменной в момент сохранения ссылающейся страницы.

Например «timestamp»:

<nowiki>{{subst:CURRENTDAY}} {{subst:CURRENTMONTHNAME}} {{subst:CURRENTYEAR}},    {{subst:CURRENTTIME}} (UTC)</nowiki>

подставится при сохранении, как:

3 March 2005,    16:56 (UTC)

=== Альтернатива subst ===

* Используйте {{..}}, затем, в окне «preview», вытащите результат и замените исходные {{..}}.
* Аналогично можно использовать msgnw.

== Перенаправления ==

Когда страница, вызванная для включения, является страницей-перенаправлением, то включается содержимое страницы, на которую указывает перенаправление.

Страница, которая ничего не содержит, кроме включения другой страницы, в общем схожа со страницей-перенаправлением, но имеет и множество различий, например:

* Заголовок страницы-результата есть имя исходной страницы, а не включаемой страницы.
* Вся функциональность, (редактирование, обсуждение, watch-list, …) относится к включающей странице, и ничего (если не смотреть код) не связывает ее с включаемой страницей.
* Включающая страница лежит в тех же категориях, что и включаемая.
* Работают «двойные перенаправления» основанные на включении.

== Ссылки на шаблон ==

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

== История изменений для страниц содержащих шаблоны ==

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

== Функции парсера ==

В [[{{SITENAME}}]] установлено расширение [http://www.mediawiki.org/wiki/Help:Extension:ParserFunctions ParserFunctions], позволяющее выполнить нетривиальное препроцессирование разметки.

Более подробно см. [[RuPedia:Википедия:Функции парсера]].

== Ссылки ==

* [{{SERVER}}{{localurl:Special:Allpages|namespace=10}} Наши Шаблоны]

== <nowiki><noinclude> и <includeonly></nowiki> ==

Текст между <nowiki><noinclude> и </noinclude></nowiki> включается только когда шаблон не включен в статью. Наоборот, includeonly работает только когда шаблон включен в другую статью. Применение - категории, распространяющиеся только на шаблон или только на его включение; оглавление и титульный лист, которые должно уйти при включении во композитную статью и т.п.

{{replicate-from-custiswiki-to-lib}}
{{replicate-from-custiswiki-to-tools}}

Обсуждение блога:Максима Цепкова/2014-04-20: SQAdays в Москве - спектр и тренды отрасли/c000029

2014-05-07T15:49:31Z

MaksTsepkov:

Пока нет. Видео оперативно выкладываются на https://www.facebook.com/sqadays - следите. А потом ссылки появятся на сайте конференции.
{{wl-comment: Максима Цепкова/2014-04-20: SQAdays в Москве - спектр и тренды отрасли/c000028 }}

Обсуждение блога:Максима Цепкова/2014-04-20: SQAdays в Москве - спектр и тренды отрасли/c000029

2014-05-07T15:48:30Z

MaksTsepkov: Новый комментарий от MaksTsepkov: Пока нет. Видео оперативно выкладываются на www.facebook.com/sqadays - следите. А потом ссылки …

Пока нет. Видео оперативно выкладываются на www.facebook.com/sqadays - следите. А потом ссылки появятся на сайте конференции.
{{wl-comment: Максима Цепкова/2014-04-20: SQAdays в Москве - спектр и тренды отрасли/c000028 }}

Блог:Максима Цепкова/2014-04-15: AIST и Стачка

2014-04-20T21:43:14Z

MaksTsepkov:

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

= AIST =

[http://aistconf.org Analysis of Images, Social Networks, and Texts] или AIST - это научная конференция, с солидным международным программным комитетом и публикацией отобранных работ в Computer Science Series Springer. Проходила 3 дня, 10-12.04 в Екатеринбурге, правда, только один трек и не слишком много участников. Я был только в первый день, так что, возможно, впечатление неполное. Мне она напомнила европейские научные конференции (правда, я не так много там был). Приглашенные докладчики из зарубежных университетов, которые делают общие и, увы, поверхностные доклады. А потом - отобранные доклады. Они разного уровня. И среди них есть реально hardcore-доклады, касающиеся новых алгоритмов и методов, разработанных авторами, и доведенных до использования в промышленных системах. И доклады о разработке промышленных систем на основе методов, не применявшихся в данной области, или оригинальной комбинации методов. И более легкие доклады, когда какие-то идеи апробировались на прототипах. И совсем легкие, когда от идеи апробирована лишь легкая очевидная часть. В общем, это нормально, потому что конференция - поле общения, и там собираются как действующие научные работники, так и аспиранты и студенты. И конференция на это очень ориентирована, цена билета для представителей ВУЗов - 900 рублей при коммерческой цене участия 11500.

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

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

=Стачка=

[[Файл:Stachka-2014-Ulyanovsk-1.jpg|right|400px]]

В противоположность этому, http://NaStachku.ru или '''Стачка''' - практическая конференция. И, думаю, крупнейшая конференция в России, 2500 участников, 7 параллельных треков. Проходила 11-12.04 в Ульяновске, в Ленинском мемориале, что местами довольно прикольно смотрелось. Она очень широкая по тематике, было много технических докладов, много докладов по пиару и работе с соцсетями в инете (digital-коммуникации), и смежные темы - интернет-коммерция, стартапы, менеджмент. Доклады тоже разного уровня, рассчитанные как на продвинутую аудиторию, так и на новичков. И среди них были очень высокого уровня, о которых я напишу дальше. А доклады для новичков - нужны на конференциях, потому что одна из целей - ориентация начинающих сотрудников, студентов и даже школьников в сложном мире современного ИТ, чтобы они нашли там свое дело. Кстати, конференция - дешевая, 1000 рублей при ранней регистрации и 1500 позже, но для студентов и школьников, как я понимаю, распространяли бесплатные билеты.

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

==Образование и ИТ==

Начну я с круглого стола «Образование и ИТ». Привлечение студентов и школьников на конференцию - существенная составляющая целей конференции, это решение кадрового вопроса в долгую, развитие ИТ-кластера области, над которым совместно работают ИТ-компании, ВУЗы области и правительство области. Об этом говорили на круглом столе по образованию на второй день конференции, в котором, помимо ВУЗов и ИТ-компаний участвовали представители профессионального образования, школ и правительства области. Сам круглый стол произвел на меня очень интересное впечатление. Это такое очень государственное по форме мероприятие, по сути рабочее совещание, и для меня эта форма была на конференции неожиданностью. В самом начали ведущая сказала, что задача круглого стола - принять резолюцию, что генерация идей для нее уже была проведена, идеи обобщили, так что сейчас ее прочитают, присутствующие могут высказаться - и примем. Дальше так и было - прочитали, обсудили и приняли. Но вот содержание - было вполне адекватным. Если, конечно, уметь воспринимать государственные бумаги, там мысли излагаются в интересной форме.

Существенный упор там был на школьное образование. Потому что проблему они видят в том, что к второму-третьему курсу 70% (или больше?) студентов понимают, что пошли не туда. А в старших классах при нынешней системе школьники думают про ЕГЭ, а не про профориентацию, поэтому ориентировать их надо раньше. Чтобы они делали выбор сознательно, а не шли на поводу у родителей, которые не слишком понимают в нынешнем ИТ. При этом не было обсуждения, что надо изменить всю систему, или федеральные законы - участники работали исходя из ограничений текущей ситуации и обсуждали, что нудно сделать. Например, одна из проблем школ - это отсутствие сисадминов, которые могли бы поддерживать школьные компьютеры. Сами компьютеры - есть, и даже деньги на ставку сисадминов есть, только вот есть федеральные нормы, которыми инженерные ставки в школе запрещены. Но, оказывается есть механизм для обхода этого, через государственное предприятие при городских (или областных) структурах образования, которое берет на себя обслуживание. И дальше чисто практический вопрос как заставить эту систему работать - который при наличии воли и заинтересованности - решается.

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

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

В ИТ есть опыт организации подобных процессов, организации площадок общения и их достаточно легко можно применить и поставить при заинтересованности ИТ-сообщества. Более того, поскольку в Ульяновске ряд компаний специализируется на организации digital-коммуникаций, площадок в соцсетях, то можно профессионально на высоком уровне сделать продвинутую версию, с вовлечением как участников, проводящих профориентацию, так и самих школьников и поддерживать это при разумной стоимости затрат (потому что вопрос денег, эффективности деятельности - сохраняется). Правда, это получается достаточно сложная конструкция, причем непривычная для части участников - ВУЗы и другие образовательные организации, госструктуры ей не владеют. С другой стороны, тренды современного мира говорят, что именно за такими конструкциями - будущее. Это и есть Co-Creation, создание совместной ценности (value) скоординированной деятельностью организаций, когда каждая вносит в свой вклад не только в деятельность, но и в формирование образа этих ценностей.

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

== Kennon Thom. Digital Era==

Thom Kennon, один из руководителей Brabble, в своем докладе «Death of the Madmen in the Post Digital Era» попробовал дать крупную картину тех изменений, которые, с его точки зрения, принесла новая цифровая эра. Основная идея – переход от крупных брендов больших корпораций к мозаике мелких компаний и даже личных брендов. И от централизованно формируемого контента нескольких каналов телевидения к мозаике различных контентов интернета. Эти вещи похожи и связаны, и они уничтожают «сумасшествие», которое было присуще прежнему миру. И это, с одной стороны, хорошо как увеличение разнообразия и свободы общества, что дает гораздо больше возможности для самореализации, а с другой стороны. обостряет проблемы как для потребителя или сотрудника, требуя ориентации среди множества возможностей, так и для производителя, требуя продвижения своего продукта и компании как места работы в конкуренции с большим количеством аналогов. Качественная работа в этих условиях требует быть вести маркетинг для самого себя, при чем в полном объеме – и выбор продукта и возможностей. и продвижение своего. И это, в общем, неожиданный эффект. Бойся желаний, ибо они исполняются  Правда, по моим наблюдениям на таком уровне доклад восприняло не так много участников, для большинства он остался некоторыми общими рассуждениями высокого уровня, без ярко выраженной мысли.

==Digital communication==

Были очень интересны два доклада '''Сергея Меньшикова''' из Одноклассников. Первый – про сами одноклассники, включая подробности специальных проектов с виртуальными подарками. Подробности были про разработку и характер проектов, но масштаб – он тоже неизбежно присутствовал, потому что является неотъемлемой составляющей. Второй доклад, который Сергей прочитал экспромтом как замену – про методы работы с репутацией компаний в соцсетях, про создание и продвижение брендов – с раскрытием деталей и методов работы.
В продолжение темы про социализацию бизнеса – доклады '''Андрей Волкова''' из Grape, '''Виталия Шендрика''' из SEReputation и другие – про методы работы в соцсетях с репутацией компаний. Там было много деталей и подробностей. Это не моя профессиональная сфера, однако она очень интересна с точки зрения осознания развития современного общества. Тут следует отметить, что присутствие в соцсетях, работа с ними – это инструмент, направления и цели применения которого, как и любого инструмента, могут быть очень различны. Он может быть использован для организации рядом с компанией сообщества пользователей, для совершенствования своего продукта. А может быть использован для впаривания продукта для извлечения прибыли. При этом цели извлечения прибыли, естественным образом, не заявляются широко, а мимикрируют под социально значимую направленность. И для ориентации в мире важно не просто понимать это, а уметь различать одно от другого в конкретном кейсе, а для этого – разбираться в механизмах действия. которые и раскрывали доклады.

==Процессы и люди==

'''Мовчан Константин (AGIMA). «Нестандартные ситуации клиента и исполнителя. Обходимся малой кровью»'''. Интересная попытка дать комплексное видение процесса переговоров с клиентами. Что надо учитывать, как построить организацию внутри компании – они расформировали свой отдел продаж, заменив account-группами. В целом доклад удалась, хотя докладчик явно волновался, думаю, поэтому выступление было несколько неряшливо структурировано.

'''Табунов Михаил. Coub. «Управление проектом в условиях стремительного роста на примере Coub»'''. Интересный доклад о масштабировании бизнеса на лету, в условиях роста в полтора раза в месяц(!). При таких темах возникают проблемы по всему фронту – технические, процессные, бизнесовые, и их надо решать в этом темпе. И он рассказывал о постановке процессов, системе тестирования и выпуска версий – недельными итерациями с балансом автоматических тестов API и ручных тестов интерфейса, системе continuous delivery, реально непрерывной, до 50-60 релизов в день. О технологической политике – использование готового и облачных сервисов, куда выносятся многие инфраструктурные задачи, такие как рассылка почты – чтобы не делать своего не только в смысле разработки, но и в смысле поддержки серверных мощностей, в облаке дешевле.

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

'''Дмитрий Нечаев''' из WaveAccess рассказывал о преднамеренных практиках на основе книги Anders Ericsson. Только при их переносе в разработку необходимо определять саму деятельность – они срабатывают в областях, где возможно повышение уровня за счет тренировок, а разработка включает в себя большую часть не тренируемых (на нынешнем уровне понимания) видов деятельности, характерных для НИОКР. Эти аспекты в докладе не раскрыты.

'''Алексей Пименов''' из Финам в докладе «Неполная, но окончательная история менеджмента» дал элегантную картину, как управление проектами в ИТ, начиная с построения упорядоченной структуры и процессов переходит к лидерству, обучению команды, переходит к continuous delivery и работе без итераций и оценки, возвращаясь, по сути к тому же, с чего начали – но на следующем, более высоком уровне осознания.

'''Мой доклад''' тоже был про людей. Я рассказывал про '''Спиральную динамику''', которая дает основу для технологизации работы с ценностями человека, раскрывая структуру организации ценностей. В докладе не просто представлены конструкции спиральной динамики, а раскрыта их связь с «большим» менеджментом, как его представляют Друкер и Адизес и с менеджментом ИТ-проектов. Собственно, именно врастания конструкций спиральной динамики в мою картину развития мира, дополнение и объяснение многих существенных моментов и привело меня к желанию рассказать об этом.

[[Файл:SpiralDynamics-Tsepkov-NaStachku-2014-36.png|right|400px]]

Структурное описание ценностей позволяет переходить от индивидуального рассмотрения частных случаев для конкретных людей к осознанному формированию ценностей на уровне команд и компании в целом. При этом, что важно, совершенно не обязательно это должно быть стремление к самоорганизованной команде самореализующихся людей, объединенных общественно и экономически востребованной деятельностью разработки. Тут руководство может принимать решения, исходя из специфики конкретной фирмы и проекта. А сотрудники, в свою очередь, могут принимать решения о работе в фирме, так же опираясь не на частные случаи, а на структурированное понимание ситуации. Я, естественно, уверен, что в конечном итоге будут востребованы именно те компании, которые будут ориентироваться на продвинутые формы ценностей. Однако, это – в конечном итоге. А сейчас люди находятся на разных уровнях, работа в компаниях далеко не всегда рассматривается как добровольная и в этих условиях компания может сознательно занять и иную позицию, рассчитывая на определенный персонал. Который, возможно, будет вырастать и уходить за определенное время – но в этом нет ничего страшного.

Этот доклад я делаю второй раз, первый раз он был на AgileDays и уже выложено [http://talks.rosalab.com/20140321-59 видео и слайды]. Доклад на Стачке был с учетом этого опыта, а а в презентации появился слайд, иллюстрирующий отношение в Scrum людей разного уровня - по осмыслению докладов и обсуждений на AgileDays. После обоих докладов люди подходили и говорили, что спиральная динамика их зацепила, что она помогает понять проблемы и дополняет картину мира, и они будут дальше смотреть на нее.

==Технические доклады==

Теперь про технические доклады. Очень хороший доклад '''Николая Рыжикова''' из WaveAccess «'''Работаем со сложной предметной областью'''». Продолжая идеи DDD о переносе практик программирования, применимых для отдельных объектов, на аналитическую часть работы, Николай рассказал, как имеет смысл работать в сложных и новых для вас предметных областях, в которых построить модель невозможно, потому что вы не понимаете эту область. В этом случае для начала можно рассмотреть систему как большой объект. UserCase начинают играть роль тестов для такого мега-объекта, и вы можете их написать именно как тесты. А далее, имея тесты – проводить безопасный рефакторинг системы, рассматриваемой как единый объект, улучшая внутреннюю структуру. Помимо этой основной идеи Николай достаточно много рассказывал про практики DDD, касающиеся проектирования, начиная со стратегического уровня - Bounded Context, Ubiquitous language, Context Maps. Тактический уровень раскрыть не получилось потому что время поджимало.

'''Филипп Торчинский''' из JetBrains рассказывал про '''веб-разработку на Котлине'''. Кто не знает, Kotlin – это новый язык с компиляторов в JVM, JavaScript и некоторыми другими, сильно совместимый с Java – JetBrains разрабатывает его для того, чтобы перейти в существующих больших проектах на разработку нового функционала на нем. Очень приятно, что Котлин уже дорос до практического использования и на нем идет внутренняя разработка в JetBrains – Филипп рассказывал про внутренний проект сайта и про плагин LifeEdit. Правда, стабильная версия еще не вышла, сейчас скорость и качество порождаемого кода их устраивает, но они работают над скоростью компиляции, пока недостаточной для больших проектов. Но вот уже начали разрабатывать. И этим можно пользоваться, тем более, что это проект с открытым исходным кодом, тексты доступны через GitHub. Смысл использования Kotlin в web-разработки в том, что серверную и клиентскую часть ты пишешь на едином языке, а потом серверная компилируется в код для Java-машины на сервере приложений, а клиентская – в HTML и CSS. И помимо языка у тебя есть фреймворки и библиотеки для сервера и клиента со всякими вкусностями. Например, поддержка работу с базой данных, включая порождение таблиц при их отсутствии. А сам код получается много компактнее, чем при классическом способе, например, при генерации html, к тому же не возникает смешения языков.

В докладе '''Егора Лукаш''' (ivi.ru) был обзор применяемых ими решений по хранению данных – в памяти, в базах данных, с особенностями использования. Потому что в их проекте применения не альтернативны, разные средства используются для разного. И были интересные кейсы, как, например, на slave-узле для базы данных в памяти, хранящей подключения закончилась память, они решили остановить репликацию, добавить память и включить назад – а репликация снова не поднялась. И пришлось в оперативном режиме поднимать второй мастер, ставить перед ними прокси и таким образом обеспечить постепенный переход на новый мастер с сохранением живых данными в памяти.

Естественным образом на конференции были доклады про инструментарий разработчиков – виртуализация ('''Александр Кириллов''') автоматическое тестирование ('''Сташевский Павел'''), новости PostgreSQL ('''Бартунов Олег''') и другие. Ряд технических докладов раскрывали внутреннее устройство промышленных систем на достаточно высоком уровне. Например, хранилище данных Яндекса ('''Смородинников Кирилл'''), или устройство транзакционности Firebird ('''Еманов Дмитрий''') без ведения журнала логов. Раскрывалось не только как сделано, но и почему так сделано. И потому эти доклады интересны не только тем, кто работает конкретно с этими продуктами для понимания внутреннего устройства. Они интересны и тем, кто создает свои решения как возможные шаблоны архитектуры. Потому что парадоксальная логика развития состоит в том, что наблюдается массовое включение NoSQL хранилищ и построение распределенных систем, которые требует от разработчиков решения тех самых вопросов, с которыми разработка сталкивалась 20 лет назад, когда персоналки были слабыми и имели мало памяти, а базы данных - не слишком продвинутыми. Потом базы данных взяли это на себя, позднее отчасти передали серверам приложений, а теперь оно возвращается в прикладной код. Как давно работающий в отрасли давно, я просто опознаю эти задачи и логические шаблоны решения. Я это увидел в докладе '''Василия Савунова''', и ряда других. Надо отметить, что речь идет именно о логике и аспектах, которые надо принять во внимания – сами решения отличаются, иногда сильно, из-за большей распределенности систем и особенностей мобильных устройств, которые по нынешним временам тоже предъявляют большие ограничения для эффективных приложений. Это меняет взаимные веса разных аспектов, которые надо учитывать, вырабатывая решение, причем с учетом специфики проекта.

== И еще пара фоток ==

Фойе конференции.

[[Файл:Stachka-2014-Ulyanovsk-2.jpg|456px]] [[Файл:Stachka-2014-Ulyanovsk-3.jpg|339px]]

На этом я заканчиваю свой обзор.

[[Категория:Конференции]] {{replicate-from-custiswiki-to-lib}}
{{wl-publish: 2014-04-15 01:39:28 +0400 | MaksTsepkov }}

Файл:Stachka-2014-Ulyanovsk-3.jpg

2014-04-20T21:40:15Z

MaksTsepkov:

Файл:Stachka-2014-Ulyanovsk-2.jpg

2014-04-20T21:39:52Z

MaksTsepkov:

Блог:Максима Цепкова/2014-04-20: SQAdays в Москве - спектр и тренды отрасли

2014-04-20T20:11:20Z

MaksTsepkov:

18-19.04.2014 в Москве прошла 15-я конференция [http://sqadays.com/ru/program/15080 SQAdays]. Отрадно отметить, что конференция развивается. На ней стало больше технических докладов. А еще — повысилось качество, докладчики понимают, что рассказываемые кейсы и методы работы — одни из возможных в отрасли и пробуют их позиционировать. И это — следствие работы программного комитета, которые не только отбирают доклады, но и работают с докладчиками над их кристаллизацией, выявлением смыслов. При этом конференция не уходит в мероприятие для продвинутых тестировщиков, она оправдывает свой девиз '''«SQAdays — точка роста твоей карьеры»'''. Что особенно важно в условиях отсутствия систематического образования. Есть тренинги, но они — по конкретным вопросам, и чтобы на них пойти, надо уже представлять свои потребности.

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

= О спектре отрасли и трендах =

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

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

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

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

Кроме того, сама отрасль разнородна по своим потребностям, а для разных проектов эффективны разные формы. Ряд inhouse и enterprise проектов до сих работают в режиме, характерном для создания опытных образцов а не промышленного производства — когда тестирование и внесение изменений идет на промышленном сервере. В твиттер-ленте конференции самым популярным стал твит про недоуменный вопрос одного из разработчиков инхауза одного топового банка «а зачем тестовая база, когда можно проверить изменения прямо на проме».

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

А еще происходят сдвижки рынка, когда в сегмент, ранее занятый более традиционными компаниями, по тем или иным причинам приходят игроки с новых сегментов рынка и присущей им новой, динамичной организацией компании. Сейчас такой процесс идет в гос.секторе. На SQAdays было несколько докладов о тестировании софта, заказываемого или разрабатываемого для государственных организаций. Оно выносится на аутсорсинг, и с ним приходит представление о современной технологии работы — с системой ведения дел, прозрачно для заказчика, быстро. И дальше подрядчики окажутся перед необходимостью соответствовать требованиям такого независимого тестирования. Другая сдвижка в этой же области, о которой, правда, я услышал несколько раньше, на [http://2014.secon.ru SECON] в Пензе — переход от заказной разработки к opensource решениям. Решение для системы одного окна, разработанное и внедренное в Пензенской области, выложено в opensource для свободного использования. А разработчики рассчитывают на востребованность доработок на внедрении, которое закажут им просто потому, что это выгоднее, чем растить свою команду. И рассчитывают, что решение будет востребовано потому, что оно существенно дешевле в сопровождении, чем большинство существующих закрытых вендорских решений. Фактически, оно вообще может выполняться собственными силами — исходный код доступен. Посмотрим, насколько оправдаются их надежды в этом случае, но, по любому, это — существенный сдвиг в парадигме работы с государством.

= Доклады =

Возвращаясь к докладам на конференции. С моей точки зрения, они полноценно, репрезентативно представляют спектр применяемых процессов и технологий в отрасли. И на общем, ценностном уровне, и в практике. И авторы понимают, что показывают один из вариантов. В некоторых докладах есть попытка осмысления, почему сложилось именно так. Понятно, что в большинстве случаев мы имеем то, что просто исторически сложилось. Но, по большому счету, сформулировать этого недостаточно, надо понимать, почему именно так было естественно в тех условиях, когда оно формировалось, а еще — сопоставить сложившийся процесс с текущей ситуацией, чтобы понять, надо ли его придерживаться и совершенствовать, или стоит готовиться к быстрым радикальным изменением, ибо ситуация в вашем сегменте отрасли уже изменилась. И, на самом деле, при подготовке доклада у авторов есть мощный и бесплатный инструмент для этого в лице членов программного комитета конференции, которые помогают готовить им доклад. По сути, есть возможность получить бесплатный и качественный экспертный аудит по теме доклада. Правда, это возможность, а не обязанность, это не входит а задачу ПК непосредственно, но вместе с обсуждением темы доклада — это можно. А уж пользоваться ли этой возможностью или оставить ее без внимания — дело автора.
А теперь кратко о запомнившихся докладах. Отмечу, что я почти не останавливаюсь на описаниях практических техник — потому что для этого во многих случаях надо плотно пересказывать доклад, а это требует времени. И если кого из авторов этих или других, не упомянутых, докладов интересует более подробный отзыв — пишите.
* '''Сергей Михалев. VIAcode. Подход доктора Хауса в тестировании оптимизации запросов'''. Хороший доклад об оптимизации SQL как о балансе между скоростью чтениями и изменения. С кейсами и подходами поиска этого баланса. И с оригинальной формой подачи, которая видна уже из названия.
* '''Михаил Курышкин. Перфоманс-лаб. Организация тестирования системы на основе смарт-карт'''. На этом докладе я понял, что еще один тренд современного тестирования — сильное включение аппаратной части, так что можно говорить об тестировании аппаратно-программных комплексов, а не просто тестировании софта. Кстати, возникает это не только при работе с конечными устройствами — тестирование надежности и производительности высоконагруженных круглосуточных сервисов и организация их мониторинга тоже по сути является тестированием АПК.
* '''Инна Смирнова. Рексофт. Исследование багов: учимся у Шерлока Холмса!''' Доклад для новичков, и по содержанию он не принципиально отличается от аналогичных — рассказывают очень правильные и актуальные вещи. Но форма подачи — хороша.
* '''Alexey Lyanguzov. Grid Dynamics. Успешный тестировщик. Путь профессионала'''. Хороший доклад про профессионализм и, главное, ценности в своей работе, то, что можно объединить в одно слово самореализация, а можно — раскрыть по пунктам. И, собственно, для осознанной самореализации как раз надо эти пункты представлять. Конечно, у разных людей они могут различаться, но доклад в любом случае хорош как начальная точка работы над собой. Вообще в вопросах к докладу прозвучал голос скептика «все это хорошо звучит, но мир-то не белый и пушистый, он — серый, так что все это не слишком применимо, как думаете?» Алексей ответил в духе «надо стремиться», а у меня есть более четкий ответ «Да, мир серый, и Вы не можете быть белыми пушистым. И раз так — давайте поставим свою серость под собственное управление, решим для себя, в каких областях я серый, насколько и почему». Эту позицию не обязательно озвучивать, это вообще зависит от окружения, но вот выработать для себя — полезно.
* '''Даниил Подойницын. Ventra Москва. Способы расширения зоны влияния вашей системы автотестов'''. Доклад о том, как с помощью костылей расширять область автоматических тестов. Костыли — это докладчик их назвал. А на самом деле, большинство представленного — никакие не костыли, а легкие и уместные решения. Просто не модные и не считаемые «достойными», высокотехнологичными. Правда, ну нет же технологии в том, чтобы организовать обмен через текстовый файл, который парсишь подручными утилитами. А дальше происходит парадоксальная вещь: это решение не рассматривают вообще, либо заменяя дорогим, либо оставляя в этом месте ручное тестирование. Спрашивается — зачем? Но вообще легкие решения упоминались во многих докладах., при этом там есть свои особенности, при которых авторы прорывались при создании, как и Данила, так что эти доклады не просто дают сообщение, что так можно, а передают опыт.
* '''Роман Иовлев. I-Free Санкт-Петербург. VIQA — Тестирование UI с помощью Виртуального интеллекта'''. Рассказ про обертку над Selenium на C#, которую они написали из-за особенностей тестируемого сайта — когда функциональные элементы (типа кнопок) имеют в html нестандартную визуальную реализацию. Хороший рассказ про проект, с раскрытием внутренней логики решений и архитектуры. И, да, они понимают почему это сделали и чем их не устраивали готовые обертки.
* '''Игорь Бондаренко. Intetics Co. Минск. Crystal Agile, или как мы приспособили процесс разработки для обеспечения максимального качества'''. Довольно интересный рассказ о том, как мутирует agile-процесс (начинали со scrum) в ходе адаптации под особенности проекта. Мутирует он в сторону, больше усложнения, а не упрощения, с включением практик из более традиционных процессов, но сохраняя дух целесообразности. При этом автор понимает что и почему происходит, процесс идет сознательно — и в докладе это показано.
* '''Антон Семенченко. ISSoft / CoherentSolutions Минск. Как эффективно организовать Автоматизацию, если у вас недостаточно времени, ресурсов и денег'''. Рассказ о том, что находится за пределами стандартно рассматриваемого процесса разработки и работы с требованиями? которыми занимаются Delivery Team и Value Team. А находится там работа с сотрудниками, повышение их квалификации — курсы и тренинги. При этом, оказывается, что при умелой организации можно в качестве предмета тренинга давать реальные проектные задачи, которые успешно решаются. Чем превращать внутренние тренинги в коммерчески оправданное мероприятие. Правда, детальная механика такой работы в докладе не раскрыта. Жаль. Потому что это ж наверняка не просто «взял и сделал» — было б просто — все бы так поступали 
* '''Natalya Rukol. Quality Lab. Миссия тест-менеджера'''. Наташа начала с того. что доклад будет не про решения, а про проблемы, которые для нее открыты. Но выдержать эту рамку не смогла: хотя доклад был полон проблемных моментов, но там же было и множество решений, основанных на вовлеченности и энергетике. Хороший доклад, жаль что короткий. И я знаю, что хотел бы услышать — про те хинты и приемчики, которые помогают все это делать помимо личной энергетики. Я знаю, что без энергетики — никуда, и чаще всего не хватает именно ее. Но наверняка за много лет работы наработаны и приемы, которые помогают все это делать. И о них тоже хочется услышать.
* '''Сергей Мартыненко. Стратегии тестирования. 42 способа сделать ваш проект успешнее'''. Наверное, у каждого в ВУЗе были опытные профессора, которые плохо рассказывали свой предмет. Сергей много знает, рассказывал сложные вещи, но, к сожалению, приоткрывая мозаику, много отвлекаясь в стороны, а не давая цельную картину. Хотя среди мозаики проскальзывают весьма интересные вещи. Все-таки жаль, что скилл докладчика он, по-видимому, считает недостаточно ценным, чтобы вкладываться в его прокачку.
* '''Yury Kupriyanov. WikiVote! Легковесный фреймворк для оценки качества на основе подхода SEMAT'''. Юра рассказывал про SEMAT и его назначение. Это сложно, потому что SEMAT сам по себе — не простая конструкция, и хотя создатели поработали над снижением порога входа, рассказать за полчаса для неподготовленного слушателя — тяжело. Так что — как получилось. В конце из зала был вопрос про соотношение SEMAT и CMMI — потому что многие слова на карточках — были слушателю знакомы. Тут есть два ответа. Во-первых, SEMAT включает три составляющие мира — объект — софт, который мы делаем, процессы, и людей, команды. А CMMI — он только про процессы, которые представляют лишь треть этого мира, при чем обеспечивающую, целью все-таки является именно создание софта, а не процессы про это. А во-вторых, CMMI жестко диктует — как сделать, а SEMAT свои карточки дает лишь как начальную точку, почти sample, от которой можно двигаться в любую сторону в соответствии с особенностями вашей компании и ее проектов. Что, собственно, и составляет ценность SEMAT в нынешнем разнообразном мире ИТ-разработки.
* '''Алексей Баранцев. Software-Testing.Ru. Тестирование на основе моделей: «ужас-ужас» или всё не так страшно?''' Алексей рассказывал про построение тестов на основе модели перехода между состояниями: вместо линейных сценариев вы описываете узлы переходов по состояниям, а система сама строит граф сценариев тестирования. Модель интересная. Правда, у меня вызвало недоумение тот уровень детальности и постепенности, с которым Алексей представлял модель, но я подумал, что Алексей лучше знает аудиторию из своего опыта проведения обучения. Правда, если уровень таков, то у меня возникает некоторая печаль. Ну, что поделать…
* И мой доклад. Вернее, наш: '''Максим Цепков, Андрей Мясников, Рина Ужевко «Вы и Заказчик: решаем проблемы, а не отрабатываем требования» '''. Он был последним на конференции, и из-за этого я не услышал доклад Майкла Болтона — он шел параллельно. Это был довольно смелый эксперимент: мы втроем попытались показать на кейсах работу с Заказчиком из позиции сотрудничества. При том, что опыт у нас троих сильно разный: заказная разработка, продуктовая и игры. Была идея, что попытка положить столь разные кейсы в некоторую общую картину поможет выявить общее и донести идеи до слушателей. Вроде оно получилось и опыт оказался удачным.

На этом завершаю свой рассказ о конференции. Другие отчеты можно посмотреть через [[Блог Максима Цепкова - оглавление|оглавление блога]]

[[Категория:Конференции]]
{{wl-publish: 2014-04-20 23:27:36 +0400 | MaksTsepkov }}
{{replicate-from-custiswiki-to-lib}}

Блог:Максима Цепкова/2014-04-20: SQAdays в Москве - спектр и тренды отрасли

2014-04-20T20:10:24Z

MaksTsepkov:

SQAdays-15-mtsepkov

2014-04-20T19:33:09Z

MaksTsepkov: Перенаправление на Блог:Максима Цепкова/2014-04-20: SQAdays в Москве - спектр и тренды отрасли

#REDIRECT [[Blog:Максима Цепкова/2014-04-20: SQAdays в Москве - спектр и тренды отрасли]]

SQAdays-15-mtsepkov

2014-04-20T19:32:57Z

MaksTsepkov: Перенаправление на Блог:Максима Цепкова/2014-04-20: SQAdays в Москве - спектр и тренды отрасли

#REDIRECT [[Blog:Максима Цепкова/2014-04-20: SQAdays в Москве - спектр и тренды отрасли]]

Блог:Максима Цепкова/2014-04-20: SQAdays в Москве - спектр и тренды отрасли

2014-04-20T19:29:46Z

MaksTsepkov: Новая страница: «18-19.04.2014 в Москве прошла 15-я конференция [http://sqadays.com/ru/program/15080 SQAdays]. Отрадно отметить, что к…»

18-19.04.2014 в Москве прошла 15-я конференция [http://sqadays.com/ru/program/15080 SQAdays]. Отрадно отметить, что конференция развивается. На ней стало больше технических докладов. А еще — повысилось качество, докладчики понимают, что рассказываемые кейсы и методы работы — одни из возможных в отрасли и пробуют их позиционировать. И это — следствие работы программного комитета, которые не только отбирают доклады, но и работают с докладчиками над их кристаллизацией, выявлением смыслов. При этом конференция не уходит в мероприятие для продвинутых тестировщиков, она оправдывает свой девиз '''«SQAdays — точка роста твоей карьеры»'''. Что особенно важно в условиях отсутствия систематического образования. Есть тренинги, но они — по конкретным вопросам, и чтобы на них пойти, надо уже представлять свои потребности.

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

= О спектре отрасли и трендах =

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

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

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

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

Кроме того, сама отрасль разнородна по своим потребностям, а для разных проектов эффективны разные формы. Ряд inhouse и enterprise проектов до сих работают в режиме, характерном для создания опытных образцов а не промышленного производства — когда тестирование и внесение изменений идет на промышленном сервере. В твиттер-ленте конференции самым популярным стал твит про недоуменный вопрос одного из разработчиков инхауза одного топового банка «а зачем тестовая база, когда можно проверить изменения прямо на проме».

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

А еще происходят сдвижки рынка, когда в сегмент, ранее занятый более традиционными компаниями, по тем или иным причинам приходят игроки с новых сегментов рынка и присущей им новой, динамичной организацией компании. Сейчас такой процесс идет в гос.секторе. На SQAdays было несколько докладов о тестировании софта, заказываемого или разрабатываемого для государственных организаций. Оно выносится на аутсорсинг, и с ним приходит представление о современной технологии работы — с системой ведения дел, прозрачно для заказчика, быстро. И дальше подрядчики окажутся перед необходимостью соответствовать требованиям такого независимого тестирования. Другая сдвижка в этой же области, о которой, правда, я услышал несколько раньше, на [http://2014.secon.ru SECON] в Пензе — переход от заказной разработки к opensource решениям. Решение для системы одного окна, разработанное и внедренное в Пензенской области, выложено в opensource для свободного использования. А разработчики рассчитывают на востребованность доработок на внедрении, которое закажут им просто потому, что это выгоднее, чем растить свою команду. И рассчитывают, что решение будет востребовано потому, что оно существенно дешевле в сопровождении, чем большинство существующих закрытых вендорских решений. Фактически, оно вообще может выполняться собственными силами — исходный код доступен. Посмотрим, насколько оправдаются их надежды в этом случае, но, по любому, это — существенный сдвиг в парадигме работы с государством.

= Доклады =

Возвращаясь к докладам на конференции. С моей точки зрения, они полноценно, репрезентативно представляют спектр применяемых процессов и технологий в отрасли. И на общем, ценностном уровне, и в практике. И авторы понимают, что показывают один из вариантов. В некоторых докладах есть попытка осмысления, почему сложилось именно так. Понятно, что в большинстве случаев мы имеем то, что просто исторически сложилось. Но, по большому счету, сформулировать этого недостаточно, надо понимать, почему именно так было естественно в тех условиях, когда оно формировалось, а еще — сопоставить сложившийся процесс с текущей ситуацией, чтобы понять, надо ли его придерживаться и совершенствовать, или стоит готовиться к быстрым радикальным изменением, ибо ситуация в вашем сегменте отрасли уже изменилась. И, на самом деле, при подготовке доклада у авторов есть мощный и бесплатный инструмент для этого в лице членов программного комитета конференции, которые помогают готовить им доклад. По сути, есть возможность получить бесплатный и качественный экспертный аудит по теме доклада. Правда, это возможность, а не обязанность, это не входит а задачу ПК непосредственно, но вместе с обсуждением темы доклада — это можно. А уж пользоваться ли этой возможностью или оставить ее без внимания — дело автора.
А теперь кратко о запомнившихся докладах. Отмечу, что я почти не останавливаюсь на описаниях практических техник — потому что для этого во многих случаях надо плотно пересказывать доклад, а это требует времени. И если кого из авторов этих или других, не упомянутых, докладов интересует более подробный отзыв — пишите.
* '''Сергей Михалев. VIAcode. Подход доктора Хауса в тестировании оптимизации запросов'''. Хороший доклад об оптимизации SQL как о балансе между скоростью чтениями и изменения. С кейсами и подходами поиска этого баланса. И с оригинальной формой подачи, которая видна уже из названия.
* '''Михаил Курышкин. Перфоманс-лаб. Организация тестирования системы на основе смарт-карт'''. На этом докладе я понял, что еще один тренд современного тестирования — сильное включение аппаратной части, так что можно говорить об тестировании аппаратно-программных комплексов, а не просто тестировании софта. Кстати, возникает это не только при работе с конечными устройствами — тестирование надежности и производительности высоконагруженных круглосуточных сервисов и организация их мониторинга тоже по сути является тестированием АПК.
* '''Инна Смирнова. Рексофт. Исследование багов: учимся у Шерлока Холмса!''' Доклад для новичков, и по содержанию он не принципиально отличается от аналогичных — рассказывают очень правильные и актуальные вещи. Но форма подачи — хороша.
* '''Alexey Lyanguzov. Grid Dynamics. Успешный тестировщик. Путь профессионала'''. Хороший доклад про профессионализм и, главное, ценности в своей работе, то, что можно объединить в одно слово самореализация, а можно — раскрыть по пунктам. И, собственно, для осознанной самореализации как раз надо эти пункты представлять. Конечно, у разных людей они могут различаться, но доклад в любом случае хорош как начальная точка работы над собой. Вообще в вопросах к докладу прозвучал голос скептика «все это хорошо звучит, но мир-то не белый и пушистый, он — серый, так что все это не слишком применимо, как думаете?» Алексей ответил в духе «надо стремиться», а у меня есть более четкий ответ «Да, мир серый, и Вы не можете быть белыми пушистым. И раз так — давайте поставим свою серость под собственное управление, решим для себя, в каких областях я серый, насколько и почему». Эту позицию не обязательно озвучивать, это вообще зависит от окружения, но вот выработать для себя — полезно.
* '''Даниил Подойницын. Ventra Москва. Способы расширения зоны влияния вашей системы автотестов'''. Доклад о том, как с помощью костылей расширять область автоматических тестов. Костыли — это докладчик их назвал. А на самом деле, большинство представленного — никакие не костыли, а легкие и уместные решения. Просто не модные и не считаемые «достойными», высокотехнологичными. Правда, ну нет же технологии в том, чтобы организовать обмен через текстовый файл, который парсишь подручными утилитами. А дальше происходит парадоксальная вещь: это решение не рассматривают вообще, либо заменяя дорогим, либо оставляя в этом месте ручное тестирование. Спрашивается — зачем? Но вообще легкие решения упоминались во многих докладах., при этом там есть свои особенности, при которых авторы прорывались при создании, как и Данила, так что эти доклады не просто дают сообщение, что так можно, а передают опыт.
* '''Роман Иовлев. I-Free Санкт-Петербург. VIQA — Тестирование UI с помощью Виртуального интеллекта'''. Рассказ про обертку над Selenium на C#, которую они написали из-за особенностей тестируемого сайта — когда функциональные элементы (типа кнопок) имеют в html нестандартную визуальную реализацию. Хороший рассказ про проект, с раскрытием внутренней логики решений и архитектуры. И, да, они понимают почему это сделали и чем их не устраивали готовые обертки.
* '''Игорь Бондаренко. Intetics Co. Минск. Crystal Agile, или как мы приспособили процесс разработки для обеспечения максимального качества'''. Довольно интересный рассказ о том, как мутирует agile-процесс (начинали со scrum) в ходе адаптации под особенности проекта. Мутирует он в сторону, больше усложнения, а не упрощения, с включением практик из более традиционных процессов, но сохраняя дух целесообразности. При этом автор понимает что и почему происходит, процесс идет сознательно — и в докладе это показано.
* '''Антон Семенченко. ISSoft / CoherentSolutions Минск. Как эффективно организовать Автоматизацию, если у вас недостаточно времени, ресурсов и денег'''. Рассказ о том, что находится за пределами стандартно рассматриваемого процесса разработки и работы с требованиями? которыми занимаются Delivery Team и Value Team. А находится там работа с сотрудниками, повышение их квалификации — курсы и тренинги. При этом, оказывается, что при умелой организации можно в качестве предмета тренинга давать реальные проектные задачи, которые успешно решаются. Чем превращать внутренние тренинги в коммерчески оправданное мероприятие. Правда, детальная механика такой работы в докладе не раскрыта. Жаль. Потому что это ж наверняка не просто «взял и сделал» — было б просто — все бы так поступали 
* '''Natalya Rukol. Quality Lab. Миссия тест-менеджера'''. Наташа начала с того. что доклад будет не про решения, а про проблемы, которые для нее открыты. Но выдержать эту рамку не смогла: хотя доклад был полон проблемных моментов, но там же было и множество решений, основанных на вовлеченности и энергетике. Хороший доклад, жаль что короткий. И я знаю, что хотел бы услышать — про те хинты и приемчики, которые помогают все это делать помимо личной энергетики. Я знаю, что без энергетики — никуда, и чаще всего не хватает именно ее. Но наверняка за много лет работы наработаны и приемы, которые помогают все это делать. И о них тоже хочется услышать.
* '''Сергей Мартыненко. Стратегии тестирования. 42 способа сделать ваш проект успешнее'''. Наверное, у каждого в ВУЗе были опытные профессора, которые плохо рассказывали свой предмет. Сергей много знает, рассказывал сложные вещи, но, к сожалению, приоткрывая мозаику, много отвлекаясь в стороны, а не давая цельную картину. Хотя среди мозаики проскальзывают весьма интересные вещи. Все-таки жаль, что скилл докладчика он, по-видимому, считает недостаточно ценным, чтобы вкладываться в его прокачку.
* '''Yury Kupriyanov. WikiVote! Легковесный фреймворк для оценки качества на основе подхода SEMAT'''. Юра рассказывал про SEMAT и его назначение. Это сложно, потому что SEMAT сам по себе — не простая конструкция, и хотя создатели поработали над снижением порога входа, рассказать за полчаса для неподготовленного слушателя — тяжело. Так что — как получилось. В конце из зала был вопрос про соотношение SEMAT и CMMI — потому что многие слова на карточках — были слушателю знакомы. Тут есть два ответа. Во-первых, SEMAT включает три составляющие мира — объект — софт, который мы делаем, процессы, и людей, команды. А CMMI — он только про процессы, которые представляют лишь треть этого мира, при чем обеспечивающую, целью все-таки является именно создание софта, а не процессы про это. А во-вторых, CMMI жестко диктует — как сделать, а SEMAT свои карточки дает лишь как начальную точку, почти sample, от которой можно двигаться в любую сторону в соответствии с особенностями вашей компании и ее проектов. Что, собственно, и составляет ценность SEMAT в нынешнем разнообразном мире ИТ-разработки.
* '''Алексей Баранцев. Software-Testing.Ru. Тестирование на основе моделей: «ужас-ужас» или всё не так страшно?''' Алексей рассказывал про построение тестов на основе модели перехода между состояниями: вместо линейных сценариев вы описываете узлы переходов по состояниям, а система сама строит граф сценариев тестирования. Модель интересная. Правда, у меня вызвало недоумение тот уровень детальности и постепенности, с которым Алексей представлял модель, но я подумал, что Алексей лучше знает аудиторию из своего опыта проведения обучения. Правда, если уровень таков, то у меня возникает некоторая печаль. Ну, что поделать…
* И мой доклад. Вернее, наш: '''Максим Цепков, Андрей Мясников, Рина Ужевко «Вы и Заказчик: решаем проблемы, а не отрабатываем требования» '''. Он был последним на конференции, и из-за этого я не услышал доклад Майкла Болтона — он шел параллельно. Это был довольно смелый эксперимент: мы втроем попытались показать на кейсах работу с Заказчиком из позиции сотрудничества. При том, что опыт у нас троих сильно разный: заказная разработка, продуктовая и игры. Была идея, что попытка положить столь разные кейсы в некоторую общую картину поможет выявить общее и донести идеи до слушателей. Вроде оно получилось и опыт оказался удачным.
На этом завершаю свой рассказ о конференции.

[[Категория:Конференции]]
{{wl-publish: 2014-04-20 23:27:36 +0400 | MaksTsepkov }}

AIST Stachka

2014-04-14T21:41:31Z

MaksTsepkov: Перенаправление на Блог:Максима Цепкова/2014-04-15: AIST и Стачка

#REDIRECT [[Blog:Максима Цепкова/2014-04-15: AIST и Стачка]]

Блог:Максима Цепкова/2014-04-15: AIST и Стачка

2014-04-14T21:39:28Z

MaksTsepkov:

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

= AIST =

[http://aistconf.org Analysis of Images, Social Networks, and Texts] или AIST - это научная конференция, с солидным международным программным комитетом и публикацией отобранных работ в Computer Science Series Springer. Проходила 3 дня, 10-12.04 в Екатеринбурге, правда, только один трек и не слишком много участников. Я был только в первый день, так что, возможно, впечатление неполное. Мне она напомнила европейские научные конференции (правда, я не так много там был). Приглашенные докладчики из зарубежных университетов, которые делают общие и, увы, поверхностные доклады. А потом - отобранные доклады. Они разного уровня. И среди них есть реально hardcore-доклады, касающиеся новых алгоритмов и методов, разработанных авторами, и доведенных до использования в промышленных системах. И доклады о разработке промышленных систем на основе методов, не применявшихся в данной области, или оригинальной комбинации методов. И более легкие доклады, когда какие-то идеи апробировались на прототипах. И совсем легкие, когда от идеи апробирована лишь легкая очевидная часть. В общем, это нормально, потому что конференция - поле общения, и там собираются как действующие научные работники, так и аспиранты и студенты. И конференция на это очень ориентирована, цена билета для представителей ВУЗов - 900 рублей при коммерческой цене участия 11500.

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

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

=Стачка=

[[Файл:Stachka-2014-Ulyanovsk-1.jpg|right|400px]]

В противоположность этому, http://NaStachku.ru или '''Стачка''' - практическая конференция. И, думаю, крупнейшая конференция в России, 2500 участников, 7 параллельных треков. Проходила 11-12.04 в Ульяновске, в Ленинском мемориале, что местами довольно прикольно смотрелось. Она очень широкая по тематике, было много технических докладов, много докладов по пиару и работе с соцсетями в инете (digital-коммуникации), и смежные темы - интернет-коммерция, стартапы, менеджмент. Доклады тоже разного уровня, рассчитанные как на продвинутую аудиторию, так и на новичков. И среди них были очень высокого уровня, о которых я напишу дальше. А доклады для новичков - нужны на конференциях, потому что одна из целей - ориентация начинающих сотрудников, студентов и даже школьников в сложном мире современного ИТ, чтобы они нашли там свое дело. Кстати, конференция - дешевая, 1000 рублей при ранней регистрации и 1500 позже, но для студентов и школьников, как я понимаю, распространяли бесплатные билеты.

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

==Образование и ИТ==

Начну я с круглого стола «Образование и ИТ». Привлечение студентов и школьников на конференцию - существенная составляющая целей конференции, это решение кадрового вопроса в долгую, развитие ИТ-кластера области, над которым совместно работают ИТ-компании, ВУЗы области и правительство области. Об этом говорили на круглом столе по образованию на второй день конференции, в котором, помимо ВУЗов и ИТ-компаний участвовали представители профессионального образования, школ и правительства области. Сам круглый стол произвел на меня очень интересное впечатление. Это такое очень государственное по форме мероприятие, по сути рабочее совещание, и для меня эта форма была на конференции неожиданностью. В самом начали ведущая сказала, что задача круглого стола - принять резолюцию, что генерация идей для нее уже была проведена, идеи обобщили, так что сейчас ее прочитают, присутствующие могут высказаться - и примем. Дальше так и было - прочитали, обсудили и приняли. Но вот содержание - было вполне адекватным. Если, конечно, уметь воспринимать государственные бумаги, там мысли излагаются в интересной форме.

Существенный упор там был на школьное образование. Потому что проблему они видят в том, что к второму-третьему курсу 70% (или больше?) студентов понимают, что пошли не туда. А в старших классах при нынешней системе школьники думают про ЕГЭ, а не про профориентацию, поэтому ориентировать их надо раньше. Чтобы они делали выбор сознательно, а не шли на поводу у родителей, которые не слишком понимают в нынешнем ИТ. При этом не было обсуждения, что надо изменить всю систему, или федеральные законы - участники работали исходя из ограничений текущей ситуации и обсуждали, что нудно сделать. Например, одна из проблем школ - это отсутствие сисадминов, которые могли бы поддерживать школьные компьютеры. Сами компьютеры - есть, и даже деньги на ставку сисадминов есть, только вот есть федеральные нормы, которыми инженерные ставки в школе запрещены. Но, оказывается есть механизм для обхода этого, через государственное предприятие при городских (или областных) структурах образования, которое берет на себя обслуживание. И дальше чисто практический вопрос как заставить эту систему работать - который при наличии воли и заинтересованности - решается.

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

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

В ИТ есть опыт организации подобных процессов, организации площадок общения и их достаточно легко можно применить и поставить при заинтересованности ИТ-сообщества. Более того, поскольку в Ульяновске ряд компаний специализируется на организации digital-коммуникаций, площадок в соцсетях, то можно профессионально на высоком уровне сделать продвинутую версию, с вовлечением как участников, проводящих профориентацию, так и самих школьников и поддерживать это при разумной стоимости затрат (потому что вопрос денег, эффективности деятельности - сохраняется). Правда, это получается достаточно сложная конструкция, причем непривычная для части участников - ВУЗы и другие образовательные организации, госструктуры ей не владеют. С другой стороны, тренды современного мира говорят, что именно за такими конструкциями - будущее. Это и есть Co-Creation, создание совместной ценности (value) скоординированной деятельностью организаций, когда каждая вносит в свой вклад не только в деятельность, но и в формирование образа этих ценностей.

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

== Kennon Thom. Digital Era==

Thom Kennon, один из руководителей Brabble, в своем докладе «Death of the Madmen in the Post Digital Era» попробовал дать крупную картину тех изменений, которые, с его точки зрения, принесла новая цифровая эра. Основная идея – переход от крупных брендов больших корпораций к мозаике мелких компаний и даже личных брендов. И от централизованно формируемого контента нескольких каналов телевидения к мозаике различных контентов интернета. Эти вещи похожи и связаны, и они уничтожают «сумасшествие», которое было присуще прежнему миру. И это, с одной стороны, хорошо как увеличение разнообразия и свободы общества, что дает гораздо больше возможности для самореализации, а с другой стороны. обостряет проблемы как для потребителя или сотрудника, требуя ориентации среди множества возможностей, так и для производителя, требуя продвижения своего продукта и компании как места работы в конкуренции с большим количеством аналогов. Качественная работа в этих условиях требует быть вести маркетинг для самого себя, при чем в полном объеме – и выбор продукта и возможностей. и продвижение своего. И это, в общем, неожиданный эффект. Бойся желаний, ибо они исполняются  Правда, по моим наблюдениям на таком уровне доклад восприняло не так много участников, для большинства он остался некоторыми общими рассуждениями высокого уровня, без ярко выраженной мысли.

==Digital communication==

Были очень интересны два доклада '''Сергея Меньшикова''' из Одноклассников. Первый – про сами одноклассники, включая подробности специальных проектов с виртуальными подарками. Подробности были про разработку и характер проектов, но масштаб – он тоже неизбежно присутствовал, потому что является неотъемлемой составляющей. Второй доклад, который Сергей прочитал экспромтом как замену – про методы работы с репутацией компаний в соцсетях, про создание и продвижение брендов – с раскрытием деталей и методов работы.
В продолжение темы про социализацию бизнеса – доклады '''Андрей Волкова''' из Grape, '''Виталия Шендрика''' из SEReputation и другие – про методы работы в соцсетях с репутацией компаний. Там было много деталей и подробностей. Это не моя профессиональная сфера, однако она очень интересна с точки зрения осознания развития современного общества. Тут следует отметить, что присутствие в соцсетях, работа с ними – это инструмент, направления и цели применения которого, как и любого инструмента, могут быть очень различны. Он может быть использован для организации рядом с компанией сообщества пользователей, для совершенствования своего продукта. А может быть использован для впаривания продукта для извлечения прибыли. При этом цели извлечения прибыли, естественным образом, не заявляются широко, а мимикрируют под социально значимую направленность. И для ориентации в мире важно не просто понимать это, а уметь различать одно от другого в конкретном кейсе, а для этого – разбираться в механизмах действия. которые и раскрывали доклады.

==Процессы и люди==

'''Мовчан Константин (AGIMA). «Нестандартные ситуации клиента и исполнителя. Обходимся малой кровью»'''. Интересная попытка дать комплексное видение процесса переговоров с клиентами. Что надо учитывать, как построить организацию внутри компании – они расформировали свой отдел продаж, заменив account-группами. В целом доклад удалась, хотя докладчик явно волновался, думаю, поэтому выступление было несколько неряшливо структурировано.

'''Табунов Михаил. Coub. «Управление проектом в условиях стремительного роста на примере Coub»'''. Интересный доклад о масштабировании бизнеса на лету, в условиях роста в полтора раза в месяц(!). При таких темах возникают проблемы по всему фронту – технические, процессные, бизнесовые, и их надо решать в этом темпе. И он рассказывал о постановке процессов, системе тестирования и выпуска версий – недельными итерациями с балансом автоматических тестов API и ручных тестов интерфейса, системе continuous delivery, реально непрерывной, до 50-60 релизов в день. О технологической политике – использование готового и облачных сервисов, куда выносятся многие инфраструктурные задачи, такие как рассылка почты – чтобы не делать своего не только в смысле разработки, но и в смысле поддержки серверных мощностей, в облаке дешевле.

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

'''Дмитрий Нечаев''' из WaveAccess рассказывал о преднамеренных практиках на основе книги Anders Ericsson. Только при их переносе в разработку необходимо определять саму деятельность – они срабатывают в областях, где возможно повышение уровня за счет тренировок, а разработка включает в себя большую часть не тренируемых (на нынешнем уровне понимания) видов деятельности, характерных для НИОКР. Эти аспекты в докладе не раскрыты.

'''Алексей Пименов''' из Финам в докладе «Неполная, но окончательная история менеджмента» дал элегантную картину, как управление проектами в ИТ, начиная с построения упорядоченной структуры и процессов переходит к лидерству, обучению команды, переходит к continuous delivery и работе без итераций и оценки, возвращаясь, по сути к тому же, с чего начали – но на следующем, более высоком уровне осознания.

'''Мой доклад''' тоже был про людей. Я рассказывал про '''Спиральную динамику''', которая дает основу для технологизации работы с ценностями человека, раскрывая структуру организации ценностей. В докладе не просто представлены конструкции спиральной динамики, а раскрыта их связь с «большим» менеджментом, как его представляют Друкер и Адизес и с менеджментом ИТ-проектов. Собственно, именно врастания конструкций спиральной динамики в мою картину развития мира, дополнение и объяснение многих существенных моментов и привело меня к желанию рассказать об этом.

[[Файл:SpiralDynamics-Tsepkov-NaStachku-2014-36.png|right|400px]]

Структурное описание ценностей позволяет переходить от индивидуального рассмотрения частных случаев для конкретных людей к осознанному формированию ценностей на уровне команд и компании в целом. При этом, что важно, совершенно не обязательно это должно быть стремление к самоорганизованной команде самореализующихся людей, объединенных общественно и экономически востребованной деятельностью разработки. Тут руководство может принимать решения, исходя из специфики конкретной фирмы и проекта. А сотрудники, в свою очередь, могут принимать решения о работе в фирме, так же опираясь не на частные случаи, а на структурированное понимание ситуации. Я, естественно, уверен, что в конечном итоге будут востребованы именно те компании, которые будут ориентироваться на продвинутые формы ценностей. Однако, это – в конечном итоге. А сейчас люди находятся на разных уровнях, работа в компаниях далеко не всегда рассматривается как добровольная и в этих условиях компания может сознательно занять и иную позицию, рассчитывая на определенный персонал. Который, возможно, будет вырастать и уходить за определенное время – но в этом нет ничего страшного.

Этот доклад я делаю второй раз, первый раз он был на AgileDays и уже выложено [http://talks.rosalab.com/20140321-59 видео и слайды]. Доклад на Стачке был с учетом этого опыта, а а в презентации появился слайд, иллюстрирующий отношение в Scrum людей разного уровня - по осмыслению докладов и обсуждений на AgileDays. После обоих докладов люди подходили и говорили, что спиральная динамика их зацепила, что она помогает понять проблемы и дополняет картину мира, и они будут дальше смотреть на нее.

==Технические доклады==

Теперь про технические доклады. Очень хороший доклад '''Николая Рыжикова''' из WaveAccess «'''Работаем со сложной предметной областью'''». Продолжая идеи DDD о переносе практик программирования, применимых для отдельных объектов, на аналитическую часть работы, Николай рассказал, как имеет смысл работать в сложных и новых для вас предметных областях, в которых построить модель невозможно, потому что вы не понимаете эту область. В этом случае для начала можно рассмотреть систему как большой объект. UserCase начинают играть роль тестов для такого мега-объекта, и вы можете их написать именно как тесты. А далее, имея тесты – проводить безопасный рефакторинг системы, рассматриваемой как единый объект, улучшая внутреннюю структуру. Помимо этой основной идеи Николай достаточно много рассказывал про практики DDD, касающиеся проектирования, начиная со стратегического уровня - Bounded Context, Ubiquitous language, Context Maps. Тактический уровень раскрыть не получилось потому что время поджимало.

'''Филипп Торчинский''' из JetBrains рассказывал про '''веб-разработку на Котлине'''. Кто не знает, Kotlin – это новый язык с компиляторов в JVM, JavaScript и некоторыми другими, сильно совместимый с Java – JetBrains разрабатывает его для того, чтобы перейти в существующих больших проектах на разработку нового функционала на нем. Очень приятно, что Котлин уже дорос до практического использования и на нем идет внутренняя разработка в JetBrains – Филипп рассказывал про внутренний проект сайта и про плагин LifeEdit. Правда, стабильная версия еще не вышла, сейчас скорость и качество порождаемого кода их устраивает, но они работают над скоростью компиляции, пока недостаточной для больших проектов. Но вот уже начали разрабатывать. И этим можно пользоваться, тем более, что это проект с открытым исходным кодом, тексты доступны через GitHub. Смысл использования Kotlin в web-разработки в том, что серверную и клиентскую часть ты пишешь на едином языке, а потом серверная компилируется в код для Java-машины на сервере приложений, а клиентская – в HTML и CSS. И помимо языка у тебя есть фреймворки и библиотеки для сервера и клиента со всякими вкусностями. Например, поддержка работу с базой данных, включая порождение таблиц при их отсутствии. А сам код получается много компактнее, чем при классическом способе, например, при генерации html, к тому же не возникает смешения языков.

В докладе '''Егора Лукаш''' (ivi.ru) был обзор применяемых ими решений по хранению данных – в памяти, в базах данных, с особенностями использования. Потому что в их проекте применения не альтернативны, разные средства используются для разного. И были интересные кейсы, как, например, на slave-узле для базы данных в памяти, хранящей подключения закончилась память, они решили остановить репликацию, добавить память и включить назад – а репликация снова не поднялась. И пришлось в оперативном режиме поднимать второй мастер, ставить перед ними прокси и таким образом обеспечить постепенный переход на новый мастер с сохранением живых данными в памяти.

Естественным образом на конференции были доклады про инструментарий разработчиков – виртуализация ('''Александр Кириллов''') автоматическое тестирование ('''Сташевский Павел'''), новости PostgreSQL ('''Бартунов Олег''') и другие. Ряд технических докладов раскрывали внутреннее устройство промышленных систем на достаточно высоком уровне. Например, хранилище данных Яндекса ('''Смородинников Кирилл'''), или устройство транзакционности Firebird ('''Еманов Дмитрий''') без ведения журнала логов. Раскрывалось не только как сделано, но и почему так сделано. И потому эти доклады интересны не только тем, кто работает конкретно с этими продуктами для понимания внутреннего устройства. Они интересны и тем, кто создает свои решения как возможные шаблоны архитектуры. Потому что парадоксальная логика развития состоит в том, что наблюдается массовое включение NoSQL хранилищ и построение распределенных систем, которые требует от разработчиков решения тех самых вопросов, с которыми разработка сталкивалась 20 лет назад, когда персоналки были слабыми и имели мало памяти, а базы данных - не слишком продвинутыми. Потом базы данных взяли это на себя, позднее отчасти передали серверам приложений, а теперь оно возвращается в прикладной код. Как давно работающий в отрасли давно, я просто опознаю эти задачи и логические шаблоны решения. Я это увидел в докладе '''Василия Савунова''', и ряда других. Надо отметить, что речь идет именно о логике и аспектах, которые надо принять во внимания – сами решения отличаются, иногда сильно, из-за большей распределенности систем и особенностей мобильных устройств, которые по нынешним временам тоже предъявляют большие ограничения для эффективных приложений. Это меняет взаимные веса разных аспектов, которые надо учитывать, вырабатывая решение, причем с учетом специфики проекта.

На этом я заканчиваю свой обзор.

[[Категория:Конференции]] {{replicate-from-custiswiki-to-lib}}
{{wl-publish: 2014-04-15 01:39:28 +0400 | MaksTsepkov }}

Файл:SpiralDynamics-Tsepkov-NaStachku-2014-36.png

2014-04-14T21:30:30Z

MaksTsepkov:

Файл:Stachka-2014-Ulyanovsk-1.jpg

2014-04-14T21:29:41Z

MaksTsepkov:

Категория:Максим Цепков

2014-04-12T04:38:30Z

MaksTsepkov:

{{----}}
[[Файл:MaksTsepkov-1.jpg|right|thumb|200px]]

Записи докладов Максима Цепкова (http://www.facebook.com/mtsepkov и http://www.facebook.com/mtsepkov).
Смотри также [[:Категория:Максим Цепков (Статьи)|публикации Максима в СМИ]].

[[Категория:Известные докладчики|Цепков]]
{{replicate-from-custiswiki-to-lib}}

Категория:Максим Цепков

2014-04-12T04:36:24Z

MaksTsepkov:

Блог:Максима Цепкова/2014-03-23: AgileDays-2014

2014-03-30T18:42:18Z

MaksTsepkov:

Конференция [http://agiledays.ru AgileDays-14] 900 участников, 70 докладов на 5 треках. Впечатления - ожидаемые, потому что конференция просто фиксирует состояние отрасли, которая живет поисками нового прорыва. За год его не произошло, и поэтому на конференции -доклады про эффективность существующих подходов и практик в разных вариантах и про кейсы их применения в расширяющейся области перемежаются докладами про новое, прочитанное или услышанное, которое потенциально может толчок новому развитию - если получится, если правильно синтезировать.

Собственно, примерно об этом я писал в [http://softwarepeople.ru/blog/2013/03/31/agiledays-2013/ отчете о AgileDays-2013], но тогда это ощущение было более свежим. А сейчас оно уже более устоялось, в нем можно выделить отчетливые тренды.

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

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

И это послужило толчком к массовому признанию Agile и его внедрению. К тому же для управления любые могут быть изменения полезны – известно, что регулярное умелое перетряхивание организаций может благотворно влияет на процесс в короткую просто за счет мобилизации персонала. В длинную оно губительно, но мало кто мыслит в длинную. Естественно, при этом возникли мутации и мимикрия, выхолащивание сути и формальные понятия типа Scrumbut - замечательная идиома «скнамно» по-русски. Зато agile-практики хорошо сопряглись с традиционным менеджментом. И внедряются в больших организациях, как под флагом agile, так и без него. И даже большие банки – в этом тренде. Про Дойч известно давно, сейчас идет проект в Альфе, а ВТБ24 внедряет TFS с agile-шаблонами, не поднимая Agile на флаг.

Собственно, исходя из этого можно выделить основные типы докладов на конференции.

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

'''2. Осмысление места agile в больших организациях'''. Например, как островков интенсивного развития в большой структуре, как рассказывала Обухова из Люксофт. И рекомендации развития. Кстати, доклад Асхата про NoEstimate разработку, думаю, тоже здесь. С моей точки зрения, это осмысления с точки зрения Agile практик inhouse-разработки, в которых оценку часто не далают, зато выдают value в темпе, в целом устраивающем стейкхолдеров. И да, так тоже можно, это не противоречит подходам Agile, а является их расширением, уместным в соответствующем классе ситуаций. И еще раз напоминает, что нельзя к практикам относиться догматически. Доклад был интересным, стоит послушать.

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

'''4. Развитие Agile там, где его восприняли на ценностном уровне'''. Здесь рассказ Николая Рыжикова про применение в их компании парного программирования – оно тотально и это не типично, Кирилла Мокевнина про формирование инженерной культуры, Михаила Рыжикова про сообщества – как внутри организации, так и про включение во внешние. Кстати, Михаил – один из организаторов PiterUnited, метасообщества, объединившего другие ИТ- сообщества Питера – пока, естественно, не все, но думаю, что процесс будет идти. Был любопытный доклад Александра Горника. Он поработал в избирательной компании Навального и обнаружил, что применявшиеся там практики организации работ очень созвучны Канбану и пробует применить увиденное в своей компании.

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

'''5. Ветви интенсивного развития''' – игрофикация, визуализация и другие. Формально безотносительны к принятию ценностей, но связь – есть. Потому что возникают они там, где ценности приняты, апробированы и востребованы именно в такой обстановке. А вне этого могут быть бесполезны или даже разрушительны, как игрофикация, которая при неосторожном применении вполне может нанести серьезный урон или даже разрушить компанию. Именно поэтому я отделяю эту категорию от первой. Про игрофикацию было много докладов и мастер-классов, включая рассказы Максима Коробцева, который, на мой взгляд, является наиболее продвинутым и разбирающимся в этом вопросе специалистом в России, про конкретные кейсы.

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

'''6. Поиски источников для нового'''. Из различных внешних книг – по психологии, управлению и другим. В целом Agile много заимствовал в известных методах, творчески переосмысливая на основе ценностей. Это доклад Алексея Пименова «Прививка креативности», мастер-класс Юрия Куприянова про Rapid Forsight и так далее. Будущее можно искать не только в теории, но и в практике, таков был блиц Сергея Котлова про компании 21 века в конкретных примерах.

[[Файл:Tsepkov-AgileDays-2014-SpiralDynamics-slide34.png|400px|right]]

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

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

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

А остановка развития в Agile связана с тем, что Бирюзовый еще не построен, для него не выработано адекватных оргформ. Это еще предстоит. Но появится это именно у нас, в ИТ – как появился Желтый.

Вот такое у меня сейчас восприятие мира – через ее призму спиральной динамики. С одной стороны, это многое проясняет. С другой – восприятие через схему всегда обедняет мир. Особенно если правильность схемы не доказана, а у тебя, к тому же, своя интерпретация. Поэтому очень хочется обсуждать это и проверять в широком кругу. Кому интересно – пишите в коментах. Презентацию можно посмотреть на slideshare http://www.slideshare.net/mtsepkov/tsepkov-agile-days2014spiraldynamics

На этом заканчиваю. Обзора не будет, потому что видел далеко не все доклады, и точно не видел несколько хороших – 5 треков насыщенных требуют делать выбор. А еще при таком широком спектре надо смотреть доклады с учетом своей собственной ситуации, а не на восприятие экспертов.

[[Категория:AgileDays]]{{replicate-from-custiswiki-to-lib}}
{{wl-publish: 2014-03-23 21:18:55 +0400 | MaksTsepkov }}

AgileDays-2014-mtsepkov

2014-03-23T17:21:07Z

MaksTsepkov: Перенаправление на Блог:Максима Цепкова/2014-03-23: AgileDays-2014

#REDIRECT [[Blog:Максима Цепкова/2014-03-23: AgileDays-2014]]

AgileDays-2014-mtsepkov

2014-03-23T17:21:04Z

MaksTsepkov: Перенаправление на Блог:Максима Цепкова/2014-03-23: AgileDays-2014

#REDIRECT [[Blog:Максима Цепкова/2014-03-23: AgileDays-2014]]

Блог:Максима Цепкова/2014-03-23: AgileDays-2014

2014-03-23T17:18:55Z

MaksTsepkov:

Конференция [http://agiledays.ru AgileDays-14] 900 участников, 70 докладов на 5 треках. Впечатления - ожидаемые, потому что конференция просто фиксирует состояние отрасли, которая живет поисками нового прорыва. За год его не произошло, и поэтому на конференции -доклады про эффективность существующих подходов и практик в разных вариантах и про кейсы их применения в расширяющейся области перемежаются докладами про новое, прочитанное или услышанное, которое потенциально может толчок новому развитию - если получится, если правильно синтезировать.

Собственно, примерно об этом я писал в [http://softwarepeople.ru/blog/2013/03/31/agiledays-2013/ отчете о AgileDays-2013], но тогда это ощущение было более свежим. А сейчас оно уже более устоялось, в нем можно выделить отчетливые тренды.

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

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

И это послужило толчком к массовому признанию Agile и его внедрению. К тому же для управления любые могут быть изменения полезны – известно, что регулярное умелое перетряхивание организаций может благотворно влияет на процесс в короткую просто за счет мобилизации персонала. В длинную оно губительно, но мало кто мыслит в длинную. Естественно, при этом возникли мутации и мимикрия, выхолащивание сути и формальные понятия типа Scrumbut - замечательная идиома «скнамно» по-русски. Зато agile-практики хорошо сопряглись с традиционным менеджментом. И внедряются в больших организациях, как под флагом agile, так и без него. И даже большие банки – в этом тренде. Про Дойч известно давно, сейчас идет проект в Альфе, а ВТБ24 внедряет TFS с agile-шаблонами, не поднимая Agile на флаг.

Собственно, исходя из этого можно выделить основные типы докладов на конференции.

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

'''2. Осмысление места agile в больших организациях'''. Например, как островков интенсивного развития в большой структуре, как рассказывала Обухова из Люксофт. И рекомендации развития. Кстати, доклад Асхата про NoEstimate разработку, думаю, тоже здесь. С моей точки зрения, это осмысления с точки зрения Agile практик inhouse-разработки, в которых оценку часто не далают, зато выдают value в темпе, в целом устраивающем стейкхолдеров. И да, так тоже можно, это не противоречит подходам Agile, а является их расширением, уместным в соответствующем классе ситуаций. И еще раз напоминает, что нельзя к практикам относиться догматически. Доклад был интересным, стоит послушать.

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

'''4. Развитие Agile там, где его восприняли на ценностном уровне'''. Здесь рассказ Николая Рыжикова про применение в их компании парного программирования – оно тотально и это не типично, Кирилла Мокевнина про формирование инженерной культуры, Михаила Рыжикова про сообщества – как внутри организации, так и про включение во внешние. Кстати, Михаил – один из организаторов PiterUnited, метасообщества, объединившего другие ИТ- сообщества Питера – пока, естественно, не все, но думаю, что процесс будет идти. Был любопытный доклад Александра Горника. Он поработал в избирательной компании Навального и обнаружил, что применявшиеся там практики организации работ очень созвучны Канбану и пробует применить увиденное в своей компании.

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

'''5. Ветви интенсивного развития''' – игрофикация, визуализация и другие. Формально безотносительны к принятию ценностей, но связь – есть. Потому что возникают они там, где ценности приняты, апробированы и востребованы именно в такой обстановке. А вне этого могут быть бесполезны или даже разрушительны, как игрофикация, которая при неосторожном применении вполне может нанести серьезный урон или даже разрушить компанию. Именно поэтому я отделяю эту категорию от первой. Про игрофикацию было много докладов и мастер-классов, включая рассказы Максима Коробцева, который, на мой взгляд, является наиболее продвинутым и разбирающимся в этом вопросе специалистом в России, про конкретные кейсы.

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

'''6. Поиски источников для нового'''. Из различных внешних книг – по психологии, управлению и другим. В целом Agile много заимствовал в известных методах, творчески переосмысливая на основе ценностей. Это доклад Алексея Пименова «Прививка креативности», мастер-класс Юрия Куприянова про Rapid Forsight и так далее. Будущее можно искать не только в теории, но и в практике, таков был блиц Сергея Котлова про компании 21 века в конкретных примерах.

[[Файл:Tsepkov-AgileDays-2014-SpiralDynamics-slide34.png|400px|right]]

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

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

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

А остановка развития в Agile связана с тем, что Бирюзовый еще не построен, для него не выработано адекватных оргформ. Это еще предстоит. Но появится это именно у нас, в ИТ – как появился Желтый.

Вот такое у меня сейчас восприятие мира – через ее призму спиральной динамики. С одной стороны, это многое проясняет. С другой – восприятие через схему всегда обедняет мир. Особенно если правильность схемы не доказана, а у тебя, к тому же, своя интерпретация. Поэтому очень хочется обсуждать это и проверять в широком кругу. Кому интересно – пишите в коментах. Презентацию можно посмотреть на slideshare http://www.slideshare.net/mtsepkov/tsepkov-agile-days2014spiraldynamics

На этом заканчиваю. Обзора не будет, потому что видел далеко не все доклады, и точно не видел несколько хороших – 5 треков насыщенных требуют делать выбор. А еще при таком широком спектре надо смотреть доклады с учетом своей собственной ситуации, а не на восприятие экспертов.

[[Категория:AgileDays]]{{replicate-from-custiswiki-to-lib}}
{{wl-publish: 2014-03-23 21:18:55 +0400 | MaksTsepkov }}

Блог:Максима Цепкова/2014-03-23: AgileDays-2014

2014-03-23T17:18:14Z

MaksTsepkov: Новая страница: «Конференция [http://agiledays.ru AgileDays-14] 900 участников, 70 докладов на 5 треках. Впечатления - ожидае…»

Конференция [http://agiledays.ru AgileDays-14] 900 участников, 70 докладов на 5 треках. Впечатления - ожидаемые, потому что конференция просто фиксирует состояние отрасли, которая живет поисками нового прорыва. За год его не произошло, и поэтому на конференции -доклады про эффективность существующих подходов и практик в разных вариантах и про кейсы их применения в расширяющейся области перемежаются докладами про новое, прочитанное или услышанное, которое потенциально может толчок новому развитию - если получится, если правильно синтезировать.

Собственно, примерно об этом я писал в [http://softwarepeople.ru/blog/2013/03/31/agiledays-2013/ отчете о AgileDays-2013], но тогда это ощущение было более свежим. А сейчас оно уже более устоялось, в нем можно выделить отчетливые тренды.

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

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

И это послужило толчком к массовому признанию Agile и его внедрению. К тому же для управления любые могут быть изменения полезны – известно, что регулярное умелое перетряхивание организаций может благотворно влияет на процесс в короткую просто за счет мобилизации персонала. В длинную оно губительно, но мало кто мыслит в длинную. Естественно, при этом возникли мутации и мимикрия, выхолащивание сути и формальные понятия типа Scrumbut - замечательная идиома «скнамно» по-русски. Зато agile-практики хорошо сопряглись с традиционным менеджментом. И внедряются в больших организациях, как под флагом agile, так и без него. И даже большие банки – в этом тренде. Про Дойч известно давно, сейчас идет проект в Альфе, а ВТБ24 внедряет TFS с agile-шаблонами, не поднимая Agile на флаг.

Собственно, исходя из этого можно выделить основные типы докладов на конференции.

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

'''2. Осмысление места agile в больших организациях'''. Например, как островков интенсивного развития в большой структуре, как рассказывала Обухова из Люксофт. И рекомендации развития. Кстати, доклад Асхата про NoEstimate разработку, думаю, тоже здесь. С моей точки зрения, это осмысления с точки зрения Agile практик inhouse-разработки, в которых оценку часто не далают, зато выдают value в темпе, в целом устраивающем стейкхолдеров. И да, так тоже можно, это не противоречит подходам Agile, а является их расширением, уместным в соответствующем классе ситуаций. И еще раз напоминает, что нельзя к практикам относиться догматически. Доклад был интересным, стоит послушать.

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

'''4. Развитие Agile там, где его восприняли на ценностном уровне'''. Здесь рассказ Николая Рыжикова про применение в их компании парного программирования – оно тотально и это не типично, Кирилла Мокевнина про формирование инженерной культуры, Михаила Рыжикова про сообщества – как внутри организации, так и про включение во внешние. Кстати, Михаил – один из организаторов PiterUnited, метасообщества, объединившего другие ИТ- сообщества Питера – пока, естественно, не все, но думаю, что процесс будет идти. Был любопытный доклад Александра Горника. Он поработал в избирательной компании Навального и обнаружил, что применявшиеся там практики организации работ очень созвучны Канбану и пробует применить увиденное в своей компании.

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

'''5. Ветви интенсивного развития''' – игрофикация, визуализация и другие. Формально безотносительны к принятию ценностей, но связь – есть. Потому что возникают они там, где ценности приняты, апробированы и востребованы именно в такой обстановке. А вне этого могут быть бесполезны или даже разрушительны, как игрофикация, которая при неосторожном применении вполне может нанести серьезный урон или даже разрушить компанию. Именно поэтому я отделяю эту категорию от первой. Про игрофикацию было много докладов и мастер-классов, включая рассказы Максима Коробцева, который, на мой взгляд, является наиболее продвинутым и разбирающимся в этом вопросе специалистом в России, про конкретные кейсы.

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

'''6. Поиски источников для нового'''. Из различных внешних книг – по психологии, управлению и другим. В целом Agile много заимствовал в известных методах, творчески переосмысливая на основе ценностей. Это доклад Алексея Пименова «Прививка креативности», мастер-класс Юрия Куприянова про Rapid Forsight и так далее. Будущее можно искать не только в теории, но и в практике, таков был блиц Сергея Котлова про компании 21 века в конкретных примерах.

[[Файл:Tsepkov-AgileDays-2014-SpiralDynamics-slide34.png|400px|right]]

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

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

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

А остановка развития в Agile связана с тем, что Бирюзовый еще не построен, для него не выработано адекватных оргформ. Это еще предстоит. Но появится это именно у нас, в ИТ – как появился Желтый.

Вот такое у меня сейчас восприятие мира – через ее призму спиральной динамики. С одной стороны, это многое проясняет. С другой – восприятие через схему всегда обедняет мир. Особенно если правильность схемы не доказана, а у тебя, к тому же, своя интерпретация. Поэтому очень хочется обсуждать это и проверять в широком кругу. Кому интересно – пишите в коментах. Презентацию можно посмотреть на slideshare http://www.slideshare.net/mtsepkov/tsepkov-agile-days2014spiraldynamics

На этом заканчиваю. Обзора не будет, потому что видел далеко не все доклады, и точно не видел несколько хороших – 5 треков насыщенных требуют делать выбор. А еще при таком широком спектре надо смотреть доклады с учетом своей собственной ситуации, а не на восприятие экспертов.

[[Категория:AgileDays]]
{{wl-publish: 2014-03-23 21:18:14 +0400 | MaksTsepkov }}

Файл:Tsepkov-AgileDays-2014-SpiralDynamics-slide34.png

2014-03-23T17:15:56Z

MaksTsepkov:

Файл:Tsepkov-AgileDays-2014-SpiralDynamics-slide34.png

2014-03-23T17:06:08Z

MaksTsepkov:

Блог:Максима Цепкова/2014-03-14: SECON в Пензе

2014-03-17T17:38:27Z

MaksTsepkov:

[[Файл:SECON-2014-photo-2.jpg|right|300px]]

Вслед за [http://happydev.ru HappyDev] где я был в декабре, 14.03.2014 поехал в Пензу на [http://2014.SECON.ru SECON] — меня позвали рассказать про DDD. Я еще в Омске почувствовал отличие региональных конференций от проходящих на уровне России и СНГ и писал об этом в [http://lib.custis.ru/HappyDev-2013-mtsepkov своем посте]. Дело в том, что региональные конференции неотделимы от регионального IT-сообщества, организуются ими и как площадка общения IT-шников и как возможность для них получения новых знаний, нового опыта, для чего приглашаются хорошие докладчики. Но и местные докладчики тоже, естественно, присутствуют, потому что сильные IT-сообщества означают наличие достаточно значимых разработческих компаний в регионе. При этом конференции реально многолюдные, в Пензе второй год число участников — около 500, это много и по меркам российских конференций. И это — не предел, в Ульяновске проходит [http://nastachku.ru/ Cтачка] и [http://ulcamp.ru UlCamp], собирающие больше тысячи участников с пригашают докладчиков-экспертов мирового уровня. На них я еще не был.

На фотках — зал на открытии конференции, на переднем плане на второй фотке — Максим Семенкин, организатор и идейный вдохновитель конференции.

[[Файл:SECON-2014-photo-1.jpg|right|300px]]

И новых условиях крупным конференциям надо заново искать свою позицию. Я не хочу сказать, что они будут вытеснены региональными конкурентами, просто надо представлять себе какую именно ценность они приносят. Мы в [http://secr.ru SECR] пробуем в этих условиях стать мостом между новыми формирующимися сообществами и более традиционными IT-институтами мирового уровня. Приглашать докладчиков — реальных гуру, таких как Ивар Якобсон, создатель UML и usecase, и при этом продолжающих активно действовать — Ивар рассказывал на конференции 2013 года про SEMAT, который появился только-только и при этом успешно завоевывает мир. Служить площадкой для общения IT-сообщества с ВУЗами — статус ACM-конференции означает, что принятые доклады, оформленные как научные статьи, еще и попадают в электронную библиотеку публикаций ACM, что важно для совмещающих практическую работу с преподаванием и для их университетов. Ну и собирать лучшие доклады высокого уровня в России, СНГ и мире. Пользуясь случаем, агитирую выступать и приезжать участвовать. Хотя участие — дороже, оно доступно, особенно при ранней регистрации, а для докладчиков участие бесплатно.

[[Файл:SECON-2014-photo-3.jpg|right|300px]]

Возвращаюсь к SECON. Конференция проходила в пензенском Технопарке высоких технологий «Рамеев», носящем имя пензенского ученого, участвовавшего в создании вычислительной техники СССР, начиная с аналоговых моделей. На фотке — выставка.

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

В формате обмена мнениями был очень интересный '''баркэмп про образование'''. Это, кстати, тоже тренд, проявившийся [http://softwarepeople.ru/blog/2013/12/18/spmconf-образование-vs-ит/ на круглом столе SPMconf], HappyDev и здесь. Трендом тут является не тема, а суть обсуждения. IT развилось до того уровня, когда есть потребность в подготовке кадров, которую крупные компании в свое время закрыли для себя учебными центрами, а новым этого — не хватает. И они обсуждают различные формы в практическом, деятельностном залоге. В том числе — взаимодействие с ВУЗами, где они пока не готовы открывать кафедры. Тут, кстати, все сильно зависит от местного ВУЗа. В Омске, например, университет сотрудничает с местным сообществом и за последний год они перешли от уровня взаимодействия с отдельными компаниями к скоординированной общей деятельности. Что, кстати, сразу дало позитивный эффект — после сравнения курсов, читаемых разными компаниями получилось убрать дублирование и, за счет этого сэкономить время и дать дополнительные материалы. В Ульяновске идет взаимодействие на уровне предоставления площадей. А в Пензе, и не только в ней ВУЗ относится к деятельности IT-компаний как к попыткам поживиться за счет государства, или как к потенциальному месту срубить деньги — и хочет денег даже за предоставление помещений. Потому что в образование как система — не заинтересованно в подготовке специалистов, востребованных обществом, у него по факту — совсем другие KPI. И, собственно, основным выводом обсуждения было признание этого факта и, как следствие — работа на уровне конкретных преподавателей с созданием параллельных структур образования в тех местах, где ВУЗы глухи. Да, это непрофильная деятельность и обременение, но — вполне посильное сильным IT-сообществам. И факт состоит в том, что через несколько лет оно обременением быть перестанет, поэтому ВУЗы, не включившиеся в такую деятельность — вымрут. Значит, туда им и дорога.

Теперь о том интересном, что я услышал на докладах. '''Кирилл Мокевнин''' рассказывал про все аспекты работы с сотрудниками, которые позволяют построить не просто компанию, а сообщество увлеченных, успешно самореализующихся людей, действующих совместно. Составляющие, с одной стороны, понятные и теоретически знакомые, с другой стороны — далеко не везде такое получается и даже ставится такая задача. А между тем это — явные тренд, веление времени. Правда. успешные примеры пока ограничиваются небольшими компаниями, до 50 человек или несколько больше. Но большие, включая таких гигантов как Google и Microsoft некоторое время назад тоже начали работать в этом направлении, и я думаю, что через некоторое время тут будет прорыв. Я, кстати, буду на AgileDays рассказывать, почему это соответствует общемировым закономерностям развития, говоря [http://agiledays.ru/members/profile/211/ о системах ценностей].

Был интересный доклад Максима Зайцев. «'''Госуслуги. Open: OpenSource для государства'''» — о том, как систему портала для оказания гос.услуг, разработанную и эксплуатирующуюся в Пензенской области выложили в OpenSource и в результате она является бесплатно-доступной для всех желающих. И разработчики надеются, что она вытеснит большинство других системы госуслуг, потому что многие из них были сделаны быстро в ущерб качеству и представляют собой тяжелые в эксплуатации и неповоротливые изделия, а их же необходимо развивать, подключая новые услуги. Сами разработчики при этом готовы предоставлять услуги по развертыванию системы и адаптации ее к нуждам конкретного региона, уже на платной основе, однако при открытых исходных кодах и наличии квалифицированных кадров можно обойтись и без них, во всяком случае, спектр взаимодействия весьма широк. Они спокойно на это смотрят, видя в этом еще и социальную составляющую — госуслугами пользуемся мы все и если система будет эффективна — то общество в выигрыше. А внутри системы — BPMN-движок для выстраивания процессов по оказанию услуг и их прохождению по разным ведомствам, и точки интеграции с системами конкретных ведомств, обвешанные электронными подписями и прочей достаточно тяжелой инфраструктурой, необходимой для такой системы.

Еще я был на '''нескольких докладах''', на которых рассказывали про осваивание новых для команды технологий или шаблонов реализации или даже созданию новых, например, от переходов от callback к взаимодействию через события или кодогенерации интеграционного слоя на основе описаний структур данных с аннотациями. Тут очень интересные впечатления. Когда такую вещь рассказывают с техническими подробностями, то, во-первых, это полезно тем, кто только смотрит в эту сторону, решая аналогичные задачи. А, во-вторых, хотя это куда менее очевидно, полезно тем, кто этот путь уже прошел. Дело в том, что конкретная реализация — отличается. И настоящий профессионал — тот, кто понимает, почему реализация оказалось другой и может сравнить плюсы и минусы в контексте конкретных проектов. Сами докладчики, чаще всего, это сделать не могут, потому что для них это первый опыт. Но вот, что интересно, более опытные тоже не могут — они в свое время такой путь прошли, и у них тоже единственный опыт — свой, который, при удаче, рассматривается как лучший, а при неудаче — как непригодность технологии (ну, пусть, только к их проектам). А на самом деле он, как правило, не лучший, а просто другой. Особую прелесть этим сравнением придает тот факт, что «программирование — единственная область, где с костылями быстрее, чем без них» (Максим Дорофеев), и отличие профессионала в том, что он умеет сроить баланс костылей и красивых решений. Я не хочу сказать, что сам могу всегда ответить на вопросы, сравнения разных решений но, во всяком случае, я исходно рассматриваю услышанные решения именно как другие, различаю костыли и красивые решения и пробую сравнить их и свои решения с этой точки зрения.

А сам я делал обзорный '''доклад по DDD''', акцентируя внимание на концептуальный уровень, на единый язык и построение коммуникаций, а не просто работу с моделями, и на сложное отражение в код через шаблоны, а не просто через Domain Model и RichObjects — потому что, по опыту, оно гораздо уместнее в сложных проектах. Именно эта часть, по моему опыту, часто ускользает от внимания, в результате DDD интерпретируется как достаточно простая конструкция — с существенными ограничениями по применению. Презентацию доклада можно посмотреть [http://lib.uml2.ru/Tsepkov-SECON-2014-DDD-review здесь].

На этом я кончаю свой отчет о конференции, до встречи на новых конференциях.
{{wl-publish: 2014-03-16 12:48:46 +0400 | MaksTsepkov }}
[[Category:Конференции]]{{replicate-from-custiswiki-to-lib}}