LINUX.ORG.RU

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

 


3

2

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

Как я понимаю знание этих методик обязательно для прожект-менеджмента и тим-лидера.

Ответ на: комментарий от byko3y

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

ugoday ★★★★★ ()
Ответ на: комментарий от ugoday

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

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

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

byko3y ()
Ответ на: комментарий от byko3y

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

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

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

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

abs ★★ ()
Ответ на: комментарий от byko3y

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

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

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

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

Nervous ★★★ ()
Ответ на: комментарий от abs

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

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

byko3y ()
Ответ на: комментарий от Nervous

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

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

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

byko3y ()
Ответ на: комментарий от byko3y

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

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

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

Princesska ()
Ответ на: комментарий от Princesska

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

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

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

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

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

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

byko3y ()
Ответ на: комментарий от byko3y

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

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

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

Princesska ()
Ответ на: комментарий от Princesska

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

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

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

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

Это я про:

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

byko3y ()

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

anonymous ()

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

anonymous ()

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

anonymous ()

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

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

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

dn2010 ★★★★★ ()
Ответ на: комментарий от abs

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

abcq ()
Ответ на: комментарий от abcq

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

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

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

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

byko3y ()
Ответ на: комментарий от abcq

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

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

abs ★★ ()
Ответ на: комментарий от abs

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

abcq ()
Ответ на: комментарий от anonymous

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

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

Владимир

anonymous ()
Ответ на: комментарий от abcq

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

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

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

abs ★★ ()

Лень читать тред, скажите, популярный Сергей Идельс (люксофт одесса менеджер) и Женька Продан упоминались?

Знаете же, что наш гуру аджайла делает с ушами программистов? Значете?

anonymous ()
Ответ на: комментарий от abs

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

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

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

abcq ()
Последнее исправление: abcq (всего исправлений: 1)
Ответ на: комментарий от abcq

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

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

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

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

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

abs ★★ ()
Ответ на: комментарий от abcq

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

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

abs ★★ ()
Ответ на: комментарий от abs

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

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

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

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

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

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

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

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

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

alpha ★★★★★ ()
Ответ на: комментарий от alpha

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

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

byko3y ()
Ответ на: комментарий от byko3y

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.

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

alpha ★★★★★ ()
Ответ на: комментарий от alpha

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

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

byko3y ()
Ответ на: комментарий от byko3y

А ничего.

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

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

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

alpha ★★★★★ ()
Ответ на: комментарий от abs

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

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

anonymous ()
Ответ на: комментарий от alpha

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

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

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

Требования:

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

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

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

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

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

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

Владимир

anonymous ()
Ответ на: комментарий от byko3y

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

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

Требования:

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

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

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

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

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

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


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

Владимир

anonymous ()
Ответ на: комментарий от anonymous

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

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

abs ★★ ()
Ответ на: комментарий от byko3y

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

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

abs ★★ ()
Ответ на: комментарий от abs

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

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

anonymous ()
Ответ на: комментарий от abs

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

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

anonymous ()
Ответ на: комментарий от abs

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

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

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

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

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

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

byko3y ()
Ответ на: комментарий от byko3y

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

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

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

abs ★★ ()
Ответ на: комментарий от byko3y

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

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

abs ★★ ()
Ответ на: комментарий от abs

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

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

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

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

byko3y ()