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

0. Александр Лапшин (zfilin) 1816 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) 336 27.02.15 11:12 Сейчас в теме
Видимо меня заминусуют, но я не вижу реальных плюсов от новой схемы. Трекер + приоритеты решали бы все описанные проблемы на ура, а так удлинили цикл разработки и увеличили время на планирование и сопутствующие вещи, что в итоге выльется в падение производительности людей, которые будут отвлечены от работы занесением дополнительных аналитик в новую систему.
Вопрос саппорта решается выделением времени сотрудников на этот самый саппорт с ведением длинных тикетов, которые имеют шанс перейти на другого сотрудника, в трекере.
Вопрос взаимовлияния разработки решается либо наличием архитектора системы, либо документированием аналитиками.
Так к чему же эта работа ради самой работы?
ПС: это не попытка наехать на автора, скорее вопрос, обусловленный личным негативным опытом, когда внедрением подобной схемы закончилось развалом команды (из 12 работников отдела ИТ 10 покинули компанию, при этом ни одна из заявленных новым РП целей не была выполнена в срок, что было объяснено старыми кадрами, но даже набор новых не дал результатов, все как в анекдоте про 3 конверта)
ivv1970; olgerd666; +2 Ответить
3. Сергей Иванов (1Service2) 12.05.16 12:08 Сейчас в теме
Оставьте свое сообщение