ЛАФ-2010

Ссылки сюда (1) →

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

Ссылки:

• Сайт конференции conf.uml2.ru
• Группа в google LAF_2010
• Фото Насти Григораш

Конференция удалась. В субботу на докладах, было 83 человека, на воскресенье осталось около 40. География - достаточно широкая, кроме Москвы Питера и Иваново - Минск, Рязань, Самара, Краснодар и другие. Люди активно слушают, интересуются, реагируют. Ночевка и воскресенье были в пансионате (типа Акварели), тем не менее, поднявшись и искупавшись люди активно участвовали в круглых столах, менялись опытом и проблемами.

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

Шла интернет-трансляция, обещана публикация презентаций и видео докладов.

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

Мой доклад — Диаграммы планов счетов

Аннотация

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

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

Ирина Сурова - Ведение требований на несколько версий продукта

Аннотация

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

Григорий Печенкин - Жизнь замечательных ТЗ

Аннтотация

Стиль доклада - набор историй. Есть теоретически правильный процесс со своими этапами (сформулированный в водопаде, но современные методики его не отрицают, просто делают короче). А есть отклонения от него, например, когда ТЗ неожиданно утверждается через пару лет, когда авторы уже все забыли, или когда его пишут после тестирования для сдачи, ну и другие. Для меня - понятно, что в жизни бывает всякое, и это не должно приносить особый дискомфорт, просто рабочие моменты, поэтому я в целом воспринимал без откровений и темп подачи информации для меня был низковат...

Еще была достаточно известная (мне) мысль, что ГОСТ - его писали умные люди, следовать ему буквально, конечно, не стоит, однако прочитать и размышлять над ним - полезно. Я в целом согласен.

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

Юра Веденин - Как написать хорошее коммерческое предложение

Аннотация

Аутсорсерная компаний из Минска. У пары представителей оттуда - забавные визитки, на месте должности - Умный аналитик (Юра) и Хитрый аналитик ().

Доклад был по шагам от практика, как писать коммерческое предложение. В какие места и каким образом упаковывать неопределенности, которые нельзя показывать заказчику. Где надо быть кратким и избегать многословия, не забывая. при этом. отметить существенные и важные моменты. Например. в разделе оговорок по условиям - оценивать стоимость и писать только то, что ее изменит в 1.5-2 раза, а те, у которых влияние 10% - не писать.

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

Юлия Нечаева - Тестирование требований

Аннотация

Компания Web-разработки, 50 человек, из них 35 - основной состав.

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

Доклад сильно портил пример, спертый, наверное, в какой-то книге о том как владелец программисткой фирмы обнаружил, что сотрудники кучу времени сидят в кофейне напротив и решил бороться с этим, установив кофемат на работе :) С моей точки зрения - управленчески сильно непонятный и надуманный, я не мог воспринимать его как модельный пример (как не могу воспринимать пример, в котором рыба сидит на дереве).

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

В их компании тестирование требований реализуется на уровне инициативы отделов по низам, в бизнес-процесс - не встроено.

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

Александр Байкин - Свой среди чужих

Аннотация

Рассказ про работу аналитика в in-house разработке. Что в этом случае тоже надо вести проект и постановки правильно, а не парой программист-пользователь. Хотя есть тенденция срезать много углов, потому что продавать же никто не собирается. А еще постановки тут часто изменяются. В целом нам (мне) это хорошо знакомо по наблюдениям за жизнью СМ и понятно, а темп доклада был относительно неторопливым - поэтому я больше слушал Юлию про тестирование требований.

Корнипаев Андрей - Управление командой аналитиков

Аннотация

Автор сейчас работает в reqs.ru, но рассказ - про более раннее время, когда он работал в Ренесанс-капитал и руководил командой из 15 аналитиков. Разработка при этом частично была внутри команды, а частично - вынесена на аутсорсинг, для которого они тоже писали требования. Основная проблема, которую решали - наведение порядка в темпе реализации, обеспечение предсказуемости по скорости разработки. Стиль доклада - больше истории из жизни.

Мартыненко Сергей - Написание тестов, как вид тестирования требований

Аннотация не слишком внятная, зато очень внятный докладчик.

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

О тестировании требований - это надо делать. Есть формальные методики, есть нормы. Если написание требований - 3 страницы в день (14 кеглем, 30 строк по 60 символов), то рецензирование (а это и есть проверка) - 5 страниц в час. И все это надо закладывать в трудоемкость. Нормы рецензирования - высокие, поэтому начинать правильно с простых проверок. Как то: русский язык, наличие how-to-demo, полнота объект-действие (любой объект можно изменить и удалить, и описано как оно происходит), полнота объект-действие (указаны роли). А дальше - более сложное, например, противоречивость. Из примеров - "поиск союза И": ищем его в требованиях, делим по нему на два и сравниваем - они часто получаются противоречащими, например, "интуитивно-понятный и быстрый интерфейс".

Вторая часть - как формулировать задание на проект.

Первый вопрос - о цели, которую надо спрашивать так: "Как Вы (заказчик) узнаете, что проект успешен?"

Второй вопрос: "Кто, Кому и Как будет сдавать проект".

Третье - собственно снятие требований. Которые надо формулировать как ответ на вопрос "Как можно (мы будем должны) доказать, что программа делает то, что от нее хочет заказчик" (how-to-demo). По-сути, это ПМИ (программа методика испытаний), с которой правильно начинать требования и, если она написана хорошо, то больше ничего особенного не потребуется. ПМИ должно касаться и нефункциональных требований (например: интуитивно-понятный интерфейс - 7 из 10 операционисток после 5-минутного инструктажа могут выполнить задание в новой системе; эффективный интерфейс - 2 операционистки после недельной тренировки достигают таких-то показателей по исполнению операций).

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

Было интересное замечание про эффективность работы при совместительстве: если мощность на одном проекте - 100, то на двух - 40+40, а на трех - 20+20+20. Похоже на правду.

В целом докладчик, и доклад очень понравились, жаль, что слушал не сначала.

Левенец Ирина - Бесконтактное обследование

Аннотация

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

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

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

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

Безуглый Дмитрий - Сценарное планирование

Аннотация - сильно невнятная. В докладе я услышал несколько блоков мыслей.

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

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

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

В целом эти три вида сценариев (бизнес-сценарии, сценарии использования и архитектурные сценарии) определяют каркас системы.

Примерно так, по моим записям... Но я слушал доклад не полностью.

Булуй Юрий - Инженерия требований на практике

Аннтотация

Докладчик - project manager в HP в Москве. Они не занимаются разработкой, а внедряют готовые крупные решения от HP под бизнес-заказчика. Под это дело у HP разработана своя методика - HP Global method для IT Solution, о которой он и рассказывал, в преломлении к практическому опыту применения.

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

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

Иванов Денис - Моделирование на UML2

Аннотация-1 Аннотация-2

Два доклада, из них один двойного объема (то есть всего - три!) читал автор книги Моделирование на UML2, которую я привез с выставки. На первом докладе я не был, так как он пересекался с интересным докладом про дистанционное обследование и внедрение, а на второй - пошел.

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

Дальше пошел пример - hello world :) Очень постепенно, подробно и мелко, причем не интерактив, а готовые экраны в презентации. Послушав некоторое время, я все-таки не выдержал и ушел. Так что мое мнение о бесперспективности UML как языка моделирования. равно как и других аналогичных средств - не изменилось.

Белин Александр - Практика работы с требованиями в иностранной компании

Аннотация

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

Бредюк Константин - Специфика управления требованиями при разработке корпоративных коробочных решений

Аннотация

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

Основная идея - аналитик должен становится маркетологом. Ну, или project manager должен становится маркетологом (у них 8 аналитиков, направление действий определяет PM). Идеи, что маркетологи где-то сбоку, формируют заказ или наоборот проводят исследования по заданиям - поддержки не нашла. Детали про способы исследований. в частности как избежать "среднего" решения, которое окажется никому не нужным - тоже не прозвучали.

Вечер первого дня

Была большая тусовка (человек 40), шашлык, вино и прочее. При этом шел дождь, поэтому все было очень компактно, на крытой веранде, с активным общением. Хотя профессиональные темы звучали не очень - за день все-таки устали. Поэтому воспроизвести - не могу. Зато, ближе к концу, весьма активно играли в крокодила - поскольку компания новая и сильно разная, получалось интересно.

Круглый стол - Требования к аналитикам

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

Плакаты с обсуждения можно посмотреть здесь.

По требованиям я для себя ничего особо нового не услышал - вполне понятный спектр. Помимо понимания бизнеса, аналитических и технологических навыков много говорили про навыки вне профессиональной квалификации - коммуникативные и управленческие. Схемы - из внешних учебников (упоминались Swebok, Вигерс, Кокберн "Usecase 10 лет спустя"), это не креатив, а вот слова - из опыта. С моей точки зрения, схемы надо рисовать несколько по-другому, и, возможно, я еще напишу об этом в блоге. Я готов прокомментировать плакаты на слайдах, если эта тема кого-то интересует.

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

Мастер-класс - Снятие требований

Сергей Мартыненко провел очень интересный мастер-класс по снятию требований. Он играл две роли: Инструктора (учителя) и Заказчика, переключаясь между ними.

Модельным примером была система bug tracking как знакомая всем область. При этом вводная была следующая: у Заказчика есть bugzilla, она его не устраивает потому что... и он хочет чего-то другого. Быстро сошлись, что свое писать не будем, а будем настраивать одно из готовых решений. но проект - не только решение, но и настройки, а также регламент использования и программа обучения для новичков.

Ну и на это снимали требования. Формат такой: Сергей сначала рассказал оглавление в целом (с объяснениями), потом по очередной части формулировал, что там должно быть и переключался в роль Заказчика. А участники - коллективно или индивидуально писали эту часть. Потом Сергей с ними обсуждал результат, фиксировалось общее решение и шли дальше. Про каждую часть договаривались, кто из участников оформит для uml2.ru, так что там должно появиться.

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

От имени Заказчика Сергей рассказал, как происходит выбор задач для исполнения. Есть две координаты: уверенность (разброс) оценок и критичность для релиза. Сначала берут неизвестные-критичные, потом - известные-критичные, потом - не критичные-известные, потом - не критичные-неизвестные. В общем, эту схему я где-то видел, но рассказано вполне интересно. Еще для каждой задачи дают две оценки: менеджер и программист, независимо и в диапазоне, который и показывает уверенность - 8-12 или 2-30 - большая разница, хотя сведенные к одной цифре обе могут дать 12.

О визитках

И в заключении - еще одна мысль.

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