• Мифы и заблуждения о проектировании в Scrum
    +1
    Ваши вопросы относятся к теме развития людей и команды, это большая и важная тема. Может быть напишу и по ней статью.

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

    Пара проектировщиков и аналитик начинают проектирование как можно раньше, команда в это время занимается понятными задачами, техдолгом, поддержкой продуктива. По мере понимания задачи команда подключается к прототипированию, проработке конкретных деталей.
  • Мифы и заблуждения о проектировании в Scrum
    +1
    По поводу «аналитического паралича».

    Из личного опыта я усвоил, что командная работа от него спасает не всегда. «Закапываться» и «залипать» впятером можно так же, как и одному.

    На мой взгляд решение стоит искать в других подходах (предупреждаю, они не всем подойдут):
    • Не пытаться придумать заранее детальное решение всех проблем. Сделать схему по-крупному с зависимостями, а дальше двигаться: каждый спринт брать кусочек, проектировать и сразу делать. Если при этом возникнут проблемы с уже сделанным — дорабатывать старое или даже переделывать (переделки очень тонкий момент, обсудите с заказчиком заранее). Со временем ваше понимание и знания увеличиваются и вы находите решения, которые не нашли бы находясь в «аналитическом параличе».
    • Урезать функциональность. Бывает просят кучу вещей, которые друг другу противоречат. Тогда помогает сначала понять, что действительно важно, донести это до заказчика/стейкхолдера и выкинуть лишнее. Так вы уменьшите количество связанных задач и распутать «клубок» будет легче.
    • Проектировать от кейсов пользователей. Обычно кейсы реальной жизни противоречат друг другу реже, чем написанные кем-то «требования».
    • Периодически оценивать трудоемкость фич. Наверняка у вас есть максимальная цена в совокупности для всего проекта. Чаще всего нет смысла проектировать фичи, которые вы не будете делать. Если вы оцените весь «клубок» и выясните, что у вас превышение бюджета в два раза переходите к пункту «урезать функциональность».
    • Чаще обсуждать проблему. Я имею ввиду не только обсуждения в команде, но и с владельцем продукта, заказчиком. Совет спорный, все таки это затраты времени, но проверено на себе: в случае «паралича» это встряхивает проектировщиков и некоторые проблемы решаются сами собой.
  • Мифы и заблуждения о проектировании в Scrum
    +1
    Насчет технической документации.

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

    У нас документ «по-крупному» должен содержать 4 раздела:
    1. В разделе «Открытые вопросы» зафиксированы текущие вопросы, которые необходимо обсудить на ближайшем совещании, либо вопросы, на которые нужно ответить к ближайшему обсуждению.
    2. Раздел «Решения» состоит из текущих прорабатываемых вариантов решений, итоговой оценки трудоемкости, мокапов, скриншотов прототипов. Для предлагаемых вариантов выделяются плюсы и минусы в виде таблицы.
    3. В раздел «Приложения» переносятся:
      • закрытые вопросы;
      • результаты исследований;
      • ссылки на связанные документы;
      • прочая вспомогательная информация.
    4. При согласовании документа с заказчиком, рекомендуется выделять вверху документа раздел «Аннотации» с кратким содержанием и выводами.


    При этом документы получаются короткими, воду лить не нужно. Описать решение тому, кто его придумал обычно не сложно, плюсы и минусы тоже. В документ пишут все участники команды. Проектная документация на спринт команды из 6 человек — 5-6 страниц (с картинками).
  • Мифы и заблуждения о проектировании в Scrum
    0
    Вы правы, со временем так или иначе начинаешь работать эффективнее и процессы становятся отлаженными.

    Почему я упомянул Scrum?

    Потому что он в моем случае подталкивал к таким решениям. Командная работа подталкивает к командному проектированию. Итерационная разработка заставляет искать способы ускорения процесса. Ретро это отличный способ работы над улучшениями — вопросы проектирования на ретро поднимаются чаще всех остальных, даже сейчас.
  • Мифы и заблуждения о проектировании в Scrum
    0
    Уже ответили про документирование, примерно того же мнения придерживаюсь и я.

    Вы подняли интересную тему «analysis paralysis». Я с ней сталкивался сам, пытался решить разными способами и Вы совершенно правы: нанять аналитика это не решение, он впадет в такой паралич часто быстрее разработчика. Проблема сложная и возможно заслуживает отдельного анализа и статьи. Может быть поделитесь другими сложностями, решение которых лично Вам было бы интересно?
  • Мифы и заблуждения о проектировании в Scrum
    0
    А если изучение предметной области занимает месяцев 3..9?

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

    А если не секрет какая предметная область требует изучения нормативной документации по 9 месяцев?

    Необходимый минимум для кого?

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

    «бумажки» пишут как раз не программисты

    Где как, но чаще архитекторы и аналитики, вы правы. Я имел ввиду именно проектную документацию (ТЗ, спецификации).

    Как этот процес работает с контрактами Time & Material и Fixed Price?

    Сильно зависит от заказчика, но может работать. Коллега из отдела внедрения недавно писал статью по опыту недавних внедрений как раз по fixed price и time&material.
  • Мифы и заблуждения о проектировании в Scrum
    0
    Не могли бы Вы сказать какие проекты и в каких предметных областях вы реализовали по такой методологии?

    Конкретные проекты назвать не могу, предметная область — ЕСМ и все что вокруг ЕСМ.

    Как вы «встраиваете» работу с аналитиком в свою реализацию Scrum?

    Аналитик физически в команде, активно участвует в исследовании, проектировании, тестирует, занимается документацией и справкой. Задач по ходу спринта хватает для 100% загрузки.

    Куда относится работа по «требуется исследование предметной области, конкурентов, кейсов работы пользователей»

    Все в рамках проектирования в итерации. Если это будет отдельно, а потом отдельно проектирование, а потом отдельно реализация это уже не совсем Scrum :-)

    Почему работа по «исследование… конкурентов» относится к самому циклу разработки продукта/решения?

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

    И как так получилось что «программисты пишут бумажки» и какие? да еще и «на выброс»?

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

    Сколько у вас примерно «стоит» проектирование?

    Посмотрел по прошлому релизу: проектирование + разработка, тестирование и поддержка реализованного (баги, развертывание, продуктивы и т.д.) занимают одинаковое время.

    Как новый участник проекта получает необходимие знания по проекту?

    Обучение внутри команды + самостоятельно по справке к продукту, парное программирование, своя wiki по архитектуре и приемам разработки, привлечение к проектированию и планированию.
    Обычно этого достаточно, чтобы освоиться за пару месяцев.
  • Мифы и заблуждения о проектировании в Scrum
    0
    Владелец продукта ставит перед командой задачу: что и зачем нужно сделать, на уровне его видения. Дальше проектируем: разбираемся как будем делать, потом декомпозируем на мелкие части и оцениваем.

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

    Если говорить про остальных «заинтересованных лиц», то в любом случае придется потратить время на взаимодействие. Либо в виде демо, либо в виде постоянных ответов на их вопросы, потому что сами они могут неправильно понять что вы делаете и зачем.
  • Мифы и заблуждения о проектировании в Scrum
    0
    Мне кажется «скрам-хайп» был актуален лет 5 назад, как раз тогда мы на него и перешли. С тем, что он с тех пор набил оскомину соглашусь, но все таки методологий управления разработкой не так уж и много, повторения неизбежны.

    А фишка в том, что взять методологию — это половина дела, надо еще адаптировать ее под себя. И я как раз scrum не пиарю, он в этом не нуждается, а просто делюсь наблюдениями за эти 5 лет.
  • Мифы и заблуждения о проектировании в Scrum
    0
    Надеюсь, что нет.
    Ничего против них не имею, но именно в концепции аналитика-проектировщика есть определенные минусы, которые в моем случае получилось устранить за счет проектирования всей командой.
  • История одной фичи или зачем хакатон программисту
    0
    Видимо я этот момент обошел стороной. Эти выходные для участников были оплачиваемыми.

    Не поленился и нашел опрос, которой проводили как раз по итогам, на тему все ли устроило в бытовом плане. Вот типичные ответы:
    Мне просто понравилось. Попилить что-то своё в хорошей компании — всегда весело

    Я участвовал не ради «покушать» или «призов», а чтобы писать код — с этим было все ок

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

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

    С учетом того, что полезной и реализуемой оказывается примерно 1 идея из 10 и на доведение ее до ума нужно времени в 10 раз больше, чем на прототип я бы поспорил с тем, что это «бесплатные фичи».

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