Как стать автором
Обновить

Комментарии 162

Ожидайте комментариев сообщества Agile.

Даже можно сказать какой будет первый: СКРАМ хорош но вы не умеете его готовить.

Правильный ответ: СКРАМ хорош, но вы не понимаете, зачем он вам

Или например так: Вы еще не понимаете что СКРАМ — все что Вам нужно.

ЭТО БЫЛ НЕПРАВИЛЬНЫЙ СКРАМ
@
НАСТОЯЩИЙ СКРАМ НИКОГДА НЕ БЫЛ ПОСТРОЕН
@
САМА ИДЕЯ СКРАМА ХОРОША, ИМЕЛИ МЕСТО ПЕРЕГИБЫ НА МЕСТАХ
@
А БЫЛ БЫ У НЕГО СЕРТИФИЦИРОВАННЫЙ СКРАМ-МЕНДЖЕР, ВСЕ МОГЛО БЫ СЛОЖИТЬСЯ ПО-ДРУГОМУ
@
ЕСЛИ БЫ ОН НЕ ИСПОЛЬЗОВАЛИ СКРАМ, ТО СКРАМ ИСПОЛЬЗОВАЛИ СОЛДАТЫ НАТО
Не могло бы сложиться по другому, это я вам как сертифицированный скрам(и канбан) менеджер говорю.
Ну такое бывает, владелец в пивнушке или в бане или еще где услышал, что кто-то из друзей поставил БЛОКЧЕЙН или ИИ или типа того, и все заиграло, заискрилось фонтанами зелени.
Видел такие истории, но в большинстве случаев, это просто слив бабла, тут обычно 2 варианта или с гордостью отдаете кнопку, делите деньги и сливаетесь или заявляете, что теперь ЕПР тоже надо адаптировать к болкчейчну, но для этого ее надо полностью переделать, что бы блокчейн могла распознать и на входе и выходе и все такое.
В общем все не так плохо у Вас, творите, наслаждайтесь, а если откажетесь, так там уже очередь стоит со своими услугами.
Что сказали stakeholders? Они довольны этой кнопкой или ее надо было сделать покрупнее?
Видать ревью еще не было
Стейкхолдеры мечтают о второй кнопке — ее наличие повысит стоимость токена в геометрической прогрессии.
Ну так правильно. Потому что задача изначально некорректно поставлена. Вы приняли пожелание заказчика за пользовательскую историю. Отсюда и мнимое противоречие.

Пользователь не хочет никакой системы получить. И уж тем более, ему плевать на блокчейн. Нужно не нафантазировать, что он хочет, а пойти и спросить у него и бережно записать.

Блокчейн нужен, если есть какая-то пользовательская история, которую невозможно сделать без блокчейна, но очень хочется. А не просто так от балды.

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

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

А какая разница? Если команда показала неудовлетворительный результат, ее просто распустят, и, если необходимость в разработке не отпала, соберут новую.

Это же детство — рассчитывать, что за вас кто-то будет другой думать. Сбору и анализу требований учат в вузе, любой разработчик это умеет.

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


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

А чем вы занимаетесь в свободное время? Ну, в смысле, рабочий день 8 часов, код вы пишете примерно 2 часа. Что вы делаете в остальное время?

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

На вопрос вы не ответили. Вот когда ответите, тогда и поймете.

Зависит от построения процесса в компании. Вот буквально прошлая пятница, 11 утра:


Тимлид — "Слушай, тут хотят, чтобы таймаут связи происходил только когда нет пакетов N, можешь сделать чтобы только они таймер сбрасывали? А пакеты M, Q игнорить."
Я — "Говно идея, у нас есть кейсы X, Y и Z, когда пакеты N и Q не идут, а только пакеты M есть, если так сделать всё развалится — можем в сбросе таймаута просто начать игнорить Q, тогда будет примерно оно, но на глаз один хрен почти ничего не поменяется."
Тимлид — "Хм, хорошо, спрошу у заказчика, можно ли так."


Вот уже понедельник, всё ещё сидим, ждём пока разродятся. Можно конечно сказать "ну так сиди рефакторь", но чтобы опять предъявили "зачем ты столько кода поменял, на вид же всё так же работает, не делай так больше" — оно мне надо?

Я правильно понял, что вы за пятницу ничего не сделали? Диалог, который вы пересказали займет пару минут. Что вы делали оставшиеся 7:58 часов?

[оффтоп]Ну и сразу вопрос: а почему вы сами внутри себя не можете такой вопрос решить? Владелец — он ведь про бизнес, про продукт, а не про пакеты.[/оффтоп]

Если сверху пришла задача про пакеты, значит, кто-то вверху — про пакеты.

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

Ничего и не делали. Разве что ещё пара багов, один из которых — очепятка в локализации, а второй — тестеры со стороны заказчика забыли включить колонки на стенде и отписались что "ваше обновление звук сломало теперь".


Там не владелец сверху, а другая контора, со своими разработчиками и менеджерами.


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


(Обратные, когда они соглашались, что да, сурово технологическое решение будет конкретно так неудобно, и сделанная реализация лучше — тоже были, но не в большинстве)

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


Дальше только полёт фантазии, от проектирования и до написания кода, с периодическими уточнениями и проверками.


А тут всё зарегулировано, за коммит без тикета при нём может и прилететь, код уже кое-как написан кем-то до, на вопрос тимлиду о том, что тут бы порефакторить — "ну вот баги все добьём и попрошу дать времени всё причесать, может дадут".


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

Не совсем. В скраме тоже такого нет, что сидишь-пилишь месяцами. Что-то должно работать уже через две недели и это надо сделать не в одиночку, а всем вместе.

Это да, тут просто не скрам :-)
Пилят они эту штуку ещё с 2017, когда я пришёл на проект — был уже очень сырой MVP, за год допилили и может быть даже релизнемся наконец.


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

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

Product Owner должен быть.

Более того, он не просто должен быть. Он должен обладать определенным уровнем квалификации и компетентностей.

Почему тот, кому платят деньги — разработчик — должен обладать определенной квалификацией, а к тому, кто платит деньги — к представителю заказчика, Product Owner-у — таких требований не предъявляется?

Формально Product Owner есть, то только лишь формально.
Кто-то ж собирал команду именно в таком составе, как она есть? Определил какие специалисты будут нужны, какой стек технологий использовать, какой уровень квалификации специалистов (и какой бюджет)?

Архитектора в команде не предусмотрено — кто должен заставить заказчика правильно сформулировать свои Пользовательские истории?
Front-end developer? Back-end developer? Database developer? Blockchain developer?
Она сама собралась. То есть, каждый член команды по отдельности согласился делать этот продукт для этого владельца.

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

Front-end developer? Back-end developer? Database developer? Blockchain developer?

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

Архитектора в команде не предусмотрено — кто должен заставить заказчика правильно сформулировать свои Пользовательские истории?

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

Я, например, пришел в проект по такому объявлению на сайте вакансий:
"We are looking for Senior Blockchain Developer for our new project.
You can apply your technical skills and motivation to build a new cutting edge and extremely innovative product. Lots of challenging tasks are waiting for you!
Requirement experience with:
— 5+ years of overall software development experience (backend preferred)
— 3+ years of Blockchain development
— Independent self motivated
"

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

Можно просто не брать плохо сформулированные пользовательские истории в работу.

Вы точно уверены, что руководство «галеры» разрешит программистам «не брать плохо сформулированные пользовательские истории в работу»?

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

Independent self motivated

Вот как раз требование в вакансии на эту тему есть.

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

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

Развернуться и уйти — это будет как в анекдоте про цыгана в партизанском отряде — «Эти ваши листовки — очень плохой товар, я еле их продал».

Что касается присутствия «владельца продукта», то как раз он и сформулировал 1ю и единственную Пользовательскую историю (напомню, она звучит как "Я, как пользователь, хочу получить систему, в которой производственные и бизнес-процессы предприятия отображаются в блокчейне")

ИМХО, «Independent self motivated» — совсем не означает, что каждый разработчик из команды должен кроме программиста быть еще и Проект менеджером и Архитектором и Техническим писателем. Рискую нарваться на «минуса в карму», но такое совместительство как минимум тупо не оплачивается…
Я работал как раз в аутсорсе/аутстаффе крупном. У меня всегда спрашивали.

Развернуться и уйти — это будет как в анекдоте про цыгана в партизанском отряде — «Эти ваши листовки — очень плохой товар, я еле их продал».

Ну вы же не товар на самом деле. Вы сами себя воображаете товаром, а потом страдаете, что выбора нет.

У меня как было: у меня было резюме внутри компании. И ресурсный менеджер показывал это резюме заказчикам. Не обычное мое публичное резюме на hh, а именно специальное. И там было все написано, что могу, что не могу, и так далее.

ИМХО, «Independent self motivated» — совсем не означает, что каждый разработчик из команды должен кроме программиста быть еще и Проект менеджером и Архитектором и Техническим писателем. Рискую нарваться на «минуса в карму», но такое совместительство как минимум тупо не оплачивается…

В скраме нет подразделения на должности, есть только разработчики. Если команде не достатет навыков для работы — это один вопрос, и серьезный. Но его надо решать еще до начала работы.
У меня как было: у меня было резюме внутри компании. И ресурсный менеджер показывал это резюме заказчикам. Не обычное мое публичное резюме на hh, а именно специальное. И там было все написано, что могу, что не могу, и так далее.

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

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

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

Я не обижаюсь, но это оскорбление. Я себя товаром не считаю. У товара выбора нет, а у меня есть.

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

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

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

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

Еще раз прошу прощения за неверное применение такого некорректного термина, я просто его взял из Вашего сообщения "Ну вы же не товар на самом деле.". Да, согласен. Не товар. Как-то по-другому…

Оценка — это просто такой повод синхронизировать модели. Если кто-то что-то недопонимает — это наверняка отразится на оценке.

Для верной оценки ИМХО нужно ПОНИМАТЬ механизмы реализации той конкретной задачи, которая оценивается.

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

Не использовать. Резюме, ресурс-менеджеры — это просто такой инвентарь, чтобы быстрее получать работу. Вы вступаете в обычные рабочие отношения с заказчиком, просто в ускоренном темпе.
Так бы вы на поиск и окучивание заказчика потратили недели, а так вам чики-пуки-шпили-вили — все готовенькое на блюдечке, напрягаться не надо.
Можно провести аналогию с биржей. На бирже же торгуются реальные товары, реальные акции, реальное все. Просто оно настолько автоматизированно, что создается впечатление нереальности происходящего, как будто бы оно не с вами происходит, а где-то «на рынке».
Понял.
За счет автоматизации на бирже торгуются не товары, а активы.
Соответственно, когда софтварная фирма предлагает заказчику использовать конкретного разработчика (который обладает определенным набором характеристик, определенными условиями применения и определенной ценой) — то нужно использовать термин «актив»? Cофтварная фирма предлагает использовать заказчику актив?
Вы предлагаете заказчику свои услуги. И отдаете копеечку в адрес вашего аутсорса за его услуги вам.
Бизнес аутсорса/аутстаффа завязан на том, что он предлагает разработчикам более интересные условия, чем может предложить усредненный заказчик. И поэтому он получает возможность аккумулировать у себя множество интересных разработчиков, которых нет на рынке труда, до них не может добраться заказчик.
Вам же бенчи оплачиваются? Оплачиваются. Репутация у бренда вашего аутсорса хорошая? Хорошая. Продажники продают? Продают. Ресурсный менеджер работает? Работает. HR работает? Работает. Вы получаете доступ к заказчикам, которые работают преимущественно с аутсорсом и не берут людей с рынка? Получаете. Вот это все в совокупности и составляет то, за что вы делитесь с аутсорсингом копеечкой.
Я не работаю на аутсорсе, не предлагаю заказчику свои услуги и данный проект также не относится к аутсорсным.

Извините, что ввел Вас в заблуждение. Возможно в Вашем случае, когда Вы фрилансер/аутсорсер — то Вы можете отказываться от «плохо сформулированных пользовательских историй».

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

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

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

Фирма по разработке программного обеспечения под заказ.
Полный комплекс услуг по разработке, внедрению и сопровождению программных решений клиентам из более чем 30 стран мира. Более 1500 высококвалифицированных ИТ-специалистов. Реализация ИТ-проектов различной сложности и масштаба.


… не знаю, как еще объяснить… Зарплату платит фирма, а не заказчик. Процессами разработки руководит фирма, а не заказчик.
Фирма по разработке программного обеспечения под заказ.

Это аутсорс. Вы работаете в аутсорсе.

… не знаю, как еще объяснить… Зарплату платит фирма, а не заказчик.

А фирма откуда деньги берет?

Процессами разработки руководит фирма, а не заказчик.

Вы же по скраму работали. В скраме нет как такового руководства.
Это аутсорс.

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

А фирма откуда деньги берет?

Понятия не имею… Честно говоря, даже не интересовался этим вопросом. Возможно, что всю разработку полностью оплачивает заказчик, а возможно что часть денег фирма вкладывает самостоятельно (ну а вдруг). А Вы как думаете?

Вы же по скраму работали. В скраме нет как такового руководства.

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

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

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

Понятия не имею… Честно говоря, даже не интересовался этим вопросом. Возможно, что всю разработку полностью оплачивает заказчик, а возможно что часть денег фирма вкладывает самостоятельно (ну а вдруг). А Вы как думаете?

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

В том то и беда… Прихоть заказчика, что ж тут поделать…

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

То есть, когда производственная компания заказывает разработку, производство и затем покупает у другой компании специализированный станок; и когда производственная компания увольняет своих дворников и заказывает услугу уборки территории у другой компании — и то и другое это аутсорс?

Так что заказчик платит вам + комиссия вашей фирме.

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

Покупка станка — не аутсорс. Производство ПО на заказ — аутсорс.

Производство ПО для себя — не аутсорс.

Еще раз повторюсь — я понятия не имею что и как заказчик платит фирме, с которой у меня трудовые отношения. Свечку-с не держал…

Курс экономики предприятия проходили?
Покупка станка — не аутсорс. Производство ПО на заказ — аутсорс.

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

Курс экономики предприятия проходили?

То есть Вы полностью исключаете, что часть разработки софтверная фирма может финансировать за счет собственных средств? Например, чтоб потом продать разработанный продукт еще в 2-3-4 места с незначительными изменениями?
Почему первое — НЕ аутсорс, а второе — аутсорс?

Кажется, я вас не верно понял. Если станок производится специально для нужд этого заказчика — аутсорс. А если станок готовый, то не аутсорс.

То есть Вы полностью исключаете, что часть разработки софтверная фирма может финансировать за счет собственных средств? Например, чтоб потом продать разработанный продукт еще в 2-3-4 места с незначительными изменениями?

Это вообще никакой роли не играет.

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

https://outstaff.ronova.ru/stati/autsorsing-i-autstaffing-skhodstva-i-razlichiya/


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

Аутстаф — да, это персонал.
А аутсорс — это именно разработка.
Понятно, что не только разработка может быть аутсорснута, но вообще все что угодно.
Мне кажется, что разделение аутсорс/не аутсорс только по признаку, что это уникальная специализированная разработка для конкретной компании — некорректна.

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

К примеру, заказчик — животноводческая ферма. Раздача корма поросятам — это основная бизнес функция компании. А постройка зданий, в которых живут поросята — к ежедневным бизнес-процессам компании не относится.

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

вы еще только только полного названия компании не написали. они себя цитате узнают и огорчатся ))
думаю, что многие тысячи компаний узнали себя по этой цитате ;)
… не знаю, как еще объяснить… Зарплату платит фирма, а не заказчик. Процессами разработки руководит фирма, а не заказчик.

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


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

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

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

И так — восемь раз.
К девятому — сдохнут и ишак, и падишах

PROFIT!
Ну так раз восемь команд не справилось, значит, дело уже не в них, а в чем-то другом. Надо разбираться.
Не понятно какую мысль хотел донести автор статьи. Не получилось в вашем «стартапе» полезного SCRUM'а. Бывает. Как говорится, держите в курсе. С таким уровнем неадеквата в менеджменте и «классический» подход вышел бы не лучше. Но при чем здесь российский SCRUM? Или американский? Или шведский?

Я с Вам полностью соглашусь. Если менеджмент адекватный — то разработка тоже будет адекватной. Вчера на Хабре кстати было опублковано интервью с сотрудниками Амазона из которого свидетельствует что там разрботка идет по скраму 2-недельным спринтами. Но там ничего не говорилось о карго-скраме и о скрам-тамадах.

Именно. Что скрам, что водопад, что канбан какой-нибудь — это же все просто инструменты. Нужно понимать почему ты хочешь использовать тот или иной инструмент управления, что он может дать и как его адаптировать к конкретной ситуации. И при необходимости поменять.
А когда появляется «группа инициативных менеджеров» которая зачем-то, сама не знает зачем, хочет блокчейн и скрам, а исполнители при этом не могут влиять на процесс (а может и не хотят или не умеют), то все. Ничего хорошего уже не будет. Надо тикать из такой конторы, пока стокгольмский синдром не случился.
Мысль автора была следующей — не для всех видов разработки подходит SCRUM, особенно если он превращается в карго-культ.
Когда заказчик ТРЕБУЕТ каждую неделю показать какой-то результат, который можно «пощупать руками», то иногда результат выглядит просто смешно.

В публикации как раз и рассказывается про такой «смешной случай», когда вместо того что выполнить подготовительные действия (выбрать, установить и настроить инструменты разработки; описать сущности и определиться со структурой данных, создать ТЗ и т.д.) за 1-ю неделю разработки требуется показать готовый продукт.

«Я, как пользователь, хочу получить систему, в которой производственные и бизнес-процессы предприятия отображаются в блокчейне» — это не только 1-я Пользовательская история, но и общее описание проекта.
Еще одна проблема скрама — это вечный дедлайн. Большая часть людей исходит из предположения что программист может выдавать код как рабочий на конвеере. Это не так, во всяком случае мне не доводилось работать с людьми долгое время выдающими стабильный результат.

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

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

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

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

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

И в итоге скрам используется эффективно только в 2 случаях: когда менеджеру нужно продать себя за счет методологии, и когда нужны формальные оправдания дрючить низкоквалифицированных программистов аки сидоровых коз при условии что они в большом количестве решают типовые задачи. Был бы рад услышать и о третьем случае, желательно не от менеджера.
Скрам появился в том числе и для этого, для повышения прозрачности для стейкхолдеров, и для большей прозрачности работы программистов, иначе, согласитесь у них тоже лафа и комплекс студента перед сессией при долгих итерациях, которые сами по себе проблема из-за меняющихся требований в живом бизнесе, которые бесмысленно морозить надолго. И да, как побочка — больший напряг для программистов и их более быстрое выгорание. И хз что лучше. Для бизнеса, если есть стопка CV — скрам лучше. Если этой стопки нет — то он довольно опасен.
НЛО прилетело и опубликовало эту надпись здесь
Опять таки перед стэйкхолдерами. Отсюда закономерный вопрос — а в чем кайф для программистов?

Ну по хорошему больше свободы в принятии решении и больше контроля над процессом. Это если по хорошему.

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

У меня прямо противоположный опыт. То есть когда нам надо что-то быстро, то скрам обычно не особо хорошо работает. И когда проекты стартуем с нуля тоже обычно работаем по «облегчённому варианту скрама». А вот когда проект уже идёт, то тогда уже переходим на «обычный скрам».
НЛО прилетело и опубликовало эту надпись здесь
Что значит «быстро» у вас? В моем тезисе я имел в виду интервал условно говоря в квартал — пол года (чтобы говорить о скраме должно быть, ну скажем, – десяток спринтов, каждый по две недели).

Как раз таки примерно те самые квартал-полгода. То есть если у нас проект меньше чем на полгода, то скрам просто не успевает нормально «раскрутиться».
То есть у нас скрам по хорошему это проекты 6 месяцев и дольше. Самый «долгий проект», или точнее самая долгая работа по скраму с одним клиентом над одним продуктом, идёт уже больше семи лет.

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

А это на мой взгляд вообще к скраму прямого отношения не имеет. Это просто обычный бардак и он точно так же может быть и в канбане и в водопаде и вообще где угодно.
>Опять таки перед стэйкхолдерами. Отсюда закономерный вопрос — а в чем кайф для программистов?

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

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

прикольно когда люди выбирают технологию, не удосужившись прочитать о ней даже в википедии.
что такое блокчейн?
— у нас есть определенный круг пользователей информации
— эти пользователи не доверяют друг другу и не доверяют ни одному из централизованных хранилищ информации
— эти пользователи ДЛЯ ПОВЫШЕНИЯ ДОВЕРИЯ к хранимой информации определенным образом ее кешируют и распределяют
— если кому-то нужно получить какой-то объем регистрируемой информации — он собирает ее из разных источников и, ПРОВЕРИВ НЕПРОТИВОРЕЧИВОСТЬ СКАЧАННОГО, начинает доверять этой информации.
— если кто-то, скачав информацию, получает доказательства ее противоречивости — он доскачивает информацию из других мест хранения и выявляет место фальсификации. После этого место фальсификации исключается и пользователь начинает доверять скачанной информации (это называется горбачевским словом консенсус).
— самой распространенной атакой на блокчейн является захват существенного количества (в идеале 50%+1) ее узлов — тогда фальсифицированная информация получит подтверждение большинства (а истинная будет признана фальсификатом)

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

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

"Моя" википедея говорит немного по другому "Блокче́йн (англ. blockchain[1], изначально block chain[2]) — выстроенная по определённым правилам непрерывная последовательная цепочка блоков (связный список), содержащих информацию. Связь между блоками обеспечивается не только нумерацией, но и тем, что каждый блок содержит свою собственную хеш-сумму и хеш-сумму предыдущего блока. Для изменения информации в блоке придётся редактировать и все последующие блоки."


Распределенная недоверенная среда — это лишь самое популярное использование технологии.

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

git — чем вам не блокчейн? Вернее блоктри из нескольких блокчеёнов:)


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

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

Да, согласен, вопросов не возникает, когда уже есть готовый продукт, — например, какой-то сайт. И требуется исправить пару опечаток на страницах этого сайта — здесь проблем нет. Создаем Пользовательскую историю типа «Я как пользователь сайта, хочу увидеть исправленную оЧеПятку на заглавной странице сайта с целью увеличить привлекательность сайта».
Успешно оцениваем каждую такую Пользовательскую историю в 1 (или даже 5) баллов. Успешно решаем задачу и к концу спринта получаем новую итерацию нашего продукта — сайт с исправленной оЧеПяткой опечаТТККой. В данном кейсе SCRUM безусловно рулит.

Но когда у нас стартап и мы вместо разработки его архитектуры сразу начинаем кодить кнопку КНОПКУ — то вот как раз здесь SCRUM неуместен. ИМХО.
Какой смысл городить 2 месяца архитектуру с тоннами абстракций, если заказчик сам ещё не знает, какая кнопка ему нужна? Скрам про итерации и обратную связь и про прозрачность работы. Всё.
НЛО прилетело и опубликовало эту надпись здесь
Ага, бездумное копирование ритуалов.
«Поскольку планируемая к использованию информационная блокчейн-технология на сегодняшний момент времени самая современная, то и метод управления разработкой программного обеспечения был выбран самый современный — а именно SCRUM»

Перевожу.
Поскольку купленная боссом Тесла-S была самой современной — то для ее заправки была куплена самая скоростная бензоколонка, которая могла заправлять 100 литров в минуту.

Простите, получается 24k$ фот пятерых, то есть зп каждого более 4000$? Не каждый senior так живёт, неплохо-неплохо.

Нет, конечно. $24к платит за 1 месяц работы заказчик, а программисты на руки получают процентов 40-50 от этой суммы…

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

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

То есть вы за неделю вместо нескольких месяцев наглядно показали заказчикам, что получается херня, и теперь ни вы, ни они не довольны? Во истину беспощадный скрам!:)

Я правильно понял вопрос — получается ли херня без предварительного планирования, разработки архитектуры, структуры данных и т.д.?
Ответ: — Да, воистину херня.

При чем здесь SCRUM? Все очень просто — в описываемой истории именно благодаря нему все эти этапы (предварительное планирование, разработка архитектуры, структуры данных и т.д.) отсутствуют…
Все очень просто — в описываемой истории именно благодаря нему все эти этапы (предварительное планирование, разработка архитектуры, структуры данных и т.д.) отсутствуют…

Нет, они отсутствуют благодаря тому, что вы делали какую-то херню. Архитектура, бизнес-анализ, системный анализ, документиррвание и тд — вполне себе цели в скраме. Мне кажется, вы вообще не прнимаете о чём сами говормте. Описываете криво поставленный заказной галерный аутсорс и называете это, почему-то стартапом. Что стартапного в рутинном аутсорсе? Описываете, как какие-то идиоты совершали карго-ритуал и называете это, почему-то скрамом. Я не люблю работать по скраму, но я участвовал в реально строгом скрам-процессе, когда всё что делается, действительно делается только по скраму и ни как не иначе. Это было муторно для меня, но это реально работает. И в этом процессе команда просто не может взять в работу юзер-стори "сделайте, чтобы всё работало". Первые стори будут — "исследовать что такое 'всё'" и "что значит 'работает'". По результатам исследования ставятся задачи на бизнес-анализ, архитектуру, дальнейшие исследования… Инкрементом бизнес-ценности в этом случае будет повышение компетенции команды в домене, создание проектной документации. Кто вам сказал, что инкрементом обязан быть сайт с кнопочкой? Сами придумали херню, сами сделали херню. Герои!

Именно поэтому публикация и называется «Российский SCRUM. Бессмысленный и беспощадный». Описывает ситуацию как НЕ надо делать. Тем более в стартапе.
Прочитайте, пожалуйста, 1й дисклеймер публикации.

Почему именно Российский?

Первые стори будут — «исследовать что такое 'всё'» и «что значит 'работает'». По результатам исследования ставятся задачи на бизнес-анализ, архитектуру, дальнейшие исследования… Инкрементом бизнес-ценности в этом случае будет повышение компетенции команды в домене, создание проектной документации. Кто вам сказал, что инкрементом обязан быть сайт с кнопочкой?

Оригинальный вариант интерпретации.

Аналогия — заказчик хочет атомную бомбу. Далее по вашему:

Первые стори будут — «исследовать что такое 'бомба'» и «что значит 'атомная'». По результатам исследования ставятся задачи на бизнес-анализ, архитектуру, дальнейшие исследования… Инкрементом бизнес-ценности в этом случае будет повышение компетенции команды в домене, создание проектной документации. Кто вам сказал, что инкрементом обязан быть сайт с кнопочкой?

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

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

Вообще переводить на модные методики выжимания пота всё и вся — это маразм. Этот маразм исходит не от программистов, а от тех, кто принимает решения о загрузке программистов. И не важно, как они там себе всё обосновывают. Хоть деньгами, хоть причудами заказчика. Если инструмент не соответствует задаче — в топку такой инструмент. А если кто-то готов платить программистам за безумства — почему бы программистам не взять себе деньги и предоставить разумный по их мнению результат (хоть и безумный с точки зрения заказчика)? Почему вы все (фанаты модных потовыжималок) считаете, что программист обязан исправить пустоту в головах, сначала, своих работодателей, а потом ещё и в башке абсолютно тупого заказчика? Он программист или мозговед? Но даже мозговеды не могут исправить пустоту, они только вид делают, что бы опять же денег срубить. А вы (фанаты моды) представляете себе мир с розовыми пони, которые ср*т исключительно шоколадом. И потому обвешиваете программистов задачами по исправлению пустых мозгов, параллельно с изучением атомного ядра и проектированием эффективного цикла производства ядерного оружия.

Маразм со стороны заказчиков поддерживается маразмом со стороны фанатов моды. В итоге получается маразм в квадрате. Но фанаты моды снова и снова поучают всех, мол вы не правильно наши модные штучки используете, а с заказчиком нужно дружить и стараться его удовлетворять. Да, даже если он хочет невозможного. Ведь он же вам денег даёт! Он святой, а вы обязаны его любить.

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

А вы должны задать себе вопрос — почему вы связались с заведомо провальным проектом по неподходящей для проекта методологии. Скрам работает, когда выполняются ключевые его требования и предпосылки. Скрам про agile, про проекты с меняющимися во времени требованиями, это не проекты «под ключ», там он работает плохо.
Вы вчитайтесь в собственное понимание на показанном примере. Вчитались? Или пропустили текст и только ухмыляетесь? Вчитайтесь, очень полезно.

Что вы имеете в виду? Я сказал ровно то, что сказал. От того, что вы бомбу подставили ровным счётом ничего не изменилось. Если разрабатывать бомбу "по скраму", то, да, именно такие стори и будут. Тут нет разницы. Вообще. А если того же Фейнмана почитать, то приблизительно так они Бомбу и разрабатывали.


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

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


Если инструмент не соответствует задаче — в топку такой инструмент.

С инструментом тут всё в полном порядке. Тут в другом проблема — заставь дурака богу молиться, так он и лоб расшибёт. Для задачи в том виде, как она описана, инструмент вполне подходящий. Но применён через джоппу.


Вообще переводить на модные методики выжимания пота всё и вся — это маразм.

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


Этот маразм исходит не от программистов, а от тех, кто принимает решения о загрузке программистов.

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


Почему вы все (фанаты модных потовыжималок) считаете

Интересно, вы по жизни лжец или просто не читаете то, на что отвечаете? Я в явном виде написал, что лично мне скрам не нравится, а вы всё равно врёте как сивый мерин.


что программист обязан исправить пустоту в головах, сначала, своих работодателей, а потом ещё и в башке абсолютно тупого заказчика? Он программист или мозговед?

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


Но к счастью в мире есть более адекватные заказчики и фирмы по разработке софта.

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

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

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

Тут дело не в методике дело, а в некомпетентности команды.

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

А теперь к реальности. Заевшихся от заказов команд в ней очень мало. Способных понять атомное ядро — ещё меньше (не нагуглить, а именно понять). Ну и фокус заевшихся и способных давно уже смещён в сторону «как мне нравится», а не «как на самом деле нужно заказчику». Поэтому если предложить им сделать атомную бомбу (вы вообще представляете весь необходимый объём работ?), то они упрутся в массу ограничений, о которых ранее даже понятия не имели, хотя и считали, что могут ну абсолютно всё. И вот эта супер-мега-айс-команда делает эпический фэйл. По скраму, разумеется. Ведь они же не какие-то там негры на галерах.

И разумеется, ребята всегда оправдаются (они же супер, не?). Обвинят во всём, понятно, заказчика. Свалят с проекта сразу, как только им скажут «ребята, у нас тут есть ограничения». Ну и распиарят свой «успешный опыт» примерно так — мы реально сделали бомбу! Но тупые заказчики, некомпетентные поставщики, и вообще всякая шваль под ногами… Ну вы поняли — виноваты все, кроме КОМАНДЫ.

Короче — ваш подход не для реального мира. Если вы входите в число заевшихся и лениво выбирающих себе заказ — ладно, вам простительно непонимание реальности (не до неё ведь). Если же нет, то уж сорри, но некомпетентны как раз вы. Других вариантов нет. Например, потому что вы не знаете, как сделать бомбу, даже если вам кажется, что вы всё знаете.

Ну а отдельные выполненные вами проекты, которыми все хвастаются как «успешными», всегда есть нечто несовершенное, весьма далёкое от идеала. Если кто-то знаком с таким явлением, то он не станет заявлять про ещё один проект (под названием «скрам») мол он успешнее всех успешных успехов, а потому всем нужно пилить только его, а кто не пилит — ну он просто некомпетентен.
НЛО прилетело и опубликовало эту надпись здесь
Менеджер имитирует бурную деятельность, ИТ отдел не бездельничает. Никого не выгоняют. Нормальная ситуация. Все заняты, все работают, всем хорошо.

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

Я, конечно, программист «древней» школы, опыт разработки более 30 лет… Но, извините уж, так и не понял — блокчейн взят типа как пример? Или и правда больше нету понимания того, что такое информация… Если как пример, то конечно, статья годная, наверно… Но это не точно… А вот если всерьез — то я очень рад, что никто этого не заметил, значит моя ценность как специалиста скоро еще возрастет :)
Вы задали очень философский вопрос…
Судя по комментариям выше, например "Какой смысл городить 2 месяца архитектуру с тоннами абстракций..." — то да, похоже понятия информации, данных, дата-флоу и т.д. «устарели»… И блокчейн в таком случае — просто один из примеров…

Интересно, если бы программисты взялись спроектировать, например, карьерный самосвал — то процесс проектирования тоже бы проходил по Скраму? То есть, раз времени выяснить характеристики проектируемого самосвала нету, то поэтому уже по окончанию 1й недели заказчик получит работающий прототип — садовую тачку, например? А уже потом будем «наворачивать» к этой тачке функционал — еще колеса, двигатель и т.д.
Ну вы же и сами понимаете, что хардварь и стартап-однодневка с единственной продаваемой фичей на авось вдруг выстрелит — это совершенно разные вещи. MVP на то и MVP, что бы как можно быстрей из г и палок, лишь бы успеть и прощупать идею. А там если взлетит, то и «инженеров» подключать будет смысл.
Это же как раз типичная инфографика гибкой разработки (хотя «гибкость разработки» — термин вообще говоря широкий и необязательно именно так инстанцируется) — вместо того, чтобы сделать сначала кабину, потом колесо, а потом двигатель, вы сначала делаете садовую тачку, ну и дальше ее улучшаете. MVP есть, ура, можно работать дальше. Просто с карьерными самосвалами это прямо в таком виде не работает, чуть иначе надо.
Интересно, если бы программисты взялись спроектировать, например, карьерный самосвал — то процесс проектирования тоже бы проходил по Скраму?

СКРАМ — одна из версий системного подхода, реализованного для разработки софта.
Управление промышленными проектами — обычно PRINCE2.
Инженерными проектами — по стандартам ISO. Их много там используется, начинать можно с этого ISO/IEC 15288
Но все стандарты ISO и все методологии построены все равно на «системном подходе» и цикле Деминга.
В реальности материальные продукты проектируются и выпускаются по похожей методологии как и SCRUM. Это один из видов «цикла разработки», «жизненного цикла» продукта. Похожесть там на уровне идей и методологий. Но сроки иные и циклы разработки организованы иначе. Причем чаще всего циклов разработки одновременно много запущено параллельно, циклы не всегда полностью отрабатываются.
Если интересно, то многое есть в книге Wasim — Standards for engineering design and manufacturing
Еще очень хорошо скрам работает в аутсорс компаниях, когда разработчик одновременно работает на 4-х проектах, и по каждому из проектов разные собрания, 30% времени тратится на эти изматывающие морально собрания, после которых уже и задачи нормально не поделаешь)
Скорей всего не везде так, но это мой личный опыт работы по скраму)

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

Слово "российский" можно убрать из заголовка :)

У скрама есть то, что тут никто не упоминул-работа команды. Скрам-мастер только коордионатор. Все делает команда, прежде всего, что нужно сделать, какие есть скрытые камни, где спрятан остальной айсберг работы. Команда от слова "скрам", это термин американского футбола, когда перед игрой команда кучкуется и ищет решение для победы в игре.
Когда один участник проекта подначивает другого, и тот ему дает обещание, что сделает код, который задействует вопрошающий.
Это не тупой конвейер, это заговор по решению проблем.
Если всех надо тянуть, заставлять, это не скрам. Это натягивание совы на глобус.
И да, прикручивать к ЕРП блокчейн, не понимая, что это даст, это тупость заказчика, и неопытность исполнителя, который на это решился.
P.S., Блокчейн это очень тяжело и трудно, видимо, никак хайп еще по этой теме не угас.

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

Вообще то классический метод начинается с PID (Project Initiation Document/Documentation). И кто вам сказал что PID не может иметь business value и не может поставляться в конце спринта? А может PID уже есть? Просто вам его никто не показал? Может уже прошли фазы инициализации и планирования и есть куча документов, откуда можно извлечь множество ответов? Или нет вообще нифига кроме договора T&M (Time and Material) между аутсорсером который вас нанял и компанией над проектом которой вы типа работаете? И надо говорить с бизнесом (люди управляющие бюджетом) на понятном ему языке — про деньги, а не про описание сущностей, их связи, архитектуру и т.д.

Кстати, судя по отсутствию QA/QC у вас вообще может быть НИОКР a.k.a. R&D проект, приемлемым результатом которого будет PoC (proof of concept) или прототип или вообще набор документации с описанием метрик и методологий их сбора и рассчета — для создания точки отсчета у будущих проектов.

ЗЫ. У вас там хоть один помидор сваренный в западном Кровавом Ынтерпрайзе в команде есть? Или все модно-стильно-молодежно — скрам-стартап-блокчейн?
В команде предусмотрена должность Скрам-мастера (SCRUM Master), который всего лишь проводит совещания, формулирует и записывает итоги обсуждения.

Скрам-мастер — не должность, а роль, совмещаемая с другой ролью в проекте. Если где-то видите отдельного скрама, то к гадалке не ходи — результат будет далёк от ожидаемого. Этот человек не будет работать на бизнес-результат, у него другие интересы — провести ритуальные церемонии, показать burndown, написать строчку в резюме...

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

И задача скрам-мастера кроме всего прочего это быть непредвзятым медиатором и помогать решать конфликты внyтри команды. Что очень трудно делать если он сам «заинтересованная сторона».
Выделенный скрам мастер тупо не наберёт фул тайм с одной командой. Значит ему вести несколько команд надо. В реальности часто скрам мастер совмещает роль PO — общается со стейкхолдерами, прорабатывает бэклог, готовит отчётность. Это уже вполне себе фул тайм в пределах одной команды и продаваемая заказчику роль, и работает плюс минус нормально, если угадать с человеком. Ну это про относительно небольшие проекты конечно.

Работа занимает всё отведённое время. Следовательно, выделенный скрам будет заниматься своими игрушками фултайм. А чтобы ему не было скучно, он позовет разработчиков в переговорку, чтобы обсудить все животрепещущие, в его представлении, вопросы.

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


А во вторых на мой взгляд быть одновременно скрам-мастером в нескольких командах это ещё куда ни шло. А вот быть в одной и той же команде и ПО и скрам-мастером это наверное самое худшее что можно придумать. Тогда уже лучше сделать так что он скрам-мастер в одной команде и ПО в другой.

На моей практике в небольших проектах, где на стороне заказчика нет вменяемого PO, а лишь стейкхолдеры бизнес толка — вполне себе работает. По большому счёту это тот же по старым понятиям PM, но с другими ритуалами и подходами. А смысловая роль всё та же — посредник между заказчиком и разработкой.

Ну так проблема именно в том и заключается что мы получаем "своеобразного PM по старым понятиям".
То есть это может быть даже как-то более-менее работает. Вот только к скраму это уже никакого отношения не имеет.


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

Почему не имеет? Скрам это роли + процессы. Скрам не требует, что бы роли выполняли разные люди. Да это best practice, но это не требование скрама.

Ну во первых если мы имеем PMa хоть в каком то виде, то о каком скраме может идти речь?


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

Ещё раз, скрам — это набор методик разработки, роли и процессы. То, что один человек, выполняет две роли не делает процесс не скрамом. Главная и основная роль PO — это поддерживать беклог и приоритеты в актуальном состоянии и общаться со стейкхолдерами. Часто скрам мастер этим и занимается и это достаточно нативно и не приводит к противоречиям, главное, что бы этим занимался грамотный T-shaped человек.

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

Роль скрам-мастера конкретно описана. Если он комбинирует эту роль с какой-то другой ролью в своей же команде, то он просто не может бытъ скрам-мастером из-за своеобразного «конфликта интересов».
Более того практически в любом описании скрама указано что скрам-мастер ни в коем случае не должен «мутировать» в тимлида или PMa.

И да, наверное где-то в мире существуют люди которые могут абсолютно непредвзято быть одновременно и ПО и скрам-мастером. Но я пока таких не встречал. По моему опыту как только эти роли начинают совмещать, так сразу такой ПО-скрамастер начинает прогибать процессы под себя. И превращается в того самого PMa. То естъ в теории может быть и допустимо такое совмещение, но на мой взгляд на практике это нормально работатъ не будет. И судя по отзывам людей работающих по такому «скраму» оно и не работает.

Скрам мастер по своей роли — сам по себе конфликт и головная боль команды, ибо именно он навязывает противоестественный для нормального программиста-интроверта процесс.

А это вообще на мой взгляд из пальца высосано. С чего вы взяли что процесс обязательно противоестественнен для любого «программиста-интроверта»? И самое главное с чего вы взяли что все программисты вдруг являются интровертами?
Не улавливаю, а в чём конфликт между ролью PO и scrum master? Один составляет беклог и приоритеты, другой фактически по процессу делает так, что бы спринты выполнялись, вместе — составляют спринты. Они сотрудничают, а не конфликтуют. Этим скрам как методология и хорош.

>С чего вы взяли что процесс обязательно противоестественнен для любого «программиста-интроверта»?

Да взять хотя бы ежедневные стендапы, не говоря уже о ретроспективах. Это основное, чем обычно недовольны программисты, когда их выдёргивают из зоны комфорта. Особенно программистов старой школы, как автор статьи и я сам.
Не улавливаю, а в чём конфликт между ролью PO и scrum master?

Ну например в том что решения о том как конкретно должны выглядеть процессы должны принимать вместе ПО и девтим. Например то как должно выглядеть DoD, как считать сложность тасков, использовать покер или нет и т.д. и т.п. А скрам-мастер должен только следить чтобы всё это не выходило за рамки скрама.
Но если у вас скрам-мастер одновременно и ПО, то он будет всё это организовыватъ так как удобнее лично ему. И хорошо если он это будет делать ненамеренно/подсознательно. А то ведь он вполне может и умышленно начать манипулировать командой. Ведь это он в конце-концов решает вписывается что-то вскрам или нет.

Да взять хотя бы ежедневные стендапы, не говоря уже о ретроспективах.

Вот как раз таки нормальные «ванильные» стендапы и ретроспективы раздражают людей достаточно редко. Особенно если грамотно организованны.

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

Особенно программистов старой школы, как автор статьи и я сам.

Ну вот именно: мы имеем каких-то отдельно взятых «программистов старой школы» которым что-то не нравится или что-то не устраивает. Но это не значит что это не устраивает абсолютно всех «программистов старой школы». И самое главное это совсем не значит что у нас все программисты являются этими самыми «программистами старой школы».

То есть я вполне себе допускаю что есть куча людей для которых скрам не подходит по тем или иным причинам. И в этом нет ничего плохого. Но это не делает скрам «противоестественным» по умолчанию.

Тут наверное уже идут те самые интерпретации Скрама, которые в каждой компании свои. Чистый скрам я нигде не видел, в частности «чистый» poker game, это что-то сферическое. В тех интерпретациях, в которых я участвовал, PO — это главным образом про сбор беклога и приоритетов и работу со стейкхолдерами. Соответственно там нет конфликта про то, как собственно спринты будут выполняться, по большому счёту для PO выполнение спринтов — это black box с определёнными KPI выполненния спринтов. В саму «технику выполнения» спринтов PO и не лезет и потому конфликта со scrum masterom нет (только если спринты не начинают регулярно фейлиться).

>И как раз это не должен допускать скрам-мастер. Bот вам и конфликт интересов на практике.

Ну так это «должностные обязанности» скрам мастера выполнять спринты по процессу, где «отчёт о работе» означает конкретные артифакты спринта. Если же скрам мастер допускает превращение ретроспектив и стендапов в отчёты каждым программистом, что он сделал — то скрам мастера надо гнать в шею. И PO вместе с ним, раз это один и тот же человек :) Я потому и говорю, что нужно правильного человека на эту роль найти, что бы понимали обе роли и где проходят границы. Такие люди есть.

>А вот если скажем стендап превращают в «отчёт о проделанной работе», то это многих раздражает.

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

Ну, как я уже писал выше, они может где-то и естъ, но я пока таких не встречал. А вот рсли послушать рассказы людей, которые работают с такими «комбинациями», то обычно ничего хорошего из этого не выходит. И как раз таки такое обычно и приводит к недовоьству скрамом среди программистов.

Это ключевой процесс «мотивации» программистов и выявления проблем как можно раньше и это ни фига не комфортно никому.

Опять таки оченъ субъективное заявление. Лично у меня нет никаих проблем с тем чтобы сказать своим коллегам что у меня возникли какие-то проблемы мешающие мне в работе. Особенно если учитывать что в большиснтве случаев моей «вины» в этих самых проблемах нет.

И вот лично я бы не сказал что стендапы имеют какое-то отношение именно к мотивации людей. Они существуют для того чтобы выявитъ проблемы если таковые вдруг возникли. По крайней мере у нас это так.
>И вот лично я бы не сказал что стендапы имеют какое-то отношение именно к мотивации людей. Они существуют для того чтобы выявитъ проблемы если таковые вдруг возникли.

Очень многие не любят, когда их выдёргивают посередине задачи, когда осталось 2 часа, что бы эту задачу закрыть и вместо этого заставляют терять фокус и рассказывать, почему же пришлось потратить больше времени, вместо того, что бы работать. Очень многие вообще хотят жить в тепле и уюте, что бы их неделями вообще не трогали и дали «спокойно покодить». Тем более, что такие работы есть. Скрам со всеми этими ритуалами не особо комфортен для таких людей. Но, цинично скажем, это их проблемы в современном мире.
Очень многие не любят, когда их выдёргивают посередине задачи, когда осталось 2 часа, что бы эту задачу закрыть и вместо этого заставляют терять фокус и рассказывать, почему же пришлось потратить больше времени, вместо того, что бы работать.


И зачем это тогда делать? Ну то есть с чего вы решили что это обязательное условие стендапа? Кто мешает делать эти самые стендапы в начале рабочего дня? Перед обедом? После обеда? Перед уходом домой? Ну то есть тогда когда люди всё равно сами по себе отрываются от работы?

И опять же: да это не всегда возможно. Ну так никто и не говорит что именно скрам будет работать всегда и везде. Иногда он не подходит и тогда стоит выбрать что-то другое. Даже если это будет водопад.
Затем, что стендап — это чёткий и главный ритуал скрама, на котором основаны метрики backlog burnout и обратная связь для scrum master => PO. Promises vs reality — это самое главное в стендапе. Если всего этого нет, то это не скрам, а культ карго.
А вот это уже на мной взгляд какая-то ваша личная «интерпретация» этого самого стендапа. Тот же «backlog burnout» вообще не является чем-то обязательным для скрама.
Не вижу смысла продолжать дискурсию, походу мы не о скраме дискутируем, а о каком-то фейке скрама.
Вопрос только в том у кого из нас он «фейковый»…
The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal.

https://www.scrumguides.org/scrum-guide.html#events-daily


Никаких backlog burnout, никаких "обратная связь для scrum master => PO", никаких "Promises vs reality"


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


В общем выглядит так, что фейк скрама скорее у вас

Если уж цитируете библию, то цитируйте ключевое.

What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Это и есть обратная ключевая связь для Scrum Mastera. Особенно последний пункт.
Во первых эта информация совсем не обязательно именно для скрам-мастера. Возможно она идёт только для девтима. Для скрам-мастера интересны далеко не все impediments. А уж ПО тут вообще сбоку. Он даже на стендапы и ходить не обязательно должен. Опять же цитата: "The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting."

А во вторых где там хоть слово про «backlog burnout» и/или обязательность его наличия?
Про связь с PO я недостаточно выразился. Под scrum master => PO я подразумеваю их частое общение о прогрессе между собой, если это не один и тот же человек.

Burnout chart — это чисто техническая штука как производное issue tracking системы. Он просто есть by default. Scrum master, получая ежедневный фидбек на стендапах (кстати стендапы не просто так стендапами называются, они именно про выход из зоны комфорта), соответсвенно может прогнозировать, что у него будет с burnoutом и возможно внесёт корректировку в спринт (хоть это и не приветствуется).
Под scrum master => PO я подразумеваю их частое общение о прогрессе между собой, если это не один и тот же человек.

И в каком месте определения скрама написано что это должно обязательно иметь место?

Burnout chart — это чисто техническая штука как производное issue tracking системы. Он просто есть by default.

С чего вы это взяли? Если это так у вас, то оно не обязательно должно быть так у всех.

Scrum master, получая ежедневный фидбек на стендапах, соответсвенно может прогнозировать, что у него будет с burnoutом

Cкрам-мастера по хорошему вообще прогресс как таковой не интересует. Что и как закоммитил девтим и что они смогут показать на ревью это дело этого самого девтима. Скрам-мастер это контролировать совсем не обязан.

кстати стендапы не просто так стендапами называются, они именно про выход из зоны комфорта

«Стендапы» вообще называются «Daily Scrum Meeting». Они могут проводится в форме этого самого «стендапа»(то есть стоя), а могут и как-то по другому. Это каждая команда может решать для себя сама.

и возможно внесёт корректировку в спринт (хоть это и не приветствуется).

Скрам-мастер не имеет никакого отношения к «корректировкам спринта». Это не его дело и не его решение. Ну вот вообще никак.
>И в каком месте определения скрама написано что это должно обязательно иметь место?

А где я утверждаю, что это должно быть у всех?

По факту по ходу разработки то к PO часто вопросы возникают, и тут как раз хорошо, если SM и PO — одно и то же лицо, ускоряет комуникацию.

>С чего вы это взяли? Если это так у вас, то оно не обязательно должно быть так у всех.

Ну для скрама это как бы такая естественная вещь. Спринт — это набор тасков в системе. Burnout — количество закрытых делённое на общее число тасков. Это чисто технический KPI, необходимый для SM, что бы среагировать на низкий burnout как можно раньше.

>Cкрам-мастера по хорошему вообще прогресс как таковой не интересует.

Мда, приехали…

В ваших проектах стейкхолдеры это кто?
А где я утверждаю, что это должно быть у всех?

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

По факту по ходу разработки то к PO часто вопросы возникают, и тут как раз хорошо, если SM и PO — одно и то же лицо, ускоряет комуникацию.

И в чём разница если у вас ПО и скрам-мастер это два разных человека? Кто мешает разработчикам просто взять и напрямую спросить у ПО?

Ну для скрама это как бы такая естественная вещь.

Как бы нет.

Спринт — это набор тасков в системе. Burnout — количество закрытых делённое на общее число тасков. Это чисто технический KPI, необходимый для SM, что бы среагировать на проблему как можно раньше.

Во первых он не является необходимым. А во вторых скрам-мастер вообще-то на такое реагировать и не должен. Это не входит в его обязанности.

Мда, приехали…
В ваших проектах стейкхолдеры это кто?

Ну вообще-то обычно представители клиентов. Но однозначно не скрам-мастер.
>Кто мешает разработчикам просто взять и напрямую спросить у ПО?

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

>Ну вообще-то обычно представители клиентов. Но однозначно не скрам-мастер.

Кто отвечает клиентам о прогрессе?
ПО без контроля SM может нагородить отсебятины, увеличивающих эстимейт таска или порождающий новые таски.

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

Кто отвечает клиентам о прогрессе?

Во время спринта никто. На ревью это делают ПО и девтим.

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


Ну и считать процент завершенных тасок бессмысленно в целом. Ничего не говорит результат спринта "мы сделали 9 тасок из 10".

Что бы поставить задачу в спринт — её надо заестимейтить. Что бы её заестимейтить — её надо проработать на достаточно подробном техническом уровне, и эту детализацию куда-то записать. Это уже далеко не бумажка на доске.

>Ну и считать процент завершенных тасок бессмысленно в целом. Ничего не говорит результат спринта «мы сделали 9 тасок из 10».

Зато «мы выполнили последние 3 спринта в среднем с успехом в 90%, поэтому вносим поправку в эстимейты на коэффициент 1.1, что бы постараться следующий спринт выполнить на 100%» — это имеет смысл. Хоть и редко работает по факту.

Это решает команда, достаточно ли ей бумажки на доске или нет.


Для оценки капасити команды нужно не количество тасок считать, а суммарный эстимейты, например, "запланировали задач на N попугаев, сделали на 0.9 M попугаев. В следующий раз берём на 0.9 M, если с попугаями работать удобно"

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

На фига вам SM, который даже на стендапах не присутствует?
Спрашивать совета если что-то непонятно в том как должен работать скрам.
И при необходимости разруливать проблемы с «окружающим миром».
Как он может разруливать, если он по вашему описанию для команды 1) стороннее лицо 2) не отвечает за выполняемость спринтов?
Эээ, а почему это должно ему мешать что-то разруливать? Он может и не отвечает за выполнение целей спринта как таковых, но он отвечает как раз за то чтобы разруливать эти самые проблемы.

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

За выполняемость спринтов отвечает команда разработки, ни ПО, ни СМ в неё не входят, они входят в скрам команду вместе с командой разработки.

В реалиях жизни колхоз никогда ни за что не отвечает, а топам и клиентам нужны конкретные люди с ответственностью. В моих реалиях это люди, совмещающие SM/PO. Но у меня относительно небольшие проекты с командами до 10 человек и там это отностительно хорошо работает. В больших компаниях, где SM это отдельный некий коуч, не лезущий в ежедневную работу конкретных команд (и возможно это более правильный скрам) — по другому, спорить не буду. Важно, что оно и у вас, и у меня — работает, проекты делаются, и скрам кому-то помогает.

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

>все программисты вдруг являются интровертами?

Лень искать, но иследования на это тему были, большинство программистов высокого уровня — интраверты. Интровертство создаёт условия более тщательного изучения предмета (больше времени и более сосредоточенно человек торчит в конкретной теме), отсюда и более высокий конечный уровень.
Ну даже если это вдруг так(в чём я лично всё ещё не особо уверен), то это всего лишь означает что скрам не всегда хорошо подходит в том случае если у вас в команде есть эти самые «программисты высокого уровня». Но это далеко не всегда так.
Скрам — не про программистов, скрам — про процесс имплементации требований стейкхолдеров. Программисты почему-то часто ожидают, что скрам и любая другая методология должны быть им комфортны. И вот тут противоречие. Такие методологии больше про то, как их заставить работать и выдавать результат в проектах с относительно часто меняющимися требованиями :)
Скрам — не про программистов, скрам — про процесс имплементации требований стейкхолдеров.

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

Программисты почему-то часто ожидают, что скрам и любая другая методология должны быть им комфортны.

Да. Ожидают. И я ожидаю. И ничего неправильного в этом не вижу.

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

Не cоглашусь. Такие методологии существуют для того чтобы сделать работу более комфортной «в проектах с относительно часто меняющимися требованиями». Проблема то в том что даже если вы откажетесь от скрама, то это совсем не означает что требованию вдруг по волшебству начнут реже меняться…

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

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