История внедрения Scrum в отделе внутренней разработки 1С

0. Александр Лапшин (zfilin) 1883 10.02.15 14:27 Сейчас в теме
Я работаю с 1С с 2004 года. В процессе своей работы я сменил несколько команд, и практически все они были командами внутренней разработки большого или среднего заказчика. В одной из команд (это был холдинг среднего размера) мы внедряли Scrum. Об этом я и хочу рассказать.
Итак, мой доклад будет о внедрении Scrum. «Глубоких мыслей» не обещаю, просто постараюсь рассказать о том, как это было у нас, и возможно, пояснить, почему это было именно так

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

Комментарии
1. Денис Бурлыко (borodabmc) 26.02.15 16:08 Сейчас в теме
Вкратце расскажу наш путь к Agile... За чашечкой чая в одно прекрасное утро подумали, что стало скучно работать в полном хаосе и пошли гуглить...
Начинали сначала с чистого "КАНБАНа". У каждого отдельная доска, только со своими задачами. Реализовали и на доске и в своей CRM. Аналитиками бросались задачи на конкретных разработчиков или в общую корзину. Вначале по правилу "кто первый встал, того и тапки", то есть кто-раньше поставил задачу, ту задачу быстрее брали в работу. Вначале все было достаточно хорошо. Но кампания росла, и в такой адаптации уже не помогало, а зачастую мешало работать. Стало не хватать адекватного планирования...(чтоб хоть банально закрыть вопрос со сроками, которые озвучивать заказчикам). В итоге прикрутили приоритеты к задача - тоже мало.
Начали внедрять Scrum со всеми артефактами (user story, спринтами, ролями, доской, и т. д.).
Тяжело было вначале донести людям (те, с которыми поднимали Канбан, давно слились), которые привыкли работать в хаосе и постоянно в режиме хотфикса... Пришлось даже пенделей отвесить некоторым: вроде собрались, замутили спринт, на выходе - спринт мертвый... почему... не понятно, чего от них хотят... Собрались, еще раз объяснил, что Scrum, в первую очередь, - это командная работа... Вроде прислушались... Второй спринт взлетел... В итоге работает несколько команд на проектах.
С дежурным хорошая идея, тоже пытался, чтоб был человек дежурный на второй линии поддержки, если первый уровень не справляется. Тяжело пошло... продукты разные, проекты тоже... (от розницы до автотранспорта)... и универсальных бойцов мало...
По итогу:
Scrum завелся, разработка на проектах.
Вопрос поддержки - два уровня... если первый не справляется то задача прогерам.
Борюсь с офисной мудой - чтоб прогеры меньше отвлекались на вопросы аналитиков и консультанотов (особенно если они вообще не по теме)
firma-modul; spawn8995; blindcat2006; Agrognom; Perk0n; zfilin; +6 Ответить
2. Алексей Соловьев (Silenser) 414 27.02.15 11:12 Сейчас в теме
Видимо меня заминусуют, но я не вижу реальных плюсов от новой схемы. Трекер + приоритеты решали бы все описанные проблемы на ура, а так удлинили цикл разработки и увеличили время на планирование и сопутствующие вещи, что в итоге выльется в падение производительности людей, которые будут отвлечены от работы занесением дополнительных аналитик в новую систему.
Вопрос саппорта решается выделением времени сотрудников на этот самый саппорт с ведением длинных тикетов, которые имеют шанс перейти на другого сотрудника, в трекере.
Вопрос взаимовлияния разработки решается либо наличием архитектора системы, либо документированием аналитиками.
Так к чему же эта работа ради самой работы?
ПС: это не попытка наехать на автора, скорее вопрос, обусловленный личным негативным опытом, когда внедрением подобной схемы закончилось развалом команды (из 12 работников отдела ИТ 10 покинули компанию, при этом ни одна из заявленных новым РП целей не была выполнена в срок, что было объяснено старыми кадрами, но даже набор новых не дал результатов, все как в анекдоте про 3 конверта)
davydoff; ivv1970; olgerd666; +3 Ответить 1
3. Сергей Иванов (1Service2) 12.05.16 12:08 Сейчас в теме
4. Иван Белокаменцев (1c-intelligence) 1317 17.08.17 11:53 Сейчас в теме
Расскажите, пожалуйста, насколько возросла скорость разработки в попугаях за время использования скрама?
5. Геннадий Николаев (genayo) 17.08.17 12:01 Сейчас в теме
Вот, наконец то статья с нормальными практическими примерами, а не чистая теория...
6. Владимир Безфамильный (Vovan1975) 14 17.08.17 12:40 Сейчас в теме
У несчастного на рабочем месте стояла большая красная машина (та, которая на картинке). И все знали, кто на этой неделе обречен общаться с пользователями и заниматься их сиюминутными проблемами.


вот в этом, ребята, ваша проблема. Вы боитесь общаться с народом.
корум; +1 Ответить 1
7. Владимир Безфамильный (Vovan1975) 14 17.08.17 12:45 Сейчас в теме
и да, не могу не оставить это здесь:
"SCRUM или шабаш ведьм"
http://blog.jdevelop.com/software/2014/03/25/lifestyle.html
8. Виталий Попов (Сурикат) 149 17.08.17 13:32 Сейчас в теме
(2)
Если мы говорим о порелизной разработке, то гибкие методологии удобнее, чем приоритеты.
+ при наличии сильно изменяющихся требований они дают определенные плюсы. Мы же выкатываем почти всегда законченную функциональность

И очень сильно зависит от культуры команды. Если люди не понимают какие проблемы такие методологии решают, то они и не зайдут
9. Иван Белокаменцев (1c-intelligence) 1317 18.08.17 08:44 Сейчас в теме
(7)
и да, не могу не оставить это здесь:
"SCRUM или шабаш ведьм"
http://blog.jdevelop.com/software/2014/03/25/lifestyle.html


вы сами что думаете про то, что написано по этой ссылке?
10. Александр Лапшин (zfilin) 1883 18.08.17 14:45 Сейчас в теме
(4) Давно все это было. Скорость "в попугаях" плавала, то росла, то уменьшалась. Сейчас не отвечу на этот вопрос.
Главным было то, что повысилась управляемость и прогнозируемость процесса разработки.

(5) Спасибо. Это стенограмма с выступления.

(6) Вы немного ошибаетесь. "Боитесь" это не то слово. Просто разработка и поддержка это немного разные виды деятельности и не все могут мгновенно вынырнуть из отладчика, ответить на вопрос "почему у меня не проводится реализация", а потом так же быстро погрузиться обратно в отладчик.
Именно с таким дроблением времени и была призвана бороться пожарная машина. Ну, а что описал я это с иронией словами "несчастный" и "обречен", так в любом даже самом серьезном деле есть время "погыгыкать".
11. Александр Лапшин (zfilin) 1883 18.08.17 14:59 Сейчас в теме
(7) Я могу вам еще одну ссылку дать, тоже интересную - https://ebanoe.it/2016/12/26/woxapp-scrum-slavery/

Критика методологии была очень популярна в начале, когда она только приборетала популярность. Более того, была обоснованной, так как были ошибки, неопытные scrum-мастера, scrum тулили где он нужен и не нужен и даже делали все совершенно противоречащее принципам agile, называли это agile и жаловались какая гадость этот scrum.

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

И да, сейчас я не использую гибкие методологии, потому что в конкретно данный момент не вижу это для своей комманды целесообразным. Однако, как только понадобится, я с удовольствием снова ими воспользуюсь.
12. Владимир Скворцов (Vovanches) 18.08.17 15:47 Сейчас в теме
Люди, откуда у вас столько времени, чтобы заниматься этой фигней?
Yashazz; vitalbasl; +2 Ответить 1
13. Andrey Erastov (tailer2) 18.08.17 15:53 Сейчас в теме
14. Иван Белокаменцев (1c-intelligence) 1317 21.08.17 19:45 Сейчас в теме
(10)
Главным было то, что повысилась управляемость и прогнозируемость процесса разработки.


Два вопроса, если позволите:
1. Управляемость и прогнозируемость процесса разработки вы как-то измеряли? Как определили, что они повысились?
2. Почему вы назвали это "главным"? Оно было главным изначально, как цель? Или стало главным в итоге, как лучший из полученных результатов?

Спасибо.
15. Яков Коган (Yashazz) 2119 23.08.17 19:28 Сейчас в теме
(10)
Скорость "в попугаях" плавала, то росла, то уменьшалась... Главным было то, что повысилась управляемость и прогнозируемость процесса разработки.

А вот и момент истины. То есть, все вышеописанные прыжки и гримасы выполнялись исключительно ради собственного удобства внутренней группы айтишников, и никак - подчёркиваю, никак - не принесли пользы бизнесу, за счёт которого айтишники кормились и чьё время, по сути, тратили на эту фигню. Поясню: управляемость - это очень красивое слово, за которым не стоит ничего. Ни умения фрагментировать задачу и контролировать её решение, ни прозрачности для руководства, ни мониторинга занятости. Управляемость. Волшебное нечто из лексикона всяких коучей... Прогнозируемость - это очень смешное слово. Требования бизнеса априорно непредсказуемы, т.к. это всегда может быть как задача рынка, так и шлея под хвостом гендира или главбуха. Прогнозировать разработку это как угадывать цены на нефть. Заложите худший сценарий и может быть частично угадаете, но всегда без конкретики.
А самое главное, человекочасы, скорость, с которой бизнес получает отдачу от айти, не изменилась. Вот и видим, что служебное сервисное подразделение вместо полезной деятельности занималось какой-то самоценной, пардон, фигнёй. Да ещё и на статьи об этом время тратють... Непорядок, робятки, с точки зрения гендира - явный непорядок.

Интересно, долго этот сферический в вакууме просуществовал? Долго ли придерживались сиих положений?
1c-intelligence; +1 Ответить 1
16. Александр Лапшин (zfilin) 1883 30.08.17 14:35 Сейчас в теме
(14)
1. Повышение управляемости стало очень заметно заказчику. Мы не вели "количество положительных отзывов" как исчисляемую метрику, но улучшение было видно "невооруженным взглядом".
После внедрения заказчики (руководители профильных департаментов, например) начали получать достаточно точную информацию о том, в какие сроки будет реализован тот или иной запрашиваемый функционал, против "ну, будет готово когда-нибудь, как будет готово".
Получив доступ к бэклогу и возможность присутствовать (по желанию) на митингах, стали понимать какая фича находится в разработке в данный момент, какая запланирована в эту итерацию, а какая отложена до следующей. Что в конечном итоге привело к пониманию, какие требования и задачи менять уже нельзя, а где еще можно сказать "я передумал, давайте тут поменяем, у вас оно все-равно на следующую итерацию запланированно".
Присутствуя на демо заказчики могли видеть получившийся результат и могли тут же внести в бэклог какие-то новые требования, корректировки на следующую итерацию. А не получали обратную связь уже от конечных пользователей, когда тех уже "достала эта тупая 1С".
То-есть разработка стала более понятной и прозрачной для заказчика и как следствие, заказчик получил возможность этот процесс _разумно_ "направлять" в русло интересов бизнеса, в конце-концов.
17. Александр Лапшин (zfilin) 1883 30.08.17 14:37 Сейчас в теме
(14) Про управляемость процесса внутри комманды писать не буду, сам Scrum достаточно хорошо и красиво описывает это. Митинги, ретроспектива, доска - все это иструменты упорядочивающие отношения внутри команды и во многих статьях про это и так уже сказано.
18. Александр Лапшин (zfilin) 1883 30.08.17 14:57 Сейчас в теме
(15) Я думаю, что вы противник agile-подходов, что нормально. Agile не серебрянная пуля и не обязан всем нравится.

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

Зубоскалить:
"долго этот сферический в вакууме просуществовал?" - вам же на самом деле не интересно долго или нет.

Додумывать за топикстартера:
"и никак - подчёркиваю, никак - не принесли пользы бизнесу" - это не так, почитайте (16).

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

Демонстрировать полное незнакомство с вопросом, типа "слышал звон":
"ни умения фрагментировать задачу и контролировать её решение, ни прозрачности для руководства" - это все, что вы опровергаете, заложено в 12 принципов agile и метолологии.
Без фрагментации невозможно планирование и нормальное ведение бэклогов. Для контроля есть дэйли-митинги, для прозрачности - демо. И еще много чего. Начните хотя бы с этого - http://agilerussia.ru/category/books/

Боюсь, нам с вами не по-пути.
19. Александр Лапшин (zfilin) 1883 30.08.17 14:59 Сейчас в теме
(14) 2. Да, это изначально было основной целью. Скорость все-таки была на втором месте.
20. Денис Краснов (Neco) 70 31.08.17 14:12 Сейчас в теме
Во всех этих играх с Agile важно, чтобы ваш заказчик знал, понимал и участвовал в процессах планирования и демо. Нужно объяснить сотрудникам заказчика, что задачи выполняются по приоритету, приоритет вот это бэклог и что надо, как-то в него заглядывать а не строчить гневные письма типа когда вы это сделаете.
21. Евгений Парфенов (deminded) 5 31.08.17 17:43 Сейчас в теме
Очень похоже на нашу историю, но у нас еще куча нерешенных проблем =) Есть и отличия:
Дежурный у нас меняется ежедневно;
Продукт один, эпиков много и они относятся к разным бизнеса;
Для оценки в "Попугаях" решили ввести список эталонных задач;
Вместо инженерного дня у нас под технологические задачи выделено отдельное количество SP в спринте;
Мы зависли в переходе от оценок Tasks к User Story, но уже понимаем, что надо когда берем в спринт User Story делить ее на кучу Tasks, одна из которых будет документация...
22. Яков Коган (Yashazz) 2119 31.08.17 20:24 Сейчас в теме
(18)
вам же на самом деле не интересно долго или нет
Эдак Вы лихо решаете за других, что кому интересно и что кому нет. За своих клиентов так же уверенно решаете?) Если я спросил, значит, интересно. Я статистику провалов веду - ну, если кто вообще признаётся. Обычно это выдыхается и вырождается в пределах года. Что, хватит духу сказать, сколько прожил более-менее полно внедрённый подход? Или увильнёте?

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

"самое главное, человекочасы, скорость, с которой бизнес получает отдачу от айти, не изменилась" - очевидно, что скорость создания никому ненужного функционала никому не принесет пользы. Вопрос не в том "как быстро", а "делаем ли мы то, что нужно".
Стоп-стоп-стоп. Вы ж сами сказали, что скорость не выросла. Не путайте тёплое с мягким. Если Вы под "то, что нужно" подразумеваете внутренний самоконтроль группы разработчиков, то это вопрос даже не управления проектом, а чёткости поставленной задачи (ТЗ) и профессионализма исполнителей.

"ни умения фрагментировать задачу и контролировать её решение, ни прозрачности для руководства" - это все, что вы опровергаете, заложено в 12 принципов agile и метолологии.
В теории - может быть. На практике, повторюсь, сперва пафос, а после пшик и проблемы. Я говорю от чистой практики.

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

Я тут Вам немножко изобразил реакцию прагматика на всякие заумные изыски, притом, что нужда в решении заявленных вопросов безусловно есть. А Вы грубите. В общем, нашей группе компаний эту методологию в своём изложении Вы, увы, не продали)))
23. Яков Коган (Yashazz) 2119 31.08.17 22:14 Сейчас в теме
(20) Заказчик не будет никуда заглядывать. Вы можете предоставить сотни удобнейших бэклогов, равно как и любых иных средств мониторинга процесса. Заказчик, а особенно внутреннее руководство, хочет простых вещей, чтоб всё и побыстрее. И если заказчик вдруг узнаёт, что вместо экстенсивного роста скорости выполнения работ исполнители заняты какой-то малопонятной внутренней интенсификацией с каким-то эйджилом, то единственная реакция, нормальная бизнесовая реакция, такова: "вам что там, делать нехрен?". А сотрудники заказчика будут в меру своей скандальности орать, что всё просрочено, ничего не работает итд.

Как вы не поймёте, что тут вообще главное другое. Что никому, кроме вас самих и вашей группы разрабов, не интересно всё это и бесполезно. Что эмоциональный неадекват истеричных заказчиков, которые в сети ужастиков начитались, визита ФНС испужались, чё-то где-то слышали от знакомых итд, никак не коррелирует с вашей "прозрачностью и управляемостью", и единственное, чем его можно перекрыть - силовой административной поддержкой либо сверхбыстрым выполнением ВСЕХ задач СРАЗУ. И в том, и в другом случае всё вышеопубликованное в лучшем случае страдание фигнёй. В худшем - нецелевая трата времени и сил. Году, помнится. в 2002-м одного такого при мне вышибли с его группой коллег, с треском. Из достаточно крупной телекоммуникационной конторы. Потому как он на вопросы главбуха про какие-то спринты рассказывал, а "у него крыжики и краснота". Будьте реалистами, коллеги.
24. Александр alex_2h2008 (alex_sh2008) 5 01.09.17 09:09 Сейчас в теме
(23)
Будьте реалистами, коллеги.

Agile и создали реалисты. Нужно просто правильно применять эти методики в реальной жизни. Насколько я понял сейчас эта фишка среди 1С стала очень популярна, при это люди толком не понимают, а что же это такое на самом деле, вот и вылезают проблемы о которых вы говорите. На самом деле именно Agile и помогает работать с не адекватными заказчиками, главное что бы команда которая для себя выбрала именно эту методику должна точно оценивать риски. Одна команда не сможет одновременно и писать продукт и поддерживать его, проект развалится очень быстро.
25. Александр Лапшин (zfilin) 1883 01.09.17 10:48 Сейчас в теме
(22) Если вам нужны ответы на вопросы, приходите в личку. Расскажу все что знаю. Кстати, у меня к вам тоже есть несколько вопросов.
Но я думаю, что вы скажете что-то типа "а что нельзя ответить мне в комментариях?" и в личке я вас не дождусь, потому что вы тролль и вам не важно получить информацию и новые знания, а важно публично провоцировать участников обсуждения.
26. Яков Коган (Yashazz) 2119 01.09.17 15:11 Сейчас в теме
В личку пришёл. Если хотите слегка пооффтопить прямо тут - с 03.09.17 буду к вашим услугам.

потому что вы тролль
Знаете, очень забавно выглядит, когда абсолютно (подчёркиваю, абсолютно) все виденные/читанные мной проповедники подобных систем, будучи предметно спрошены о конкретном выхлопе, впадают в тот или иной неадекват и пытаются прекратить общение.
Я вот вас спрашиваю: что получил бизнес, кроме прозрачности? Вы стали успевать втиснуть критическую задачу между плановыми так, чтобы их сроки не сдвинулись? Вы распределили ресурсы так, что разработчики перестали трудиться сверхурочно при факапах?
27. Яков Коган (Yashazz) 2119 01.09.17 15:21 Сейчас в теме
А самое главное, что никакие обвинения в троллинге не способны опровергнуть зримый и ощутимый опыт. Опыт стабильного провала всех этих эйджил-заумей. Когда руководители проектов и отделов доводили всё до полнейшего трындеца и, извините, мне сотоварищи приходилось своим горбом вытаскивать проекты. Когда приходилось при всей этой красотени лично вправлять мозги заказчикам и терпеть их матюки. Когда отбирали премию именно потому, что мы "вместо работы всякие хрени сами себе внедряем". Когда, наконец, 1С триумфально внедряет Agile и качество платформы, начиная с 8.3.7, падает ниже плинтуса, каждый релизит своё, багтрекер живёт своей жизнью, ранее исправленное всплывает опять, и с подблоками внутри платформы бардак полнейший.
Опыт, он штука такая. Факт есть факт.
28. Александр Лапшин (zfilin) 1883 01.09.17 16:34 Сейчас в теме
29. Александр Лапшин (zfilin) 1883 01.09.17 16:34 Сейчас в теме
30. Геннадий Николаев (genayo) 01.09.17 17:26 Сейчас в теме
(29) Жаль, что в личку. Работа с возражениями - очень интересный навык :)
31. Александр Лапшин (zfilin) 1883 01.09.17 21:45 Сейчас в теме
(30) Если в личной переписке станет понятно, что я ошибся и уважаемый Яков Коган не тролль или, возможно, у нас в беседе будут важные мысли в тему публикации, то мы обязательно вернемся в комментарии. До тех пор треду лучше обойтись без наших препирательств.
32. Яков Коган (Yashazz) 2119 04.09.17 01:12 Сейчас в теме
Заметьте, я высказался по публикации, а автор - по моей персоне. Разницу ощущаете?)
33. Александр alex_2h2008 (alex_sh2008) 5 14.09.17 09:29 Сейчас в теме
(32)Ну и чем все закончилось, мировая или ошибки ни кто не хочет признавать?
34. Яков Коган (Yashazz) 2119 17.09.17 13:49 Сейчас в теме
(33) Довольно конструктивно пообщались в личке, пришли к выводу, что "стороны опубликуют совместное коммюнике", на этом всё и зависло. Работа не волк, работа "ворк". И я замотался, и Александр, видимо, тоже.
36. Александр Лапшин (zfilin) 1883 20.09.17 15:12 Сейчас в теме
(33) (34) Так и есть. Насыпало работы и разъездов.
При первой же возможности итоги опубликуем.
Оставьте свое сообщение