Этой записью хочу начать цикл материалов об организации работы IT отдела в непрофильной компании.
В Беларуси (а в России тем более) уже давно многие компании вместо услуг внешних подрядчиков формируют свои IT отделы для разработки и обслуживания своих информационных систем. Часто такие системы бывают достаточно сложными и содержат много информации, которую не хотелось бы выносить за пределы компании.
Сегодня хочу рассказать о том, почему в таких отделах не работает планирование спринта как того рекомендует методология SCRUM и как с этим жить.
Согласно классическим понятиям и теории из того же SCRUM Giude, спринт — единица планирования времени разработчиков со своими целями и жёстко зафиксированным составом работ. Это подразумевает что с того момента, когда спринт спланирован, и до момента окончания спринта состав задач меняться не может. Что же на практике? Если бы отдел внутри непрофильной компании занимался только разработкой новых модулей — так бы всё и происходило. Но чаще всего на этом же отделе лежит бремя поддержки и консультирования пользователей а так же «тушение пожаров» — закрытие срочных горящих задач, которые возникают внезапно и требуют немедленного вмешательства.
И вот получается ситуация: спринт спланирован, разработчики занялись разработкой, и вдруг прилетает такое вот горящее задание. На лицо дилемма:
1. Не будут достигнуты цели спринта если взяться за горящую задачу
2. Компания может понести некоторого рода убытки (материальные, временнЫе и т.д.) если задачу не закрыть.
В нашем отделе данная проблема решается через перепланирование. Это несомненно спорный метод, потому что с точки зрения методологии SCRUM перепланирование спринта вообще не допустимо. Но всё же такое явление тоже иногда имеет место. Почему? Иногда возникают ситуации, по времени выходящие за все заглушки и планируемые пожары, но всё ещё требующие оперативного вмешательства. Понимая ценность отдыха сотрудников, мы категорически не приветствуем переработки и работу сверх рабочего дня. Поэтому приходится жертвовать низкоприоритетными запланированными задачами в угоду критически важным. Как выходить из такой ситуации при планировании спринта? На такой случай в план спринта добавляется несколько задач с самым низким приоритетом, которыми можно легко пожертвовать. К таким задачам относятся задачи доработки интерфейса или рефакторинг уже работающего кода. Такой подход помогает избежать «синдрома студента» когда разработчик будет пытаться отложить выполнение задачи на последний момент.
В любом случае, при появлении необходимости перепланирования спринта, всегда надо понимать, что важнее для бизнеса — непрерывное функционирование процессов или небольшое отступление от методологии разработки? Согласно миссии нашего отдела, важнее всё-таки процессы бизнеса.
На этом всё.
В следующий раз расскажу про формирование миссии отдела и зачем вообще существуют регламенты.
Добавить комментарий