Подробнее
-¿¿г и с 'а/п е г; - а Ьторцт^рйЫ^Г • Сеть п^мм^-аи^е цели и -------лигНюа Тсйет £с*х ‘ ‘ /Лд'.к — идеология и рилгцА Работа |>а^ вА€На мя СП^>ииГПЪ| с конкретными уаЪв'РЦчи ьны пе*ди со&>С каэ1ЛиГ_ ч«АоР.к-орк«стр ка^Ьчи^ас«^.,., С1 лрицрки М аленькие команды намного Л^цщдС и прсЬс|к^оц^мвс. 6альшиЪ ш у -* ' - * У раЬны ме<д.и I ч С' \ л , .С-3 ^Цээн-мас-грер помогает а переходный период при полном скрапе он не ¿^ет ркен 1 999 Партий: -¿^морнгарная -если генеральная линия — |асгга£ляегп бсех ^аЛэта^б |\ОНИС^ИиЗИ — идеологи/* ц реи Ра^а ра^елен* на пятилетки с койк|>ег<?ныии ^а\ача^ц ^кусарЬа ^сло1еня мау^о* П С0 -В. и. Ленин Д^чи^е меньше^ >>а¿цчт*! * — 1Ъ и. Ленин о с^елнироРаиич Сгл^^ Соичали?м оо^огае^ I? пере*о&| период; гг>и полном ^онн^ни^мв он не Ока^зле/* нв^ц^неепосо ¿вц Со&в1ечие? А вы по^ро^Гме сло&о т СКРАМ" ?адом наперед!
Программистское,скрам,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,СССР
Еще на тему
А так иди
Как в том анекдоте, про место проклятое
тут опять
Политик, лидер и боец!
А теперь представь, что в СНГ? 99% опрошенных считают скрамом доску с тачками, а больше им и не надо.
Говорю вам, как человек, который внедряет нечто подобное на команду из 6-7 человек, это реально может работать неплохо. Процесс подбора членов отряда, мотивация их, это то, что определит залог успеха.
У меня за почти 10 лет айти такой проект, правда, был один %)
Скрам нам говорит, что мерять задачи надо в сторипойнтах, что переводить их в часы или дни или недели некошерно - это уже за рамками скрама. Сторипойнты - это очень удобно и хорошо и конкретные временные промежутки к ним привязывать нельзя - это все портит. Ведь сторипойнты могут эволюционировать и изменяться
Далее конкретный промежуток времени для выполнения четкого объема работ - нельзя в скраме посчитать. В скраме надо пройти пару спринтов с командой, чтобы замерять велосити, нельзя оценивать велосити одного отдельного человека, есть только общая велосити команды. Если добавились или ушли или просто поменялись люди - велосити надо перемерять за пару спринтов. Нельзя планировать с учетом "необкатанной" велосити, это уже другая команда.
Четкий скоуп (объем работ) - его нет, потому что скрам предполагает получение фидбека от конечных пользователей и смену приоритетов соответственно в последующих спринтах, а то и изменение запланированной функциональности. Если у тебя есть четкий объем работ и зафиксированная функциональность - это не гибко. Если мы гибкие и у нас скрам - то четкого скоупа нет, есть только предполагаемый, который может измениться.
Документация не должна быть важнее работающего продукта - сначала сделаем то, что хотят пользователи, а потом задокументируем как сумеем.
Я не говорю, что сферический скрам в вакууме - это плохо. Как коммунизм, работающая карма или правовое государство - это хорошо. Просто скрам не работает в реальном мире. Реальный заказчик со стороны - не как часть команды, а именно заказчик со стороны, даже если это продуктовая корпорация, или заказчик на аутсорсе - хотят знать, что они получат, когда и сколько это будет стоить. Тогда мы берем скрам и заворачиваем его в корпоративный менеджмент. И локально на 3-7 человек оно работает. Но вокруг этого островка свободы от обязательств и экспериментальной площадки есть менеджер, который тайно переводит сторипойнты в часы или недели и меряет кто, сколько успевает сделать за спринт, борется за согласование требований и согласование изменений бюджета при изхменении объема работ, а так же коммуницирует маркетинговому отделу заказчика, когда будет готов продукт или его новая версия, и что в него будет входить. А еще долбится в голову, доказывая, что гибкость в плане фич должна отражаться гибкостью в плане сроков и гибкостью в плане бюджета, а с этим не все согласны.
Посторюсь - да, я согласен, что скрам работает либо для маленькой команды стартапа, либо если вокруг есть обслуживающий персонал, которые делает всю менеджерскую, тестерскую. дизайнерскую работу и ведет документацию.
Потому что:
1) Гибкость в ответе на фидбек не только тогда нужна, когда есть конечный пользователь, который уже использует софт. Есть QА, есть проджект овнеры, есть, в конце-концов, селф-тестинг и "нам надо перепилить вот этот кусок потому что".
2) Отсюда же и полная ересь про документацию - документация к юзеру не имеет никакого отношения, документация - внутренний инструмент общения команды.
3) Скрам не имеет никакого отношения к предпоследнему абзацу в принципе. Заказчик, со стороны ли, изнутри ли - хуй клал на то, как делает продукт. Продукт должен быть выпущен в срок и соответствующего _внешнего_ качества. Аудит кода занесший бюджет человек проводит в одном случае на тысячу и не своими руками. И зачем нужен менеджер, который херит рабочую схему? Если предположить, что кто-то ломает систему изнутри - конечно, блин, она работать не будет. И, в конце-концов, маркетинговый отдел заказчика должен эту информацию получать не от менеджера-исполнителя, а от тех, кто принимает работу на стороне клиента.
У меня ощущение, что ты сталкивался с скрамом в вебе или какой еще другой дешевой и помойной ипостаси. То, что ты описал - это дроч на методологию, а не реальное использование.
И да, в моем опыте по скраму работала тима из суммарно +- 100 человек. От бека и фронта (нет, не веб, приложение на ведроид) до QA и аналитиков. И это был на данный момент мой лучший опыт, просто по сумме сотрудников, планирования и исполнения. И состав команды менялся несколько раз в ту или иную сторону и все равно мы вышли за пределы срока всего на неделю.
Поправь меня если я неправильно понял, но ты говоришь, что: в скраме есть удобные и работающие элементы, вы успешно организовали процессы на проекте по скрам, при этом вы взяли из скрама то, что для вас работает и выкинули то, что не работает.
Вот, что я имею в виду: я согласен, что в скраме есть удобные и работающие элементы, которые отлично встраиваются в рабочие процессы в реальной жизни, но есть и нерабочие вещи и я считаю, что вы не работали по скраму, потому что вы взяли из скрама то, что для вас работает и выкинули то, что не работает.
Разногласие в том, что ты называешь скрамом часть элементов скрама, которые вы взяли без изменений из стандарта, замиксованных с измененными элементами из стандарта и еще с элементами из других методологий управления. Так скрамом можно назвать что угодно со спринтами и дейликами.
изменению. При внедрении отдельных элементов данного фреймворка, полученный результат не может называться Скрамом."
© Руководство по скраму, страница 21, раздел "Заключение"
https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Russian.pdf&ved=2ahUKEwjYrsma5_TsAhVEhlwKHdRfCr8QFjAAegQIJRAC&usg=AOvVaw0wKCtRlqrGgynih1zXpZyn
Joseph....
Jo.....
......
OH MY GOSH
Joseph Stalin Joestar
Сегодня на повестке дня дело комсомольца Бирюкова
Мэлс, встань. Был советский студент Мэлс, а теперь перед нами стиляга Мэл!
Казалось бы, всего одна буква, правда, товарищи?
Такая малость...
Но давайте вспомним, что означает имя МЭЛС?
В нём зашифрованы святые для нас имена: Маркс, Энгельс, Ленин... Сталин
А теперь давайте подумаем, что означает небрежно выброшенная им буква С?
Круговая порука мажет как копоть
Я беру чью-то руку, а чувствую локоть
Я ищу глаза, а чувствую взгляд
Где выше голов находится зад
За красным восходом коричневый закат
Да в оригинале был именно что коричневый, но такой текст цензура просто не пропустила. Потому что получается что этот текст про то как совок прогнил, все к друг-другу подстраиваются и осуждают всехкто не с нами. Превращая это именно что в фашизм. Именно это и говорит фраза коричневый закат
И так остальной текст. Он весь про то что совок говно, нас превратили в тупое быдло, а мы только рады этому и ничего кроме еще большей жопы мы не получим.
Что у нас тут
Мы блять, едины, а ты говно! Ты не такой, как все. Ко-ко-ко. Тоталитаризм такой тоталитарный
Короче превратили охуенниший текст Кормильцева с толпой смысла и аллюзий в тупое говно.
Кадр сразу после финальной дуэли, если что.
И вряд ли штандартенфюрер, то есть полковник, был бы комендантом лагеря. Если мне не изменяет память, ими всякие обсосы типа старлеев руководили.
Поэт. У нас тут фашизм, все только и занимаются что обслуживают друг друга
Толпа (это припев) Нам похуй мы вместе, мы едины. (Именно это он означает, ответ толпы о том что у нас одна цель, мы связанны цепью)
Поэт. Мужики вокруг пиздец. Никто не верит тому что говорит, все только и умеют что ходить строем
Толпа. Нам похуй мы вместе, мы едины
Поэт. Тут нет веры ни во что, у нас нет цели, все радуются что есть работа, но на ней нихуя не платят, вы все никогда ничего не будите иметь. И самое главное ты ничего не сможешь сделать, потому что тогда за тобой придут
Толпа. Нам похуй мы вместе, мы едины
Вот про что эта песня. Она про обличение пороков общества, по сути она пиздец как актуальна сейчас, потому что смысл не меняется. Небольшое количество пытается изменить общество, сделать его лучше потому что все вокруг пиздец полный. Но им затыкает рот толпа которое единственное, что и умеет говорить это как они едины и неделимы. Больше оно ни на что неспособно.
А уверенность, которую ты демонстрируешь - ложная.
Если брать дизайнера, бизнес аналитика, qa и разработчиков фулстеков - то скрам не получается. Можно выделить с разработчиков в отдельную команду и организовать ее по скраму, а остальные ее будут обслуживать, но это комунизм в отдельно взятой деревне ща счет окружающих и не дает запланировать работу по проекту (государству). Но я буду благодарен за конструктивную критику и указания на мои ошибки, а так де за реальные инструкции, как правильно настроить скрам в команде с широким спектром узконаправленных (относительно) специалистов и как в бухгалтерии согласовывать бюджеты.
Но в общем неизвестный автор прав - та же показуха, стремление уложиться в сроки и хуёвое тестирование.
Кстати, как по-коммунистически будет технический долг?
Скрам больная тема вообще, но очен хочется излить душу, извиняюсь заранее. Я щетаю, что скрам гробят в основном недалекие шишки, которые услышали модное слово и теперь все должны быть скрам, а еще биг дата, а еще дата лейк и дата сайенс.
Типичная ситуация на прошлом проекте - докидывают новые тикеты в текущий спринт или меняют полностью требования. Говоришь, что мы не можем так делать, мы не планировали это работу и не может гарантировать что ее довезем.
Ответ "гениальных проджект менеджеров" (они, сука, не знают что в скраме нету проджект менеджеров) - ну так вы же должны быть АДЖАЙЛ. Типа если ты сказал АДЖАЙЛ, то похуй что скоуп в 2 раза вырос или переделать все надо, релиз передвигать не будем, мы уже обещали. А потом такие: "ойойой, а почему это мы не успеваем".
У нас был какой-то директор который сказал что команда на 78% процентов скрам. Сука, посчитал же как-то
Ну и со стороны девелоперов тоже есть большие сомнения в полезности скрама. Никто не хочет быть и аналитиком, и разработчиком, и тестировщиком, и дев опсом одновременно. Потому что мастер на все руки это хуевый мастер в каждой отдельной специальности. Поэтому скрам очень слабо приживается и почти все используют "гибрид" - делай что хочешь и кричи "АДЖАЙЛ"!
А теперь попробуй тоже самое сделать в скраме. Ты начинашь спринт - ничего не сделано, тестировать нечего, тестировщики курят, девелоперы ебашат. А в конце наоборот - куча тикетов уже на тестовых средах, а тестеры не успевают все протестировать. Поэтому типа все должны делать всё. А так не бывает.
Тестеры совместно с скрам мастером обязаны набрать в спринт задач так, что они не простаивали. Делается это на платное - одном из скрам ритуалов.
А перед плагином есть груминги, где, собственно, задачи на будущий спринт обсуждаются и предварительно оцениваются.
Канбан доски же позволяют трепать реализацию задач и прогресс по ним, контролировать поток тикетов, чтоб в потоке не было больше установленного количества.
Очень полезно их комбинировать, так называемый скрамбан.
Советую пройти курс по сертификации скра мастера и скрам ПО, чтоб разобраться в темах.
Аналитика в скраме нет, от слова совсем. Есть ПО.
Короче, планинги и груминги решают всё
Cкрам, это в первую очередь про результат - польза для заказчика, которую вы, как команда, регулярно приносите в виде нового функционала. Веришь или нет, заказчику поебать как и где вы дрочите - на грумингах, на планингах или еще где, главное чтобы кнопочка появилась и делала красиво, как он хочет.
Задач ты можешь набрать столько сколько надо, но не все задачи доступны всем сразу. Но вот дал ты тестеру задачи - протестить 5 новых кнопок на веб-форме. Окей. Как он будет тестить если кнопок еще нету? Он сидит ждет, пока девелоперы хоть что-то сделают. А 5 девелоперов делают свои 5 кнопок 5 дней. И вот на 6ой день тестировщик получает сразу 5 задач. И теперь у него осталось 2 дня чтобы из протестировать. И он часть протестирует.. абы как, потому что надо успеть перед ревью.
Вот поэтому в скраме и нет ролей, в том числе и тестировщика, о котором ты пишешь. Есть только разработчики, скрам мастер и ПО. Так что ты бы это... перепрочитал свои тренинги что ли :)
И да, скрам артефакты не для мебели придумали, а как средство достичь той цели, о которой ты заявил - принести бизнес ценность.
Я думаю, что ты сидишь в аутсорсе, это там такая дичь часто происходит. У меня - продукт. Тестеры есть и будут, ибо скрам/аджайл не есть Библия, а вполне изменяемая вещь. Не "написали кнопочку"? Пишите автотесты. Или у вас 100% покрытие? Никогда не поверю. А если у вас только мануальщики, то мои соболезнования. Меняйте процессы.
"Детальное описание фреймворка представлено в рамках данного Руководства. Роли, артефакты, правила и события Скрама не подлежат изменению. При внедрении отдельных элементов данного фреймворка, полученный
результат не может называться Скрамом. "
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Russian.pdf
Так что если у вас есть тестировщики, то я тебя поздравляю, у вас нету скрама.
"Пишите автотесты." - ну так да, приходится так и делать чтобы не было роли тестировщика. Это никак не противоречит тому что я написал - в скраме команда это мастера на все руки. Если ее нету, то у вас не скрам, а просто иммитация с использованием понятий которые кто-то выучил готовясь к сертификации. Успехов.
У нас же жопа. Куча задач тупо исследовательские в стиле "как бы сделать такую дичь", "почему дичь не работает", "где производительность, сука". Куча внешних зависимостей от других команд, которые надо пинать. Разные люди в команде лучше шарят за те или иные области, поэтому нельзя взять и любого человека поставить на любую задачу, будет неэффективно. Юзерстори в половине случаев не несут законченного полезного функционала для потребителя продукта, а представляют внутренние и служебные вспомогательные задачи (см. выше). И мы уже очень давно хуй знаем, как это исправить. Скорее всего, чистый скрам тупо не работает из-за специфики говна, что мы делаем.