Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 138
Задачи, которые можно быстро закрыть, выдаются как приз тем, кто хорошо работал на долгих задачах
скрам=скам
угадать сроки
Ключевая фраза
Выглядит как "давайте уберём ремень безопасности: он только мешает, и ни разу пока не помог"
ремень безопасности не есть рулевое колесо. Просто на дороге не нужно уж так теребонькать рулем туда-сюда, изображая крутецкий дрифт
ну вот вы сидите себе за рулём.
руль не трогаете, потому что никуда не едете и вообще, ручник затянут.
вы не пристёгнуты, пассажир рядом пристёгнут.
сзади в вас слетает грузовик.
пассажир сидит дальше, а вы отправляетесь в увлекательный полёт через лобовое стекло.
а ведь крутецкий дрифт не изображали и рулём туда-сюда не теребонькали!
как же так?!
Если это такой сарказм, то вы забыли поставить тег <s>, а если цитата — то ссылку на источник
Т.е., скрам помогает так же редко, как ремень безопасности? А если помогает, то прям точно помогает?
Скрам скорее навигатор, который каждые 100 метров перестраивает маршрут и требует подтвердить, что ты все еще едешь прямо, иногда проще выключить его и ехать по знакам
Не, это как "мы знаем что то что мы ищем где-то на севере, мы не знаем где именно, мы не знаем как долго мы будем ехать на север чтобы это найти, мы предполагаем что с очень высокой вероятностью мы доедем до этого за 3 месяца и мы не будем останавливаться каждый час и измерять пройденное расстояние, мы будем просто ехать вперёд ибо чтобы достичь цели к ней нужно двигаться".
Аналогия - не аргумент. Можно: давайте уберем рак/уродливую родинку/балласт бюрократии: он только мешает, и ни разу пока не помог. А если реально скрам годится только для команд где людям не доверяют и считают, что человек будет только кофе гонять на рабочем месте, по факту это обычно проекция своей мидлменеджерской неэффективности на людей которые 12-17+5+- лет оттарабанили(и как правило хорошо) в школах и университетах, чтобы стать программистами. Просто желание лупоглазым по носу дать, че они так много зарабатывают.
Метрики нужны не когда все хорошо и все работает, а когда что то работает со сбоями или плохо, и что бы попытаться предугадать проблемы хотя бы до того как они начнут заметно влиять.
Как вы собираете искать 'импостера' в команде, если команда для вас - черный ящик.
Как собирать и какие именно метрики нужно собирать что бы стало хорошо, вопрос на миллион.
Как вы собираете искать 'импостера' в команде, если команда для вас - черный ящик.
Это очень легко делается: просто научитесь программировать и смотрите что они там коммиттят.
А если вам это лень, и удобнее занятым людям голову клевать, то значит вы занимаете чужую должность
Конечно, это прекрасно работает в команде до 10.. ну 20 человек, а дальше 'научитесь программировать' уже не работает, вы человек и ваши возможности ограничены.
Я сейчас не защищаю современные методы построения этих метрик, там такой кошмар что волосы дыбом встают, но собирать метрики так или иначе нужно, и задача руководителя построить систему контроля такой, что бы она не мешала (или мешала по минимуму) работе.
ИМХО, не сто́ит иметь столь большие команды, лучше их дробить на более мелкие из 5..6 человек, включая лида. Опять-таки, ИМХО, глубокая древовидная структура предпочтительнее и эффективнее новомодной "плоской" модели.
Вы удивитесь, но из команд по 5 человек формируются отделы по 20 и направления по 100. И их руководителям тоже нужно как-то отслеживать эффективность работы своих подчинённых и прогресс своих задач. Процессы не заканчиваются отношениями между разработчиком и его тимлидом.
Тут ключевое "тоже нужно как-то отслеживать", причём каждое слово важно.
"Тоже нужно" - ну какой же он руководитель без отслеживания? Нельзя же подвергнуть сомнению его необходимость в роли руководителя?
"Как-то" - значит всё равно как, не важно точно или не точно ты отслеживаешь, оказывает этот контроль положительное влияние на процессы или не оказывает. Главное, чтобы были хоть какие-то цифры, которые можно показать и вниз и вверх для создания иллюзии контроля.
Процессы не заканчиваются отношениями между разработчиком и его тимлидом.
Почему? У 6 разработчиков есть тимлид, у 6 тимлидов есть тимтимлид. У тим тим тим лида в подчинении 258 человек, а подчиненных - шестеро. И еще 36 человек могут "через голову" нажаловаться на своего руководителя.
Никогда этого не понимал. Зачем? К чему этот микроменелжмент? Вы рук отдела, у вас есть лиды, всё. Если кто-то проёбывается, это вопрос к лиду, он уже должен делать свою работу.
Ни разу не видел, чтобы не мешала. А она существует в природе?
Это дань моде и ощущение, что что то упускаешь. А также "прокачаюсь в агиле за счёт работодателя", вдруг пригодится
То есть это всё нужно когда в менеджменте сидит левый контингент, не разбирающийся в этой этой отрасли, присосавшийся к айтишке на волнах хайпа?
Ой давайте уберем дедлайн, он же стресовый....
Дейли как ремень безопасности в авто, лишь бы не пригодился, но если что то важное и неожиданное происходит позволяет узнать об этом раньше.
Вообще без стеснения укладываемся в 5 минут дейли. Прощелкали доску, проговорили нет ли рисков если есть запланировали обсуждение и пошли работать дальше.
В зрелой команде нет осуждений что кто то 3 спринта одну задачу может копать или промахнуться в оценке.
Ни нужно ни одно действие в жизни воспринимать абсолютно, все имеет некий разбег, Много метрик не есть хорошо, и работать без метрик не есть хорошо. Дедлайн как священная корова - утопия, но и без дедлайна работать плохая идея.
Если происходит что-то важное и неожиданное, нужно ли ждать дейли, чтобы об этом рассказать? Может лучше рассказать сразу, но по другому каналу передачи информации?
И не похож дейли на ремень безопасности. Скорее похож на жужжание навигатора, который кроме предстоящих действий сообщает о выполненных: "Когда я повернул на улицу Ленина, увидел что она перекрыта. Поэтому маршрут перестроил и совершил разворот. На ближайшем перекрёстке поверну направо и поищу параллельную улицу." Польза есть, если кто-то это внимательно слушал и знает, что там параллельных улиц нет до самого выезда из города. Подскажет, что надо повернуть налево: сэкономит немного времени на манёврах. Вот и всё, пожалуй. А ремень безопасности - это алерты и автооткат релизов по метрикам приложения. Но это уже не про мерам.
Если происходит что-то важное и неожиданное, нужно ли ждать дейли, чтобы об этом рассказать?
А человек может и не знать, что у него проблема. Что он решает промежуточную проблему, которую уже позавчера решили в соседней команде. Или что эту проблему год назад решал другой человек и признал её заградительно дорогой. Или что ваши работы случайно пересеклись и вы на мёрже друг другу помешаете. Или что сосед знает более эффективное решение. Разработчик, например, может не отдавать себе отчёта в том, что фичу лучше урезать, если она растягивается, но решить в срок. И так далее, много может что быть.
И дейли тут выступает в роли милиционера на лошади - одна голова хорошо, а две лучше.
В простых потоковых задачах это, может быть, и не нужно, а в сложных проектах с большим количеством контрибьюторов без постоянной коммуникации постоянно кто-нибудь будет забредать не туда, не по злобе, а просто ну потому что разработчик заведомо знает меньше, чем пять разработчиков.
А всё потому что, оказывается, созвониться на 15 минут в день придумал злой лид от безделья.
Даже если сам дейлик занимает 5 минут, чего я никогда и нигде не встречал, то это не значит, что его стоимость 5 минут. Overhead на неё всё равно не меньше 30-60 минут на разработчика: как и любая встреча он разбивает поток на до и после. Время тратится как на вхождение в митинг с потерей контекста разработки, там и на выход
У нас ввели дейлики через 15 минут после начала рабочего дня. Просто пестня. Хотя можно как раз успеть подвигать задачи по доске до актуального состояния. То есть по факту - подготовка к дейлику и больше ничего, а по документам - дейлик всего 15 минут.
Человек постоянно входит и выходит в состояние потока. ритуал отлаженный отнимает не много сил, но позволяет подправить план. В идеале конечно же разраб по ТЗ пилит пилит и пилит, но всегда есть отклонения, задержки, риски взаимосвязей. И дейли позволяет в этой части синхронизироваться. Напомнить что ждеim результат по связанной задаче, подсветить что есть что то неясное в ТЗ или БТ и т.п.
Если он вам не нужен, то я искренне рад за вас.
Но я для команды считаю лучше дейли чем пушить в сообщениях по таким вопросам. Собрались, обменялись инфой - пошли работать дальше.
До этого надо ещё дойти, через боль и слезы видимо. Причём система как описана у автора более требовательная нежели история с списанием часовых затрат на каждую задачу.
Любые метрики можно обойти, зачем вообще они нужны, говорите людям что делать надо и все? Вы видели программистов которые игнорируют приоритеты? Рое и текучесть команды - метрики и вопросы компетентным людям, где требуются перемены, а где их требуется меньше.
Я так думаю, что команде мотивированных профи и правда ничего не нужно, никаких фреймворков. А как управлять командой, где есть джуны, стажёры, токсичные авторитеты и другие интересные кадры каждый со своим взглядом на всё вокруг?
Добавить в этот коктейль скрам-токсичности, как же ещё?
//У меня была супер-мотивированная команда, которую мне позволили набрать самому. Это были люди, которые изначально хотели заниматься дизайн-системой
Вот. И как с остальными командами, которые занимаются: легаси г..ом, сервисами перекладывания "json", и в т.ч. где "джуны, стажёры, токсичные авторитеты и другие интересные кадры "
Токсичные авторитеты любой скрам превратят в балаган, тут не процессы нужны, а жесткие кадровые решения. Никакой диаграммой Ганта токсичность не лечится
А как управлять командой, где есть джуны, стажёры,
Над ними берут шефство опытные разработчики
токсичные авторитеты и другие интересные кадры
Этих надо держать в узде. Всё-таки, руководство — это не про даш-борды, а про людей.
Да, и добавим сюда более реалистичные условия, чем "делаем никому не нужную хрень с нуля и без внешних сроков". Ну там постоянный поток багов, легаси, обязательства по срокам перед заказчиками/инвесторами и прочие милые особенности реального мира.
джунам помогает тимлид и лично следит без всякого скрама как они развиваются. "токсичные авторитеты" вообще наоборот получают буст к токсичноси при наличии всяких ритуалов скрама
Из всех скрам-церемоний я на самом деле положительно отношусь к дейликам и, как ни странно, к ретро. Сейчас и так все на удалёнке, никто никого не видит, общение, хотя бы по звонку, полезно. С Ретро то же самое.
Груминги постановок с командой, общекомандные демо - тоже полезные практики, но прибито ли это гвоздями к пресловутому "скрам-процессу"?
Спринты, с моей точки зрения, имеют смысл только тогда, когда они привязаны к релизам. На этапах R&D, MVP это просто бесполезная церемония.
Оценки не имеют смысла никогда. Будучи тим-лидом я мог оценить скорость доставки фичи плюс-минус палец без всяких циферок, просто понимая степень проработанности постановки, сложность открытых вопросов и валовой объём работы. Гадание на сторипойнтах точности не прибавит. И я совершенно согласен с посылом автора, что вся эта скрам-история - это создание иллюзии контроля для менеджеров среднего звена и красивых отчётиков для бизнеса.
ИМХО, если задача не зашита под разработчика, который уже давно в теме что и как он будет делать, то гадание на сторипоинтах позволяет убедиться, что все понимают задачу одинаково, что никто из команды не видит подводных камней. На покере как раз сталкиваются взгляды "построим кастомизируемый механизм, заложим фундамент на его развитие на годы вперед" против "ну эту мелкую хотелку можно подпереть костылем за пол дня работы"
без всякого покера когда создается задача в ней тим-лид пишет описание как минимум вида "заложим фундамент на его развитие на годы вперед" либо "ну эту мелкую хотелку можно подпереть костылем за пол дня работы"
У нас аналитики пишут. Что-то типа "надо чтобы пользователю был виден статус документа" А дальше можно завести реквизит статус, и пусть проставляют что хотят, а можно сделать интеграцию с ЭДО и подтягивать статус оттуда. Причем сделать красиво, не для одного документа естественно, а с возможностью подключения любого.
После декомпозиции тим-лидом задачи имеют уже достаточно определенную постановку. Если под задачей подразумевается постановка от аналитика, которую ещё и читало пол человека до планирования, вот тогда, да, остаётся покер или другие виды гадания.
Оценка помогает приоритезации. Когда ты приходишь к бизнесу и говоришь - у нас тут 100500 задач, в каком порядке брать? И понимая размер задачи бизнесс может захотеть что-то в первую очередь пропихнуть, что-то во вторую.
Вообще не понимаю сторонников отмены оценки. Особенно со стороны тимлидов. Рассуждения уровня хобби.
Как бизнесу (заказчику) понимать, как быстро он получит что-то, что ему настолько важно, что он готов платить немалые деньги?
Да, оценка это пальцем в небо. Но лучше уж так, и продать её (вернее труд команды), а потом обосновать почему больше. Чем сказать: мы беремся, но сроков нету, собирать метрики работают ли вообще в команде не будем, но хотим 2млн в наносек. Каждому.
Бизнесу интересна оценка не задач (юнитов для MR), а фич.
Оценка скорости доставки фичи определяется в первую очередь ясностью хотелок и проработанностью постановки.
Так что и без всякого покерного гадания я могу сказать, что вот в этой фиче всё понятно, за две недели сделаем, а тут такая куча подводных камней, что оценку давать бессмысленно.
Хорошо, на 4 месяца энтузиазма и мотивации точно хватит, когда команда пилит новый продукт. Все заряженные и неуставшие. Но что дальше? Когда продукт в виде uikit будут использовать множество команд, ставить свои сроки фич и требовать быстрого фикса багов? Тут придётся прикручивать процессы
SCRUM это скам над Agile. Если скам убрать, то получатся то самое, что задумывали отцы-основатели (читаем манифест).
Из личных наблюдений - перешел с работы с отчетами по часам и оценками задач на обычный канбан без оценок и заметил, что стал работать эффективнее.
Просто потому, что если ты дал оценку в 10 часов с рисками, её все согласовали, а ты сделал работу за 5 часов - нет никакой мотивации сдавать задачу сильно раньше.
Отчасти это, конечно, из-за отсутствия нормальной системы мотивации и оценки перформанса, но все же.
Бесполезной управленческой единице надо показать и доказать свою нужность перед вышестоящим начальством. Оменно отсюда вылезают почти все метрики. Бездельник наводит суету, но, поскольку высокое начальство за матчасть своих подчиненных не шарит - у них свои задачи, оно принимает пустопрожнюю мышиную возню за реальные производственные процессы. Если взять и проверить, чего за пузомерки мы считаем - две трети менеджеров вылетят со свистом. Та же история в чиновничьем аппарате, например.
Как только мы начинаем что-то измерять, и это измерение начинает влиять на зарплаты - будте уверены, большинство работников сразу переключится с основной цели на накрутку/закрытие показателей. И если, например, на заводском конвеере можно точно синхронизировать цели и метрики - процент брака, количество деталей в час, и так далее - то в разработке считать нечего, почти все метрики там искуственные, не отражающие реальность в полной мере. Тут для оценки нужен менеджер, который сам разбирается в матчасти, чтобы понять, какая команда проседает, где есть проблемы, и всё в этом духе...
Scrum нужен и удобен там, где много задач, которые после декомпозиции по объему меньше или равны длине спринта. То есть никаких монолитных RnD на полгода, никакого рефакторинга одной фичи на пять спринтов, и прочего - только то, что мы можем адекватно разбить на подзадачи. И опять же, никаких сторипоинтов - задачи распределяет живой человек, и спрашивает статус на дейликах по ним тоже живой человек.
Дейлики и прочие встречи не чаще раза в день (лучше через день-два, зависит от задач) - хорошо, так как на удаленке очень важно понимать, что делает коллега. Встречи чаще раза в день, и больше часа - уже рак и трата времени. Если команда настолько большая, что каждый не успевает за час высказаться - эта команда должна быть поделена на части.
Разработка радиоэлектроники. Работал по системе с ежедневными отчетами... месяца три, наверное. Как итог:
При постановке задачи требуемый срок в голове умножал на два и орал, как контуженная чайка, что даже в этот срок укладываюсь только с мотивацией и загрузкой 146%.
Рабочий день закончен - adios, amigos, через 9 часов и 30 секунд после утреннего логина на свой ПК никакой силой меня не удержать на рабочем месте, ибо отчет за день готов и отправлен.
Нужно надуть себе атомарных задач, чтобы отчет выглядел солиднее? Нет никаких проблем, я-то на каждый клик мышкой в САПР могу написать предложение, которое этот клик превращает в самостоятельную задачу. Учитывая, что административный персонал термины "импеданс", "диаграмма Смита" и "децибел относительно милливатта" понимал ещё хуже, чем я SCRUM и AGILE, проблем никогда не возникало.
Так и не смог придумать, к каким задачам отнести те 15 минут в день, что я ходил, простите, пописать и покакать. Размазывал (ой какой плохой каламбур вышел...) по остальной "воде".
На написание отчета уходило от 15 до 30 минут, с учетом п.2... Эффективность зашкаливала.
Ладно спринты, я юнитесты убрал для малых проектов и тоже ничего не сломалось. А разработчики стали тщательнее тестировать. Правда ничего и не улучшилось, только стало меньше переключений контекста.
У меня была супер-мотивированная команда, которую мне позволили набрать самому
C таким чит-кодом любой менеджер будет эффективным, а попробуй выдать результат с теми, кто есть: с уставшим мидлом, джуном, который боится комитить, и сеньором, которому все надоело. А с "командой мечты" можно и в баре планирование проводить, результат будет отличный
"А с майонезом огуречный" а со скрамом всё это сразу взлетит!
Уставшего мидла заменяем на свежего и бодрого
Джуна уже заменила нейронка
Синьеру тоже предлагаем найти место, где ему будет веселее, может тогда и интересно сразу станет
А если серьезно, то такую команду в целом ничего не спасет
В большинстве контор есть куча реальных, годами не разгребаемых проблем, которые являются реальными причинами и усталости мидла, и безразличия сеньора. Проблемы остаются всё теми же, а графики agile с годами становятся всё краше.
Уставшего мидла заменяем на свежего и бодрого
и шерстяного 🐺
Кажется, это автоматически вытекает из желания горящих глаз вместо повидавших некоторого дерьма, если речь о грейде от мидла и выше.
Я в новой команде сменил формат дейли на пн/ср/пт и ничего не изменилось кроме экономии 1 часа времени в неделю.
Сказал команде, что как поставим всё на рельсы и если все будут хорошо работать, то сделаю формат пн/пт и все только обрадовались ,
Спойлер, спустя полгода так ничего и не сломалось...
На споры о важности процессов можно ответить так же, как и на споры о важности знания алгоритмов: если вы можете успешно работать без них, значит вы решаете слишком простые задачи.
Впринципе согласен. Вкратце изложил бы причины появления скрамов так:
1. карго культ - другие так делают, значит и мы должны
2. менеджмент хочет иллюзию контроля. Они никогда на самом деле не будут контролировать, но иллюзию в виде циферок они хотят
3. менеджмент хочет наверх носить какую-то статистику. Но они не умеют пользоваться гитом. Поэтому они заставляют вести дублирующую и бесполезную статистику вместо того чтобы брать статистику из коммитов, смотреть на мры и обсуждения (даже не код, а просто даты, что делается и далее).
В моей компании делалось бы примерно так:
Есть просто список задач, оцениваются они не в стори поинтах, а легко/сложно. Только для больших задач ещё оценивается компетенции скольких людей вообще потребуются для реализации, кому что придётся изучить новое
из созвонов - дейли 2-3 раза в неделю в целях просто обсуждения кто чем занимается, обсудить предложения, возникшие проблемы
никаких оценок в днях наперёд, только назад. Т.е. записываем сколько ушло времени на задачу (без всяких трекеров, просто от взятия до коммита)
маленькие команды (4-5 человек) профессионалов, тщательный отбор
@Kelbon, я помню потратил порядка 20 часов, искал баг в подключаемой по jni библиотеке, его не было когда ее подключаешь напрямую, но через прослойку - вылезали страшные глюки, отлаживать java было не просто, поэтому ковырялся с логами и экспериментами с кодом (правил его то тут то там)... проблему я нашел, ее исправление была одна строчка, добавил auto в определение переменной.
Если вы мою работу оценивали бы по git-у, вы бы меня уволили.
Если просто назвать рандомное количество дней, и то будет лучше. Так хотя бы команде не придется постоянно заниматься этим адом с покер-планингом и прочими ритуалами.
Так и делаю. Если людям наверху нужны реперные точки, то зачем мне мучить команду. Правда, иногда спрашивают за сроки, но мы же не миссию на Марс отправляем: опоздание на пару недель ни к какой катастрофе не приведёт
Я был и PM, и PO. И ключевая ошибка в подобных текстах — путать «у нас получилось» с «так можно управлять».
Процессы нужны не для контроля людей и не ради отчётов наверх.
Процессы — это про управляемость и снижение неопределённости, чтобы с высокой вероятностью получить ровно тот результат, который задумывали, в нужный срок и с понятными рисками.
По тексту создаётся ощущение, что автор никогда не нёс ответственности за бюджет, занятые деньги или стоимость срыва сроков — либо воспринимал их как абстрактные фантики, хотя по тому как вы себя позиционируете это явно не так. В реальности за потраченные ресурсы нужно отвечать: перед бизнесом, инвесторами, иногда — буквально своей позицией.
Да, в маленькой, изолированной, супер-мотивированной команде без внешних зависимостей можно работать без Scrum, оценок и спринтов. Я сам так работал — и это действительно эффективно. Но это частный кейс, а не воспроизводимая модель для продукта, платформы или бизнеса.
Как только появляются:
— несколько команд
— зависимости
— бюджет и стоимость простоя
— ожидания бизнеса до, а не после результата
любая антипроцессная романтика быстро заканчивается.
Проблема не в Scrum, сторипойнтах или дейли.
Проблема в том, что процессы часто внедряют без понимания зачем, превращая их в имитацию контроля.
Но отсутствие процессов — это не свобода.
Это ставка на удачу и мотивацию, а не на управляемую систему.
Зачем сюда писать генерированные AI комментарии? Пора бы уже настроить на хабре автоопределение и не допускать к публикации такие тексты
любая антипроцессная романтика быстро заканчивается.
Про-процессная романтика может заканчиваться не менее быстро, поскольку требует очередной попытки определиться с трудоемкостью выполнения инженерных задач и склонна превращаться в формальность и тягомотину.
Проблема не в Scrum, сторипойнтах или дейли.
Это также может вызывать отторжение...
«Не совсем понимаю, почему многие называют судьбу индейкою, а не какою-либо другою, более на судьбу похожею птицею"
Не спорю с вами, даже в некотором роде согласен.
Просто процессы позволяют планировать тройственное ограничение: деньги, время, ресурсы. Когда это всё ваше собственное, поверьте ни от какого планирования вы отказываться не будете. Это как в поход собираться в горы. Поверьте, когда в горы собираешься, точно решишь посчитать количество еды, вес, и собственные силы, это не прихоть, это вопрос вашего выживания.
Не спорю с Вами и даже полностью согласен, когда Вы описали вопрос русским языком.
Частично согласен когда "всё ваше собственное" вы начинали с нуля.
Нельзя согласиться, когда приходит дядя со стороны и говорит, все ваши опыты, СП, СНИПЫ, ГОСТЫ...ерунда, а он принес!!!...непонятно что.
:-) А впоследствии оказывается и похожее на то, что было раньше (Скажем, сетевое планирование)
— А давайте будем оценивать задачи в сторипойнтах! — предлагает радостно
— Зачем?
— Чтобы давать предсказуемые сроки по фичам
— Каким образом это поможет угадать сроки?
— …
выдуманные диалоги легче поворачивать куда вам нужно.
в реальном таком диалоге, даже если вдруг он состоится и вас позовут, решение уже принято менеджером и согласовано выше, вас позвали ознакомить с решением и заручиться непротивлением.
если вы будете сопротивляться громко, то вся ложь, которая не случилась, не случилась из за вас, тк вы саботируете и вообще всегда были проблемным кадром. если не будете громко сопротивляться - тоже, потому что вы согласились и саботируете/недостаточно хорошо работаете, вечно у вас что-то там, нужно взять на контроль (от которого ничего не станет лучше, но будет создаваться правильная иллюзия у ЛПР).
реальность не важна, цифры не важны, никому до этого нет дела. важны ощущения нескольких ЛПР, то как они интерпретируют то, что слышат. не результаты, а то, что они чувствуют, когда им эти результаты преподносят.
контроль не важен, важна иллюзия контроля (привет Илон Маск, Роскомнадзор). результаты не важны, важно ощущение, возникающее у слушателя, когда результаты презентуют (привет OpenAI, Apple).
так появляется правильно подобранная статистика, карго-культистские процессы и пр.
РФ специфика менеджмента, с его ордынской архитектурой, лишь добавляет оттенков поверх, не меняет картину радикально.
добро пожаловать в IT, и корпоративный мир в целом.
Разгадка тут:
У меня была супер-мотивированная команда
Чаще всего это это не так.
Подитоживая реплики ряда комментаторов: В вашем описанном кейсе:
Компактный срок в 4 месяца и чётко поставленная цель.
Команда, подобранная без существенных ограничений.
Неудивительно, что Скрам тут бесполезен. Он придуман для больших задач с не конкретной целью (слишком амбициозной или заказчик сам не до конца знает). Для этого проект бъется на спринты, каждый из которых согласуется с заказчиком. Такой компромисс между Time&material и проектами с фиксированной оплатой за результат.
А кроме таких задач, которым подходит Скрам, есть и другие. Например, когда целей много (различные сервисные команды). Для них есть другие системы.
Тут наверняка комментируют много людей, кто строил процессы. Поделитесь что у вас реально заработало?
И что можно было бы сделать в случае микро команд (2-3-4 чел, это без учета менеджмента, типа продукт овнера и скрам мастера) на довольно сложных проектах, а еще когда нет отдельных людей на аналитику и некоторые программисты или QA работают на два спринта одновременно или даже отвлекаются на саппорт.
я могу сказать про то, что не заработало: ничего. Если у вас нет гарантированной длины спринта ("отвлекаются на саппорт"), нет команды ( в том числе это варианты типа "в прошлый раз на проекте работал Вася, в этот раз будет Петя", "Вася пилит проект слева, Петя справа, точек пересечения нет"), нет того, что любят называть "ненужными ритуалами" - то ничего и не заработает.
Мда, какое гигантское количество агиле адептов улетают в космос на задней тяге. Я думал мода на это прошла уже достаточно давно, чтобы даже в России начали выздоравливать от скрума и прочих эффективноменеджерские болезней.
Интересно, как же в других отраслях живут без спринтов, сторипойнтов и прочей чепухи?! Чем же айтишка такая особенная, что им нужен целый набор профессий, чтобы строить эти самые эффективные процессы, оценивать задачи и клеить стикеры на доску?!
В общем, успехов автору, что встал на правильный путь эффективного менеджера без всяких посторонних примесей.
А… вы иронизируете. Ясно ясно
В других это тех где пару месяцев уходит на согласование проекта, год(ы) на проектировку и месяцы(годы) на приёмку? Ну да, это куда лучше чем спринты по две недели.
Планерка, пятиминутка, квартальный план, месячный план, отдел технического контроля, сдача/приемка продукции, наряд-задания, разбор полетов, оперативно-календарное планирование и т.д. Все что есть в agile есть в том или ином виде в других отраслях. Просто называется иначе.
Цена контроля и управляемости в замедлении. Существенном. Большие команды - контролировать невозможно, можно только делать бумажки, на которые можно скинуть ответственность когда что-то пойдет не так, а оно пойдет. Менеджмент хочет быть сверху, хотя на деле он снизу, для многих программистов он прокладка для негатива. А ведь ещё можно проводить эксперименты с нейронами, дать одинаковые задания, но для одних вводить все это, для других нет.
И да заметить импортёра можно только имея хотя бы 60% его скиллов. Тогда можно оценить что человек делает, и нужно ли его держать в команде. А метрики - становятся предметом манипуляций, неизбежно если они открытые.
Акционерные общества обязаны отчитываться перед гос регуляторами. От сюда и все эти запары были внедрены в Agile, имхо.
А еще перед собеседованием не забудьте спросить у работодателя, если у них внедрена система ISO:2009, которая обязывает вести документацию таким образом, что любая требуемая информация должна быть получена в течении пяти минут. Естественно в таких условиях вам всем приходится не слабо напрягаться. Нет не только вам — программистам, а как раз тем менеджерам «прокладкам» между вами и топ-менджмеетом, между компанией и регулятором…
Так что да — это бюрократия. Удачи!
Уберите в маленьком городке разметку на дорогах, дорожные знаки и мало что изменится. Уберите в большом городе и получите хаос. Если ничего не сломалось, значит ничего и не работало.
Я тут попробовал ездить в чистом поле без всяких ПДД, поворотников и ремней безопасности и знаете - ничего не случилось. Вывод - пдд не нужны.
Очень правильный вывод, в поле ппд не нужны
Уберите в большом городе
Возможно, просто убрано постоянное регулирование светофоров без причины и частые отчеты по грузопотокам в городских кварталах.
Вероятность того, что бывают "моддинги офисов" тоже исключить нельзя. Помните, когда на заре...приемные оборудовались панелями с мигающими лампочками, что очень влияло на клиентов.
Всё это просто болтология. Как выполненные цели в срок 4 месяца доказывают, что скрам неэффективен? А где гарантия, что вы с командой не выполнили бы эти же цели быстрее, пользуясь скрамом? Ваш успешный опыт ничего не доказывает и ничего не опровергает. Хотите что-то доказать, поставьте научный эксперимент: 2 команды с примерно равными навыками и опытом и две примерно одинаковые или одинаковые задачи; в одной команде пользуйтесь скрамом, а другая пусть просто пишет код; кто быстрее и качественнее справиться с задачей, тот и победил.
А эффективность скрама доказана подобными научными экспериментами? Ну, чтобы было, что опровергать.
Эффективность Scrum была неоднократно доказана различными исследованиями и практическим применением в реальных проектах: Google, Spotify, Microsoft и др.
Угу, "у вас просто неправильный скрам"/"вы не понимаете, что такое скрам".
Я - практикующий скрам-мастер в команде, я не менеджер ни разу, я сеньор фронтенд-разработчик с большим бэкраундом в бэкенд-разработке и разработке вообще. На роль скрам-мастера меня выбрала команда. Отвечу Вам ровно тем же сообщением, которым я ответил автору этой статьи в его ТГ-канале по ссылке выше. И, да, это не повторение заученных фраз из скрам-гайда, это ежедневное применение скрама и наблюдение за работой команды до введения этих практик и после их введения (производительность команды значительно выросла).
"Скрам - это лишь инструмент, набор практик, призванный облегчить работу замотивированной команды для достижения цели наиболее оптимальным способом. Если он доставляет команде боль, то это только потому, что команда использует его неправильно. Скрам полагается на 3 столпа: прозрачность, инспекция, адаптация. Прозрачность нужна команде, чтобы все чётко видели цель (как долгосрочную, так и краткосрочные). Инспекция, - чтобы все члены команды понимали, что они по-прежнему движутся к цели оптимально. Адаптация, - чтобы команда могла корректировать свой курс при движении к цели. Скрам - это не бюрократия, а инструмент разработки."
Причём, я добавлю, это инструмент самоорганизующейся команды в первую очередь, а не менеджеров, как указано в этой статье. И, да, если он вам доставляет боль, то значит просто это не тот инструмент, который вам нужен прямо сейчас (для задач или условий, в которых находится ваша команда) или вы неправильно его используете.
Очень вредная статья
Аффтор не понял что такое скрам и решил его изобрести заново. Тот же скрам, только на свой манер. И потом сказал, что он отменил его))
Когда одна команда а задач мало, никто не звонит и не дёргает с проблемами, все классно. Такой идеальный проект в песочнице. А когда куча зависимостей, проекты затрагивают 2-3-10 команд, компания динамичная, меняются архитектуры, продукты, без сроков просто каша, проекты застревают на месяцы некоторые выгорают а некоторые сидят без работы месяцами, куча узких мест и никто не может ничего исправить ....
Но это больше не про скрам а про масштабируемые фреймворк, конечно.
А целом, все сработало потому что условия скорее всего были тепличные
Согласен с Вами, особенно со вторым пунктом в самую точку. Кстати я заметил если раньше коментарии были от наглухо непонимающих людей скрам. То сейчас уже ощутимо больше видно комментариев в пояснениями какие проблемы он помогает решать.
Да уж, тепличные условия. Команде дали понятную задачу, выделили адекватные ресурсы, поставили ясный срок - команда справилась.
А вот если бизнес-требования плавают от месяца к месяцу, ресурсов на новые хотелки нет, а команда соседей полтора месяца делает то, что делать уже не надо, то тут только скрам поможет. Хотя я и при скраме подобный срам регулярно наблюдаю.
Если заказчик не спрашивает исполнителя - а когда?
Можно делать все, что угодно и, как угодно))
Соглашусь - грустная статья. В Скраме есть выражение - to do Scrum vs pretend to do Scrum. Как раз про ситуацию, когда Скрам отождествляется с церемониями. Выполняются церемонии, а Скрама нет, и соответственно нет эффекта. Не закрепилось в чем заключается Скрам, для чего нужен, в чем заключается эффект. Но нужно признать это недостаток оригинальной литературы по Скраму. Книги в основном рекламируют платное обучение и консалтинг.
Но дело даже не в Скраме, а в том, что является артефактами работы команды и для чего они вообще нужны.
у меня вопрос уже к первому абзацу. "если убрать все серам атрибуты то менеджерам будет нечего делать"
Я прошу прощения, но в скраме разве есть такая роль "менеджер"? Я не то что бы большой фанат скрам (имхо это такой костыль, для тех кто никогда не работал по agile). Но по моему каждый раз когда в критике скрам появляется слово "менеджер" это такой Ред флаг, говорящий что сейчас будет не критика скрам, а критика чего то, на что пытаются натянуть снятую со скрам "кожу" в виде терминологии, ритуалов и тп. Но что ни к скрам ни к аджайл отношения не имеет
Кажется, у вас не было скрама. Если ничего не сломалось от отмены церемоний, значит это были просто тупые церемонии.
Если вы не понимаете, зачем нужна ретра, то конечно она у вас работать не будет.
Вобщем, спасибо что поделились признанием ваших менеджерских способностей.
Все начинается с мантры "главное софтскилы а программировать мы и обезьяну научим". Потом дейлики и прочие ритуалы, изначально созданные чтобы сплотить мотивированных профессионалов плечо к плечу, превращаются в инструмент контроля за софтскильными неучами и лентяями. Потом эти же ритуалы превращаются в способ имитации работы при раздутом штате. Потом пузырь лопается и первыми выставляют на мороз тех кто любит работать, потому что софтскилы важнее. Что будет потом увидим.
По опыту, работал в команде с аджайлом и дейликами где 6 человек писали 10 dto и json-ов 3 месяца. И в команде и одним митингом в неделю где один программист собирал сервис за две недели. За что купил за то продаю.
Имхо, это просто результат кризиса культуры менеджмента и управления. Вместо того чтобы создавать условия для работы, происходит банальное администрирование процессов без понимания их принципов. А проблемы начались с того момента когда в менеджмент начали пускать тех, кто не понимает процессы которыми они управляют, то бишь без технического опыта. И про бесполезность менеджеров говорят как раз поэтому. Аджайл практики так вообще скатились чуть ли не до уровня консалтинга, и внедряют их куда ни попадя, лишь бы получить иллюзию контроля. Особенно пугает когда аджайл вводят туда, где он противопоказан и где кроме V-образной модели не может быть ничего.
Давно автор, вас читаю, есть реально интересные публикации. Но в данном случае вы демонстрирует полное непонимание самой сути управления чем-то крупным и статью можно свести к мысли "оставьте умных людей в покое, и все будет работать хорошо". На проектах с большим бюджетом, зрелой спаянной командой, лояльными заказчиками это действительно может так получиться. Но как только появляется какой-то дефицит - и идея самокалибрующейся системы начинает троить. Тут ведь знаете, есть такая работа, которую не видно, пока все идёт хорошо. Никто не видит дворника пока улицы чистые и никто не думает про электрика пока в доме есть свет. И никто не понимает, зачем кормить менеджмент, пока есть заказы и нет задержек зарплат и сокращений.
Так вот, говорю вам как человек, много времени проведший с обеих сторон, и как пишущий скрипты и постановки аналитик, и как выстраивающий процессы управленец:
Оценки нужны не чтобы отдать их наверх. Они нужны что спланировать роадмап продукта и график релизов, убедиться что при текущем ресурсе команды реально выдержать сроки, с учётом SLA по поддержке, обязательств по контрактам и поставке фичей, запланировать ресурсы команды и инфры. И идея "просто оставьте умных людей в покое" не решит этой задачи. Эти же самые умные люди потом будут крепки задним умом и будут говорить что менеджер должен был подумать заранее про приоритеты фич, про найм человека на фронт и на инфру, должен был сформировать реалистичные ожидания у заказчиков и многое многое другое. И можно будет справедливо сказать "мы работали хорошо, а менеджер не справился". Так как ему справиться если у него нет инструмента для хотя бы примерного прогнозирования-то?)
А если продукт/проект большой? Десятки, сотни человек? В таким масштабах физически нереально не то что каждого учесть, даже в лицо-то не каждого знаешь, в этих условиях какой команде сколько нагрузки запланировать? Когда они это отдадут? Как сформировать ожидания смежных команд, чья работа зависит от поставки этой? Вот эти все простои , потом авралы, разве это не есть прямое следствие неумения менеджера в дата драйвен?
Есть, конечно, те, кто используют отчёты как средство самопродвижения и самопиара, только процессы-то тут причем? Это не процессы ненужные, это люди ими корыстно злоупотребляют просто. Так любой порядок можно довести до абсурда, а любой закон - превратить в насмешку. Так что ж теперь, отменять все законы, скатываться в каменный век?) Так в джунглях тоже есть законы) Так что правильный путь - бороться не с процессами, а с теми, кто их извращает и лишает содержательности.
Ага, "ребят, нам надо ганту заполнить, есть две фичи, по одной аналитик начал копать вчера, по другой ещё не начал, дайте _какую-нибудь_ оценку". Реальный случай из практики.
Без планирования вообще никаких бюджетов не построишь и никаких контрактов не заключишь. Но такие планирования, на год вперёд, неизбежно подразумевают, что впереди неизвестность и являются гаданием, которое может и должно опираться не на оценки спринтов, а на чуйку. Ну и зачем тогда все эти игрища с оценками задач спринта?
Истории бывают разные. В одной конторе не было никаких скрамов, тебя только закидывали задачами и на дейли ты отчитывался что и как. И вроде нормально жилось. Но потом пришёл тот самый заряженный менеджер и стал внедрять скрам. В итоге двухнедельные спринты, одна встреча в середине спринта, уточнить всё ли идёт по плану и на демо ты отчитываешься по задачам, которые ты получил на спринт. Из минусов, планирование спринта занимало почти целый день и выматывало неимоверно. Но то что тебя потом 2 недели практически не трогают, того стоило! И да, было проговорено и договорено, что если ты успеваешь раньше чем за 2 недели, молодец, можешь остаток времени заняться чем угодно, можешь по рефачить что-нибудь, можешь коллегам по спринту помочь, а можешь статейки на Хабре читать)
Одним словом - стало действительно лучше, по крайней мере для исполнителей.
Мне тоже посчастливилось работать с таким скрамом. Спринт две недели - неделю вкалываешь, ты заряжен и мотивирован все делать быстро, где-то перерабатываешь, отдаешь все задачи в тестирование, а потом сидишь, чилишь, помогаешь тестерам, команде, уходишь домой пораньше. Бывало даже когда все задачи закрывались, в последний день спринта можно было на работу не приходить, работа вся сделана, отдыхали ) работы делалось много и все спринты закрывались в срок. Команда была мотивирована улучшать процессы, искать способы автоматизации - все ради того чтобы отдохнуть на второй неделе, покопаться с техдолгом. Тестеры, кстати, отдыхали в первую неделю, потому что задач в тестировании первые два дня не было, они лениво копали бэклог/документацию и пили чаек.
Но потом пришли менеджеры и сказали что если все успели, значит неправильно спланировали. Если задачи кончились, возьмите еще одну/две/три. Потом появился окр и за слишком быстро закрытые цели награждали презрением что мы были недостаточно амбициозны и увеличением числа целей. Ну а дальше, сами понимаете к чему это привело)
Все тут на тоненького. Я считаю, что не нужны ретро например, но потом поговоришь в бане с друзьями руководами, работают в других компаниях, они отвечают, что вы просто не умеете их готовить. То есть этот тот случай когда одни научились это использовать с пользой, а в другой компании, команде - это действительно не нужно, потому, что ни кто не знает кроме срамного мастера, зачем?
Что касательно оценок задач, тоже бесило это планирование. Все ведь понимают с одной стороны, что в оценку закладывается оверхед, где-то пальцем в небо. Но однажды на одном из проектов попался мне на дейлике очень хороший инженер, он сказал фразу, которая изменила мое мнение об оценках задач. Сказал одну простую вещь "если у задачи нет оценки, значит ни кто не знает, как её делать, и значит, что ее в работу брать нельзя" - и вот тут то я прозрел, что это действительно так. Если меня попросить оценить бэклог на супер спринт, в момент декомпозиции и оценивания я уже подумал, как я ее буду делать, то есть я уже понимаю, что это реализуемо при этом в разумные сроки, пусть с погрешностью. Какие-то задачи уедут за дедлайн, какие-то выкатим раньше. Но суть не в этом, суть эта в понимании реализуемости. Более того заказчик тоже хочет знать в какие сроки какая задача будет в прод. Плюс оценки так же, что при известной ёмкости трудочасов разработчика можно заранее часть задач, вынести в след квартал и обговорить с заказчиком это ещё на берегу и тогда факапы будут бить не сильно больно, точнее какие то вещи не успели, но это будет на минималках, основное, что планировали сделали. Ожидание и реальность начинают идти рядом и от этого строится в том числе здоровая коммуникация с заказчиком, без нервов и на позитиве.
Дейлики меня тоже напрягали, но тут ещё зависит от Лида, унылое г он(сегодня третий день, как мы не хотим работать, оповещал каждое утро один персонаж))) или реально лид. Лид не должен быть унылым). Лид должен знать как вы двигаетесь по задачам иначе в конце недели вы сделаете ему больно если реализовали вместо трёх, половинку одной. Ни один разработчик не будет писать сам, что у него не получается, он будет заниматься, работать ночами, пробовать сам решить и когда придет момент встречи больно будет всем. Поэтому дейлики нужны, лиду чтобы понимать, что все ок и в случае когда тормозим оказать помощь если процесс реализации затянулся, опять же тут и про оценку. Где-то тормознуть в попытках и поштурмить проблему. Если лид уныл, вас будут бесить дейлики, если лид забыл сразу после дейлика, что вы рассказывали, вас будут бесить дейлики, если лид норм, вы будете спокойно с пониманием и осознанием приходить и рассказывать и ни какого дискомфорта. Я работал с разными лидами и теми и этими. На опыте;)
И что-то во мне подсказывает, читая свои же рассуждения, что это зрелость. :))) ну и нормальный лид)
>Сказал одну простую вещь "если у задачи нет оценки, значит ни кто не знает, как её делать, и значит, что ее в работу брать нельзя
Это просто решается нормальной проработкой требований до планирования. Я, как лид, всегда так делал, но мало где ещё такое встречал, потому что это требует больших затрат от одного человека, поэтому везде и всюду это заменяется в продвинутых командах - покерным гаданием, в менее продвинутых - гаданием без покера.
И всё равно, даже после подробной проработки и декомпозиции:
1. Всё равно остаются неясные моменты, которые всплыли во время этой проработки и которые требуют "уточнить у бизнеса на следующей планёрке", "обсудить открытые вопросы интеграции с другой командой". Если выстраивать водопад и не брать фичу, пока вообще все вопросы не будут по ней закрыты, то никакой жизни не хватит, чтобы когда-нибудь её начать.
2. Даже для ясных задач сроки всё равно широко плавают. Я и с оценкой для себя промахиваюсь, с оценкой за другого разработчика ещё больше могу промахнуться, а сам разраб промахнётся, потому что к моменту планирования ещё не погружён в задачу так же глубоко, как тим-лид (так будет всегда).
3. Наконец, несмотря на всё сказанное выше, интегральная оценка сроков доставки фичи с обозначенными рисками +-неделя мне ясна. Зачем тогда все эти микрокалькуляции?
Спасибо за Ваш ответ. Спешу прокомментировать.
Всегда в задачах есть эти неясные моменты, блокеры, зависимости. Бывает, что их нет. Важно другое, что Вы стратегически спланировали будущее продукта. Общие сроки проект? Я Вас умоляю. Просто в цифрах: у вас проект, в нем 100 задач, 30 задач одинаково важны, но с точки зрения разработки имеют разные сроки исполнения. Оценить на ближайший квартал например эти задачи уже помогает далее провести переговоры с заказчиком, что вот эту фичу мы сделаем за неделю, но придется выкинуть из плана это и это. Но возьмём её в следующем квартале. Это вроде достаточно очевидно. Особенно для лида.
Со сроками промахиваются все, сам себе и товарищу. Это и называется оверхед в оценке, по нашему выше предположительно реального. И это нормально. Я повторюсь, это позволяет заказчику осознавать исполнения в прогнозируемые даты тех или иных реализаций задач. Как вы себе представляете ответить заказчику на вопрос, когда будет реализован какой либо из этапов проекта? - получается вы сразу на себя берете ответственность, что весь проект будет реализован когда-нибудь. При этом зачастую выкатывается mvp, а дальше оно обрастает функционалом и тут уже важно, а когда выйдет эта фича или исправление, а когда та? В вашу интегральную оценку я здесь не поверю. Да и заказчик будет недоволен когда вы обещали и не сделали. А когда будет подгорать, вы как лид будете давить на исполнителей, потому что вы обещали, а они исполнители. И здесь не про микро, здесь про осознание и планирование, важное слово, когда у исполнителя одна голова и две руки, а так же 8 часовой рабочий день из которых он эффективно работает 5-6.
Ответил в п.2
Тут я сделаю ремарку, что есть проекты, работа, когда не нужно например иметь план на квартал, год или полгодпа. Есть просто задачи и их надо делать. Но не бывает такого, чтобы не спросили к какому дню ты её сделаешь. Не бывает. Дают задачи, спрашивают оценку, Вы, как уважаемый лид, спросите, к какому дню можно ожидать реализацию))). А зачем спрашивать когда будет сделана задача, к чему эта микрокалькуляция, микроменеджмент, у нас же есть понимание интегральное? Пусть делают, как сделают, так прийдут с результатом). Туше.;)
>Просто в цифрах: у вас проект, в нем 100 задач, 30 задач одинаково важны, но с точки зрения разработки имеют разные сроки исполнения.
Но ведь вы никогда не получите декомпозицию проекта на "100 задач" сроком так на полгода вперёд. Неоткуда такой подробной декомпозиции взяться. Предоставить такую подробную декомпозицию - это всё равно, что до того, как взяться за проект, наполовину его сделать. Их невозможно в таком объёме спланировать и оценить наперёд. Поэтому всегда будет крупноблочная оценка работ и плавающая смета. А все эти ежеспринтовые оценки задач на планировании, которые мы тут обсуждаем, они к долгосрочному планированию никак не применимы.
Смотрите, я не писал про полгода, это ваша формулировка. У меня написано буквами - квартал. Я делаю оценку бэклога на квартал и в нем задачи проекта декомпозированы до уровня позволяющего ее оценить в днях. Затем сложить оценку, понять помещается ли это в капасити и дальше принимать решение что идёт в работы на квартал точно, что идёт по принципу если успеем, а что точно идёт в следующий. Далее расставляются приоритеты задачам и согласно этому списку и порядку мы двигаемся по этой карте. Таким образом у всех сторон есть договоренность и известно, что будем делать и в каком порядке. Более того есть уже приближенное понимание о задачах на следующий квартал.
Наверное, можно по разному понимать, что такое задача (фича для бизнеса или неделимый объём работы для разработчика) и по разному понимать уровень проработки и декомпозиции, который позволяет оценить задачу в днях.
С моей точки зрения проработать даже одно требование на одну фичу и нарезать по ней задачи на две недели вперёд - это уже большая и трудная работа. И даже в столь подробно декомпозированных задачах оценки будут плавать в широких пределах.
Нарезать столь же подробно 30 задач на квартал вперёд - это, по моему мнению, и невозможно (ресурса не хватит) и бессмысленно (изменения со стороны бизнеса, аналитики, смежников сделают половину нарезанных задач неактуальными). Значит вы, скорее всего, под декомпозицией на задачи понимаете не задачу на разработку, которые и оцениваются во время стандартных скрамовых планёрок, а какие-то более крупноблочные вещи, скорее всего фичи. Т.е., либо мы говорим о разных вещах, либо ваш опыт радикально не бьётся с моим, потому что в условиях неопределённости _всех_ тех проектов, в которых мне приходилось работать, скрупулёзная нарезка задач даже на месяц вперёд - это всегда попусту потраченное время.
В общем: подробное окно планирования неизбежно будет коротким, а длинное окно планирования не может быть детальным. Чем короче планирование - тем достоверней могут быть оценки, чем дольше окно планирования - тем оценки гадательнее. Но с подробными оценками на коротком плече есть та проблема, что хотя достоверность их и выше, польза такого краткосрочного планирования сама по себе сомнительна.
всё так в общем и похоже на рассуждения в стиле "хорошо мотивированному сотруднику контроль только мешает, он и так отлично работает". ну как бы да, я тоже только за всё хорошее и против всего плохого.
в жизни очень много нюансов и нет общих правил.
Достаточно прочитать начало, когда автор говорит что ему нужно выполнить требования за 4 месяца. А потом рассуждает об Agile и Scrum...
Гибкая разработка нужная чтобы не делать пол года никому не нужную фичу. Не делать MVP полтора года на который не будет спроса. Не разрабатывать пол года интернет магазин, заказчик которого скажет, что мне надо было по другому.
Гибкая разработка для того, чтобы получать обратную связь от рынка / заказчиков как можно раньше. А не для того, чтобы выполнить ТЗ в конкретно поставленный срок...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Я убрал оценки задач, спринты, планирование и ретроспективы — и ничего не сломалось