Просмотр исходного текста страницы ЛАФ-2011 - отчет Максима Цепкова

= Общее впечатление =

Конференция ЛАФ-2011 (http://conf.uml2.ru) прошла 25-26.06.2011 в Иваново в офисе Консультант-Плюс, который помогал в организации. На конференции было около 100 человек, из Москвы, Питера, Иваново. Самары, Краснодара, Минска и других мест. Три трека - доклады, круглые столы и мастер-классы. Как и в прошлом году, впечатление - крайне позитивное, конференция живая. Люди активно общаются, по этому признаку ее вполне можно сравнить с AgileDays. При этом она практически бесплатная, 200 рублей - это не деньги. Так что хочется высказать большую благодарность и почтение организаторам. Я сожалею, что не смог остаться на вечер и второй день по личным обстоятельствам, надеюсь, что в будущем году это получится.

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

= Мой доклад =

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

Кстати, если говорить об опыте нашей компании, то построение учетных моделей с помощью диаграмм учета, о котором я подробно рассказывал на ЛАФ-2010 и на других конференциях постепенно овладевает умами. Поезд из Москвы приехал в 6 утра и пока мы ждали открытия конференции, несколько человек спрашивали меня о деталях и подробностях этого подхода. Мы с ними обсуждали схемы, которые были недавно опубликованы в журнале Бухгалтер и Компьютер №5 http://lib.custis.ru/Когда_всем_понятно. И меня это радует.

Презентация выложена http://www.slideshare.net/custisppt/ddd-2011, надеюсь, появится запись.

= Резюме докладов =

== Ирина Левенец. Управление ожиданиями ==

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

Что я отметил.
* В новостях релизов надо публиковать не просто новые фичи, а новое value, которое заказчик может получить с помощью этой возможности. Например, не "добавили поле фильтра", а "с помощью нового фильтра вы можете проанализировать продажи так-то".
* При планировании релиза это value также надо учитывать помимо приоритета и трудоемкости. И балансировать - заказчики разные, не все фичи полезны каждому, но в релизе каждый из них должен что-то найти для себя. 
* Еще интересный момент про value: преднастроенная стандартная конфигурация, например, деление клиентов по размеру счета увеличивает value, те, кто не задумался бы о делении клиентов - начинают пользоваться.  
* Обещать надо осторожно, лучше сделать больше, чем обещал, чем не сделать обещанное. В частности, они сейчас борются с обещанием мелких и неважных фич "когда-нибудь в будущем" - будущее-то наступает, заказчики это помнят.
* Но Заказчик привыкает и к тому, что делаешь больше чем обещал и начинает ждать этого. Пока они не умеют с этим бороться.
* Для длительных проектов не слишком работают техники разовых проектов. Говоришь клиенту спасибо за идею - он хочет проценты, или скидку за сопровождение и т.п.
 
Мне доклад был интересен, поскольку наша компания работает в условиях длительного сотрудничества с заказчиками. Правда, у нас - заказная разработка, а не продуктовая, однако мы имеем много общего. И эти соображения следует учитывать. Например, балансируя релиз по value для различных групп стейкхолдеров внутри заказчика. Что, правда, сильно противоречит другому принципу организации работ, призывающему сосредотачиваться на одном направлении, чтобы уменьшить переключение контекста.
   
==Алексей Киселев. Могут ли быть выгодны ошибки аналитика или история одного тендера==

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

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

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

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

==Сурова Ирина. Сравнение форматов требований==

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

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

В качестве форматов рассмотрены следующие:
* текстовый документ (с нумерацией абзацев)
* набор таблиц
* набор изображений (png)
* модель (диаграммы) enterprice architect
Еще был упомянута база данных и прототип, но в анализе не участвовала.

Критерии поделены на две группы:
* профессиональные, на которые влияет аналитик
* проектно-зависимые, на которые он не влияет

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

Использование модели не означает полного отказа от картинок, таблиц или документов - они остаются там, где это уместно, но грузятся в систему моделирования. 

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

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

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

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

==Сергей Мартыненко. Варианты управления требованиями==

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

Начало было про CMMI. Там есть второй уровень, на нем управление требованиями, и для начала - целевой. А только на третьем уровне - разработка.
* 2 уровень, требование - учимся понимать, какие вещи делать правильно.
* 3 уровень - учимся правильно делать.
Если пошли сразу на 3 уровень - мы правильно делаем неправильные вещи :)

Аналитик должен набрать больше требований, чем может сделать команда. Для того, чтобы при планировании можно было отсеять неважное и ненужное. Потому что как правило аналитик обнаружит требования в пропорции: 1 нужное, 1 бантик и 2 вредных. Чтобы выбрать 5 нужных или хотя бы не вредных, надо выявить куда больше требований.

Отвратительные способы выбора требований в релиз.
* Кто громче крикнет (внутренний заказчик)
* Кто самый занудный
* Hippo - мнение человека, получающего самую большую зарплату. Требование директора раньше требований аналитика.

Плохие методы.
* Срочность. Квадрант Важность-Срочность. Важно + Срочно = Пожар. А Работа - Важно и НЕ срочно, там 80% надо быть. НЕ важно + НЕ срочно - мусор, НЕ важно + срочно - Спешка. Если попросишь заказчика написать приоритет - будешь заниматься срочными задачами всю жизнь. В жизни Срочные должны быть, но немного.
* Еще хуже, чем срочность - Управление по диаграмме Ганта для отдельных задач, назначаемых конкретному разработчику. Потому что сроки малых задач неопределенны.
 
Далее было о правильных способах. 

* Управление двухуровневое.
** Отбор фич в релиз
** Выбор задач в работу внутри релиза в работу.
* Выбор в разработку внутри релиза.
** Самый простой. Задачи в релизе должны быть поделены на must и want. Сначала берем must, затем want.
** Более сложный - по квадранту: Ясность - Критичность. Сначала Критичные Неясные, потом Критичные Ясные, потом Некритичные Ясные. Смысл в том, что после разборок с неясными ты можешь оценивать сроки. Чтобы участок неопределенности пройти раньше.
** Если задачи еще оценены по трудоемкости, и/или есть зависимость, то начинать надо с тех, что образуют наиболее длинную критическую цепью. или просто с самых больших - внутри описанных выше подходов.
* Выбор задач в релиз. Здесь гораздо больше искусства. Есть теоретический способ - value/cost и по убыванию. Но, если cost еще можно оценить, то числовой value практически невозможно вытащить из заказчика. А еще фичи зависят, последовательность влияет на cost. И часть задач имеет жесткие календарным сроки требуемой готовности. Так что тут формализма нет. Выбрать релиз из пула 300 фич от 15 заказчиков вместе - искусство.
 
Что касается разработчика, то очень важно, чтобы очередь была задана правилами. Тогда разработчика не дергают, и это - важно.

==Ирина Векленко. Мастер-класс Анализируй это: Жизнь как Проект==

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

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

==Михаил Мочалoв. Подготовка молодых кадров на должность системного аналитика==

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

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

Тут я пошел посмотреть другие потоки, потому что в целом структуру понял, а детали организации смогу посмотреть в записи.

==Дмитрий Безуглый и Виктория Преображенская. Мастер-класс Использование творческих методов в групповой работе==

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

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

==Денис Казика. Внедрение ITIL/ITSM==

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

==Алексей Попов. Все гениальное просто. Лучшие практики в разработке ПО==

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

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

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

[[Category:Отчеты о Событиях Сообщества]]