2014-05-25: AnalystDays-2014 - ожидаемо высокий уровень
м |
м (→Ирина Сурова. ЗАО «Лаборатория Касперского». Шаблоны трассировок бизнес-требований на больших кросс-проектных продуктах) |
||
Строка 86: | Строка 86: | ||
Инструментом Управления требованиями у них является TFS. Не потому, что он лучший, а потому, что он принят в компании как общая система ведения дел и поддержки разработки — ведения кодовой базы, поддержки интеграции. Поэтому использование его для управления требованиями — логично. Но при этом сами требования, содержательно — ведутся в другом инструменте, Enterprise Architect. Это было принять еще до внедрения TFS, но отказываться они от EA не собираются — Ира перечисляла, что именно в TFS их не устраивает по ведению требований. Основные претензии — к версионированию и нормальной выгрузке в word-документы. Если бы для WorkItem была такая же поддержка версий, как для кода — проблем бы не было, выгрузку, думаю, они бы допилили. Но этого нет, и содержание требование остается в EA. | Инструментом Управления требованиями у них является TFS. Не потому, что он лучший, а потому, что он принят в компании как общая система ведения дел и поддержки разработки — ведения кодовой базы, поддержки интеграции. Поэтому использование его для управления требованиями — логично. Но при этом сами требования, содержательно — ведутся в другом инструменте, Enterprise Architect. Это было принять еще до внедрения TFS, но отказываться они от EA не собираются — Ира перечисляла, что именно в TFS их не устраивает по ведению требований. Основные претензии — к версионированию и нормальной выгрузке в word-документы. Если бы для WorkItem была такая же поддержка версий, как для кода — проблем бы не было, выгрузку, думаю, они бы допилили. Но этого нет, и содержание требование остается в EA. | ||
− | И у них наработались шаблоны, применяемые на многих проектах. Если кратко, то устроено оно так. Все начинается от бизнес-требований, которые фиксируются в TFS и представляют собой некоторое требование уровня бизнеса, некоторая фича. Которая попадает к системным аналитикам в EA и они ее декомпозируют на | + | И у них наработались шаблоны, применяемые на многих проектах. Если кратко, то устроено оно так. Все начинается от бизнес-требований, которые фиксируются в TFS и представляют собой некоторое требование уровня бизнеса, некоторая фича. Которая попадает к системным аналитикам в EA и они ее декомпозируют на системные требования. Системные требования попадают назад в TFS как подчиненные, для этого налажена синхронизация. А еще по ним из EA можно выгрузить содержательный документ. |
− | Производится маппинг требуемых изменений на компоненты, и далее | + | Производится маппинг требуемых изменений на компоненты, и далее, независимо от декомпозиции на системные требования, бизнес-требование делится на change request к компонентам. При этом связь системных требований и change request тоже присутствует. По change request в командах, отвечающих за компоненты, с учетом описания системных требований, делается оценка. При этом могут порождаться подчиненные change request к библиотечным компонентам и инфраструктуре. С запросами к инфраструктуре — отдельная ветка, потому что там около 150 сервисов, и команды не очень представляют внутреннее устройство. Поэтому была сделана «служба единого окна», маршрутизирующая change request к инфраструктуре. |
− | Отдельная ветка контроля — учет в релизах требований, исходящие из позиционирования продукта Касперского, такие как «топ-3 по детектированию вирусов». Или требований от юристов. Для поддержки таких требований все продукты должны обладать определенными фичами, и их реализация должна быть вставлена в релизы. | + | Отдельная ветка контроля — учет в релизах требований, исходящие из позиционирования продукта Касперского, такие как «топ-3 по детектированию вирусов». Или требований от юристов. Для поддержки таких требований все продукты должны обладать определенными фичами, заключающимися в исполнении бизнес-требований, и их реализация должна быть вставлена в релизы. |
− | После получения совокупности оценок и с их учетом происходит планирование релиза. А потом, по этой же структуре — контролируется ход работ. При этом, естественно, работы декомпозируются на отдельные задачи, которые выполняются. И добавляются тест кейсы. Получается трассировка полного цикла. Что касается изменения требований в ходе работ, что структура верхнего уровня, сформированная при оценки, меняется редко — потому что она верхнеуровневая. А вот содержание | + | После получения совокупности оценок и с их учетом происходит планирование релиза. А потом, по этой же структуре — контролируется ход работ. При этом, естественно, работы декомпозируются на отдельные задачи, которые выполняются. И добавляются тест кейсы. Получается трассировка полного цикла. Что касается изменения требований в ходе работ, что структура верхнего уровня, сформированная при оценки, меняется редко — потому что она верхнеуровневая. А вот содержание системных требований изменяется, EA это поддерживает, и влечет изменение декомпозиции на задачи. |
Вокруг TFS накручены | Вокруг TFS накручены | ||
Строка 100: | Строка 100: | ||
* роботы: проходят по всем требованиям и пушат «берете-не берете». Пишут PM’ы | * роботы: проходят по всем требованиям и пушат «берете-не берете». Пишут PM’ы | ||
− | После доклада был интересный вопрос про унификацию требований. Ответ: для целей управления требованиями это не важно, достаточно | + | После доклада был интересный вопрос про унификацию требований. Ответ: для целей управления требованиями это не важно, достаточно, чтобы скоуп проекта был суммой соответствующих item’ов независимо от формы, и совпадал смысл ключевых статусов прохождения. |
== Антон Семенченко. ISSoft / CoherentSolutions. BDD or DSL как способ построения коммуникации на проекте — опыт комплексного внедрения == | == Антон Семенченко. ISSoft / CoherentSolutions. BDD or DSL как способ построения коммуникации на проекте — опыт комплексного внедрения == |
Версия 16:12, 26 мая 2014
В субботу 24.05 был на конференции AnalystDays-2014 в Москве. Уровень конференции был выше предыдущей, и она собрала больше участников, неожиданно даже для организаторов — около 500 человек. А для аналитиков это много, потому что их не так много в современном ИТ. Web-разработка и разработка небольших проектов обходится без них, функции проектирования выполняют квалифицированные разработчики или дизайнеры интерфейсов. И в некоторых докладах приводили примеры, что спрашивая на форуме об организации процесса «кто должен проектировать интерфейсы» — аналитиков даже не упоминают — про такую специализацию вопрошающий не знает :)
Впрочем, в enterprise-разработке и в больших высокотехнологичных продуктах аналитики востребованы. Правда, там есть другой тренд и о нем тоже говорили на конференции — это все большая потребность в эргономичных интерфейсах enterprise-приложений. Если раньше на это было наплевать совсем, то сейчас положение изменяется. Так что не исключено, что и там аналитиков потеснят UX-специалисты :)
Правда, это может произойти и неожиданным образом (этого на конференции я не слышал, тут мое мнение): в Штатах enterprise все больше уходит на облачные платформы — и в банках и в корпорациях. В банках этому еще способствует требование регулятора на наличие двух географически разнесенных data-центров. А еще таким радикальным способом они решают проблемы исторически накопившегося зоопарка в своем ИТ-ландшафте, переходя от 50-100 приложений к 2-3. При этом становятся востребованными разработчики и аналитики, владеющие не столько предметной областью, сколько конкретной платформой — для проектирования кастомизации этих приложений в точках расширения и подключения оригинальных приложений, в которых содержится know-how конкретных предприятий. А вот UX там будет в объеме, предоставленном платформой.
Но вернемся к конференции. Как я отмечал, уровень докладов по сравнению с предыдущими годами повысился. И хотя это не было для меня большой неожиданностью — работая в ПК я был знаком с будущими докладами и представлял их уровень, все-таки реально качество выясняется, когда доклад слушаешь, потому что насколько автор хорошо рассказывает свой доклад, представить заранее трудно. Я знаю, что ряд конференций при подготовке докладчиков устраивают предварительные прогоны, но у нас на это, увы, не хватает ресурсов. А за доклады опытных и ранее зарекомендовавших себя докладчиков особо не беспокоишься, а на конференции качество содержания может стать приятным сюрпризом. Потому что качественный доклад по сложному контенту сделать непросто независимо от опыта, и априорных гарантий, что получится — тоже нет. И такие сюрпризы на конференции для меня были.
Многие участники сожалели, что конференция была короткая, однодневная. Тут я хочу сказать, что на двухдневную конференцию качественных докладов из числа поданных, все-таки, не нашлось бы. Не очень хотят аналитики делиться своим опытом, в отличие, например, от тестировщиков. Может потому, что сильно устают от подготовки всяких презентаций по основной деятельности, может у них слишком завышенные внутренние критерии качества. Но все-таки я призываю подумать — вам наверняка есть что рассказать. Кстати, если есть желание, но Вы не уверены — пишите мне или другим членам программного комитета — мы вместе попробуем найти тему и сформировать содержание доклада. Кстати, отмечу, что три лучших доклада по мнению участников конференции были сделаны новыми авторами, которые выступали впервые.
Перед обзором докладов — пара слов про организацию конференции. Она проходила в Измайлово, и по сравнению с Инфопространством там не хватало пространства для общения участников рядом с залами. Ну и сами залы были маловаты для такого числа участников, на многих докладах люди стояли — но это организаторы недооценили число участников. А в целом — организация на высоком уровне, что? впрочем, традиционно для серии конференций Влада Орликова (SQAdays, ADD, SPMconf, AnalystDays). После конференции был afterparty, где настоящей находкой был струнный квартет классической музыки — с одной стороны, музыка есть и хорошего качества, а с другой — она не мешает разговаривать и общаться, что, собственно, и является основной целью участия в afterparty для многих.
А теперь — обзор докладов. Сразу хочу оговориться, что он сильно неполон, на конференции было три параллельных трека, и мой выбор определялся тем, как содержание доклада соотносится с областью моей профессиональной деятельности. И все равно иногда приходилось выбирать между интересными докладами, идущими параллельно. С Вашей точки выбор может быть другим, так что не ограничивайтесь моим обзором. Тем более, что по всем докладам скоро появятся презентации, в течении месяца-двух — видео.
Содержание
- 1 Мой доклад
- 2 Лучшие доклады по выбору участников
- 3 Что мне особенно понравилось
- 3.1 Быченков Константин. ООО «Открытый код». Аналитик — первый помощник «большого босса»
- 3.2 Ирина Сурова. ЗАО «Лаборатория Касперского». Шаблоны трассировок бизнес-требований на больших кросс-проектных продуктах
- 3.3 Антон Семенченко. ISSoft / CoherentSolutions. BDD or DSL как способ построения коммуникации на проекте — опыт комплексного внедрения
- 4 Просто хорошие доклады
- 4.1 Григорий Печенкин. Colvir Software Solutions. Горе от системного ума
- 4.2 Анна Абрамова. ЗАО "НИПК «Электрон». Формирование и согласование структуры требований
- 4.3 Ольга Павлова. «Собака Павлова». Аналитические навыки менеджера по работе с заказчиком: как и зачем?
- 4.4 Dmitry Bezuglyy. ООО «Системный Подход». Переосмысление роли Аналитика
- 4.5 Вадим Мустяца. Deeplace. BDD и спецификации эпохи постиндустриализма
- 4.6 Надежда Тарасюк. R-Style Lab. О чем молчит стейкхолдер
Мой доклад
Из твиттера Максим Цепков на #analystdays рассказывает о Domain Driven Development как Николай Дроздов :) Не очень понятно, но слушать приятно :))) - Alexander Attsik
Начну я со своего доклада, не потому что он лучший, а потому что обзор — мой. И тут будет не оценка, а рефлексивная аннотация. Я рассказывал про метод Domain-Driven Design — о том, как модель на едином языке заменяет традиционные требования, с примерами построения и модели и единого языка для проекта и фреймом модели для корпоративных приложений, разработанном у нас в компании.
Это не первый мой доклад на эту тему, и содержание не является полностью новой. Но с каждым докладом добавляются какие-то новые мысли и конструкции, а изложение общего материала становится более коротким и обзорным, чтобы слушатели узнали идею в целом и смогли для себя решить — стоит ли им знакомиться подробнее. В этот раз новым были варианты разделения ответственности между аналитиком и разработчиком в разных проектах и позиционирование проектирования по моделям в этих вариантах, а также тема разделения контекстов в DDD. Возможно, это в будущем вырастет в полноценный доклад, а пока был первый подход.
А если говорить про метод DDD в целом, то у нее есть вторая часть — о прозрачном отображении модели в код. Наиболее простой вариант, с использованием Domain Model и Rich Objects, имеет свои недостатки, которые мы преодолеваем с помощью так называемых технологических рельсов. Об этом я в докладе не говорил совсем, обычно я рассказываю это на разработческих конференциях, последний раз на SECON, но, возможно, стоит сделать об этом доклад, представив материал с точки зрения аналитика.
Доклад на моем сайте http://mtsepkov.org/DDD-req-AnalystDays-2014, а здесь http://mtsepkov.org/Category:DDD - все мои доклады про DDD.
Лучшие доклады по выбору участников
В этом разделе — о трех докладах, которые участниками были признаны лучшими. Авторы получили ценные призы, за первое место был робот-пылесос.
Юлия Ерина. i-Sys. Клинический случай в коммуникациях с заказчиком
Первое место. Любопытный доклад про сравнение аналогичных по функционалу проектов, отличающихся подходом Заказчиков: в первом был «раздолбай», а второй — «формалист», любил вникать в детали и мелочи. И это различие очень сильно сказалось на ходе обоих проектов, оно существенно влияет на риски, и для успешного продвижения необходимо применять существенно разные приемы.
Юлия сказала, что это — достаточно типичные случаи и большинство заказчиков относится к одной из этих категорий, поэтому здесь изложена достаточно общий подход. Но при этом изложен на конкретных примерах, что делает его гораздо более выпуклым.
Отмечу, что «клинический случай» в названии идет из метафоры врач-пациент: Заказчик пришел к Вам как пациент к врачу, за решением проблем. И ваша задача — помочь, а не стать пациентом самому. Поэтому при общении с первым типом — помните, кто из вас врач, не разрешайте себя лечить. А со вторыми — не принимайте к себе критику, помните, что у пациента — есть право на истерику, а истерика у Вас — не уместна.
Интересно отметить, что в целом проект с заказчиком-раздолбаем был гораздо более успешным и по соблюдению сроков и бюджета, и по темпам дальнейшего развития. Так что мелочный интерес заказчика и стремление к тотальному контролю играет против него самого.
Артём Митропольский. Digital Design. Уязвимости мышления
Второе место. Артем делал доклад рассказывал не тему, которая, казалось бы, не относится к аналитике непосредственно, но реально очень важна для построения коммуникаций. Речь идет о тех уязвимостях, которые имеет наше мышление и которые срабатывают, если на них не обращать специального внимания. О том, что формулировка вопроса влияет на ответ и читерский вопрос дает заданное искажение. Про эффект привязки, заключающийся в том, что любая посторонняя информация, которая присутствовала в момент принятия решения — на него влияет. О том, что по умолчанию люди склонны считать свои знания репрезентативными. Про то, как включение деталек неявно повышает оценку обоснованности и надежности текста. И про фундаментальную ошибку атрибуции, которая кратко формулируется как «все уроды, а я д’Артаньян».
И многое другое, здесь перечислено далеко не все, что было в докладе, а там был рассказ лишь про часть, остальное представлено ссылками. Потому что информация, на самом деле, доступна, но вот многие ли знакомились ли с ней для того, чтобы реально применять в работе и жизни, а не просто как с любопытными исследованиями? И, я надеюсь, исходя из высокой оценки доклада, что таких людей станет больше.
Татьяна Васильева. CUSTIS. Analyst’s Guide to GUI: Проектирование интерфейсов как элемент системного анализа
Третье место. Таня — из нашей компании и мне приятна такая высокая оценка доклада. Я слушал доклад на прогоне в компании, поэтому на конференции пошел на параллельный доклад Кости Быченкова, а к Тане зашел в самом конце, увидел, что зал переполнен и люди стоят у стен, с интересом слушают и было много вопросов.
Таня рассказывала про использование проволочных диаграмм при проектировании интерфейса, и про место этого в общем процессе проектирования, уместность в разных видах проекта и преимущества, достигаемые, если аналитик включает такой способ в арсенал своих инструментов. И это была не только теория, но и реальный пример. А в конце успела рассказать про сравнение разных инструментов построения моделей интерфейса.
Что мне особенно понравилось
В этот раздел вынесены доклады, которые оказались для меня неожиданным сюрпризом, хотя их авторов я уже знал как хороших докладчиков. Они превзошли уровень моих ожиданий, выросли, и это — приятно.
Быченков Константин. ООО «Открытый код». Аналитик — первый помощник «большого босса»
Доклад о том, как маленькая компания, развиваясь, прошла этап становления орг.структуры руководителей, которые бы сняли часть обязанностей с руководителя компании. И это — в период интенсивного роста, когда компания доказала свою состоятельность и получила большое количество заказов, которые теперь надо было выполнить. Сама компания — интеграторы в региональном гос.секторе, работают со здравоохранением. Высококонкурентная среда.
Костя рассказывал не только о том, что получилось, но и о разных вариантах, которые они испробовали. В результате пришли к конструкции, когда аналитики являются руководителями и отвечают за проект перед заказчиком. Кроме бюджета, который пока у руководителя. Опасности этого варианта — перегруз аналитика и «звездная болезнь», для этого есть руководитель компании.
А были варианты с аналитиком — коммуникатором между группой с отдельным тимлидом, и вариант когда аналитик просто внутри команды. Оба работают хуже, потому что аналитик теряет мотивацию. А в первом (посредник) — еще и переходит на сторону заказчика, чрезмерно защищая его интересы.
Основной навык аналитика — вербальный, умение общаться. А остальное выстраивается потом. И из умения общаться выстраиваются люди, которые умеют принимать решения. И Аналитики у него — выстраивают общение с Заказчиком.
- Регулярное взаимодействие с Заказчиком.
- Итерационный подход к разработке, с выпуском готового продукта.
И родилась интересная метафора «Аналитик у Заказчика должен быть ангелом!»"
Что у них не получилось? Не получилось оценить работу аналитика. Не могут отстраивать. Из-за этого он вляпывается в микроменеджмент, плавают роли, все непрозрачно. И в этом есть проблемы, особенно когда надо руководству объяснить.
В целом компания успешно преодолела период роста. За руководителем остались стратегические функции, картина в целом, а аналитики подхватили остальное. При этом личный вклад — невелик. Но они входят в команду, и вместе делают новое — очень роскошно! И компания оправдывает свой слоган «Мы можем все, на что решимся».
Ирина Сурова. ЗАО «Лаборатория Касперского». Шаблоны трассировок бизнес-требований на больших кросс-проектных продуктах
Совершенно роскошный доклад Иры был в переполненном зале, и не случайно. Ирина достаточно подробно показала в своем докладе, как в Касперском управляют требованиями. Именно управляют, а не ведут их наполняя содержанием. Продукты Касперского — сложные и многокомпонентные, а сами компоненты зависят от отдельных общих библиотек и инфраструктурных служб. Например, Internet Security — это около 10 компонент с независимыми командами, и еще 15 сервисов. А релиз надо выпускать точно к сроку, жесткий time-driven development, и требуется достаточно надежно определить состав будущего релиза в этих условиях.
Релизы одного продукта могут выходить на разных платформах и в разные сроки, а еще изменения должны быть своевременно поддержаны централизованной сервисной инфраструктурой. На на аналитиках лежит задача согласования всего этого на верхнем уровне, включая трудозатраты и планирование к сроку. А еще — контроль поставки для нескольких команд. При этом команды — достаточно разнородны по процессу, каждая из них — отражения своего лидера и спектр процессов от agile-agile с кроссфункциональностью и без аналитиков до более традиционных процессов с разделением ролей и выделением аналитиков. И Ира рассказывала, как в этих условиях поставлена работа с требованиями и формирования скоупа релизов продукта и работа коллектива аналитиков, отвечающих за это. И работа не просто поставлена — надо учить новых аналитиков жить в такой разнородной среде.
Понятно, что методика у них весьма сложная — потому что сложный продукт. И рассказу предшествовал дисклеймер «Не пытайтесь повторить не думая» — уместный, в общем, для любого доклада. А Ире решить трудную задачу — изложить эту методику, достаточно отделив ее от контекста компании, без углубления в детали. Да еще — неявно показать стиль работы в Касперском — через схемки, рисуемые от руки на доске, фотки которых потому просто вставляются в соответствующие описания. Правда, для слайдов фон надо было осветлить, но, думаю, Ира в следующий раз это учтет, а не будет рисовать специальные схемы для презентации — такие схемки воспринимаются лучше.
Инструментом Управления требованиями у них является TFS. Не потому, что он лучший, а потому, что он принят в компании как общая система ведения дел и поддержки разработки — ведения кодовой базы, поддержки интеграции. Поэтому использование его для управления требованиями — логично. Но при этом сами требования, содержательно — ведутся в другом инструменте, Enterprise Architect. Это было принять еще до внедрения TFS, но отказываться они от EA не собираются — Ира перечисляла, что именно в TFS их не устраивает по ведению требований. Основные претензии — к версионированию и нормальной выгрузке в word-документы. Если бы для WorkItem была такая же поддержка версий, как для кода — проблем бы не было, выгрузку, думаю, они бы допилили. Но этого нет, и содержание требование остается в EA.
И у них наработались шаблоны, применяемые на многих проектах. Если кратко, то устроено оно так. Все начинается от бизнес-требований, которые фиксируются в TFS и представляют собой некоторое требование уровня бизнеса, некоторая фича. Которая попадает к системным аналитикам в EA и они ее декомпозируют на системные требования. Системные требования попадают назад в TFS как подчиненные, для этого налажена синхронизация. А еще по ним из EA можно выгрузить содержательный документ.
Производится маппинг требуемых изменений на компоненты, и далее, независимо от декомпозиции на системные требования, бизнес-требование делится на change request к компонентам. При этом связь системных требований и change request тоже присутствует. По change request в командах, отвечающих за компоненты, с учетом описания системных требований, делается оценка. При этом могут порождаться подчиненные change request к библиотечным компонентам и инфраструктуре. С запросами к инфраструктуре — отдельная ветка, потому что там около 150 сервисов, и команды не очень представляют внутреннее устройство. Поэтому была сделана «служба единого окна», маршрутизирующая change request к инфраструктуре.
Отдельная ветка контроля — учет в релизах требований, исходящие из позиционирования продукта Касперского, такие как «топ-3 по детектированию вирусов». Или требований от юристов. Для поддержки таких требований все продукты должны обладать определенными фичами, заключающимися в исполнении бизнес-требований, и их реализация должна быть вставлена в релизы.
После получения совокупности оценок и с их учетом происходит планирование релиза. А потом, по этой же структуре — контролируется ход работ. При этом, естественно, работы декомпозируются на отдельные задачи, которые выполняются. И добавляются тест кейсы. Получается трассировка полного цикла. Что касается изменения требований в ходе работ, что структура верхнего уровня, сформированная при оценки, меняется редко — потому что она верхнеуровневая. А вот содержание системных требований изменяется, EA это поддерживает, и влечет изменение декомпозиции на задачи.
Вокруг TFS накручены
- плагин с автозаполнением полей по умолчанию
- кликабельные отчеты
- нотификации по понедельникам
- роботы: проходят по всем требованиям и пушат «берете-не берете». Пишут PM’ы
После доклада был интересный вопрос про унификацию требований. Ответ: для целей управления требованиями это не важно, достаточно, чтобы скоуп проекта был суммой соответствующих item’ов независимо от формы, и совпадал смысл ключевых статусов прохождения.
Антон Семенченко. ISSoft / CoherentSolutions. BDD or DSL как способ построения коммуникации на проекте — опыт комплексного внедрения
Очень интересный для меня доклад о применении DSL, иллюстрированный практическим опытом.
Сначала про кейс. Была система печати рекламных листовок, inhouse разработка в одной американской фирме, занимающей солидную долю этого рынка, которую 20 лет писал один разработчик. И вот он ушел, а система осталась и с ней надо что-то делать. А документации нет, есть устная традиция, при чем все подробности знает только топ — а он жутко занят другими делами. От проекта все отказались — и он попал к ним.
Первая, традиционная попытка получить требования обычным способом кончилась не очень удачно. хотя заказчика результат устроил и они санкционировали продолжение проекта. И на втором этапе они подошли нестандартным способом, а именно, выделили пару ключевых мест и для них сделали модель и DSL, который его конфигурировал.
- Как проводятся акции, срок, ценовое поведение, еще что-то. И тут этого мало, и можно описать на формальном языке.
- Нюансы печати. Один — хочет видеть дугообразный верх. Где-то ложки сверху, слева и прочее.
Штука в том, что в обоих случаях для построения DSL со всеми нюансами не нужен топ, достаточно узкого специалиста, занимающегося конкретно этими вопросами. И этот dsl — дает сразу и модель. А еще dsl такого уровня понимает заказчик.
А дальше наличие этих двух частных моделей позволило связать все в единое целое и фактически реализовать систему заново. Да еще сразу предложить бизнес-профит — dsl для конфигурации конечного принтера, что позволило децентрализовать печать и сократить издержки на доставку. Старая система на это рассчитана не была, а добавить — никто не брался.
Если же говорить об общем подходе, то он заключается в следующем. Когда мы строим некоторую модель, то мы сразу разрабатываем DSL для ее конфигурирования. И после реализации это позволяет покрывать систему тестами, используя BDD. И это фишка. А еще dsl дает способ коммуникации и с заказчиком и с разработчиками, и вот это — реально важно, потому что снимает риск неверного понимания задачи. А этот риск — основной.
При этом процесс — итерационный. БА поговорил первый раз сделал первую модель, дальше к ней dsl — и повторили цикл. И это позволяет структурировать реализацию бизнес-логики со всеми нюансами. Потому что нет ничего более нелогичного, чем бизнес-логика.
И тоже самое можно делать при реализации простого API к сложной библиотеки, или простого необходимого подмножества сложного протокола — делаешь обертку как DSL, получаешь тестирование и контролируемое развитие.
DSL они обычно используют текстовый, на основе простых файлов. Подсветку синтаксиса сделать легко, библиотек парсинга и кодогенерации — громадное количество. И потому это — дешево. Модель-то все равно делают и реализуют. И если с самого начала рассчитывать на DSL, то накладные расходы — процентов 10.
Просто хорошие доклады
по этим докладам у меня вау-эффекта не было, и про некоторые я могу сказать, что они могли бы быть лучше. Тем не менее, уровень их — высокий, и «хорошие» в названии раздела — не просто политкорректная формулировка.
Григорий Печенкин. Colvir Software Solutions. Горе от системного ума
В докладе были довольно философские размышления о тренде развитии отрасли, и о месте аналитика в ней, исходя из этих трендов. Там было много конкретных кейсов и примеров (местами, на мой взгляд, устаревших, но это не страшно — они иллюстрировали мысль докладчика, а больше от примера не требуется). С моей точки зрения, не хватало систематичности в представлении трендов и кейсов, но, с другой стороны, может быть в таком виде и лучше: тебе представлена картина мира, в которой ты должен самоопределиться сам, а более систематичное изложение может подтолкнуть тебя на конкретный путь.
А пока — мои заметки о представленной картине.
- Многие в отрасли не знают кто такие аналитики. Разработка сайтов и обходятся без них. Аналитики только в enterprise, а доля этого сегмента сокращается.
- Классическая программа аналитиков — требования, usecase и прочее — устарела.
- Определение Автоматизированной системы из ГОСТ. Мы автоматизируем функции, люди — часть автоматизированной системы. И как следствие перекос в функциональное мышление. Пример — сайт гос.услуг. Функции — и непонятно куда придти. Наконец проходим — и обнаруживаем, что услуга не оказывается.
- В современном мире конкуренция смещается от функций к usability. До enterprise это пока не дошло, но уже доходит.
- Классическая модель излишне идеалистична. SRS — список из 8 требований к usecase. Полнота модели и прочее. Так не бывает. В современном мире, в agile разработке Leffingwell формулирует что «User Story не является требованием» — в старом смысле, с теми критериями, что Agile.
Анна Абрамова. ЗАО "НИПК «Электрон». Формирование и согласование структуры требований
Аня неоднократно оказывалась в ситуации, когда аналитика зовут в уже разогнанный проект, который до этого велся разработчиками без аналитика, начало сбоить — и руководство зовет аналитика, чтобы с этим разобраться. И она делилась своим опытом, как в этих ситуациях организовать, структурировать функциональные требования, получаемые отчасти реинжинирингом, отчасти — из коммуникаций. У нее сложилась такая структура, которую она использует для проектов в качестве начальной, и в своем докладе она решила ей поделиться. Опыт был на разных проектах, а сейчас у нее сложные проекты, связанные с медицинским софтом, там и изменение требований, которое решается через версионирование.
Кстати, отмечу, что вопрос «как вы работаете с изменением требований» был одним из самых популярных на конференции. Общий ответ был «нормально работаем», с пояснением деталей.
В целом содержание доклада — хорошее, но Ане хочется пожелать большей внутренней уверенности в своем опыте — чтобы снять и волнение, которое местами мешало изложению, и, что важнее, помогало более артикулировано и уверенно обозначать свою позицию, не очень оглядываясь на ее соответствие «правилам». А еще — фонт в презентации надо крупнее.
А саму структуру требований я тут излагать не буду, смотрите презентацию и сам доклад. Она вполне рациональна, и, думаю, может быть успешно использована в качестве начального шаблона, если у Вас еще не сложилось своего. Важно только помнить (и об этом было в докладе), что структура требований — она не только для аналитиков. В ней есть заинтересованность у многих действующих лиц — руководители, разработчики, тестировщики… А еще структуру требований стоит описать, а не рассчитывать, что ее читатель поймет по документу, и расшифровать термины «не для аналитиков».
Ольга Павлова. «Собака Павлова». Аналитические навыки менеджера по работе с заказчиком: как и зачем?
Задача всех докладов Ольги — пробудить у людей осознанность в своей работе. Темы осознанности, естественно, различаются. А стиль подачи — достаточно жесткий. Одних он раздражает, но до других — доходит и они изменяются. И этот доклад не был исключением. Я слушал кусочек, потому что параллельно шел мастер-класс Димы Безуглого и там тоже было интересно. Так что пересказывать не буду, приведу (неполный) список приемов, которые я записал в конце. Может, он побудит посмотреть доклад.
- Диктофон — реально запись дает чувство собственной значимости
- Доступность документов. Не вам, а заказчику.
- Рефлексивно упоминать документы — чтобы заказчик почувствовал важность
- Коротко ясно и по-русски.
- Рисовать картинки и схемы
- Игрушка, но легкая
- Не просите написать документ, присылайте черновик — порог чистого листа
- Демонстрируйте интерес.
Да. приемы — не однозначны, у них есть отрицательный эффект и применять надо разумно думая. Собственно, это и есть осознанность.
Dmitry Bezuglyy. ООО «Системный Подход». Переосмысление роли Аналитика
Областей, где работает один умненький, он написал, и все сделали — становится меньше. Правда, так и не было, но делали вид, что так работает. Во многих компаниях аналитик не нужен.
Суть value stream mapping: картируем процесс, а потом убираем мусор. При проведении этого процесса в компании можно выяснить дофига интересного. Например, выяснилось, что в одной компании разные люди (в руководстве) несколько лет по-разному понимали аббревиатуру СА: Системный архитектор или системный аналитик. Отдел СА считал, что они — архитекторы, требования — это не к ним. А отдел БА считал, что раз они бизнес-аналитики, то СА — системные аналитики, и требования — это к ним.
А после такого вступления был обобщенный value stream mapping про роль аналитика. Обобщенный — потому что у участников, естественно, нет единого процесса. Но в этом я не мог участвовать, так как у меня был свой доклад. Надеюсь, прочту о результатах в чужих отзывах.
Вадим Мустяца. Deeplace. BDD и спецификации эпохи постиндустриализма
У Вадима был вдохновляющий рассказ про проект для Нацбанка Молдовы, в котором целью было принципиально изменить структуру подачи материала на сайте, и изменить отношение людей. Если метафорически — то сделать проект «Слон с крыльями». При этом слон — большой, и если его делать во всей полноте, то в разумные сроки не уложишься. И Вадим рассказывал про последовательные приближения, организацию сотрудничества.
В трехуровневой схеме Card — Conversation — Confirmation, о которой он рассказывал год назад.
- Card. Голос пользователя. Обвешиваем приоритетами, оценкой, проектом и прочее. Важно, что карточка — она легкая.
- Conversation. Обсуждение. На нем проявляются невербальные знания. правда, за этим надо следить.
- Третий этап — подтверждение. Как понять, что мы поняли друг друга правильно.
Упор в докладе был именно на третий этап. Тут идеально — написать тест, но по площади это не реально. А вот по ключевым аспектам системы, с использованием BDD — вполне реально. И они это делают. И получается не просто userstory, а проверяемая в реализации.
В целом получается процесс разработки на людях, с интенсивным общением. Интересно, что это проходит с такой традиционно считающейся бюрократической структурой как НацБанк — при наличии заинтересованности. Конечно, бюрократические процедуры, документация никуда не исчезают, но к ним подходят прагматично: они должны обеспечить форму, аудит. Содержания в них нет.
Надежда Тарасюк. R-Style Lab. О чем молчит стейкхолдер
Блиц. Достаточно много приемов работы со стейкхолдерами и требованиями, выявление дырок и неявных полаганий через сопоставление. Следите за терминологией, ловите новые понятия, представляйте требования в разных видах… Проверяйте доступ на интерфейсе ко всем статусам документам и операциям над ним — о побочных ветках забывают. Контрольные списки.
Отдавайте соломенное чучело на растерзание — метафора ДеМарко. Плюс — менять легче, чем создавать — для заказчика. А тебе сделать чучело легко. Но профессиональные риски!
Я слушал кусочек, и в нем для меня лично ничего нового не прозвучало, поэтому я ушел послушать Семенченко. Но это для меня. И, возможно, я ошибался, и в неуслышанной части интересное было.