Join Yalantis and get a $1000 sign-in bonus! React.js, React Native, Python, Java, DevOps, BА. Apply now!
×Закрыть

Scrum, аутсорсинг, бизнес-аналитики и насекомые

Название сегодняшней колонки может показаться странным читателям, знакомым с практиками методологии Scrum. Дескать, какие-такие аналитики, когда есть PO, выдающий на-гора требования для команды, и всегда доступный для product backlog refinement?

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

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

Тут на помощь команде приходят пользователи. Точнее, самая продвинутая их часть — т.н. subject matter experts, т.е. люди с достаточно большим опытом в определенной области бизнеса, которые могут помочь команде уточнить требования. Теперь задача PO сводится к приоритизации бэклога и знанию, на кого можно «натравить» команду в случае каверзных вопросов.

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

Тем не менее, выделенный человек на роли БА в команде — не самая лучшая практика. Обособление приводит к тому, что такой человек быстро превращается в «узкое место» команды и если он уходит в отпуск, на больничный или в другую компанию — начинается бардак (классический пример команды с TruckNumber = 1).

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

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

В общем, строя процесс разработки и работы с требованиями, помните: специализация — удел насекомых! А действительно senior специалист должен стремиться быть «универсальным солдатом» — это не только расширяет кругозор, но и повышает его ценность для работодателя.

LinkedIn


53 комментария

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

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

Это вполне естественно. Грань между спецификациями и тестами вообще очень размыта (особенно, при использовании BDD), поэтому основы тестирования однозначно нужны.

Что касается собственно кодирования, я думаю, что участие БА в архитектурных дискуссиях имеет смысл, учить Java на уровне senior developer вряд ли для этого нужно.

А действительно senior специалист должен

Что-то последнее время senior специалист всем все должен.

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

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

Сам собой получался? Любой процесс (от RUP до Kanban) должен быть грамотно организован, в колонке речь конкретно об enterprise scale Scrum.

Сам собой получался?
нет,
хотя если получится сам сам собой, то это вообще превосходно! :)
Любой процесс (от RUP до Kanban) должен быть грамотно организован,
несомненно
в колонке речь конкретно об enterprise scale Scrum.
я пока не вижу в колонке ни слова о скраме, только «якоря» и термины PO, бэклог и т.д.

Да ладно, скрам даже в названии упомянут. Не знаю, куда уж прозрачнее.

я нигде не увидел как то что вы написали соотносится со скрамом в частности. Для красного словца написали?

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

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

прям вот краеугольным? может вы поделитесь источником такого смелого утверждения?

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


Agile development focuses on crossfunctional
teams empowered to make decisions, versus big

hierarchies and compartmentalization by function.

© Jeff Sutherland (Scrum Handbook)

Это касательно первоисточника, вообще же гугл по “scrum cross functional” находит 500K+ упоминаний.

В том числе, кстати, и по поводу “универсальных солдат” — US Army Special Operations Forces (“зеленые береты”).

а теперь контрольный вопрос:

вы видите разницу между кроссфункциональной командой и кроссфункциональным членом команды?

Конечно, вижу.

Кроссфункциональная команда + четкое разделение обязанностей = минимизация TruckNumber

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

TruckNumber нужно максимизировать

Вы в этом утверждении не ошиблись?

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

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

Это что касается собственно места продукту под названием «SCRUM» в изначальной статье.

Теперь про «универсальных солдат», ЧислоГрузовика и прочие «фишки».

Кроссфункциональная команда + четкое разделение обязанностей = минимизация TruckNumber

совсем неочевидная «формула». Раскройте пожалуйста, при каких это условиях она справедлива.

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

Вот уж вы любите слово «нужно». Можно? — да. Нужно? — нет!

2. Если в проекте обязанности размазаны по людям — это как раз и есть сигнал тревоги. И именно поэтому возникает желание препарировать команду, потому что единственно-успешное применение такого подхода возможно только в сильно отделенной (даже скорее независимой) команде от других команд (мы же большой проект разрабатываем, не так ли?), плюс такой подход требует просто очень грамотных людей в команде, с широким спектром смежных компетенций, что само по себе риск и не малый. А если нет единого центра ответственности за отдельные виды деятельности с соответствующими полномочиями — так вообще прямой путь в пропасть.
Более того, понимание бизнеса заказчика это несомненно хорошо, но применение этого понимания в работе — это прежде всего огромнейший риск, потому как
а) все члены команды должны понимать бизнес заказчика одинаково, что само по себе утопия;

б) все члены команды должны понимать бизнес как таковой, что вообще недостижимо в подавляющем большинстве случаев, разве что в случае если члены команды — учредители-заказчики :)

Ввиду «тревожности» такого подхода расскажите нам о вашем проекте:
1. Когда члены команды дописывают требования?
2. Выделяется ли на это время в плане спринта(ов)?
3. Когда и как происходит оценка трудоемкости юзерстори?

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

Пока хватит :)

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

1+2) Время на работу с требованиями учитывается командой при планировании. Требования уточняются перед спринтом в ходе Product Backlog Refinement сессий и индивидуальной работы с PO/SME. Чем крупнее user story, тем раньше (бывает, что и за несколько спринтов) начинается анализ.
3) Грубая оценка трудоемкости происходит во время Joint Backlog Refinement командами совместно, уточняется по ходу дела командой, которая начинает работать над этой стори.

4) Команда как единое целое ответственна за результат своей работы (какой вопрос, такой ответ).

По соседству говорили про обесценивание «погон». Я в принципе не против того, чтобы дать деткам поиграться «звездочками» и «званиями». Но если так уж хочется чтобы «звездочки» и «звания» что-то значили, то таки да — senior специалист много чего должен. Не всем, просто чтобы соответствовать мере экспертизы, отвественности, автономности и оплаты. А если человек «не в состоянии» (в 9 из 10 случаях оказывается, что из-за непомерной лени) понять бизнес-среду заказчика и не превышать полномочий — действительно ничего страшного, хороших middle специалистов очень не много

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

Если я правильно понял, Вы считаете, что роли в проекте никак не коррелируют с уровнем грамотности технического специалиста? Если так, то я позволю себе не согласится. Как количество, так и степень ответственности, и степень компетенции, которую подразумевает та или иная роль очень тесно (хотя и не 1:1) связаны с уровнем технической грамотности конкретного специалиста. Банальный здравый смысл диктует невозможность определения роли «deployment manager» для специалиста с уровнем junior, например

Вы считаете, что роли в проекте никак не коррелируют с уровнем грамотности технического специалиста?

Вы неправильно поняли.

Тезис 1. В описании процесса разработки как таковом нет места таким терминам как «грамотность».

Тезис 2. Степень компетентности отдельно взятого человека на отдельно взятой роли влияет лишь на вероятность достижения цели проекта (риски везде :) ), а это лежит в другой плоскости технологии/методологии разработки (заметьте, нигде нет слова «никак»).

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

1. Размазывайте обязанности в проекте (в данном конкретном случае обязанности БА), дабы не создавать «незаменимых». (Далее идет краткое изложение такого размазывания на примере автора и его проекта)

2. Да пожалуй и все.

Собственно свою точку зрения я освещу позже, если в этом будет необходимость и/или желание.

Собственно свою точку зрения я освещу позже, если в этом будет необходимость и/или желание

Можем опубликовать отдельной колонкой, бтв.

Можем опубликовать отдельной колонкой, бтв.

спасибо за предложение :)

но я здесь писать то особо не о чем, в 5 строк вместиться, если не страдать графоманией.

=ZaQ=не растекаясь по древу на многие строки, то получится следующее:

1. Размазывайте обязанности в проекте (в данном конкретном случае обязанности БА), дабы не создавать «незаменимых». =ZaQ=

собственно, зерно темы.

да, и с тайными знаниями надо бороться (методом документирования, например).

Отличные тезисы, спасибо. Надеюсь, что желание осветить свою точку зрения таки будет. :)

Но я бы не обвинял автора в намеренном размазывании обязанностей, все-таки термин «кроссфункциональная команда» придумал далеко не он, а методы достижения этой самой кроссфункцональности могут быть разными

Надеюсь, что желание осветить свою точку зрения таки будет. :)

поживем, увидим, будет ли необходимость :)

Но я бы не обвинял автора в намеренном размазывании обязанностей

я и не обвиняю, я просто констатирую факт. Хорошо это или плохо — отдельная тема. То что слово «размазывать» имеет слегка негативный оттенок — это уже шаблоны восприятия :) Зачастую правильнее изъясняться простым разговорным языком, чем использовать заумные термины, смыслом которых можно вертеть как хочешь.

Автора я критиковал за подмену некоторых ключевых утверждений в Тезисе 1 из Тезиса 2.

Ну и зачем такой «специалист» вообще нужен? Проще его работу автоматизировать.

Ok, Mr. Smartypants ;)

Initial automation costs are negligible in a long run. On the other hand, cost of ongoing support will be less than junior’s rate plus risks of human failure (quite high in case of junior).

Ну тогда Дженкинс и есть junior deployment manager. Так сказать, робот в команде.

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

Я очень слабо верю в полностью кроссфункциональные команды. Безусловно, для того чтобы качественно делать software, необходимо разбираться как в предметной области, так и в целях и процессах бизнеса (разумеется при условии, что стоит задача заработать хоть сколь-нибудь значимых денег). С другой стороны, крайне редко можно встретить людей, способных на одинаково высоком уровне поддерживать знания двух языков программирования, языка программирования и навыков DBA, актуальных навыков и знания системного администрирования и глубокое понимание практик тестирования проекта. И если представить себе, что наборы навков не бинарны, а пересекаются все со всеми... сложность освоения и поддержки их в актуальном состоянии стремится к бесконечности.
Разумеется job description хорошего senior разработчика включает в себя некоторое знание смежных областей. И в случае форс-мажорной ситуации таковой разработчик может частично взять на себя функции другого специалиста. Тоже касается и знания в области бизнес-анализа. В конечном итоге пироги должен печь пирожник, а сапоги точать сапожник.

Я так думаю.

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

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

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

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

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

По-моему это и есть описание senior-developer. Да их редко встретишь.

Костя, я не уверен, что ты меня правильно понял. Я не ратую за полный отказ от специализации, но программист, не использующий, например, TDD/BDD — это уже динозавр какой-то (точно так же, как и «ручной» тестировщик). Соответственно, граница между тестировщиком и кодером сильно размыта.

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

но программист, не использующий, например, TDD/BDD — это уже динозавр какой-то (точно так же, как и «ручной» тестировщик).
Сильное заявление :) Помнится, искал статистику подобного рода, не нашел. Может кто-то может подсказать? Хорошая тема для опроса на ДОУ, кстати, думаю, не одному мне интересно. Какой процент разработчиков использует TDD и подобные методики «2го уровня», какой процент довольствуется просто юнит-тестами, какой процент понимает что это такое, но не использует (и по каким причинам), какой процент не использует вообще(и тоже почему). То же и для тестирования — сочетание мануалки и автотестов, параллельно/перпендикулярно с тест-активностями разработчиков на данном конкретном проекте. Ну и конечно в разрезах outsourcing/in-house/product company и enterprise/web/shrink-wrapped/embedded/games

Какой процент разработчиков использует TDD и подобные методики «2го уровня», какой процент довольствуется просто юнит-тестами, какой процент понимает что это такое, но не использует (и по каким причинам), какой процент не использует вообще(и тоже почему)

Количественных оценок, увы, не дам, а качественно, по собственным наблюдениям, ситуация такая:

  • TDD использует довольно мало людей, в первую очередь потому, что для того, чтобы «проникнуться» пользой этого подхода, нужно, во-первых, основательно поменять мышление касательно низкоуровневного дизайна, а во-вторых — иметь силу воли отказаться от привычки сначала наколбасить кода, а потом только его тестировать.
  • Просто юнит-тесты используются гораздо чаще, основные «затыки» здесь — это изначально неправильно спроектированная архитектура, которая не позволяет изолировать бизнес-логику, незнание/неумение пользоваться DI фреймворками, и трудности в «продаже» юнит-тестов заказчикам — а «спрятать шляпу», поверьте, далеко не всегда возможно.
  • Понимают, но не используют юнит-тесты обычно если пишется чисто CRUD приложение без особой логики, если они нормально не поддерживаются выбранной технологией, или если в наследство достался дремучий «индусский» код, а бюджета на рефакторинг никто не выделяет

То же и для тестирования — сочетание мануалки и автотестов

Автотесты — это инвестиции, которые нужно «отбить». Я, увы, ни разу не специалист в написании таковых, но то, что я слышал от QAев на эту тему, примерно сводится к следующему:

  • Автотесты мало один раз написать, их надо постоянно поддерживать — особенно функциональные, которые очень завязаны на GUI и разваливаются при малейших переделках в UI
  • Разработка автотестов — очень дорогое удовольствие, они окупаются, если каждый тест запускается не менее 7-8 раз (тут цифру точно не вспомню, но «порядок» где-то такой был). Для довольно большого числа проектов, для которых приемлемо «good enough» качество — особенно для проектов для внутреннего применения — такое тщательное регрессионное тестирование не проводится в принципе.
  • Найти QAя, который бы умел программировать — очень и очень непростая задача. К тому же, зачастую для автоматизации тестов используются совсем другие языки, чем для написания основного кода — поэтому коллеги-программисты даже помочь, в случае чего, не смогут. А enterprise проекты, опять же, редко когда разрабатывают на Питоне, Руби или подобных скриптовых языках.

Макс, без опроса не разобраться! ;)

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

А они, члены команды, об этом знают? :) В самом деле, не сочтите за сарказм или троллинг — я за свои 10 с хвостиком лет опыта видел очень немного программистов, которых, в рамках рабочих вопросов (а в «запущенных» случаях — и не рабочих тоже) интересовало что-то, кроме кода, архитектуры, компиляторов и т.п. чисто IT-шных вещей. И если вам удалось собрать и/или воспитать команду, большинство людей в которой открыты к пониманию бизнеса и потребностей пользователей — поздравляю, вам действительно очень повезло.

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

А они, члены команды, об этом знают?

Кто не знает, тех учим. Если человек ничего, кроме «код педалить», делать не хочет, это обычно видно еще на этапе собеседования.

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

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

senior специалист должен стремиться быть «универсальным солдатом»

Не всегда.

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

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

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

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

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

Разработчики с широким кругозором ИМХО востребованы разве что в R&D (в реальном, где новые технологии и алгоритмы создают) — так пойди найди у нас этот R&D.

Отсыпь че куришь :-)

Да-да, это высокий уровень ведения дискуссии.

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

За бугром, если бы человек сказал какую-то чушь и ещё бы подписал что он работает в eBay, его бы не замедлительно уволили бы или провели бы разъяснительную беседу. У меня в контракте так и прописано.

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

человек сказал какую-то чушь

Из заповедей Максима Австралийского:

11. Не критиковать коллег публично, в т.ч. на форумах если они этого специально не попросили.

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

Что может сказать хромой про творчество Герберта фон Караяна, если ему сразу заявить, что он хромой? © ММ

must read про бренд констракшн — здесь имеется ввиду что такие посты портят бренд компании за который не мало бабло выложено, поэтому справедливо прописать в контракте.

Тут увольнять нужно автора и 70% комментаторов.

Безотносительно к содержанию колонки и комментариев, но Луркоморье находится по другому адресу.

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

Подписаться на комментарии