SCRUM в сфере разработки ПО

Выше примеры редких событий которые

Которые не предвидели идиоты, не способные мыслить даже на шаг вперёд, либо просто бредни.

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

это какие-то идиотские примеры.

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

какие, нафиг, рекламы в гугле? это любой школотрон справится.

Ты менеджер и дал разрабу таску на три часа

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

почитай хотя бы что такое планирование и зачем оно нужно

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

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

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

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

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

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

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

планирование - это планирование ВСЕГО проекта. от начала до конца.

И во всех деталях, ага. Сверху донизу.

Мне думается, что планирование не отменяет оперативного реагирования (и наоборот).

https://blog.cleancoder.com/uncle-bob/2018/04/02/InTheLarge.html

Мне думается, что планирование не отменяет оперативного реагирования (и наоборот).
https://blog.cleancoder.com/uncle-bob/2018/04/02/InTheLarge.html

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

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

Scrum of Scrums

это бред. бред из бреда. что-то вроде.

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

и да, всяческие превратности рынка и экономики шерифа не волнуют. так что в проект закладываются и возможные изменения по элементной базе (закупаются заранее нужные компоненты, с учётом запаса на ЗиПы). закладывается уровень инфляции и всё такое. всё продумывается со всех сторон, а не только в теоретическом плане, как именно делать. именно поэтому думать надо вполне себе предметно. а не как блондинка: на неделю вперёд и дальше полная неизвестность.

Докер? Зачем ты вспомнил про докер?

Тащемта, докер для продвинутых ребят, и то, он не сработает может не сработать с первого раза, в случае, если в проде нужны какие-нибудь дрова, например…

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

Ну, ты же смог идентифицировать этот риск не приступая к проекту? Правда?

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

Мне думается, что планирование не отменяет оперативного реагирования (и наоборот).

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

Я всё хочу спросить: а ты манагер/кодер/одмин/директор, или как?

Все вместе и сразу, я - клоун у п.-сов директор в малом (микро) бизнесе.

половина ключевых тезисов Agile просто отваливается

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

Планированию это никак не противоречит — только надрачиванию на неизменность Плана в непрерывно изменяющемся мире.

Планированию (которое процесс) это никак не противоречит — только надрачиванию на неизменность плана.

Дык это только в клятом совке планы были неизменными, т.к. не было возможности их оперативно перестроить (не хавтало выч. мощностей).

При капитализме план не догма, - а руководство к действию.

как можно раньше обнаружить, что мы делаем что-то не то

так если ты делаешь «что-то не то» - придёт главный инженер и настучит по башке :) что значит «что-то не то»? есть ТЗ. есть разделение на мелкие задачи. каждый занят своей задачей. а если у разработчиков нет ТЗ, то непонятно, чем они занимаются.

Все вместе и сразу, я - клоун у п.-сов

Блин, еще и витюшу читаешь - ну прям мечта, а не начальник. Может еще кактусы жрешь и на ситаре играешь?

если ты делаешь «что-то не то» - придёт главный инженер и настучит по башке

В смысле обстановка изменилась и план нуждается в корректировке. Кому стучать по башке — главному инженеру, за то, что использовал недостаточно качественный хрустальный шар при проработке плана? %)

есть ТЗ. есть разделение на мелкие задачи

И вот ты понемаешь, что твое ТЗ устарело, и если ты продолжишь ему следовать, на выходе получится надежный, качественный и никому не нужный продукт. Шо делать?

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

http://pelevin.nov.ru/romans/pe-jisn/9.html
«Пятилеток нет, - сказал Никита. - Но пятилетний план остался. Его же на пять лет вперед сушили»

Не сравнивай корректировки и работу «на глазок» без плана вообще.

Давно, кстати, не читал. Меня сейчас больше классическая русская литература прёт. Ну и всякие статьи по ML/HR/Методологиям управления чем-нибудь.

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

Не, ну, R&D имеет место быть. Причём даже в рамках скрама, если за результат будет считаться отчёт о проделанной работе. Но только как вещь в себе, дополняющая нормальную разработку, а не подменяются её.

Автора легендарной Bolgen BuguRTOS не признал?

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

Не сравнивай корректировки и работу «на глазок» без плана вообще.

А кто сказал, что аджайл был задуман как работа на глазок без плана вообще?

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

Дада, всей этой дикой орде срам-мастеров лично дядя Боб в штаны навалил.

Ты не на абстракную идею смотри, а реализацию

Ну то есть идея-то здравая? %)

есть ТЗ

Если есть ТЗ то скрам и не нужен, о чем они сами и пишут.

Здравые идеи в такую муть не выливаются.

И как же, интересно, планировать весь проект, если требования к нему могут меняться хоть на противоположные в любой момент времени? Agile это учитывает, ваши «планы» - нет

Это не разработка, это тяп-ляп, не нужно подменять понятия пафосным словцом.

Вот на habr.com много сказок про эффективных менеджеров, эффективное управление, …
Им можно верить?

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

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

а как, простите, без ТЗ что-то разрабатывать? типа, мы вот тут с пасанами собрались и решили делать типа проект... только мы в хрен не дуем, что мы делаем и как. но мы будем собираться каждую неделю и раздувать за разработку. это как вообще?

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

Вот почитайте.
https://habr.com/ru/post/429946/ Безумие и успех кода Oracle Database

PS: «Хотеть не вредно».

Про «хотелки»:
https://www.youtube.com/watch?v=Ud9oJEXq8iU «Мой прадед говорит…»

Владимир

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

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

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

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

Шутка.

таких клиентов надо отправлять лесом.

Воспитывать рублем.

Владимир

Если говорить про проектную разработку по подряду, то для заказчика то, что подрядчик подстраивается под его желания, а не уперся в тз и тыкает в контракт, является конкруентным преимуществом. И сторонники планирования на годы остаются без клиентов. Если про in-house продуктовую разработку, то с кем контракт? Заказчик - управленческий аппарат компании.

Удачи с отправлением клиентов лесом, так и надо вести бизнес. Зато план останется идеальным.

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

Здесь нужно перенимать «лучшие методики».

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

Владимир

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

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

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

Эх глупая ты баба. Даже нормативной документации не знаешь. Открываем ГОСТ 19.201-78(СТ СЭВ 1627-79).

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

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

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

Успехов на ниве автоматизации сталилитейного завода.

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

Троллинг и не более.

Для тех кто хочет «хорошо заработать» нужно освоить методологии того, как лучше «отжимать» деньги с клиента.

Владимир