0. MariaTemchina 1044 18.05.20 16:57 Сейчас в теме

Почему Scrum не работает в проектах 1С

Более точная формулировка заголовка, пожалуй будет такой - Почему Scrum в чистом виде плохо работает в проектах внедрения продуктов 1С.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. andironenko 637 18.05.20 17:29 Сейчас в теме
Да, про MVP для проектов внедрения 1С ERP - это самое главное.
Уже год сижу на таком проекте, который до меня делали по разновидности SCRUM.
Практически все приходится перевнедрять заново - функционал не стыкуется друг с другом и что обидно не стыкуется в самом ядре. Проще было бы инициировать перезапуск проекта, но денег почти не осталось.
MariaTemchina; +1 Ответить
6. MariaTemchina 1044 18.05.20 20:20 Сейчас в теме
(1) У меня ощущение, что Agile в чистом виде вообще плохо подходит для проектов со сложной архитектурой. Хотя отдельные компоненты Скрам (частые демонстрации со сбором обратной связи, роль Владельца продукта как единая точка входа требований, прозрачная отчетность и т.п.) могут улучшить ситуацию практически на любом проекте.
33. user1420880 09.06.20 11:15 Сейчас в теме
(6) Из большинства моих знакомых вайтишников и не очень, есть уверенность - что аджайл, что срам - плохо подходят вообще для чего-либо, вернее никак не подходят, их всё больше натягивают. Разве что годны для микроменеджмента и выжимания последних соков из работников.
2. ZLENKO 385 18.05.20 17:37 Сейчас в теме
Просто на проектах внедрения 1С затраты на применение Scrum не окупятся, т.к. не создается тиражируемый продукт - главное побыстрее, а качество "как получится".
Krasnyj; MariaTemchina; +2 Ответить
4. Yashazz 3249 18.05.20 19:56 Сейчас в теме
(2) Больше скажу - даже когда создаётся вроде бы тиражный продукт, по меньшей мере с прицелом на это - всё равно "давай быстрей и дешевле, потом допилим".
dock; pro-rok; ZLENKO; MariaTemchina; +4 Ответить
22. Dragonim 125 19.05.20 17:47 Сейчас в теме
(4) Не совсем понятно причем тут 1С? По моему так делаются все проекты, просто некоторые допиливают до приемлемого вида, а некоторые бросают на пол пути.
24. Yashazz 3249 19.05.20 18:17 Сейчас в теме
(22) а в случае 1С вступают в действие некоторые бизнесовые психологические стереотипы, от которых иные системы свободны или в меньшей степени "заиграны".
3. METAL 115 18.05.20 18:04 Сейчас в теме
Мои поздравления, Мария! :)
Скажите, пожалуйста, а как долго будет проходить вебинар-воркшоп?
MariaTemchina; +1 Ответить
5. MariaTemchina 1044 18.05.20 20:16 Сейчас в теме
(3) Спасибо, Михаил! )))
Я планирую примерно полтора часа
7. timmson 18.05.20 22:47 Сейчас в теме
Мария,

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

Могу рекомендовать курс PSPO от Scrum.org, в котором как раз обсуждаются аспекты продуктовой разработки.

2. "Жестко фиксированные по времени спринты с запретом добавлять работу посередине" - в Скраме нет такого запрета. Бэклогом Спринта владеет Команда Разработки, она может его менять, оставаясь с фокусом на Цели Спринта.

3. "Скрам крайне негативно относится к многозначности." - не только Скрам, но и любой Lean-based подход, т.к. переключение контекста является потерями, особенно в нематериальном производстве

4. "Результат каждого спринта должен быть потенциально поставляем" - добавлю к п.1, что Скрам работает в командах с хорошими инженерными практиками, т.е. которые позволяют иметь низкие транзакционные издержки при изменения продукта. Установка в прод несколько раз в день для топовых команд является в 2020 году уже нормой.

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

Удачи в изучение Скрама! Если появятся вопросы, стучитесь в FB - https://www.facebook.com/artem.v.krotov
portal_orsk; brr; MariaTemchina; +3 Ответить
16. MariaTemchina 1044 19.05.20 11:13 Сейчас в теме
(7) Артем, спасибо за исчерпывающий ответ!
Из опыта Скрам избыточен и сложен в ситуациях, когда нужно что-то внедрить. Ценность, которую может принести команда, конечна и ограничена условиями контракта в отличие от продуктовой разработки.

Рада, что в этом вопросе мы с вами сходимся.

"Жестко фиксированные по времени спринты с запретом добавлять работу посередине" - в Скраме нет такого запрета. Бэклогом Спринта владеет Команда Разработки, она может его менять, оставаясь с фокусом на Цели Спринта.

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

"Скрам крайне негативно относится к многозначности." - не только Скрам, но и любой Lean-based подход, т.к. переключение контекста является потерями, особенно в нематериальном производстве

Всецело согласна, что лучше, когда команда работает над одним проектом и не переключается. Я думаю, что практически любая команда тоже с этим согласится. Съесть-то он съесть, да кто ж ему дасть (С)

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

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

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

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

Спасибо, Артем! Обязательно! Если у вас появятся вопросы по проектам внедрения 1С - приходите на Инфостарт!
8. ManyakRus 392 19.05.20 09:29 Сейчас в теме
Скрамы придумали чтобы легче было "продавать" своё внедрение компаниями подрядчиками(франчайзи)
Чтобы получать оплату не в конце проекта, а каждую неделю,
Скрам определяет порядок работы и "принятие" работы т.е. оплаты.
Для не франчайзи скрамы не нужны :)
user1011815; graphbuh; +2 Ответить
12. MariaTemchina 1044 19.05.20 10:22 Сейчас в теме
(8) Александр, а вот здесь не соглашусь. По моим наблюдениям, ситуация обстоит строго наоборот - во внутренних проектах применять Agile просто, удобно, логично, и все однозначно в выигрыше. Это во внешних проектах возникают всякие странные вопросы, типа того, а когда проект закончится или сколько он будет стоить или как составить полное ТЗ...
9. Manoshkin 350 19.05.20 09:29 Сейчас в теме
ибо трудозатраты на такую “временную интеграцию”, которая потеряет смысл когда система будет внедрена целиком, могут превысить затраты на само внедрение.

тут стоит еще учитывать потери от простоев и нестабильности системы в момент перехода. они могут многократно превышать и стоимость проекта.
MariaTemchina; +1 Ответить
13. MariaTemchina 1044 19.05.20 10:29 Сейчас в теме
(9)

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

Это да. Я тоже думала об этом, когда писала статью, но решила её не растягивать. Более того, на самом деле, если не проводить боевого тестирования и интеграции кусочков, у нас есть риск того, что при переходе "по рубильнику" система по разным причинам окажется в принципе нежизнеспособной (примеров в моем окружении, к сожалению, достаточно) . И мы сравниваем не стоимость внедрения одним махом/ внедрения по кусочкам с интеграцией, а провальное внедрение/внедрение с куда большими шансами на успех.
10. Bazil 481 19.05.20 09:53 Сейчас в теме
(0) А если заменить внедрение продукта 1С на внедрение продукта не 1С, условия те же, результат будет иным?
11. MariaTemchina 1044 19.05.20 10:19 Сейчас в теме
(10) На мой взгляд, тогда ответ будет менее однозначным. Потому что контекст бывает очень разным. Но по моим ощущениям, Скрам лучше подходит для разработки, чем для внедрения.
15. Bazil 481 19.05.20 11:02 Сейчас в теме
(11) Я правильно понял, берем, например, команду одинесников, которая занимается внедрением ERP-систем на 1С, переучиваем их, например на Галактику, и сразу тезис о неработоспособности скрама в их проектах становится менее однозначным?
MariaTemchina; +1 Ответить
27. MariaTemchina 1044 20.05.20 20:04 Сейчас в теме
(15) Простой ответ заключается в том, что про Галактику я ничего не скажу, потому что не знаю.
А сфера 1С внедрений - специфичная среда с некоторыми традициями и особенностями...
14. GOshaSaveiko 30 19.05.20 10:33 Сейчас в теме
Чаще всего со стороны франча, будет прыщавый Андрейка с рандомной квалификацией, который будет сам себе скрам мастер и команда. А продакт оунером будет какой-нибудь замдиректора, который 1С в глаза не видел, и каждый раз звал Галю отборы в отчёте настроить, но который будет думать, что именно он знает как надо, например: "сделайте мне так, как было в 1сv7, только в 8 ERP". Именно поэтому и не катится. Параллельно будет толпа юзеров, которая на тестировании говорит, что всё хорошо, а на проде открывает отчёты, печатные формы и документы впервые, потом бежит к замдиректора со причитаниями: у нас ничего не работает. Замдиректора позвонит замдиректору франча, прыщавый Андрейка получит трындюлей и так по кругу. Это скрам в 1с. Потом лицо со стороны франча просто самоустранится и скажет: "Вот у нас тут Андрейка - звоните сразу ему"

А если серьезно, то на самом деле можно, но придётся накачать ресурсов:
1. разделить команду на две, где одна пилит долгоиграющие фичи по скраму, а вторая, по сути, саппорт по канбану
Канбанерам: То, что нужно быстренько подпилить, помочь
Скрамерам: то что пилим долго + укоротить время спринта до недели.
2. Владельца продукта оставить одного на растерзание. В паре со скрам-мастером выдержат. Владелец должен понимать как работает 1С.
3. Нет, не порвётся
4. Можно завести своего тестировщика, либо после тестирования пользователем возвращать фидбек Владельцу, который его выбросит на скрам или канбан.
5. ERP можно внедрять по скраму, если пилить его параллельно со старой учетной системой, показывать будущим пользователям, потом в день "Хэ" поставить на прод. И дальше допиливать на лету по рекламациям.
Но это "дорага" (г с придыханием) - дешевле втроём стегать Андрейку. И все при деле
Алексей Воробьев; Krasnyj; oleg974; MariaTemchina; semagin@gmail.com; VladimirMelnychenko; +6 Ответить
28. MariaTemchina 1044 20.05.20 20:11 Сейчас в теме
(14) Очень жизненный образ, спасибо!
Только Андрейку жалко)))).

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

В описываемом вами примере про ERP - на мой взгляд, это все-таки не совсем Скрам. Потому что слишком велик шанс, что "в день Х" не взлетит совсем. И рискуем мы здесь не парой спринтов, а многомесячной работой...
17. oleynikovpm 19.05.20 11:14 Сейчас в теме
Ни разу не видел, чтобы только Скрам использовался на проекте. Участвовал в проекте внедрения ERP, команда разработки работала по Скрам, но у владельца продукта все равно был Roadmap - какой функционал надо делать, наложенный на временную шкалу.
То есть скрам использовался для организации работы программистов, тестировщиков, а владелец продукта сидел на водопаде.

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

Самая большие проблемы, с которыми столкнулась наша команда, при работе по скрам:
1) высокие требования к владельцу продукта, потому что на него падает большая нагрузка по систематизации обратной связи, перевода с языка пользователя в требования, согласования этого, приемка релиза от команды разработки и доказательства пользователям, что реализовано именно то, что они просили.
2) проблемы с заказчиками(пользователями):
- привычка сразу получать обратную связь от разработчиков,
- изменение сроков выполнения небольших задач,
- необходимость согласовывать требования к разработке, и принимать результат (ответственность заказчика),
- необходимость планировать свою деятельность в связи с изменением сроков внесения изменений в информационную систему.
MariaTemchina; +1 Ответить
18. user1011815 19.05.20 16:12 Сейчас в теме
Скрам в 1С? Зачем? Канбан идеален. Опыт показал, что то, что пилится в 1С за 3-4 дня, на вебе или на си-подобных языках вы будете делать месяц, а то и 2. При этом, если что-то включать дополнительно в спринт по причине "директор так сказал", этот месяц растянется на 2-3. В 1С 4 дня растянутся на 6, что в принципе терпимо для всех.
20. bozo 19.05.20 17:11 Сейчас в теме
(18) Канбан - конвеерный инструмент и хорош на поддержке и в рамках её как бы проектах развития. То есть там, где нет правой границы, а имеет значение протягивание и управление приортьетами задач. А на проектах не представляю как его использовать.
23. user1011815 19.05.20 18:05 Сейчас в теме
(20) Я соглашусь, это были проекты развития. В 1С проектах полного цикла лучше всего работал водопад, наверное, здесь влияет скорость разработки на платформе, когда требования не успевают устаревать и нет существенной необходимости делать полгода PoC и MVP как это происходит в рамках реализации веб приложений.
29. tindir 21.05.20 08:01 Сейчас в теме
(18) И часовые ставки у ребятушек с "правильным программированием" чуть повыше, но опустим это. И для чистоты эксримента приравняем. В итоге "си-преподобные" с мамонта снимают (по вашим же словам) 1-2-3 месячные ставки "по Актам", а 1с-нег получает за 4-6 часа работы. В итоге у первых с фичи получается большая маржа =) Люблю "настоящее программирование" кровавого интерпрайза, но слишком туп даже для джуна, чтобы зарабатывать как боженька.
30. acanta 21.05.20 08:14 Сейчас в теме
(29) в какой-то момент любому владельцу бизнеса становится не комильфо 1с с ее сертифицированным эникейщиком. Это неизбежность. Проблема в том, сможет ли программист по образованию актуализировать свою квалификацию по диплому после 5 лет работы с 1с. И даже если сможет, будет ли этого достаточно (и для чего?).
31. tindir 21.05.20 08:22 Сейчас в теме
(30)
владельцу бизнеса
Вы имеете ввиду "хозяина" франча? Имхо тут есть момент политики ведения бизнеса. В моей голове есть два варианта: 1. Жить с оборота (1с-нег с 6 часами, но на 100 клиентов), 2. Жить со сливок ( 1 месяц с 1 клиентом). В обоих вариантах сальдо 99 будет одинаковым, при разнице оборотов 90 счета в разы. В бытность работы франча слышал от руководителя фразу типа "проще 100 клиентов на Базовом ИТС, чем 10 на почасовом сопровождении".
19. Tahallus 426 19.05.20 16:12 Сейчас в теме
Глеб Стальной из 1ПБ будет не согласен) они ведь все внедряют по SCRUM
32. MariaTemchina 1044 05.06.20 13:18 Сейчас в теме
(19) Ну, насколько я понимаю, там имиджевая составляющая важнее, чем рентабельность. По-крайней мере в том, что касается автоматизированного тестирования и прочих "наворотов".
Ну и поставка там скорее одна - то есть это более напоминает "Скрам как бизнес-процесс" как его вышел описывал Павел:

(17)
Ни разу не видел, чтобы только Скрам использовался на проекте. Участвовал в проекте внедрения ERP, команда разработки работала по Скрам, но у владельца продукта все равно был Roadmap - какой функционал надо делать, наложенный на временную шкалу.
То есть скрам использовался для организации работы программистов, тестировщиков, а владелец продукта сидел на водопаде.
21. bozo 19.05.20 17:21 Сейчас в теме
Главные проблемы скрама в ерп вижу три:
1. Предметные области требуют глубокой специализации аналитиков и иногда даже разработчиков.
2. Кастомизация сложной типовухи вертикальным срезами не очень взлетает, потому что требования к архитектуре повышенные ввиду сложности связей.
3. Договорные отношения по 223-фз, не говоря даже о 44-фз, не позволяют управлять функциональным контуром.

Для нас оптимальной пока для нас выглядит смешанная структура структура: договор на ФТТ - не гигантский ФТТ с ключевыми ограничениями (самый важный этап) - оценка и договор - много (десяток-два) этапов с разработкой блоков, интеграций, миграции и сдачей по приёмке - интегротест - запуск в один-два-три этапа, в зависимости от специфики проекта. Это для проектов на год-полтора длительности.
25. pro-rok 253 20.05.20 08:00 Сейчас в теме
Я бы назвал статью "Давайте из Scrum выкинем Scrum, но будем это называть Scrum".
Давайте разделять котлеты отдельно... Все прекрасно знаю по Scrum не построить мост, так собственно и ERP не внедрить. Хотя подождите... вру внедрить ERP можно, только стоить будет как 2-3 внедрения. Есть компании которые так и делают, нет ответственности за результат и бюджет, вот и внедряют с помощью гибких методологий.
Для внедрений есть специальные методологии ориентированные именно на внедрения. А вот в сопровождении 1С, гибкие методологии и подходят как нельзя лучше, когда можно выдавать небольшие результаты и тут же их использовать в жизни.

Мария, поздравляю со сдачей экзамена.
26. morin 14 20.05.20 08:27 Сейчас в теме
В комментариях к другой из статье, я вас критиковал, признаюсь, довольно резко. Но эта ваша работа гораздо сильнее и качественнее. Спасибо!
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Екатеринбург
зарплата от 80 000 руб. до 130 000 руб.
Полный день

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Программист 1С
Санкт-Петербург
зарплата до 150 000 руб.
Полный день

Ведущий программист 1С
Москва
зарплата от 150 000 руб.
Полный день

Ведущий программист 1С (УТ 11)
Москва
зарплата до 200 000 руб.
Полный день