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

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

Впрочем, историю с тем чудиком я зря вспомнил, потому что она здесь, всё таки, слишком уж сбоку.

Вот только при чем тут аджайл?

При гибкости.

Вообще забавно вы тут 8 страниц нафлеймили так и не разобравшись что такое этот самый agile

Для этого не нужны частые релизы.

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

Если эту операцию оставлять на конец разработки то надо либо оставлять на неё буфер в N раз больше оцененного, либо смириться с риском полного провала.

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

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

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

Liz812 Шома сказал, что ты 3,14дар. А Шоме нужно верить.

Я подозреваю, почему-то, что это мини робо дэнсер.

МРД тоже геем был?

• Коля, модульнейм твой? Я тут столкнулся с проблемой, всё правильно делаю, а модуль неправильно работает.

• Окай, посмотрю.

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

У него эксцентричное чувство юмора. Такие финты он уже проделывал.

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

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

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

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

Как всегда прибежала Д’Артаньянша-Петросянша, что-то кудахтнула, а дельного ничего не сказала.

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

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

Любопытно /и не более/ все таки было услышать мнение об этих эффективности этих методологиях от тех где их действительно пробовали использовать.

Что касаемо программных проектов, то здесь нужно иметь всего лишь пару толковых:

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

Остальное все от «умных менеджеров», "умных, умеющих руками водить’, … и иного мусора, который только губит проекты.

Владимир

Любопытно /и не более/ все таки было услышать мнение об этих эффективности этих методологиях от тех где их действительно пробовали использовать.

В интернете абсолютно подавляющее число людей, которым есть что-то сказать, - это либо манагеры/PM, которые за пять лет похоронили 5 проектов или вообще не имеют опыта, либо прогеры, на которых эти методики испытали и они теперь пишут гневные отзывы. Комерсов, которые применяли Agile/Scrum, преуспели в бизнесе, и теперь могут писать в интернете рассказы о том, как стать такими же успешными - нету. Agile/Scrum - это почти всегда смерть для бизнеса/стартапа.

люди и взаимодействие важнее процессов и инструментов

работающий продукт важнее исчерпывающей документации;

Ну и говнище. Аж мне страшно стало.

удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

А это что? Неужели наш любимый production driven tesing?

частая поставка рабочего программного обеспечения

О Г-споди! Это же знаменитый chik-chik & production driven development! В чистом виде! Они серьёзно или троллят? Никогда не интересовался темой просто.

тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

Когда кодить и заниматься

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

? Весь день только и уйдёт на трём с заказчиками и выкатыванием костылей.

простота — искусство не делать лишней работы

Если это можно рассматривать, как crutch driven development, то получится ccccombo. Чувствую надо завязывать с программированием и идти во всякой аджайл и прочее говнецо. Основы я знаю, надо под это запилить архитектуру и стричь бабки.

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

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

В резюме не забудь в качестве скила указать.

chik-chik & production driven development

Более корректно это называть «Herak-herak Driven Development».

Правильно ли понял, что для разработки программных проектов эти метологии нужны «как телеге турбина»?

Владимир

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

PS: У меня «узкая специализация» - создавать архитектуру проекта и самому же ее реализовывать в программном коде.
Остальное больше для троллинга.

Владимир

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

Есть еще более совершенный вариант, но это уже 5.1

Точно.

Email: crutchmaster at yandex.ru
Склилы: рсубд, жс, жабка, микросервисы, костыли, затычки, подпорки.
Знание методологий agile (production driven testing, 
crutch driven development, 
herak-heran & produnction driven development)
О себе: не пью, не куру, не употребляю. Нюхаю клей.

Когда в проекте все действующие лица — шланги, и никто не знает, что делать, то это вполне рабочий вариант.

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

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

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

Если концепцию так легко извратить, то это значит, что она изначально порочна.

Да всё, что угодно можно извратить и довести до абсурда. Тут просто перепутали причину со следствием, кмк. Кто-то просто подсмотрел, как где-то работали опытные разрабы и запилил из этого концепцию.

Если концепцию так легко извратить, то это значит, что она изначально порочна.

Попинал соломенный самолет по фюзеляжу и говорит — говно эта ваша авиация.

Когда в проекте все действующие лица — шланги, и никто не знает, что делать, то это вполне рабочий вариант.

Бывает, что «действуюующие лица» и руководитель - шланги … /не глупые, но «шланги еще те»/.

Владимир

На нашем предприятии менеджеры интенсивно осваивают методологию «отжайл».

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

Владимир

«Юра Деточкин» - исключение из правил.

Владимир

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

начинается самое интересное - подгонка этой метрики под нужное значение силами всей команды!

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

Владимир

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

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

Я сейчас коваыряю вот этот кусок дерьма:
https://tiptap.scrumpy.io/
и поражаюсь чудесам, которые творит аджайл. А именно, разрабы за год работы над проектом написали 2 тысячи строк базовых функций и еще 3 тысячи строк расширений, где половина строк расширений - это декларативное описание тэгов. Доки написаны на «отстаньте от нас», комментов в коде почти нет, багтрекер завален просьбами «добавьте фичанейм» и ответами «нет, мы не будем добавлять фичанейм» с оправданиями вроде «это не важная фича» и «вам нужно - вы у себя добавьте». Это при том, что по сути проект представляет собой тупо обертку над https://prosemirror.net/ , и я уже думаю послать этих скрам-мастеров на три буквы и пользовать prosemirror напрямую.

Метрика - это придуманная манагером формула, по которой считается результат спринта.

Бывает «сложный» для менеджера вопрос решается в десять минут, а «не сложный» и пару дней занимает.

Владимир

Какая нажористая тема.

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

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

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

В условиях хронически некомпетентного менеджмента и проваленной бизнес-аналитики

То есть в типичных современных условиях ).

Я уже иногда боюсь произносить слово «планирование», оно стало чем-то ругательным. Это всё равно что сказать: «а давайте прежде чем писать код, нарисуем на бумажке блок-схему».

Начинать надо не так, а давайте прежде чем рисовать блок схему напишем ТЗ (:

Я конкретно не про блок-схему, а про «модность» технологий.

Блок-схема для большинства - это что-то что преподают в ВУЗах выжившие из ума и безнадёжно отставшие от жизни дедушки советского разлива.

Не стыдно быть некомпетентным, стыдно быть не модным.

Все эти ваши IT мне вообще всё больше шоу-бизнес напоминают)

Не стыдно быть некомпетентным, стыдно быть не модным.
Все эти ваши IT мне вообще всё больше шоу-бизнес напоминают)

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

Блок-схема для большинства - это что-то что преподают в ВУЗах выжившие из ума и безнадёжно отставшие от жизни дедушки советского разлива

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

А самое главное состоит в том, что ТЗ программистам подготавливали «постановщики задач» /и вот в ТЗ и была блок-схема/.

Вы уж извините старого дурака за пояснения.

PS: Если будет интересно, то не много расскажу какие вопросы и как сейчас решают старые пердуны.

Владимир

Как самый опытный в этом треде подведу итог.

Agility — это гибкость, адаптивность и способность максимально быстро трансформировать идеи, планы, команды, любые структуры и в конечном счете самих себя. … Способность адаптироваться к новым вызовам может стать основным фактором выживания бизнеса.

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

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

Ты давай дальше двор мети, мы и не собирались твои задачи решать.

Беги дальше жевать морковку. Кстати, вот почему популярна 1С в России. Они очень быстро реагируют на любые изменения в законодательстве и позволяют мгновенно заменить одну команду другой в случае возникновения разногласий.

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

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

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

Владимир

когда включают метрику, то начинается самое интересное - подгонка этой метрики под нужное значение силами всей команды!

За что платим, то и получаем, логично же.

люди тупо повторяют ритуалы ни понимая их назначения

А наповторявшись ритуалов и так и не поняв зачем, начинают рассказывать о неэффективности.

При том что эффективность принципа и эффективность ритуальных плясок вокруг него - это разные вещи.

люди тупо повторяют ритуалы ни понимая их назначения

А наповторявшись ритуалов и так и не поняв зачем, начинают рассказывать о неэффективности.

Опять сама с собой разговариваешь?