Комментарии 162
Видел такие истории, но в большинстве случаев, это просто слив бабла, тут обычно 2 варианта или с гордостью отдаете кнопку, делите деньги и сливаетесь или заявляете, что теперь ЕПР тоже надо адаптировать к болкчейчну, но для этого ее надо полностью переделать, что бы блокчейн могла распознать и на входе и выходе и все такое.
В общем все не так плохо у Вас, творите, наслаждайтесь, а если откажетесь, так там уже очередь стоит со своими услугами.
Пользователь не хочет никакой системы получить. И уж тем более, ему плевать на блокчейн. Нужно не нафантазировать, что он хочет, а пойти и спросить у него и бережно записать.
Блокчейн нужен, если есть какая-то пользовательская история, которую невозможно сделать без блокчейна, но очень хочется. А не просто так от балды.
Пользовательская история — это запись требований в таком виде, чтобы каждому был очевиден буллшит в постановке задач. Чтобы уборщица посмотрела в бэклог и могла сказать: «так не бывает, так живые люди не делают». «Добавить блокчейн» — никому не нужен блокчейн. «Я, как начальник участка хочу видеть, кому нужно всыпать люлей за низкую производительность» — вот это по-нашему.
Вы приняли пожелание заказчика
Тут весь вопрос кто в скраме этот "Вы" который должен принимать или не принимать корректно или не корректно поставленную задачу. Коуч, который далек он всего прикладного только следит чтобы все было "по скраму". Разработчики и заказчики все равны и все решения принимаются на скрам-церемнониях способом "все согласны?".
Это же детство — рассчитывать, что за вас кто-то будет другой думать. Сбору и анализу требований учат в вузе, любой разработчик это умеет.
Если говорить о типичной такой софтверной компании, то разработчик вообще получает пракатически готовые требования, т.к. такова жизнь. Чтобы разработчик начал работать, его нужно оплатить, а значит уже должен быть договор, техническое задание. Хорош если будет выделено одному из разработчик несколько часов на анализ и оценку.
Если нет того кого раньше называли руководитель проекта (что не является синонимом менеджер проекта) все решения будут усредненными, никакими.
Ну обычно в софтверных компаниях за этим следят и кодить приходится больше. Я уже не говорю о галерах где порой есть логирование снимков экрана, клавиатурной активности, вплоть до наблюдения через веб-кмеру.
Зависит от построения процесса в компании. Вот буквально прошлая пятница, 11 утра:
Тимлид — "Слушай, тут хотят, чтобы таймаут связи происходил только когда нет пакетов N, можешь сделать чтобы только они таймер сбрасывали? А пакеты M, Q игнорить."
Я — "Говно идея, у нас есть кейсы X, Y и Z, когда пакеты N и Q не идут, а только пакеты M есть, если так сделать всё развалится — можем в сбросе таймаута просто начать игнорить Q, тогда будет примерно оно, но на глаз один хрен почти ничего не поменяется."
Тимлид — "Хм, хорошо, спрошу у заказчика, можно ли так."
Вот уже понедельник, всё ещё сидим, ждём пока разродятся. Можно конечно сказать "ну так сиди рефакторь", но чтобы опять предъявили "зачем ты столько кода поменял, на вид же всё так же работает, не делай так больше" — оно мне надо?
[оффтоп]Ну и сразу вопрос: а почему вы сами внутри себя не можете такой вопрос решить? Владелец — он ведь про бизнес, про продукт, а не про пакеты.[/оффтоп]
Если сверху пришла задача про пакеты, значит, кто-то вверху — про пакеты.
Ничего и не делали. Разве что ещё пара багов, один из которых — очепятка в локализации, а второй — тестеры со стороны заказчика забыли включить колонки на стенде и отписались что "ваше обновление звук сломало теперь".
Там не владелец сверху, а другая контора, со своими разработчиками и менеджерами.
Так что тут лучше именно выяснить — хотят они таймаута при именно конкретных пакетах, или таки тогда, когда это лучше пользователю. Уже были прецеденты — делал так, как логичнее со стороны пользователя, и прилетали жалобы переделать в том виде, как оно было поставлено со стороны техники — но, увы, совершенно неюзабельно с точки зрения 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!
Я с Вам полностью соглашусь. Если менеджмент адекватный — то разработка тоже будет адекватной. Вчера на Хабре кстати было опублковано интервью с сотрудниками Амазона из которого свидетельствует что там разрботка идет по скраму 2-недельным спринтами. Но там ничего не говорилось о карго-скраме и о скрам-тамадах.
А когда появляется «группа инициативных менеджеров» которая зачем-то, сама не знает зачем, хочет блокчейн и скрам, а исполнители при этом не могут влиять на процесс (а может и не хотят или не умеют), то все. Ничего хорошего уже не будет. Надо тикать из такой конторы, пока стокгольмский синдром не случился.
Когда заказчик ТРЕБУЕТ каждую неделю показать какой-то результат, который можно «пощупать руками», то иногда результат выглядит просто смешно.
В публикации как раз и рассказывается про такой «смешной случай», когда вместо того что выполнить подготовительные действия (выбрать, установить и настроить инструменты разработки; описать сущности и определиться со структурой данных, создать ТЗ и т.д.) за 1-ю неделю разработки требуется показать готовый продукт.
«Я, как пользователь, хочу получить систему, в которой производственные и бизнес-процессы предприятия отображаются в блокчейне» — это не только 1-я Пользовательская история, но и общее описание проекта.
Опять таки перед стэйкхолдерами. Отсюда закономерный вопрос — а в чем кайф для программистов?
Ну по хорошему больше свободы в принятии решении и больше контроля над процессом. Это если по хорошему.
Во-вторых применение скрама очень хорошо на относительно коротких интервалах времени, когда нужно привести запущенный проект в чувство.
У меня прямо противоположный опыт. То есть когда нам надо что-то быстро, то скрам обычно не особо хорошо работает. И когда проекты стартуем с нуля тоже обычно работаем по «облегчённому варианту скрама». А вот когда проект уже идёт, то тогда уже переходим на «обычный скрам».
Что значит «быстро» у вас? В моем тезисе я имел в виду интервал условно говоря в квартал — пол года (чтобы говорить о скраме должно быть, ну скажем, – десяток спринтов, каждый по две недели).
Как раз таки примерно те самые квартал-полгода. То есть если у нас проект меньше чем на полгода, то скрам просто не успевает нормально «раскрутиться».
То есть у нас скрам по хорошему это проекты 6 месяцев и дольше. Самый «долгий проект», или точнее самая долгая работа по скраму с одним клиентом над одним продуктом, идёт уже больше семи лет.
Я уже несколько раз выводил проекты/направления из ситуации, когда есть огромных технический долг, сотни открытых багрепортов, каждый день появляется чуть ли не десяток новых, а PO хотят все новых фич каждую неделю. В результате разработчики находятся в ситуации нервного срыва, бояться тронуть хоть что-то. В таких ситуация жесткие итерации спасают.
А это на мой взгляд вообще к скраму прямого отношения не имеет. Это просто обычный бардак и он точно так же может быть и в канбане и в водопаде и вообще где угодно.
Программисты кайф ловили 20-30 лет назад, а теперь программист в большинстве контор, приближенных к «реальной экономике» — это ремесленник, причём очень дорогой и своенравный и им надо как-то управлять, что бы не занимался дорогими художествами, которые заказчик даже не понимает и вряд ли на них заработает. Поэтому всякие скрамы и появились, что бы решать эту задачу. По факту — так себе решают конечно, но это уже хоть что-то между разными другими крайностями.
Отсюда закономерный вопрос — а в чем кайф для программистов?
В отсутствие (в теории) микроменеджмента, в зафиксированных (в теории) хотя бы на неделю-две требованиях, в свободе (в теории) выбирать способы и приоритеты решения задач, напрямую, с правом решающего голоса, участвовать в принятии части управленческих решений типа организации процессов разработки внутри команды.
"Моя" википедея говорит немного по другому "Блокче́йн (англ. blockchain[1], изначально block chain[2]) — выстроенная по определённым правилам непрерывная последовательная цепочка блоков (связный список), содержащих информацию. Связь между блоками обеспечивается не только нумерацией, но и тем, что каждый блок содержит свою собственную хеш-сумму и хеш-сумму предыдущего блока. Для изменения информации в блоке придётся редактировать и все последующие блоки."
Распределенная недоверенная среда — это лишь самое популярное использование технологии.
git — чем вам не блокчейн? Вернее блоктри из нескольких блокчеёнов:)
А если серьёзно, то любые задачи, которые требуют внешней верификации связности и неизменности данных, можно решить с помощью блокчейна. Даст ли он именно существенное преимущество, да хоть какое-то — от задачи зависит, не в последнюю очередь от определения преимущества, а оно очень локально бывает, типа спец по блокчейну у нас в штате есть, а по другим методам — нет.
И хотя скрам действительно может не подходить всем и каждому (например, сложно его рекомендовать при разработке железа), но к описанной выше истории это не имеет никакого отношения.
У вас была попытка использовать ритуалы скрам на уровне карго-культа. Но к реальной разработке это не имеет никакого отношения.
Да, согласен, вопросов не возникает, когда уже есть готовый продукт, — например, какой-то сайт. И требуется исправить пару опечаток на страницах этого сайта — здесь проблем нет. Создаем Пользовательскую историю типа «Я как пользователь сайта, хочу увидеть исправленную оЧеПятку на заглавной странице сайта с целью увеличить привлекательность сайта».
Успешно оцениваем каждую такую Пользовательскую историю в 1 (или даже 5) баллов. Успешно решаем задачу и к концу спринта получаем новую итерацию нашего продукта — сайт с исправленной
Но когда у нас стартап и мы вместо разработки его архитектуры сразу начинаем кодить
Простите, получается 24k$ фот пятерых, то есть зп каждого более 4000$? Не каждый senior так живёт, неплохо-неплохо.
С чего взяли что нужно сделать юзер стори? Мы на первых спринтах показываем то с чего действительно начинается проект: настройка среды разработки, конфигурации серверов и баз данных, всякие средства для тестирования и т.д.
То есть вы за неделю вместо нескольких месяцев наглядно показали заказчикам, что получается херня, и теперь ни вы, ни они не довольны? Во истину беспощадный скрам!:)
Ответ: — Да, воистину херня.
При чем здесь SCRUM? Все очень просто — в описываемой истории именно благодаря нему все эти этапы (предварительное планирование, разработка архитектуры, структуры данных и т.д.) отсутствуют…
Все очень просто — в описываемой истории именно благодаря нему все эти этапы (предварительное планирование, разработка архитектуры, структуры данных и т.д.) отсутствуют…
Нет, они отсутствуют благодаря тому, что вы делали какую-то херню. Архитектура, бизнес-анализ, системный анализ, документиррвание и тд — вполне себе цели в скраме. Мне кажется, вы вообще не прнимаете о чём сами говормте. Описываете криво поставленный заказной галерный аутсорс и называете это, почему-то стартапом. Что стартапного в рутинном аутсорсе? Описываете, как какие-то идиоты совершали карго-ритуал и называете это, почему-то скрамом. Я не люблю работать по скраму, но я участвовал в реально строгом скрам-процессе, когда всё что делается, действительно делается только по скраму и ни как не иначе. Это было муторно для меня, но это реально работает. И в этом процессе команда просто не может взять в работу юзер-стори "сделайте, чтобы всё работало". Первые стори будут — "исследовать что такое 'всё'" и "что значит 'работает'". По результатам исследования ставятся задачи на бизнес-анализ, архитектуру, дальнейшие исследования… Инкрементом бизнес-ценности в этом случае будет повышение компетенции команды в домене, создание проектной документации. Кто вам сказал, что инкрементом обязан быть сайт с кнопочкой? Сами придумали херню, сами сделали херню. Герои!
Прочитайте, пожалуйста, 1й дисклеймер публикации.
Первые стори будут — «исследовать что такое 'всё'» и «что значит 'работает'». По результатам исследования ставятся задачи на бизнес-анализ, архитектуру, дальнейшие исследования… Инкрементом бизнес-ценности в этом случае будет повышение компетенции команды в домене, создание проектной документации. Кто вам сказал, что инкрементом обязан быть сайт с кнопочкой?
Оригинальный вариант интерпретации.
Аналогия — заказчик хочет атомную бомбу. Далее по вашему:
Первые стори будут — «исследовать что такое 'бомба'» и «что значит 'атомная'». По результатам исследования ставятся задачи на бизнес-анализ, архитектуру, дальнейшие исследования… Инкрементом бизнес-ценности в этом случае будет повышение компетенции команды в домене, создание проектной документации. Кто вам сказал, что инкрементом обязан быть сайт с кнопочкой?
Вы вчитайтесь в собственное понимание на показанном примере. Вчитались? Или пропустили текст и только ухмыляетесь? Вчитайтесь, очень полезно.
Кто вам сказал, что инкрементом обязан быть сайт с кнопочкой?
Об этом говорит заказчик. Он знает, что итерация равна неделе. Он хочет увидеть бомбу через неделю. Ну или что-то похожее на бомбу. И если мы ему покажем не бомбу, а, скажем, план завода по производству бомб, он нас спросит — а за что я вам плачу деньги? Где бомба? Потому что он знает, как контролировать сроки — время прошло, а понятного результата нет.
Вообще переводить на модные методики выжимания пота всё и вся — это маразм. Этот маразм исходит не от программистов, а от тех, кто принимает решения о загрузке программистов. И не важно, как они там себе всё обосновывают. Хоть деньгами, хоть причудами заказчика. Если инструмент не соответствует задаче — в топку такой инструмент. А если кто-то готов платить программистам за безумства — почему бы программистам не взять себе деньги и предоставить разумный по их мнению результат (хоть и безумный с точки зрения заказчика)? Почему вы все (фанаты модных потовыжималок) считаете, что программист обязан исправить пустоту в головах, сначала, своих работодателей, а потом ещё и в башке абсолютно тупого заказчика? Он программист или мозговед? Но даже мозговеды не могут исправить пустоту, они только вид делают, что бы опять же денег срубить. А вы (фанаты моды) представляете себе мир с розовыми пони, которые ср*т исключительно шоколадом. И потому обвешиваете программистов задачами по исправлению пустых мозгов, параллельно с изучением атомного ядра и проектированием эффективного цикла производства ядерного оружия.
Маразм со стороны заказчиков поддерживается маразмом со стороны фанатов моды. В итоге получается маразм в квадрате. Но фанаты моды снова и снова поучают всех, мол вы не правильно наши модные штучки используете, а с заказчиком нужно дружить и стараться его удовлетворять. Да, даже если он хочет невозможного. Ведь он же вам денег даёт! Он святой, а вы обязаны его любить.
Но к счастью в мире есть более адекватные заказчики и фирмы по разработке софта. Поэтому лицам с пустыми головами оставляем задачу выживания в конкурентной среде за счёт повышенного расхода капитала.
А вы должны задать себе вопрос — почему вы связались с заведомо провальным проектом по неподходящей для проекта методологии. Скрам работает, когда выполняются ключевые его требования и предпосылки. Скрам про agile, про проекты с меняющимися во времени требованиями, это не проекты «под ключ», там он работает плохо.
Вы вчитайтесь в собственное понимание на показанном примере. Вчитались? Или пропустили текст и только ухмыляетесь? Вчитайтесь, очень полезно.
Что вы имеете в виду? Я сказал ровно то, что сказал. От того, что вы бомбу подставили ровным счётом ничего не изменилось. Если разрабатывать бомбу "по скраму", то, да, именно такие стори и будут. Тут нет разницы. Вообще. А если того же Фейнмана почитать, то приблизительно так они Бомбу и разрабатывали.
Об этом говорит заказчик. Он знает, что итерация равна неделе. Он хочет увидеть бомбу через неделю. Ну или что-то похожее на бомбу. И если мы ему покажем не бомбу, а, скажем, план завода по производству бомб, он нас спросит — а за что я вам плачу деньги?
Вы, как и автор этой статьи, говорите какую-то херню, абсолютно не понимаю смысл того, что говорите. Нет такого в скраме — потому что заказчик сказал. Задачи обсуждаются с продакт-оунером до степени понятности всем сторонам, а не тупо спускаются сверху, — "сделай мне хорошо". Если команда не понимает как делать задачу и сделает ли она её за спринт, она НЕ берёт задачу в работу. Тут дело не в методике дело, а в некомпетентности команды. С любой другой методикой в данном случае было бы то же самое.
Если инструмент не соответствует задаче — в топку такой инструмент.
С инструментом тут всё в полном порядке. Тут в другом проблема — заставь дурака богу молиться, так он и лоб расшибёт. Для задачи в том виде, как она описана, инструмент вполне подходящий. Но применён через джоппу.
Вообще переводить на модные методики выжимания пота всё и вся — это маразм.
Вообще, эджайл — это, как раз уход от методик выжимания пота :). При правильной постановке команда полностью изолируется от внешнего давления и это офигенный плюс данной методики.
Этот маразм исходит не от программистов, а от тех, кто принимает решения о загрузке программистов.
Вот видите. Вы полностью некомпетентны, как и автор. Эджайл — как раз исходит от программистов. Если нет, значит вы используете микроскоп для колки орех. Да, о-очень часто применяется неправильно. Да, подходит не для всех команд. Хотя бы у части членов команды должна быть достаточно высокая квалификация И достаточно высокий уровень ответственности. Для "команды" инфантильнных хикимори кодеров — не подходит однозначно, там нужна армейская иерархия с прапорами и сержантами, пинками и сапогом заполняющими пустоту в мозгах мамкиных "пограммистов".
Почему вы все (фанаты модных потовыжималок) считаете
Интересно, вы по жизни лжец или просто не читаете то, на что отвечаете? Я в явном виде написал, что лично мне скрам не нравится, а вы всё равно врёте как сивый мерин.
что программист обязан исправить пустоту в головах, сначала, своих работодателей, а потом ещё и в башке абсолютно тупого заказчика? Он программист или мозговед?
А, понял. Вы, похоже, не делали ничего сложнее уеб-сайтиков-визиток? Или работали маленьким винтиком в большом водопаде? Это бывает. Ничего страшного в этом нет, но не стоит обобщать свой крохотный опыт и делать выводы космической глупости. При чём здесь программисты вообще? Вы когда-нибудь слышали о бизнес-анализе? Системном анализе? Архитектуре? Перед тем, как задача передаётся на кодирование "программистам веб-сайтиков", над нею работают аналитики, архитекторы, специалисты по извлечению данных. И именно они "заполняют пустоту в головах" как заказчиков, так и программистов. А вы думаете задачи программистам волшебным образом возникают из пустоты? Нет, точно так же аналитика и системный анализ. Просто в скраме данные роли нередко (но необязательно) отдаются внутрь команды, а не откуда-то из облаков спускают сверху свои глубокомысленные указания (в сферическом скраме в вакууме они ещё и не фиксируются за членами команды и каждый может выполнять любую функцию, но такое не всегда возможно). Ну, вот это такой способ решения задач. Да, он отличается от водопада. Да, он имеет недостатки по сравнению с водопадом. Равно как и преимущества. Выбор тут за командой как им удобнее работать. Команда автора статьи, похоже, вообще не понимала зачем им скрам-эджайл и поэтому не справилась с проектом.
Но к счастью в мире есть более адекватные заказчики и фирмы по разработке софта.
Ну, тут каждому своё — кто-то предпочитает тупо кодировать взявшиеся с неба постановки задач, а кому-то может быть интересно поучаствовать и в постановках-анализе тоже. В данном случае было очеведное использование инструмента не по назначению, вызванное каким-то диким непониманием всего и вся (я так и не добился ответа почему автор банальный аутсор на галере упорно называет стартапом :) ).
я так и не добился ответа почему автор банальный аутсор на галере упорно называет стартапом :)
Есть такой вид проектов: некто с некоторыми свободными ресурсами хочет проверить бизнес-идею с сильной составляющей ИТ, набирает ИТ-команду, имплементирует идею, проверяет, далее по результатам. Такие проекты часто называют стартапами. Это могут быть "ванильные" стартапы как с привлеченными инвестициями, так и без, внутренние (компания финансирует, юридически может быть дочка под стартап, может нет), на аутсорсе полностью или частично.
Тут дело не в методике дело, а в некомпетентности команды.
О да, в идеальном мире каждая команда тоже идеальна. Она умеет всё. Что такое атомное ядро и чем отличается химическая физика от физической химии — для правильной команды это детский лепет. Как нужно строить завод по обогащению урана? Да гавно вопрос — команда нагуглит и во всём разберётся. Потому что команда — ну просто супер, как раз из того мира, где розовые пони делают конфеты некоторым специфическим способом.
А теперь к реальности. Заевшихся от заказов команд в ней очень мало. Способных понять атомное ядро — ещё меньше (не нагуглить, а именно понять). Ну и фокус заевшихся и способных давно уже смещён в сторону «как мне нравится», а не «как на самом деле нужно заказчику». Поэтому если предложить им сделать атомную бомбу (вы вообще представляете весь необходимый объём работ?), то они упрутся в массу ограничений, о которых ранее даже понятия не имели, хотя и считали, что могут ну абсолютно всё. И вот эта супер-мега-айс-команда делает эпический фэйл. По скраму, разумеется. Ведь они же не какие-то там негры на галерах.
И разумеется, ребята всегда оправдаются (они же супер, не?). Обвинят во всём, понятно, заказчика. Свалят с проекта сразу, как только им скажут «ребята, у нас тут есть ограничения». Ну и распиарят свой «успешный опыт» примерно так — мы реально сделали бомбу! Но тупые заказчики, некомпетентные поставщики, и вообще всякая шваль под ногами… Ну вы поняли — виноваты все, кроме КОМАНДЫ.
Короче — ваш подход не для реального мира. Если вы входите в число заевшихся и лениво выбирающих себе заказ — ладно, вам простительно непонимание реальности (не до неё ведь). Если же нет, то уж сорри, но некомпетентны как раз вы. Других вариантов нет. Например, потому что вы не знаете, как сделать бомбу, даже если вам кажется, что вы всё знаете.
Ну а отдельные выполненные вами проекты, которыми все хвастаются как «успешными», всегда есть нечто несовершенное, весьма далёкое от идеала. Если кто-то знаком с таким явлением, то он не станет заявлять про ещё один проект (под названием «скрам») мол он успешнее всех успешных успехов, а потому всем нужно пилить только его, а кто не пилит — ну он просто некомпетентен.
Про Скрам мастера и про его задачи вспомнили, а про Владельца продукта и его задачи забыли. :) Вот и получили то что получили. Не очень хорошая идея СКРАМ по Википедии делать. Там маловато информации.
Судя по комментариям выше, например "Какой смысл городить 2 месяца архитектуру с тоннами абстракций..." — то да, похоже понятия информации, данных, дата-флоу и т.д. «устарели»… И блокчейн в таком случае — просто один из примеров…
Интересно, если бы программисты взялись спроектировать, например, карьерный самосвал — то процесс проектирования тоже бы проходил по Скраму? То есть, раз времени выяснить характеристики проектируемого самосвала нету, то поэтому уже по окончанию 1й недели заказчик получит работающий прототип — садовую тачку, например? А уже потом будем «наворачивать» к этой тачке функционал — еще колеса, двигатель и т.д.
Интересно, если бы программисты взялись спроектировать, например, карьерный самосвал — то процесс проектирования тоже бы проходил по Скраму?
СКРАМ — одна из версий системного подхода, реализованного для разработки софта.
Управление промышленными проектами — обычно PRINCE2.
Инженерными проектами — по стандартам ISO. Их много там используется, начинать можно с этого ISO/IEC 15288
Но все стандарты ISO и все методологии построены все равно на «системном подходе» и цикле Деминга.
В реальности материальные продукты проектируются и выпускаются по похожей методологии как и SCRUM. Это один из видов «цикла разработки», «жизненного цикла» продукта. Похожесть там на уровне идей и методологий. Но сроки иные и циклы разработки организованы иначе. Причем чаще всего циклов разработки одновременно много запущено параллельно, циклы не всегда полностью отрабатываются.
Если интересно, то многое есть в книге Wasim — Standards for engineering design and manufacturing
xcoi
Скорей всего не везде так, но это мой личный опыт работы по скраму)
Слово "российский" можно убрать из заголовка :)
У скрама есть то, что тут никто не упоминул-работа команды. Скрам-мастер только коордионатор. Все делает команда, прежде всего, что нужно сделать, какие есть скрытые камни, где спрятан остальной айсберг работы. Команда от слова "скрам", это термин американского футбола, когда перед игрой команда кучкуется и ищет решение для победы в игре.
Когда один участник проекта подначивает другого, и тот ему дает обещание, что сделает код, который задействует вопрошающий.
Это не тупой конвейер, это заговор по решению проблем.
Если всех надо тянуть, заставлять, это не скрам. Это натягивание совы на глобус.
И да, прикручивать к ЕРП блокчейн, не понимая, что это даст, это тупость заказчика, и неопытность исполнителя, который на это решился.
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три команды. Что очень трудно делать если он сам «заинтересованная сторона».
Работа занимает всё отведённое время. Следовательно, выделенный скрам будет заниматься своими игрушками фултайм. А чтобы ему не было скучно, он позовет разработчиков в переговорку, чтобы обсудить все животрепещущие, в его представлении, вопросы.
Не соглашусь. То есть во первых на мой взгляд скрам-мастеру вполне себе хватит работы даже с одной командой. Естественно если он работает, а не просто митинги назначает.
А во вторых на мой взгляд быть одновременно скрам-мастером в нескольких командах это ещё куда ни шло. А вот быть в одной и той же команде и ПО и скрам-мастером это наверное самое худшее что можно придумать. Тогда уже лучше сделать так что он скрам-мастер в одной команде и ПО в другой.
Ну так проблема именно в том и заключается что мы получаем "своеобразного PM по старым понятиям".
То есть это может быть даже как-то более-менее работает. Вот только к скраму это уже никакого отношения не имеет.
А часто мы даже получаем ситуацию когда это работает плохо, к скраму никакого отношения не имеет и при этом всё равно назывется "скрам". И потом мы имеем людей с "аллергией на скрам" несмотря на то что они этот самый скрам вживую и не видели даже.
Ну во первых если мы имеем PMa хоть в каком то виде, то о каком скраме может идти речь?
А во вторых, как я уже писал выше, скрам мастер кроме всего прочего должен быть медиатором и помогать решать конфликты. В том числе и конфликты между ПО и девтимом. Если он при этом сам является ПО (или кем-то из девтима), то как это по вашему должно работать?
Далее по конфликтам. Скрам мастер по своей роли — сам по себе конфликт и головная боль команды, ибо именно он навязывает противоестественный для нормального программиста-интроверта процесс. Меня честно говоря смущает мелькающая между ваших строк дополнительная роль психолога-тим лида. Это как раз не то, что требует скрам.
Ещё раз, скрам, это набор методик разработки, роли и процессы. То, что один человек, выполняет две роли не делает процесс не скрамом.
Роль скрам-мастера конкретно описана. Если он комбинирует эту роль с какой-то другой ролью в своей же команде, то он просто не может бытъ скрам-мастером из-за своеобразного «конфликта интересов».
Более того практически в любом описании скрама указано что скрам-мастер ни в коем случае не должен «мутировать» в тимлида или PMa.
И да, наверное где-то в мире существуют люди которые могут абсолютно непредвзято быть одновременно и ПО и скрам-мастером. Но я пока таких не встречал. По моему опыту как только эти роли начинают совмещать, так сразу такой ПО-скрамастер начинает прогибать процессы под себя. И превращается в того самого PMa. То естъ в теории может быть и допустимо такое совмещение, но на мой взгляд на практике это нормально работатъ не будет. И судя по отзывам людей работающих по такому «скраму» оно и не работает.
Скрам мастер по своей роли — сам по себе конфликт и головная боль команды, ибо именно он навязывает противоестественный для нормального программиста-интроверта процесс.
А это вообще на мой взгляд из пальца высосано. С чего вы взяли что процесс обязательно противоестественнен для любого «программиста-интроверта»? И самое главное с чего вы взяли что все программисты вдруг являются интровертами?
>С чего вы взяли что процесс обязательно противоестественнен для любого «программиста-интроверта»?
Да взять хотя бы ежедневные стендапы, не говоря уже о ретроспективах. Это основное, чем обычно недовольны программисты, когда их выдёргивают из зоны комфорта. Особенно программистов старой школы, как автор статьи и я сам.
Не улавливаю, а в чём конфликт между ролью PO и scrum master?
Ну например в том что решения о том как конкретно должны выглядеть процессы должны принимать вместе ПО и девтим. Например то как должно выглядеть DoD, как считать сложность тасков, использовать покер или нет и т.д. и т.п. А скрам-мастер должен только следить чтобы всё это не выходило за рамки скрама.
Но если у вас скрам-мастер одновременно и ПО, то он будет всё это организовыватъ так как удобнее лично ему. И хорошо если он это будет делать ненамеренно/подсознательно. А то ведь он вполне может и умышленно начать манипулировать командой. Ведь это он в конце-концов решает вписывается что-то вскрам или нет.
Да взять хотя бы ежедневные стендапы, не говоря уже о ретроспективах.
Вот как раз таки нормальные «ванильные» стендапы и ретроспективы раздражают людей достаточно редко. Особенно если грамотно организованны.
А вот если скажем стендап превращают в «отчёт о проделанной работе», то это многих раздражает. И это как раз очень любят делать всевозможные менеджеры(в том числе и ПО). И как раз это не должен допускать скрам-мастер. Bот вам и конфликт интересов на практике.
Особенно программистов старой школы, как автор статьи и я сам.
Ну вот именно: мы имеем каких-то отдельно взятых «программистов старой школы» которым что-то не нравится или что-то не устраивает. Но это не значит что это не устраивает абсолютно всех «программистов старой школы». И самое главное это совсем не значит что у нас все программисты являются этими самыми «программистами старой школы».
То есть я вполне себе допускаю что есть куча людей для которых скрам не подходит по тем или иным причинам. И в этом нет ничего плохого. Но это не делает скрам «противоестественным» по умолчанию.
>И как раз это не должен допускать скрам-мастер. Bот вам и конфликт интересов на практике.
Ну так это «должностные обязанности» скрам мастера выполнять спринты по процессу, где «отчёт о работе» означает конкретные артифакты спринта. Если же скрам мастер допускает превращение ретроспектив и стендапов в отчёты каждым программистом, что он сделал — то скрам мастера надо гнать в шею. И PO вместе с ним, раз это один и тот же человек :) Я потому и говорю, что нужно правильного человека на эту роль найти, что бы понимали обе роли и где проходят границы. Такие люди есть.
>А вот если скажем стендап превращают в «отчёт о проделанной работе», то это многих раздражает.
Так стендап по своему определению это promises работы на сегодня до следующего стендапа и рассказ почему эти promises нарушены относительно стендапа вчера, если это произошло. Это ключевой процесс «мотивации» программистов и выявления проблем как можно раньше и это ни фига не комфортно никому, когда приходится рассказывать, почему ты зафейлил вчерашние обещания. Если стендапы для всех комфортны — это попахивает культом карго.
Я потому и говорю, что нужно правильного человека на эту роль найти, что бы понимали обе роди и где проходят границы. Такие люди есть.
Ну, как я уже писал выше, они может где-то и естъ, но я пока таких не встречал. А вот рсли послушать рассказы людей, которые работают с такими «комбинациями», то обычно ничего хорошего из этого не выходит. И как раз таки такое обычно и приводит к недовоьству скрамом среди программистов.
Это ключевой процесс «мотивации» программистов и выявления проблем как можно раньше и это ни фига не комфортно никому.
Опять таки оченъ субъективное заявление. Лично у меня нет никаих проблем с тем чтобы сказать своим коллегам что у меня возникли какие-то проблемы мешающие мне в работе. Особенно если учитывать что в большиснтве случаев моей «вины» в этих самых проблемах нет.
И вот лично я бы не сказал что стендапы имеют какое-то отношение именно к мотивации людей. Они существуют для того чтобы выявитъ проблемы если таковые вдруг возникли. По крайней мере у нас это так.
Очень многие не любят, когда их выдёргивают посередине задачи, когда осталось 2 часа, что бы эту задачу закрыть и вместо этого заставляют терять фокус и рассказывать, почему же пришлось потратить больше времени, вместо того, что бы работать. Очень многие вообще хотят жить в тепле и уюте, что бы их неделями вообще не трогали и дали «спокойно покодить». Тем более, что такие работы есть. Скрам со всеми этими ритуалами не особо комфортен для таких людей. Но, цинично скажем, это их проблемы в современном мире.
Очень многие не любят, когда их выдёргивают посередине задачи, когда осталось 2 часа, что бы эту задачу закрыть и вместо этого заставляют терять фокус и рассказывать, почему же пришлось потратить больше времени, вместо того, что бы работать.
И зачем это тогда делать? Ну то есть с чего вы решили что это обязательное условие стендапа? Кто мешает делать эти самые стендапы в начале рабочего дня? Перед обедом? После обеда? Перед уходом домой? Ну то есть тогда когда люди всё равно сами по себе отрываются от работы?
И опять же: да это не всегда возможно. Ну так никто и не говорит что именно скрам будет работать всегда и везде. Иногда он не подходит и тогда стоит выбрать что-то другое. Даже если это будет водопад.
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. Особенно последний пункт.
А во вторых где там хоть слово про «backlog burnout» и/или обязательность его наличия?
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%» — это имеет смысл. Хоть и редко работает по факту.
Это обмен статусом внутри дев-команды, на стендапах может никто кроме дев-команды не присутствовать, ни ПО, ни СМ, ни стэйкхолдеры. Решит команда кого-то из них уведомить — уведомят. Не решит — не уведомят. Основная обратная связь для стейкхолдеров — это спринт ревью. Для ПО — спринт ретро.
И при необходимости разруливать проблемы с «окружающим миром».
Какая-то странная у вас логика. Админы вон тоже как бы ещё более сторонние лица и никак не отвечают за цели спринта. Но если скажем у нас вдруг сетка ляжет, то они отвечают за то чтобы всё снова заработало.
За выполняемость спринтов отвечает команда разработки, ни ПО, ни СМ в неё не входят, они входят в скрам команду вместе с командой разработки.
Не обязательно это большие компании. Просто, как по мне, если за результат отвечает ещё кто-то, кроме команды разработки, то это команду расслабляет. При этом лезет SM в ежедневную работу или нет, особо значения не имеет, пока он лезет за информацией и с советами, а не с указаниями. А если с указаниями, то это уже не скрам определенно.
Лень искать, но иследования на это тему были, большинство программистов высокого уровня — интраверты. Интровертство создаёт условия более тщательного изучения предмета (больше времени и более сосредоточенно человек торчит в конкретной теме), отсюда и более высокий конечный уровень.
Скрам — не про программистов, скрам — про процесс имплементации требований стейкхолдеров.
Вот абсолютно не согласен. Скрам он на мой взгляд для всех. И программистам он тоже присносит свои плюсы.
Программисты почему-то часто ожидают, что скрам и любая другая методология должны быть им комфортны.
Да. Ожидают. И я ожидаю. И ничего неправильного в этом не вижу.
акие методологии больше про то, как их заставить работать и выдавать результат в проектах с относительно часто меняющимися требованиями :)
Не cоглашусь. Такие методологии существуют для того чтобы сделать работу более комфортной «в проектах с относительно часто меняющимися требованиями». Проблема то в том что даже если вы откажетесь от скрама, то это совсем не означает что требованию вдруг по волшебству начнут реже меняться…
Скрам о компромисах между программистами и стейкхолдерами.
Грубый пример: Многим стейкхолдерам не нравится некоторые ограничения скрама для них типа фактического запрета на вмешательство в работу скрам-команды во время спринта, но они их терпят ради того, чтобы получить программистов, которым не нравится такое вмешательство в принципе, но они готовы терпеть его пару раз в месяц.
Российский SCRUM. Бессмысленный и беспощадный