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

Хочу обратить внимание, что DevOps в теории — это такая роль в команде, а на практике — просто более модное название для админа. А FTP — это такой инструмент для обмена файлами. И данное противопоставление вообще не имеет никакого смысла.

Хочу обратить внимание, что DevOps в теории — это такая роль в команде, а на практике — просто более модное название для админа.

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

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

И примерно так же CI/CD/Docker нынче являются модными базвордами, смысл которых мало кто понимает

Так это проблемы конкретных людей, а не направление devOps. Это как сказать «программисты это хрень, потому что Вася из соседней деревни приходит принтер чинить моей бабушке и НЕ СМОГ».

У меня в проекте (3 человека) был своего рода простой девОпс - релиз происходил после изменения ветки release в гите. С одной стороны на настройку всего этого я потратил много (ну наверное часов 10 точно) - с другой стороны через эту систему прошло где-то 100 релизов (Получается что я буду в плюсе если на каждом релизе б экономил 10/100 часов (6 минут)) - в реальности наверное яб конечно релизил быстрее чем 6 минут, но я как минимум совсем не кайфовал от того что 100 раз делал бы однотипные действия.

Более того из этих 10 часов на настройку девОпс связанных вещей у меня 80% ушло на изучения - и на своем следующем проекте я потрачу 2 часа на настройку по уже изученной ранее схеме.

agile/scrum - это просто название уже давно известных методик разработки софта

ВНЕЗАПНО, правда? %)

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

Капитан, вы сегодня особенно в угаре.

У меня в проекте (3 человека) был своего рода простой девОпс - релиз происходил после изменения ветки release в гите. С одной стороны на настройку всего этого я потратил много (ну наверное часов 10 точно) - с другой стороны через эту систему прошло где-то 100 релизов (Получается что я буду в плюсе если на каждом релизе б экономил 10/100 часов (6 минут)) - в реальности наверное яб конечно релизил быстрее чем 6 минут, но я как минимум совсем не кайфовал от того что 100 раз делал бы однотипные действия.

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

agile/scrum - это просто название уже давно известных методик разработки софта

ВНЕЗАПНО, правда?

Я в самом начале треда об этом писал. Это всё старые методы, доведенные до абсурда.

Я бы не стал доверять человеку написание скрипта, который бы стал

брать последние правки, собирать их, и заливать по ftp/sftp

Просто в силу того, что человек с крайне высокой долей вероятности нагородит там жесточайший ад. Ещё есть подозрение, что довольно малая часть софта деплоится по FTP.

Я бы не стал доверять человеку написание скрипта, который бы стал

брать последние правки, собирать их, и заливать по ftp/sftp

Просто в силу того, что человек с крайне высокой долей вероятности нагородит там жесточайший ад.

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

Ещё есть подозрение, что довольно малая часть софта деплоится по FTP.

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

У тебя нет необходимости лукавить и ставить в один ряд сисадмина из ООО «Рога и копыта» с теми, кто писал некие, разумеется, очевидные каждому в треде «никсовые системы сборки». Так же, как закрывать глаза на то, что скриптовое творчество тех сисадминов — довольно солидный источник головной боли. То, что ты считаешь лишь модными базвордами по факту просто божья роса в плане предсказуемости того, что ты можешь встретить, например, на новом месте работы после предыдущего сотрудника. Это известно тебе, это известно тем, с кеми ты споришь, это не рокет-саенс, но что-то упорно заставляет тебя это оспаривать.

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

Я тебя ни на какую работу и не звал, что ты вообще несёшь?

Обсуждающим.

Все «как всегда в диалогах форума» - «абы что сказать».

Владимир

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

Мне кажется, что у нас тут возникло некоторое недопонимание на фоне разной интерпретации понятий CI/CD/Docker. Если мы отказываемся от докера, то это не значит, что мы ударяемся в хардкор, вроде написания своей собственной ОС-и на баше. Если мы отказываемся от CI/CD, то ансибл и дженкинс не обязательно пропадают - они могут остаться, просто задачи «continious integration» они уже не выполняют, а работают в составе сервера сборки, тестирования, LSP для одного разраба. В конце-концов, работоспособность кода определяется в основном не этими инструментами, а тем, насколько его хорошо написал и протестировал кодомакак, насколько адекватно он сделал сборку своей софтины - остальное на мелких проектах играет роль, незначительно отличающуюся от нулевой.

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

Я тебя ни на какую работу и не звал, что ты вообще несёшь?

Это я про:

Я бы не стал доверять человеку написание скрипта

Даже стало интересно зачем это могло понадобиться Дуче?

Работал в нескольких проектах с новомодными scrum, agile, kanban, разные team building (мы любим свою компанию, шеф нам отец родной))) и прочие ахинеи. Ничего доброго об этих методиках сказать не могу, лишь матерно. Обыкновенные западные замаскированные методики выдавливания всех соков из программистов, прикидывающиеся добрыми и пушистыми . Все западные методологии такого рода у нас как правило просто не работают или работают совершенно не так, как планируется. Слишком разные у нас менталитеты. В результате всех этих извратов обычно получается стандартное - хотели как лучше, а получилось как всегда

Все эти scrum’ы из серии как бы на ёлку влезть и ж@пу не ободрать. Как бы платить программистам поменьше, поиметь с них побольше под сладкие песни о свободе, отсутствии начальников, либеральном отношении. По опыту работы в нескольких компаниях отношение к этим извратам «эффективных менеджеров» крайне отрицательное. Зато да, в глазах мало понимающих инвесторов - модно, молодежно, эффективно. Только вся эта эффективность - замыливание глаз, втирание очков и имитация бурной деятельности.

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

Ну так экономия 5 * 60000 = 300000 рублев в месяц.
Это доказывает эффективность технологии и экономию средств предприятия.

Надо чтобы ввести в проект ограничение WiP.

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

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

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

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

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

Сможете ли вы систематизировано убедить сообщество в том, что эти подходы нужны?

говорю: подходы не нужны. Нужно эффективно выполнять работу - не нужно эффективно использовать «подходы».

А подумать и не наваливать тасок которые перекрывают друг друга?

Так в реальности они почти всегда связаны! Самый классический пример это фронт+бек таски - неразрывно связаны. Также как и дизайн-фронт таски.

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

Вторая серия.

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

Владимир

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

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

Нет, я не уверен что вы правильно меня поняли (хотя возможно и я вас неправильно).

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

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

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

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

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

хоть и реактивный по отклику на «хотелки» бизнеса?

Ну так в нормальном бизнесе хотелка будет примерно такая «Так мы вчера глянули аналитику и оказывается у нас почему-то аж 20% заходят с браузера без JS, неужели кто-то про нас на ЛОР-е написал и оттуда набежали? Давайте сделаем MPV сайта без JS»

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

Грубо говоря «хотелка» исходит от реальности (например аналитики), а не потому что директор/начальник/PO так захотел

очевидные вещи типа того, что коллеги должны общаться

аджайл также говорит неочевидную вещь - если что-то пошло не так как ты думал, то ты не продолжаешь пилить код по ТЗ с умным видом «Я делаю все по ТЗ, Я дартаньян», а реагируешь на это и подстраиваешься

аджайл очень хорошо подходит для стартапов

Это спорный момент на самом деле.

Если послушать/почитать про agile у O’Reily например, то там Agile пропагандируется для применения в совсем не стартапной Java-разработке, и с совсем другим посылом.

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

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

В таком режиме agile - это не столько про гибкость требований, сколько про возможность оценки производительности команды. И его главная идея в том что даже если ты стартуешь с абсолютно рандомной оценки в совершенно рандомных единицах измерения (назначаешь первые story points от балды), то с каждым новым спринтом оценка улучшается, потому что ты используешь предыдущий спринт как базу для оценки следующего:

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

И если спринтов довольно много, а команда статична, то после N-ной итерации у тебя получается предсказуемый конвейер. Который любят в Java-энтерпрайзе или в web-разработке.

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

после пяти спринтов ты можешь оценить производительность команд, поделить на размер беклога, и понять что сроки не выдерживаются
В таком режиме agile - это не столько про гибкость требований, сколько про возможность оценки производительности команды

Давно не читал такой чуши. Сразу видно, что перед нами - эффективный менеджер с околонулевым опытом руководства кодерскими проектами.
https://en.wikipedia.org/wiki/Ninety-ninety_rule

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.[1]

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

Вот как раз за тем чтобы 10% которые на самом деле 90 не уезжали на последний вечер перед дедлайном.

И это тоже включается в набор agile best practices.

Так что ты поспорил сам с собой.

Вот как раз за тем чтобы 10% которые на самом деле 90 не уезжали на последний вечер перед дедлайном.

Опа, маневры пошли. А что же было написано о нелинейности оценки времени в твоем исходном сообщении?
SCRUM в сфере разработки ПО (комментарий)
А ничего. Клоун.

с околонулевым опытом руководства кодерскими проектами

А это верно. Но я сразу написала, что я не своим опытом делюсь, а пересказываю лекцию по Agile из курса O’Reily

А ничего.

Вот ужас-то, не напечатала всю книгу по Agile в одном посте. Мое упущение.

А что же было написано о нелинейности оценки времени в твоем исходном сообщении?

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

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

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

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

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

Вакансия: Системный программист

Требования:

1. Знать языки программирования и иметь с использованием их не менее трех разработанных проектов: C, C++, Java, Delphi.

2. Знание и опыт разработки систем: ядра Linux /обязательно/, драйверов /иметь не менее трех разработанных/, СУБД, компиляторов /обязательно/.

3. Претенденты должны иметь сертификаты: Microsoft, Apple, Oracle.

4. Свободное владение не менее тремя языками: английский, испанский и китайский обязательно.

5. Знать и уметь использовать методологии SCRUM и AGILE.

6. З/п от $100, определяется по итогам собеседования. Рабочий день ненормированный

Владимир

Это серьезно, или стеб?

Конечно стеб.
Импровизация на «бессмертную» вакансию:

Вакансия: Водитель легкового а/м.

Требования:

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

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

3. Претенденты должны иметь сертификаты Mersedes, BMW, GENERAL MOTORS, HONDA, SUZUKI, ГАЗ, ВАЗ, ЗАЗ, БелАЗ а так же справки об участии в крупных международных ралли не более чем двухгодичной давности.

4. Кроме того иметь представление о длительных морских походах на атомных подводных лодках, навыки пилотирования новейших истребителей СУ.

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

6. З/п от $1500, определяется по итогам собеседования. Рабочий день ненормированный

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

Владимир

Т.к. абсолютное большинство т.н. «стартапов» организованы не для ежедневного зарабатывания денег, а для распила бабла инвесторов

Звучит примерно как то что земля плоская. И прочие теории заговора

Добро пожаловать в реальный мир. Прикинь, вся западная экономика последние 100 лет строится на модели пузыря. Борятся лишь с самыми быстролопающимися.

Добро пожаловать в реальный мир.

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

Звучит это также как фраза таксиста «убер завтра умрет, это фальшивка, это не компания ведь она НЕ ПРОИЗВОДИТ ВЕЩЕЙ»

Опять этот «убойный аргумент» про «теорию заговора». У фанатиков так бедно с фантазией?

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

Я работаю постоянно в стартапах

ИМХО, конечно, но это как раз то, о чем я говорю: стартапы нужны чтобы «работать в» (получая ЗП из кармана инвесторов), а не чтобы «зарабатывать».

Звучит это также как фраза таксиста «убер завтра умрет, это фальшивка, это не компания ведь она НЕ ПРОИЗВОДИТ ВЕЩЕЙ»

Ты сам привел пример, никто тебя за язык не тянул:
Третий квартал 2018 года Uber закончила с убытком более чем в $1 млрд
https://habr.com/ru/news/t/463131/

Во втором квартале 2018 года убытки составляли лишь 878 млн долларов. За отчетный период выручка Uber увеличилась лишь на 14% — с 2,78 млрд долларов до 3,17 млрд долларов

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

Я работаю постоянно в стартапах (западных и израильских) и сам пытаюсь делать свои.

Очень размытая фраза. Твои стартапы за масштаб 1000$ выходили? Если да, от откуда шло финансирование?

вся западная экономика последние 100 лет строится на модели пузыря.

Так уверенно звучал и так беспомощно порвался %)

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

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

Я же оспаривал слово «Распил» - это когда деньги каким-то образом воруют

Твои стартапы за масштаб 1000$ выходили? Если да, от откуда шло финансирование?

Прибыли и или дохода? Нет (неудачи) Трат? Да (из своего кармана на ЗП обычного программиста)

Объясняю, знаешь почему инвесторов называю венчурными? Нет? Погугли или просто переведи это слово с английского

предприятие
деятельность
авантюра

Я же оспаривал слово «Распил» - это когда деньги каким-то образом воруют

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

Прибыли и или дохода? Нет (неудачи) Трат? Да (из своего кармана на ЗП обычного программиста)

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