Есть в Германии коллективы, пишущие в режиме Agile? Хотелось бы услышать от них : эй, Вы живы?

Да много есть, а что именно интересует?

Эт вы поторопились :) Сначала надо бы выяснить что ТС под "режимом Agile" понимает....

ну так по вопросам и стало бы понятно. Подождесмъ...

Я имел в виду scrum-оподобные технологии разработки ПО.

Просто у нас здесь период, когда Agile был популярен пришелся на 2008-2012 г. Потом интерес к Agile и вообще к XP резко поубавился, хотя я считаю, что зря.

Вот, интересуюсь, в Германии этот стиль разработки ещё популярен или тоже на спаде?

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

5 REASONS WHY AGILE DOES NOT WORK IN GERMANY AND WHAT TO D...

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

А что тогда у вас стали пользовать после 2012?

Судя по статьям и докладам на всяких конференциях - до сих пор популярен. Новую хайп - волну запустить пока не смогли "agile is dead" не взлетело.

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

Да ну, ерунда, все эти 5 пунктов подходят куче стран. Да той же России. И куда лучше подходят японии. Что не помешало японцам придумать канбан. Вот бы ещё узнать с чего бы этот ветеринар себя в лучшие записал...

До Agile был водопадный подход. К нему и вернулись после ухода от Agile. Хотя те коллективы, в которых я работал в стиле Agile, выдавали потрясающие результаты по производительности и качеству. Я не понимаю, почему от Agile отказались!

Для меня достаточно того, что статья "Почему Agile не работает в ГЕРМАНИИ написана на АНГЛИЙСКОМ языке".

Американцы не любят, когда другие успешнее их.

Да вон даже Даймлер в некоторых отделах по-эджайлному программит и тестит.

Ну, 15% времени на Scrum -- не так уж и плохо.

Но ведь Agile это не только scrum. Есть такие кто на серьёзном Agile? Ну типа там с CodeReview, Retrospective , AgilePoker и прочими механизмами повышения качества ПО?

Хотя те коллективы, в которых я работал в стиле Agile, выдавали потрясающие результаты по производительности и качеству. Я не понимаю, почему от Agile отказались!

Висит на доске баг. И все знают, что это жопа. И все тянут со своим последним заданием, что бы в жопу не влезть. Это еще оптимально. А бывает, что просто никто ничего не делает. Особенно на фирмах, где руководство не имеет права заглядывать в программистскую команду с вопросом "кто конкретно что наработал". Задания на доске, никто ничего не берет и все заняты.

CodeReview это не агил. Это просто нормальный программистский процесс. Что мешает организовать CodeReview в водопадной команде?

Потом задания. Эти хреновы пукты. Задание весит 5 пунктов. Не, 5 много, пусть будет 3. Ну пусть 3. И что? Три пукта это сколько часов работы? Ааа, нельзя в часах, это не длительность, а сложность. Ну ок, пусть будет 3.

Вот у вас отличный пример "карго-культа". Стоит назвать "скрамом" и все заработает. Не-а. У вас не скрам. Потому что

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

б. что команда делает на дейли непонятно (никто ничего не берёт и все заняты)

в. что делает скрам-мастер и где он вообще - неизвестно.

Про "story points" вам явно что-то напел очередной "агильный коуч". Команда отвечает за успех Команда решает как именно она оценивает баллами задачи. Можете хоть наплевать на весь опыт и сделать как хочется - с часами. Почему это плохо? Потому что у каждого разработчика в команде эти часы будут разные. И ПО будет эти часы интерпретировать как ему хочется (а хочется ему "обещаем сделать максимум за столько часов"). На абстрактных "очках" проще договорится во время покера.

Ну и конечно, code review можно делать в водопаде. Проблема в том, что в водопаде все времена распланированы на год вперёд. И как только начинается отставание от графика (а оно начинается, наверное в 95% случаев) что первым принесут в жертву? В скраме - функционал. А в водопаде - "ненужное, отбирающее много времени занятие", т.е. code review ну или тесты, обычно всё же ревью, потому что в нём занят человек, а строчки кода не появляются, отчетность у менедвера ухудшается. Итого - я не видел водопадов где ревью продежался бы дольше 1-го дедлайна (milestone, кто как называет). Потом процесс разработки "оптимизировали" - "вы же профессионалы! мы доверяем что вы сразу пишете качественный код!".

Стоит назвать "скрамом" и все заработает

Все сделали по правилам. Наняли фирму, провели кучу семинаров, закупили доски, установили аттлассиан. Пару месяцев фирма бератовала и надзирала. технически все правильно.

команде наплевать на успех спринта (баг висит, никто не берёт, никакой взаимопомощи, команда "нерабочая")

Да, дураков нет. Когда тикеты раздавались, то чел, который до 15 должен был свой тикет закончить, 16 или должен отчитаться, почему он тянет резину или 16-го он лично и персонально получит неудобный тикет. А тут или я проявлю командный дух и меня поставят раком или подожду, пока это сделает другой дурак. А я его похлопаю по плечу. Кстати, а как перевоспитать команду? Или к скраму обычно и готовые команды продают?

что команда делает на дейли непонятно (никто ничего не берёт и все заняты)

Да, дураков нет.

Все звиздец как заняты. Люди с высшим образованием, свою работу они презентировать умеют.

Да и что такое дейли. Все свои. Все знают, что все тянут резину и демагогят. И что? Ну можно осуждающе посмотреть на бездельника. Ага.

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

Команда ни за что не отвечает. Вообще. сорри, не получилось. Упс. А каждого десятого расстреливать как то не принято. А с пуктами это вообще класс. Тикет на 3 часа делать три дня несколько странно. А вот тикет на три пункта можно и месяц делать. Хотя все знают, что это одно и то же. Так что вы святое не трожте. Пункты это неприкасаемо.

На абстрактных "очках" проще договорится во время покера.

Это точно. 8. Нет 3. ну ок, 5. И это все длится месяц.

В скраме - функционал.

Точно! Как баг вылазит, так покрытие тестами становится под 150%. И Все на собраниях. Ибо те, кто заседает, ошибок не делают.

Sorry, наболело. Впрочем на хабре есть тоже несколько негативных статей с личным опытом.

Все сделали по правилам. Наняли фирму, провели кучу семинаров...

А вы не помните что за фирма?

Да, дураков нет. Когда тикеты раздавались, то чел, который до 15 должен был свой тикет закончить, 16 или должен отчитаться, почему он тянет резину или 16-го он лично и персонально получит неудобный тикет...
Все звиздец как заняты. Люди с высшим образованием, свою работу они презентировать умеют....

И вот тут должен был возопить скрам мастер: "доколе!" И где он у вас?

Команда ни за что не отвечает. Вообще. сорри, не получилось. Упс. А каждого десятого расстреливать как то не принято.

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

Ибо те, кто заседает, ошибок не делают.

Карго-культ. "Заседает" тоже команда а не кто-то.

Перефразируя поговорку, можно сказать, что "кто в скраме работал, тот в цирке не смеется"

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

А вообще, скрам придумали для случаев, когда есть куча народу, где 50% не хотят работать, а еще 50/% не могут..Но результат какой-то выкатить надо. Работа примерно как на зоне. Построения с перекличкой. Коллективная (без)ответственность. Начальник в дела заключенных не встревает. Смотрящий пахан (скрам мастер) следит за порядком и чтобы у всех бензопила работала. В принципе, это в среднем помогает в смысле, что лучше что-то, чем ничего. Но серьезных команд, которые клепают серьезный софт в скраме я не видел (максимум это канбан).

Чушь. Канбан это недоскрам для тупых ленивых, кто только ошибки фиксят.

Почему в часах нельзя? Алгоритм Agile покера как раз на выходе даёт именно количество часов.

А фокус-фактор? Разве после каждой итерации не принято считать фокус-фактор?

Помню эту статейку, только там было вместо GERMANY написано RUSSIA.

А вы не помните что за фирма?

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

И вот тут должен был возопить скрам мастер: "доколе!" И где он у вас?

Доколе что? Тим чем дальше, тем меньше на себя берет. Небольшие задания получают большое количество пунктов. Если спринт не выполняется, то все скромно стоят потупив глаза. И называют кучу обьективных причин.

Карго-культ. "Заседает" тоже команда а не кто-то.

Да верно. Но придумать название это не решить проблему. Раньше каждый получал индивидуальное задание от шефа и индивидуальные звездюли. Или кстати индивидуальную благодарность. Шеф был полностью задействован в процессе. Теперь есть команда. Ну выпендрился я и пару раз вытянул спринты. Ну и что? Команда свое дело сделала, это никто не заметил, а команда теперь ждет, что я САМ буду брать все проблемные тикеты. То есть сам дурак.

Почему в часах нельзя?

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

А фокус-фактор? Разве после каждой итерации не принято считать фокус-фактор?

Я не считаю. Ага, хотел спросить. Как этот параметр расчитывается и как его можно использовать для поднятия производительности?

Алгоритм Agile покера как раз на выходе даёт именно количество часов.

Ага, хотел еще спросить. Что это конкретно значит?

И агил не решает автоматически проблемы в процессе программирования. Более того. Если проблемы не поняты и не проанализированы, то агил их усугубляет. Имхо.

Основая проблема как обычно в понимании инструментария :)

Скрам - это методология управления временем и внедрение скрама никак не может повлиять ни на качество кода, ни на что-либо еще.

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

Скрам ввели, проблемы как были так и остались :)

Скрам - это инструмент для управления процессом разработки. И ничего более.

Нсли что то осталось, я могу посмотреть. Но почему этот вопрос?

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

Я вообще не вижу технических проблем в организации процесса.

А зря. Вернее так - технических проблем (повесить доску, установить джиру и запланировать рефайнмент и ретроспективу) обычно и не возникает. Проблемы возникают с командой и начальством. С людьми. Всем надо свои привычные методы менять.

Во-первых надо набрать команду. Есть люди которые могут неплохо кодить, но которые просто не могут работать в скраме. Потому что а.) не любят брать на себя ответственность за что бы то ни было б.) не воспринимают решения равных им по положению, как обязательные к исполнению (ой, чё они там напридумали, все фигня). Им нужен командир. С крутым названием должности "Senior Super Mega Team Lead". Они радостно получают от него тупейшие задания, и исполняют их. Бухтя себе под нос, мол, вот дурак-то, вот ежели б я решал, я б всё по другому делал. Почему проект загублен? Низнаю... Мы всё делали как насяльника сказала.

Во-вторых начальство (проект менеджер, тим ляйтер, кто будет ПО играть) должно поменять своё отношение. Они не должны лезть в процесс. Иначе мантры о "вы сами решаете как вам удобнее" не сработают, расстройство одно будет. Они должны жить без "через 6 месяцев будет релиз с таким-то функционалом". ПО должен уметь говорить на равных с командой, а не "я так решил".

Любые методики не решают никаких проблем автоматически. Всё надо сначала научится использовать. В том же водопаде клиенты должны жить с длинным ТТМ (Time To Market), потому что 3 релиза до 2020 уже запланированы и на планировку потрачено 500 часов, никто объём 3-го релиза ради добавления новой кнопочки переопределять не будет. Чтобы добавить кнопочку - напишите-ка ТЗ на 30 листах, в которых чуть ли не названия класссов и методов уже пропишут и позицию кнопочки с точностью до пикселя при разных разрешениях экрана, а то если это не прописать то программисты такой фигни налепят, что вы.

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

Доколе что? Тим чем дальше, тем меньше на себя берет. Небольшие задания получают большое количество пунктов. Если спринт не выполняется, то все скромно стоят потупив глаза. И называют кучу обьективных причин.

Доколе процесс симулировать будем. Скрам мастер может на дейли настоять на том, чтобы кто-то взял приоритетный тикет (баг). Потому что выполнил свое - берёшь "сверху". Он должен, если это не поясняет сам программист, спросить почему тикет/подзадание у него висит уже третий день (обычно стараются делать субтаски для больших задание, так, чтобы эти таски были не дольше дня), может ему нужна помощь. Расстрельными подвалами или премиями он грозить не может, да и не должен. Если все отмалчиваются, он должен обсудить это с командой на реторспективе. Мол, последние спринты скорость в очках (sprint velocity, сумма очков у всех, сделаных с спринте заданий) росла, а количество заданий падало. Как вы думаете, почему?Почему 2 месяца назад "добавить чекбокс" было оценено как 2 очка, а в этом спринте "убрать кнопку 'отменить'" - в 5 очков? Усложнился проект? Может пора потребовать от ПО сделать спринт с рефакторингом? Что мешает нам быть такими же эффективными как 2 месяца назад? И эти вопросы задаются не в воздух. Каждый участник должен дать на них свои ответы.Тут уже просто так не отмолчишся. И даже со стороны (я сам скрам-мастером никогда не был) хорошо видно кто действительно что-то хочет исправить а кто просто отсиживает время.

Скрам мастер может выгнать ПО с любого совещания, если тот начнёт выяснять "почему Вася взял тикет с багом и облажался". Но может и посоветовать начальству разогнать команду, потому как она не работает.

Теперь есть команда. Ну выпендрился я и пару раз вытянул спринты. Ну и что? Команда свое дело сделала, это никто не заметил, а команда теперь ждет, что я САМ буду брать все проблемные тикеты. То есть сам дурак.

Не-а. Команды нет. Если "соскрамники" не оценивают вклада, принимают это как "вот теперь и паши дальше" то никакой команды у вас нет. Есть группа. И решение для такого часто бывает одно - такого "тянущего" вынимают из команды и переводят (в идеале с повышением хотя бы на пару процентов) в другую команду с такими же "тянущими". В результате полушаем хорошую команду. А в старой, после удаления тянущего, может суммарно производительность тоже возрастёт, потому как такой тянущий может остальных бесить. Без него им морально легче. Бывает. Но начинать надо с обсуждения на ретроспективе. Мол, народ, а чего у нас такое, я тяну, а вы филоните? Так самому встать и спросить непросто. Хороший скрам-мастер должен сам поднять эту тему. Личные отношения важны в любом коллективе. Даже при водопаде. Но в водопаде о них говорить не принято - это дело тим ляйтера а не процесса.

Да верно. Но придумать название это не решить проблему.

А решение это долготянущийся процесс. Всегда легче сломать, а вот исправлять потом месяцами надо - пока доверие не появится. Если команда не хочет работать в скраме - так и не надо. Можно попытаться набрать новую. Если не сможешь понять почему же они саботируют. А можно поманить морковкой - мол, сделаем 1-ю версию к 01.12 - всем по 50% месячного оклада. Можно в команде устроить срач - премия на (допустим) 5 человек команды выписывается 15 штук, но кто конкретно сколько получит - решайте сами. Хорошо людей вскрывает. Как в детском саду :)

Во-первых надо набрать команду.

Гм. Это Германия. Приличная по размерам фирма с профсоюзом. Куда девать нас, раздолбанную кучку кодеров? Можно придушить втихаря, но уволить практически нереально.

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

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

Мы уже релиз 3 раза сдвигали. Мы - это команда! (Я там потом в тексте везде на "группу" заменил, но тут "команда" звучит круче.)

В том же водопаде клиенты должны жить с длинным ТТМ

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

Скрам мастер может на дейли настоять на том, чтобы кто-то взял приоритетный тикет (баг).

Скрам мастер может настоять на чем угодно. В одном конкретном случае это даже может сработать. Но тогда только дураки будут закрывать тикеты без оглядки на то, что еще простого и интересного осталось на доске.

Если все отмалчиваются, он должен обсудить это с командой на реторспективе. Мол, последние спринты скорость в очках (sprint velocity, сумма очков у всех, сделаных с спринте заданий) росла, а количество заданий падало. Как вы думаете, почему?

И вот тут самое смешное. Кого он спрашивает если все отмалчиваются? Вы социализм не застали? Смотрите, есть толпа за все ответственных людей. И никого конкретно. ВСЕ знают почему. Но ни один дурак не скажет. А зачем?

Люди просто не хотят работать. И из-за групповой игры не видно кто. Идиоты, которые пытались выпендриваться, быстро ставились на место. Еще раз, вы социализм не застали? Очень похоже. Если БАМ, УРА и лозунги, то молодой и наивный коллектив можно заставить работать. Но опытное и циничное болото спасут только расстрелы.

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

Всех не перевешаете! И тут командная игра плюс профсоюз. Если конкретный чел не работает, ему выписывают маннунг. Потом расстреливают. Если пара бездельников развратила группу? Вы не можете всем паушально выписать коллективный маннунг. Значит разогнать можно только с повышением.

Мол, народ, а чего у нас такое, я тяну, а вы филоните?

Ну во-первых никто не филонит. Все носятся как в жопу заведенные. Например обсуждение новой функции старого модуля. В 57-й раз. А то, что функтионалитета нет, то просто не судьба. Кроме того я конечно дебил, но не настолько, что бы спросить у толпы "а чего у нас такое, я тяну". Понятно, что проблема не в группе. Проблема в дураке, который тянет. И это надо как то исправлять. Меня в жизни пару раз исправляли. Как то неохота приключений на задницу. Кроме того я неконфликтный. Я программист и ниразу не организатор. Это не мои проблемы.

И решение для такого часто бывает одно - такого "тянущего" вынимают из команды и переводят

Да вы что? Где это? Кто это такoй дурак, что бы последнего идиота, на котором висят все тикеты, из группы убрать(сейчас речь не о бо мне, я не настолько глуп)? Скрам мастер? Тот, которого и так раком за производительность ставят? И остаться с остальными ? Слабо верится.

Ссоры, получается писсимистично

Я бы из такого болота бежал как ужаленный.

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

Задач типа "жопа" в agile быть не может в принципе. Значит либо это не agile либо речь вообще не о программировании.

Ну, алгоритм Agile-покера, это когда каждый выкидывает рубашкой вверх карту со своим предполагаемым количеством часов.

Часы по классике использовать запрещено. Запрещено прямо, есть обоснование. Вы конечно можете пользоваться часами, но это отступление от канонов.

Задач типа "жопа" в agile быть не может в принципе. Значит либо это не agile либо речь вообще не о программировании.

Клиент внезапно видит чужие данные. Допустим даже сделал скрин. Нефига непонятно, откуда начинать. Понятно, что лажа с сессиями, но какими? ДБ? Аппликатионсервер? А чужие данные это жопа. И тот, кто возмет этот тикет должен будет
1. найти проблему, которую нельзя репродуцировать
2. Найти решение, которое гарантировано проблему решит. Причем время тикает.

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

Во-первых присоединюсь к совету бежать.

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

И вот тут самое смешное. Кого он спрашивает если все отмалчиваются? Вы социализм не застали?

Каждого члена команды спрашивают по отдельности. Типа каждый пишет 3-5 пунктов, что по его мнению уменьшает продуктивность, а потом по очереди выходят к доске, лепят свои 5 листиков на неё, и 3-5 минут рассказывают что именно имеется в виду под пунктами. Потом похожие пункты группируются и смотрят, какая кучка самая большая - узнаём какая проблема воспринимается большинством. Вы такого никогда на ретроспективе не делали?

И как тогда отмалчиваться? Ничего не писать? Или "меня всё устраивает, проблем не вижу"?

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

Такого в скраме быть не может. User Story уже обсуждена, принята командой в работу, никаких обсуждений больше нет (обычно, мало ли, в процессе реализации может всплыть ошибка планирования), только реализация. Тикеты на один день. Не сделал за день - берём тикет на заметку, не сделал за 2-й, подключаем ещё одного человека. Не сделали за третий ставим вопрос о профессиональном соответствии - вы же сами эти тикеты планировали, что они за 1 день реализуемы, как так?

Да вы что? Где это? Кто это такoй дурак, что бы последнего идиота, на котором висят все тикеты, из группы убрать(сейчас речь не о бо мне, я не настолько глуп)? Скрам мастер? Тот, которого и так раком за производительность ставят? И остаться с остальными ? Слабо верится.

Ну, это вам просто с адекватным менеджментом работать не приходилось. Так-то вместо 4-х команд, работающих хреново, из которых ещё и валят на другие фирмы лучшие программисты, делается 1 хорошая и 3 не сильно хуже (которые могут стать лучше). И из 1-й хорошей команды программисты не убегают. Профит. Скрам мастер, конечно, такие решения не принимает. И ПО тоже. Это должно руководство отдела/фирмы решать. Скрам мастер должен уметь заметить такое состояние и посоветовать руководству.

Хорошей команде - дополнительный бюджет, пару тысяч, которые она сама может решить как потратить - на тим-ивент в Берлин на концерт съездить, или проектор себе из потолка опускающийся в комнату заказать (только наличными выплачивать нельзя :)). Будут хреновые возмущаться - мол, а нам, отвечать что а вам - как Катаеву. В смысле "вы еще не показали вашей способности корректно работать в рамках скрама и принимать ответственные, взвешенные решения." Потому про ваши 2 тысячи решило руководство - вы на них получите очень важный для вас курс "я у мамы дурачок" "основы агильной разработки". Или сами уйдут или пара человек зашевелится. Их опять в следующую "нормальную" команду. Может сработать.

Ну, алгоритм Agile-покера, это когда каждый выкидывает рубашкой вверх карту со своим предполагаемым количеством часов.

Чушь. Карты с очками.

При этом как правило в этот момент и происходит решение кто берет эту задачу.

Чушь. Кто делает решается в тот момент, когда её из спринт-лога возьмут.

Задач типа "жопа" в agile быть не может в принципе.

Критические ошибки. Могут.

1. найти проблему, которую нельзя репродуцировать
2. Найти решение, которое гарантировано проблему решит. Причем время тикает.

1. Если уже известно что нельзя репродуцировать, то решение вообще-то простое. Мы не знает что происходило, делаем три (5,7) подзадач - "проверить работу с сессиями в A/B/C/..." с тайм-боксом, скажем 8 часов. Нашли подозрительное - правим, не нашли, говорим что не знаем от чего ошибка, соответственно исправить её не можем, и предлагайте решения - переписать логику, отключить функционал, разбросать разных пользователей по разным серверам/БД ну или что ещё придумаете. И договариваетесь с ПО.

2. С чего бы? Вы не пробовали разговаривать с ПО? Может его устроит что вы понавтыкаете логов, чтобы если такая ошибка вдруг всплывёт ещё раз, повысить шансф понять из-за чего.

-----

Ой, легко...

Просто представь ситуацию, в которой никто не может указать количество поинтов для таска...

Просто большой таск и целиком его не охватить...

Хммм... примерчик...

Есть спецификация на XSD-схемы.

Есть конвертер в код.

В конвертере есть баг - выпадает Circular Reference.

Ну и сколько его лечить?

ЖопААААА!!!! хоть с агилом, хоть без...

вы же сами эти тикеты планировали, что они за 1 день реализуемы, как так?

-----

Будет как написано у Кодера - сраный таск останется висеть как никому не нужный.

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

1. найти проблему, которую нельзя репродуцировать
2. Найти решение, которое гарантировано проблему решит. Причем время тикает.

Как можно решить проблему, если ты не можешь ее репродуцировать?

Если появляется проблема, которую нельзя репродуцировать, то есть 2 варианта развития событий:

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

2) сказать, что проблему репродуцировать нельзя, а значит этой проблемы не существует :D

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

Фокус фактор рассчитывается в конце каждой итерации.

В начале разработки это обычно коэффициент 0.3, начиная с 4-ого месяца это может быть 0.7

Нельзя вводить agile с середины проекта.

Проект должен быть рождён в agile.

Это один из основных тезисов

Уменьшить длину итерации.

По крайней мере это уменьшит вероятность появления таких проблем в будущем. Хотя раз на раз не приходится.

Кстати а Agile -проекте всегда должен присутствовать "представитель заказчика". По правилам он должен всегда находиться в помещении где сидят программисты на расстоянии не более 5м от самого дальнего ;)))

Именно представитель проекта как правило является автором проблем подобного типа

Нельзя вводить agile с середины проекта.
Проект должен быть рождён в agile.

Это ограничение ставит крест на вводе скрама во всех существующих проектах :)

Согласен.

Но нельзя использовать Agile в проектах, начатых не в Agile. Категорически!

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

1. никогда ранее не работали по водопаду

2. Желательно чтобы не работали ранее в торговой фирме.

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

Это ограничение ставит крест на вводе скрама во всех существующих проектах :)

Мало того, оно ещё и высосано из пальца и не обосновано...

Категорически!

------

Ну и слава богу - все что начиналось до игила - всякие Винды, Никсы и прочее - и весь приклад под них под игилом делать никак ниЗЗЗя!!!

Но нельзя использовать Agile в проектах, начатых не в Agile. Категорически!

Я не знаю от куда взялось это утверждение и не понимаю на чем оно основано.

Скрам - это методология управления временем и не больше.

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

У нас обысно под новый проект нанимают отдельную команду.

:) А прокты у вас все вечные? Или как потом эту команду увольняют? Или нанимают команду консалтеров? :) Ты наверное работаешь где-то, где совсем не считают деньги :)

При этом очень важным считается нанять разработчиков, которые
1. никогда ранее не работали по водопаду
2. Желательно чтобы не работали ранее в торговой фирме.

Т.е. берете студентов без опыта? ;)

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

:) Хорошо, когда не надо считать деньги :D

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

Кстати, студенты без опыта -- не самый плохой вариант. Потому что ты их будешь учить "под себя". А человека "с опытом" надо ещё ПЕРЕучивать, а он ещё будет сопротивляться...

то решение вообще-то простое. Мы не знает что происходило, делаем три (5,7) подзадач

Вообще то я не собирался углублятся в конкретную задачу. Просто скажу, что решал ее не я, функционал отключать было нельзя, потому что в тестовой среде проблема не наблюдвлась, а отключить функционал у клиентов и заставить их платить за это это даже по моим меркам наглость. Проблему нашли через 3 месяца и три месяца исполнителя переодически ставили в различные положения - это не просто баг. Это датеншуц. А мы работали на серьезные организации, не мелкорозничная торговля. Это был просто пример жопы. Кстати именно на этой фирме была именно команда. И мы помогали, чем могли.

FocusFactor -- это отношение реально затраченных часов к запланированным.

Ну путем простой логики мы и увеличили этот самый FocusFactor даже не считая. Путем уменьшения запланированных. Путем регулярного уменьшения.

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

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

Ну, это вам просто с адекватным менеджментом работать не приходилось.

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

Нельзя, не считая. Ритуалы Agile надо исполнять точно. Иначе не работает.

Тут важен не результат, а процесс.

Делается это в конце итерации на "ре роспективе". Формат проведения "ретроспективы" (разбор ошибок, разбор препятствий, выработка правил, подсчет фокус-фактор) -- все это обязательно должно иметь место. Иначе Вы никогда не получите слаженную команду. Если фокус -фактор в конце итерации увеличивается _значительно_, то это может быть. поводом для пощрения команды. Хотя, где как.

Тут важен не результат, а процесс.

Гм. Или я тупой или лыжи не едут. Разборка полетов. Запланировали 50 пунктов. Пунктов, Карл!, не часов. Пролетели, сделали 25. Не проблема, на следующий раз планируем 25 пунктов. Прирост производительности в 100%. Нужно срочно поощрять. И команда слаженная, на следующий раз запланируем 15 пунктов.

С какого перепугу? Команда не выполнила план, зачем ее поощрять? И какие нафиг пункты?

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

Итого: задачи, подзадачи и часы.

Где здесь "пункты"? Это ж не Agile, а какое-то другое творчество!

С какого перепугу?

-----

Ну как с какого?

первый раз взяли - пролетели. Тут - понятно - мимо.

второй раз взяли - попали в 100%. Тут - понятно - надо поощрять.

третий раз взяли - попали в 140%. Бля, гении - срочно стимулировать...

Пример:

В первый день итерации:
1. Считаем число доступных человеко-часов.
2. Умножаем на фокус-фактор с предыдущей итерации и получаем реальное число часов
3. Приступаем к планированию. Планирование заканчиваем, когда израсходуется реальное число часов.
4. Добавляем одну или две "бонусных" задачи.
5. Расходимся по домам. Программирование в день планирования строжайше запрещено.

Второй день интерации:
... Программируем...

....

Предпоследний день итерации
... Программируем...

Последний день итерации:
Демонстрируем результат заказчику.
Проводим ретроспективу.

На ретроспективе считаем, все ли задачи сделаны. Если все, то вычисляем фокус фактор. Если были сделаны ещё и бонусные задачи, то пересчитываем фокус-фактор.

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

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

Проектыу нас имеют начало и конец. По окончании проекта программистов переводят на другой agile-проект. Некоторых не принимают в новый проект (голосованием самих программистов). Если программиста голосованием не принимают ни в один проект, то его увольняют.

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

4 программиста, 2 тестировщика, 1 scrum-мастер, один "представитель заказчика" (итого 8 человек). Был выполнен за 4 месяца.

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

2. Желательно чтобы не работали ранее в торговой фирме.

А это почему? Я уже 10 лет работаю в торговой фирме, если что...

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

Ну да, это именно то, чем я все 10 лет и занимаюсь, и коллеги, кстати, тоже.

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

Считается, что человек, работавшей в торговой фирме программистом, уже "испорчен как программист" и для agile непригоден. Дело в том, что в торговых фирмах не принято думать над кодом. Начальник даёт задание, которое надо сделать за 20 минут потому что "клиент уже в пути, через 20 минут все должно быть готово". Поэтому программисты в таких компаниях пишут такой код, который поддерживать _в_принципе_ невозможно.

А развивать -- тебя паче.

Эту психологию искоренить невозможно. Поэтому руководители agile- проектов внимательно отслеживают предыдущие места работы соискателей. По крайней мере так в России. Как в Германии -- не знаю.

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

Согласен. Но это мера вынужденная, бытие определяет, так сказать... Вот есть у меня 4 больших проекта, которые я поднял с нуля, и развиваю, тем не менее. Так вот, самый проблемный проект - это первый, начатый мною. Там я неопытный был, и сваял симпатичную такую иерархию классов под поставленную задачу. А потом начались проблемы, все время необходимо было срочно вносить изменения, очень скоро потребовались такие, которые ни разу не совместимы с заложенной иерархией классов, и это все на испытательном сроке, и когда проект уже в деле... При этом никого не волнует качество кода, важен только функционал. Время на переделку не дают, работает и ладно, никто не знает сколько еще проект бабло приносить будет (а этот проект тогда находился под угрозой из-за планировавшегося налога на финансовые транзакции), типа лучше сделай другой проект, чем этот переделывать, тем более что в итоге будет тот же функционал. В итоге такой мутант получился, что мама не горюй, правда он и сейчас живее всех живых. Я поначалу психовал из-за этого, а потом плюнул, смотрю на это как на Kündigungsschutz.:)) Теперь умный стал, иерархий классов в проектах по-минимуму, готов к любым сюрпризам, так сказать...

Эту психологию искоренить невозможно.

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

Кстати, а у кого нибудь считается агиль с удалённой работой?

В большинстве случаев, важно не то, ЧТО человек делает, а то, КАК он это делает.

Принцип "лишь бы работало, а как сделано -- не важно" несовместим с agile. Есть набор принципов (например KISS), которые почему-то не приживаются у тех программистов, которые долго работали в торговле. Теорию можно выучить, можно накопить уйму знаний, но психология подхода после 30 лет уже не меняется.

Вот, например, есть принцип, что задача исключения избыточности кода важнее задачи разработки функционала. То есть вот программист пишет, пишет.... уже много написал, скоро уже виден конец ....и вдруг --- БАБАХ -- в коде обнаружена избыточность!!!

Правила методологии настоятельно требуют ОСТАНОВИТЬ разработку и не продолжать ее до тех пор пока не будет удалена избыточность. Для agile-разработчика отсутствие избыточности кода -- это Святое. Для торгового программиста -- это мелочь, недостойная внимания. Собственно, в этом и суть конфликта.

Скорее всего, разработчик, привыкший работать в торговой фирме не станет искоренять избыточность, скроет ее наличие от начальства.

И вот именно так появляются задачи типа "жопа".

Кстати, а у кого нибудь считается агиль с удалённой работой?

В смысле сочетается? Да.

Есть набор принципов (например KISS), которые почему-то не приживаются у тех программистов, которые долго работали в торговле.

Ну да, вам - шашечки, а нам - ехать. :))

И вот именно так появляются задачи типа "жопа".

Избыточность кода как источник появления задач типа жопа? Да ладно, с lock-free имплементацией в многопоточных приложениях ни в какое сравнение...

За комментарии спасибо. :))

Не знаю почему, но ни разу не встречал коллектив, работающий п

в режиме agile удаленно. Впрочем, тут в России и обычная удаленная работа считается чем то ругательным. По крайней мере, за ту работу, за которую платят, скажем, 90000р/мес, по удалёнке платили бы не более 40000р/мес.

Кто ж согласится за такую зарплату горбатиться? Б

Ни разу не встречал ошибок типа lock-free, хотя с многопоточных и приложениями работаю уже не первый десяток лет регулярно. А за последние 5 лет на рынке появилось такое множество инструментов разруливания lock-free проблем, что получить deadline ситуацию сейчас можно разве что по убеждению.

С какого перепугу? Команда не выполнила план, зачем ее поощрять?

Вы не посчитали? Команда делает 25 пунктов. Что бы выйти на расчетное количество, команда снизила план на следующий спринт до 16 пунктов. то есть абсолютно не изменив свой стиль заседать команда внезапно улучшила свои показатели в разы. Тут без премии не обойтись.

И какие нафиг пункты? Для каждой подзадачи выделяются часы.

Еще раз. Временные единицы использовать по канонам ЗАПРЕЩЕНО.

http://agilerussia.ru/practices/scrum-why-story-points-are...

https://myalm.ru/news/%D0%9A%D0%B0%D0%BA-Story-Points-%D1%...

https://ru.wikipedia.org/wiki/Scrum

Умножаем на фокус-фактор с предыдущей итерации и получаем реальное число часов

Это может и имеет право делать менежмент. Сами программисты во-первых не вычисляют факторы, во-вторых не имеют дела с временными единицами. И в третьих по канонам только программисты могут сказать, потянут они спринт или нет. Если команда сказала, что она потянет только 15 пунктов НИКТО не имеет права сказать - вы охренели?

Часы расчитываются во всяких водопадах.

Если программиста голосованием не принимают ни в один проект, то его увольняют.

В Германии с фирмы с профсоюзом чела уволить нельзя.

Кстати, а у кого нибудь считается агиль с удалённой работой?

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

Правила методологии настоятельно требуют ОСТАНОВИТЬ разработку и не продолжать ее до тех пор пока не будет удалена избыточность.

Я не понял. Что такое избыточность кода?

Избыточность кода -- это когда один и тот же функционал реализован более чем в одном месте.

Представляю как такой удаленный работник работает по Skype. В монитор видно, как на заднем плане голая жена из ванны выходит, слышно как дети ссорятся из-за жевательной резинки... А ты сидишь, такой, у всех на виду и дистанционно работаешь... ;)))

Избыточность кода -- это когда один и тот же функционал реализован более чем в одном месте.

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

Нельзя уволить человека.... До чего докатилась цивилизация! Даже при том демократическом условии, что за это проголосовали все сотрудники фирмы?

Мне кажется, что-то тут не так!

В монитор видно, как на заднем плане голая жена из ванны выходит,

Кстати да. Но в Германии как ни странно достаточно лояльно относятся к тому, что у человека кроме работы есть жизнь. Например почти всегда без скрипа отпускают на всякие частные дела или разрешают остаться дома, если запланирован приход сантехника. У меня на хоумоффисном ноуте камеры вообще нет.

Нельзя уволить человека.... До чего докатилась цивилизация! Даже при том демократическом условии, что за это проголосовали все сотрудники фирмы? Мне кажется, что-то тут не так!

Ситуация типа "кто оплатит рефакторинг" у нас тоже довольно частая. Этот вопрос каждый программист решает по своему.

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

Я всегда руководствовался принципом "Делай, что должен и будь, что будет". И до сих пор жив.

Жены стесняться -- детей не видать.

Начальника бояться -- на работу не ходить.

Бояться рефакторинга -- всю жизнь жить на одну зарплату

У нас тоже с пониманием к личной жизни относятся. Особенно в последние 5 лет.

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

Проектыу нас имеют начало и конец.

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

Если программиста голосованием не принимают ни в один проект, то его увольняют.

Очевидно, что в Германии ты никогда не работал. Посмотрел профиль - Питер. В России по ТК тоже хрен уволишь без выплат... т.е. увольняемый должен согласиться на увольнение. Ну или работать с контрактниками, но этом сильно дороже.

Был выполнен за 4 месяца.

"Довольно обширный проект" выполненный за 4 месяца - это детский сад.

Видимо, у Вас в Германии, очень продвинутые "детские сады, с ИИ, автоматической диспетчеризацией, отчётностью и пр. фишками"

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

Это вполне нормальная практика. Проект закончен, за него получены деньги, он сдан заказчику. Чего же тут необычного?

По-моему это лучше, чем вяло - текущий проект с постоянными доработками, авралами и прочими штучками.

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

Во всяком случае, именно так мы работали на упомянутой мной фирме (когда делали мелкие проекты на заказ). У нас был набор библиотек с готовыми решениями и мы просто составляли готовый как пазл. Там, где детальки не подходили - мы их подгоняли под требования. И проекты были в основном от 2 недель до 6 месяцев.

По-моему это лучше, чем вяло - текущий проект с постоянными доработками, авралами и прочими штучками.

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

Вы правы: это не коробочный проект.

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

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

Я всегда руководствовался принципом "Делай, что должен и будь, что будет". И до сих пор жив.

Сорры, нефига не понял. Я же быдлокодер из скрама. Мои задачи висят на борде, в крайнем случае в бэклоге. Я не могу, даже если хочу, навешать своих задач, сам оценить и начать их решать. Разрешение на любой модуль, включая внутренне необходимые перестроeния я получаю от продуктовнера(не напрямую, но в принципе).

Ни разу не встречал ошибок типа lock-free, хотя с многопоточных и приложениями работаю уже не первый десяток лет регулярно. А за последние 5 лет на рынке появилось такое множество инструментов разруливания lock-free проблем, что получить deadline ситуацию сейчас можно разве что по убеждению.

Не понял, при чем тут deadlocks, если оно "locks-free" изначально? Чтобы не быть голословным, вот пример жопы: прием и декодирование multicast UDP от биржи, с минимально возможными задержками, когда канал был 1 гигабит, то все работало, и не один год. Теперь канал 10 гигабит и неслабо возросший траффик (а все датаграммы по 50-100 байт), и прежний дизайн не справляется... И начинается препарирование Boost, приходится отказываться от sequentally-consistent семантики доступа в atomic, и переходить к семантике ослабленного упорядочивания memory_order_acquire/memory_order_release/memory_order_relaxed, а там столько граблей...

А отказаться от Multicast UDP в пользу локального облачного решения не думали?

IMHO, у Multicast UDP есть и другие "неприятности" кроме блокировок.

...отказаться от Multicast UDP

Как мы от него откажемся, если это протокол передачи данных от биржи? Все, молчу. :))

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

То есть принцип командного владения кодом у Вас не практикуется. Я понял.

Тоталитаризм у Вас, однако, и застой!

Ну, у нас, те проекты, которые не имеют конца (постоянный заработок для фирмы) через agile не ведутся.

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

Наверное, в Германии по-другому

Биржа локальная или глобальная? Вообще, о какой бирже речь?

Ну, у нас, те проекты, которые не имеют конца (постоянный заработок для фирмы) через agile не ведутся.

Почему?

Биржа локальная или глобальная? Вообще, о какой бирже речь?

Ну, во-первых, ограничения agile: для вечных проектов лучше использовать другую разновидность XP.

А во-вторых, agile вообще в России редкость.

То есть я правильно понял:

Коммерческая информация от торговой биржи распространяется по широковещательным каналам подписчикам?

Коммерческая информация от торговой биржи распространяется по широковещательным каналам подписчикам?

Да, но сеть закрытая, и физически изолирована от интернета.

А ничего, что UDP не обеспечивает гарантированной доставки?

почему не ведутся? Agile бывает разный, просто для продуктовых проектов надо делать коррекции, которые зависят от:

• сложности проекта - одно дело клепать "стандартные" вещи, типа веб-сайтов и т.п., в которых можно делать оценку задач достаточно легко, другое дело - когда требуется серьезный research, плюс интеграция со сложными продуктами (особенно плохо документированными)
• наличия требований
• как он распространяется - firmware, on premise, cloud - соотвественно разные длительности спринтов и т.п.
• количества людей на проекте (как вам проект с парой тысяч людей?)
• и т.п.

Мы в свое время (на предыдущей работе) нашли правильный подход, который типа Agile, но без 2-3 недельных спринтов и т.п.

конечно нет: there is no guarantee of delivery, ordering, or duplicate protection (https://en.wikipedia.org/wiki/User_Datagram_Protocol)

А ничего, что UDP не обеспечивает гарантированной доставки?

TCP не справится с объемом данных, поэтому гибрид:

UDP для котировок (см. схему и текст на стр. 9-10),

https://www.eurexchange.com/resource/blob/1470872/a9e0d336...

TCP для информации по своим ордерам/сделкам (ETI),

https://www.eurexchange.com/resource/blob/1394340/e8b4cc73...

Вот я и удивляюсь:

коммерческая инфа без гарантии доставки?

По Вашему это допустимо с точки зрения логики?

А локальная облачная служба?

В конце концов в каждом сегменте сети можно поставить по копии облака

Проблемы индейцев шерифа не волнуют. В конце концов все упирается в вопрос: -Брать будете?

А как же без спринтов?

Не понял: что брать?

Да тот же канбан отлично работает.

Канбан отлично работает на поддержке - баги фиксить и инциденты закрывать. Ну или для задач "а теперь то же самое, но розовенькое". Как только что-то новое, которое команда ещё не делала и канбан сыпется, на доске чёрт знает что, или новым занимается один-единственный разработчик, а остальные радостно проводят другие тикеты.

А япошки как-то умудрялись машины так делать!

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

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

Почему бе спринтов - просто есть особенности. Одно дело когда продукт в облаке или у одного клиента, другое дело когда он у сотен, и у многих падение даже на 5 минут приводит к серьёзным финансовым потеря

Знаю лично этого чувака. Типичный агиль пропогандист консультант

Вот я и удивляюсь:
коммерческая инфа без гарантии доставки?
По Вашему это допустимо с точки зрения логики?

Именно с точки зрения логики это не только допустимо но и необходимо.Другой пример это eventual consistency, ну типа все будет ok, но это не точно. Так что все эти ACIDы и гарантии это уже давно религиозные предрассудки ну или для распальцовки среди тех, кто в этом ничего не смыслит.

Вообще, слухи про ненадежность UDP сильно преувеличены. Если с сетью все нормально, то получишь ты свой пакет и "усе будет в лучшем виде". А если не получишь, значит в сети затор, но тады и TCP тебя не спасет - он будет тупо ждать пропавшие части, и повторно их запрашивать (чем еще больше усугублять ситуация). Гарантия TCP это типа как гарантия доставки пиццы в городе в случае пробок: гарантия у тебя есть, а пиццы нет.

Если немного пофлудить, то в наше время все эти fault tolerance, high availability, scalability, consistency, ACID и пр. заклинания, это часто от лукавого менеджеров с целью раздуть бюджет. (За что им конечно огромное прагматическое спасибо.) Это типа как при строительстве дорог раздувают бюджет: тут надо гидро-пневмо-анализ на 10 км в глубину сделать, там изучить влияние дороги на частоту сношений в семье бобров на соседней реке, а также специальное покрытие против свечения метеоритов, если таковые будут падать. А для всего этого сверху нам надо еще скрам, чтобы при максимально раздутом бюджете, еще и максимально сократить расходы за счет толпы быдлокодеров, которые слепо верят, что это и есть программистская вальгалла.

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

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

Если немного пофлудить, то в наше время все эти fault tolerance, high availability, scalability, consistency, ACID и пр. заклинания, это часто от лукавого менеджеров с целью раздуть бюджет.

А тут согласен. Часто всё это не надо. Надо уметь понимать когда надо а когда - нет. (p.s. partition tolerance незаслужено забыто)

Вообще, слухи про ненадежность UDP сильно преувеличены. Если с сетью все нормально, то получишь ты свой пакет и "усе будет в лучшем виде".

Ну как бы нет... Лет 30 назад может быть. А сегодня TCP может летать через рутер, а UDP ползти с потерей половины пакетов. Очень они умными стали, то приоритеты TCP выставлены, то QoS решит что важнее вот эти пакеты отправить, а UDP оно ж не важно, потом. А потом буфер для UDP переполнился и всё, нет пакетов.

Прохождение UDP датаграм сильно зависит от сетевого железа. Например, на роутере DLink серии DI достаточно просто переполнить 8кб буфер для того чтобы пакеты UDP вообще перестали ходить по сети.

На роутерах Zyxel UDP может просто внезапно перестать ходить без видимых причин.

Можно очень долго отлаживать софт, сидя под одним роутером, а потом когда компания купит другой роутер, все придется повторно переотлаживать... Поведение UDP нерегламентировано