Вы задали очень философский вопрос…
Судя по комментариям выше, например "Какой смысл городить 2 месяца архитектуру с тоннами абстракций..." — то да, похоже понятия информации, данных, дата-флоу и т.д. «устарели»… И блокчейн в таком случае — просто один из примеров…
Интересно, если бы программисты взялись спроектировать, например, карьерный самосвал — то процесс проектирования тоже бы проходил по Скраму? То есть, раз времени выяснить характеристики проектируемого самосвала нету, то поэтому уже по окончанию 1й недели заказчик получит работающий прототип — садовую тачку, например? А уже потом будем «наворачивать» к этой тачке функционал — еще колеса, двигатель и т.д.
Более того, он не просто должен быть. Он должен обладать определенным уровнем квалификации и компетентностей.
Почему тот, кому платят деньги — разработчик — должен обладать определенной квалификацией, а к тому, кто платит деньги — к представителю заказчика, Product Owner-у — таких требований не предъявляется?
Формально Product Owner есть, то только лишь формально.
Все верно. А еще иногда в информационной структуре предприятия отображаются процессы, связанные со сторонними организациями (логистика, лизинг, товар под реализацию и т.д.). В таких случаях «по-умолчанию» предполагается недоверие между субъектами.
Мне кажется, что разделение аутсорс/не аутсорс только по признаку, что это уникальная специализированная разработка для конкретной компании — некорректна.
Если ежедневные бизнес-процессы компании предполагают выполнение какой-то функции, а компания отдает выполнение этой функции «на сторону» — то это аутсорс. А вот если компания «на стороне» заказывает услугу, которая никак не входит в ее ежедневные бизнес-процессы — это обычный бизнес.
К примеру, заказчик — животноводческая ферма. Раздача корма поросятам — это основная бизнес функция компании. А постройка зданий, в которых живут поросята — к ежедневным бизнес-процессам компании не относится.
Соответственно, отдаем кормление поросят «на сторону» — аутсорс. Отдаем постройку зданий «на сторону» — не аутсорс.
Именно поэтому публикация и называется «Российский SCRUM. Бессмысленный и беспощадный». Описывает ситуацию как НЕ надо делать. Тем более в стартапе.
Прочитайте, пожалуйста, 1й дисклеймер публикации.
Покупка станка — не аутсорс. Производство ПО на заказ — аутсорс.
Не вижу разницы между этими двумя средствами производства для заказчика — специализированным станком, который разрабатывается и производится сторонней фирмой. И специализированным программным обеспечением, которое точно так же разрабатывается и производится сторонней фирмой.
Почему первое — НЕ аутсорс, а второе — аутсорс?
Курс экономики предприятия проходили?
То есть Вы полностью исключаете, что часть разработки софтверная фирма может финансировать за счет собственных средств? Например, чтоб потом продать разработанный продукт еще в 2-3-4 места с незначительными изменениями?
Не знаю. Думаю, все прекрасно понимают, что они аутсорс.
То есть, когда производственная компания заказывает разработку, производство и затем покупает у другой компании специализированный станок; и когда производственная компания увольняет своих дворников и заказывает услугу уборки территории у другой компании — и то и другое это аутсорс?
Так что заказчик платит вам + комиссия вашей фирме.
Еще раз повторюсь — я понятия не имею что и как заказчик платит фирме, с которой у меня трудовые отношения. Свечку-с не держал…
Бьюсь об заклад, что сейчас у многих владельцев компаний по разработке программного обеспечения произошел взрыв мозга…
А фирма откуда деньги берет?
Понятия не имею… Честно говоря, даже не интересовался этим вопросом. Возможно, что всю разработку полностью оплачивает заказчик, а возможно что часть денег фирма вкладывает самостоятельно (ну а вдруг). А Вы как думаете?
Вы же по скраму работали. В скраме нет как такового руководства.
В том то и беда… Прихоть заказчика, что ж тут поделать…
Хм. Даже не думал, что такой вопрос может возникнуть…
Фирма по разработке программного обеспечения под заказ.
Полный комплекс услуг по разработке, внедрению и сопровождению программных решений клиентам из более чем 30 стран мира. Более 1500 высококвалифицированных ИТ-специалистов. Реализация ИТ-проектов различной сложности и масштаба.
… не знаю, как еще объяснить… Зарплату платит фирма, а не заказчик. Процессами разработки руководит фирма, а не заказчик.
Я не работаю на аутсорсе, не предлагаю заказчику свои услуги и данный проект также не относится к аутсорсным.
Извините, что ввел Вас в заблуждение. Возможно в Вашем случае, когда Вы фрилансер/аутсорсер — то Вы можете отказываться от «плохо сформулированных пользовательских историй».
Но в данном случае, когда заказчик нанял для разработки софтверную фирму; фирма приняла на работу меня; и я работаю в первую очередь на фирму, а не на заказчика — я лишен возможности «не брать плохо сформулированные пользовательские истории в работу».
Понял.
За счет автоматизации на бирже торгуются не товары, а активы.
Соответственно, когда софтварная фирма предлагает заказчику использовать конкретного разработчика (который обладает определенным набором характеристик, определенными условиями применения и определенной ценой) — то нужно использовать термин «актив»? Cофтварная фирма предлагает использовать заказчику актив?
Я не обижаюсь, но это оскорбление. Я себя товаром не считаю
.
Тогда приношу свои искренние извинения.
Скорее всего, в процессе того как заказчику предлагают использовать конкретного разработчика, который обладает определенным набором характеристик, определенными условиями применения и определенной ценой — этого разработчика называют каким-то другим термином. Не товаром.
Еще раз прошу прощения за неверное применение такого некорректного термина, я просто его взял из Вашего сообщения "Ну вы же не товар на самом деле.". Да, согласен. Не товар. Как-то по-другому…
Оценка — это просто такой повод синхронизировать модели. Если кто-то что-то недопонимает — это наверняка отразится на оценке.
Для верной оценки ИМХО нужно ПОНИМАТЬ механизмы реализации той конкретной задачи, которая оценивается.
Как Вы оцените операцию на сердце? На сколько баллов?
У меня как было: у меня было резюме внутри компании. И ресурсный менеджер показывал это резюме заказчикам. Не обычное мое публичное резюме на hh, а именно специальное. И там было все написано, что могу, что не могу, и так далее.
Не обижайтесь, но Вы таки товар. Все признаки присутствуют — характеристики + цена.
В скраме нет подразделения на должности, есть только разработчики. Если команде не достатет навыков для работы — это один вопрос, и серьезный. Но его надо решать еще до начала работы.
Кстати, как в SCRUM-е решается вопрос, что каждый из разработчиков имеет разную направленность и разный стек технологий, но при этом все разработчики равноправно голосуют за оценку Пользовательской истории в баллах?
Поясню — я, например, разработчик блокчейн-части проекта. Мои коллеги, фронт и бек — о блокчейне слышали только из новостей о курсе Биткоина. Аналогично и я не гуру в их сфере компетентности.
Но при этом мы почему-то должны равноправно оценить задачу, которая включает в себя разные стеки технологий.
Извините, конечно, но мне кажется, что Вы или фрилансер или никогда не работали в команде.
Развернуться и уйти — это будет как в анекдоте про цыгана в партизанском отряде — «Эти ваши листовки — очень плохой товар, я еле их продал».
Что касается присутствия «владельца продукта», то как раз он и сформулировал 1ю и единственную Пользовательскую историю (напомню, она звучит как "Я, как пользователь, хочу получить систему, в которой производственные и бизнес-процессы предприятия отображаются в блокчейне")
ИМХО, «Independent self motivated» — совсем не означает, что каждый разработчик из команды должен кроме программиста быть еще и Проект менеджером и Архитектором и Техническим писателем. Рискую нарваться на «минуса в карму», но такое совместительство как минимум тупо не оплачивается…
В каком смысле «сама собралась»? Заказчик обратился в софтверную фирму, которая набрала под данный проект такое количество разработчиков определенной квалификации и владеющих определенным стеком технологий, которых посчитала нужным набрать.
Я, например, пришел в проект по такому объявлению на сайте вакансий:
"We are looking for Senior Blockchain Developer for our new project.
You can apply your technical skills and motivation to build a new cutting edge and extremely innovative product. Lots of challenging tasks are waiting for you!
Requirement experience with:
— 5+ years of overall software development experience (backend preferred)
— 3+ years of Blockchain development
— Independent self motivated"
Возможности напрямую обсудить с заказчиком его «пожелания» лично у меня нет, как нет такой возможности и у других разработчиков из команды. Собственно, обычная «галера» и обычные условия работы программистов…
Можно просто не брать плохо сформулированные пользовательские истории в работу.
Вы точно уверены, что руководство «галеры» разрешит программистам «не брать плохо сформулированные пользовательские истории в работу»?
Так что, никто никуда «сам не собирался» и никакой возможности влиять на хотелки Пользовательские истории заказчика — нет и не предвидится…
Я правильно понял вопрос — получается ли херня без предварительного планирования, разработки архитектуры, структуры данных и т.д.?
Ответ: — Да, воистину херня.
При чем здесь SCRUM? Все очень просто — в описываемой истории именно благодаря нему все эти этапы (предварительное планирование, разработка архитектуры, структуры данных и т.д.) отсутствуют…
Кто-то ж собирал команду именно в таком составе, как она есть? Определил какие специалисты будут нужны, какой стек технологий использовать, какой уровень квалификации специалистов (и какой бюджет)?
Архитектора в команде не предусмотрено — кто должен заставить заказчика правильно сформулировать свои Пользовательские истории?
Front-end developer? Back-end developer? Database developer? Blockchain developer?
И тем не менее, в данном проекте заказчик хочет, чтобы в качестве метода разработки применялся именно SCRUM.
Да, согласен, вопросов не возникает, когда уже есть готовый продукт, — например, какой-то сайт. И требуется исправить пару опечаток на страницах этого сайта — здесь проблем нет. Создаем Пользовательскую историю типа «Я как пользователь сайта, хочу увидеть исправленную оЧеПятку на заглавной странице сайта с целью увеличить привлекательность сайта».
Успешно оцениваем каждую такую Пользовательскую историю в 1 (или даже 5) баллов. Успешно решаем задачу и к концу спринта получаем новую итерацию нашего продукта — сайт с исправленной оЧеПяткой опечаТТККой. В данном кейсе SCRUM безусловно рулит.
Но когда у нас стартап и мы вместо разработки его архитектуры сразу начинаем кодить кнопку КНОПКУ — то вот как раз здесь SCRUM неуместен. ИМХО.
Судя по комментариям выше, например "Какой смысл городить 2 месяца архитектуру с тоннами абстракций..." — то да, похоже понятия информации, данных, дата-флоу и т.д. «устарели»… И блокчейн в таком случае — просто один из примеров…
Интересно, если бы программисты взялись спроектировать, например, карьерный самосвал — то процесс проектирования тоже бы проходил по Скраму? То есть, раз времени выяснить характеристики проектируемого самосвала нету, то поэтому уже по окончанию 1й недели заказчик получит работающий прототип — садовую тачку, например? А уже потом будем «наворачивать» к этой тачке функционал — еще колеса, двигатель и т.д.
Почему тот, кому платят деньги — разработчик — должен обладать определенной квалификацией, а к тому, кто платит деньги — к представителю заказчика, Product Owner-у — таких требований не предъявляется?
Формально Product Owner есть, то только лишь формально.
Если ежедневные бизнес-процессы компании предполагают выполнение какой-то функции, а компания отдает выполнение этой функции «на сторону» — то это аутсорс. А вот если компания «на стороне» заказывает услугу, которая никак не входит в ее ежедневные бизнес-процессы — это обычный бизнес.
К примеру, заказчик — животноводческая ферма. Раздача корма поросятам — это основная бизнес функция компании. А постройка зданий, в которых живут поросята — к ежедневным бизнес-процессам компании не относится.
Соответственно, отдаем кормление поросят «на сторону» — аутсорс. Отдаем постройку зданий «на сторону» — не аутсорс.
Прочитайте, пожалуйста, 1й дисклеймер публикации.
Не вижу разницы между этими двумя средствами производства для заказчика — специализированным станком, который разрабатывается и производится сторонней фирмой. И специализированным программным обеспечением, которое точно так же разрабатывается и производится сторонней фирмой.
Почему первое — НЕ аутсорс, а второе — аутсорс?
То есть Вы полностью исключаете, что часть разработки софтверная фирма может финансировать за счет собственных средств? Например, чтоб потом продать разработанный продукт еще в 2-3-4 места с незначительными изменениями?
То есть, когда производственная компания заказывает разработку, производство и затем покупает у другой компании специализированный станок; и когда производственная компания увольняет своих дворников и заказывает услугу уборки территории у другой компании — и то и другое это аутсорс?
Еще раз повторюсь — я понятия не имею что и как заказчик платит фирме, с которой у меня трудовые отношения. Свечку-с не держал…
Бьюсь об заклад, что сейчас у многих владельцев компаний по разработке программного обеспечения произошел взрыв мозга…
Понятия не имею… Честно говоря, даже не интересовался этим вопросом. Возможно, что всю разработку полностью оплачивает заказчик, а возможно что часть денег фирма вкладывает самостоятельно (ну а вдруг). А Вы как думаете?
В том то и беда… Прихоть заказчика, что ж тут поделать…
Фирма по разработке программного обеспечения под заказ.
… не знаю, как еще объяснить… Зарплату платит фирма, а не заказчик. Процессами разработки руководит фирма, а не заказчик.
Извините, что ввел Вас в заблуждение. Возможно в Вашем случае, когда Вы фрилансер/аутсорсер — то Вы можете отказываться от «плохо сформулированных пользовательских историй».
Но в данном случае, когда заказчик нанял для разработки софтверную фирму; фирма приняла на работу меня; и я работаю в первую очередь на фирму, а не на заказчика — я лишен возможности «не брать плохо сформулированные пользовательские истории в работу».
За счет автоматизации на бирже торгуются не товары, а активы.
Соответственно, когда софтварная фирма предлагает заказчику использовать конкретного разработчика (который обладает определенным набором характеристик, определенными условиями применения и определенной ценой) — то нужно использовать термин «актив»? Cофтварная фирма предлагает использовать заказчику актив?
Тогда приношу свои искренние извинения.
Скорее всего, в процессе того как заказчику предлагают использовать конкретного разработчика, который обладает определенным набором характеристик, определенными условиями применения и определенной ценой — этого разработчика называют каким-то другим термином. Не товаром.
Еще раз прошу прощения за неверное применение такого некорректного термина, я просто его взял из Вашего сообщения "Ну вы же не товар на самом деле.". Да, согласен. Не товар. Как-то по-другому…
Для верной оценки ИМХО нужно ПОНИМАТЬ механизмы реализации той конкретной задачи, которая оценивается.
Как Вы оцените операцию на сердце? На сколько баллов?
Не обижайтесь, но Вы таки товар. Все признаки присутствуют — характеристики + цена.
Кстати, как в SCRUM-е решается вопрос, что каждый из разработчиков имеет разную направленность и разный стек технологий, но при этом все разработчики равноправно голосуют за оценку Пользовательской истории в баллах?
Поясню — я, например, разработчик блокчейн-части проекта. Мои коллеги, фронт и бек — о блокчейне слышали только из новостей о курсе Биткоина. Аналогично и я не гуру в их сфере компетентности.
Но при этом мы почему-то должны равноправно оценить задачу, которая включает в себя разные стеки технологий.
Развернуться и уйти — это будет как в анекдоте про цыгана в партизанском отряде — «Эти ваши листовки — очень плохой товар, я еле их продал».
Что касается присутствия «владельца продукта», то как раз он и сформулировал 1ю и единственную Пользовательскую историю (напомню, она звучит как "Я, как пользователь, хочу получить систему, в которой производственные и бизнес-процессы предприятия отображаются в блокчейне")
ИМХО, «Independent self motivated» — совсем не означает, что каждый разработчик из команды должен кроме программиста быть еще и Проект менеджером и Архитектором и Техническим писателем. Рискую нарваться на «минуса в карму», но такое совместительство как минимум тупо не оплачивается…
Я, например, пришел в проект по такому объявлению на сайте вакансий:
"We are looking for Senior Blockchain Developer for our new project.
You can apply your technical skills and motivation to build a new cutting edge and extremely innovative product. Lots of challenging tasks are waiting for you!
Requirement experience with:
— 5+ years of overall software development experience (backend preferred)
— 3+ years of Blockchain development
— Independent self motivated"
Возможности напрямую обсудить с заказчиком его «пожелания» лично у меня нет, как нет такой возможности и у других разработчиков из команды. Собственно, обычная «галера» и обычные условия работы программистов…
Вы точно уверены, что руководство «галеры» разрешит программистам «не брать плохо сформулированные пользовательские истории в работу»?
Так что, никто никуда «сам не собирался» и никакой возможности влиять на
хотелкиПользовательские истории заказчика — нет и не предвидится…Ответ: — Да, воистину херня.
При чем здесь SCRUM? Все очень просто — в описываемой истории именно благодаря нему все эти этапы (предварительное планирование, разработка архитектуры, структуры данных и т.д.) отсутствуют…
Архитектора в команде не предусмотрено — кто должен заставить заказчика правильно сформулировать свои Пользовательские истории?
Front-end developer? Back-end developer? Database developer? Blockchain developer?
Да, согласен, вопросов не возникает, когда уже есть готовый продукт, — например, какой-то сайт. И требуется исправить пару опечаток на страницах этого сайта — здесь проблем нет. Создаем Пользовательскую историю типа «Я как пользователь сайта, хочу увидеть исправленную оЧеПятку на заглавной странице сайта с целью увеличить привлекательность сайта».
Успешно оцениваем каждую такую Пользовательскую историю в 1 (или даже 5) баллов. Успешно решаем задачу и к концу спринта получаем новую итерацию нашего продукта — сайт с исправленной
оЧеПяткойопечаТТККой. В данном кейсе SCRUM безусловно рулит.Но когда у нас стартап и мы вместо разработки его архитектуры сразу начинаем кодить
кнопкуКНОПКУ — то вот как раз здесь SCRUM неуместен. ИМХО.