Поскольку пост не короткий и даже неуместные картинки не облегчают его чтение, давайте сначала определим целевую аудиторию.
- Вы разработчик программного обеспечения, руководитель группы разработчиков, менеджер проекта или эквивалентный сотрудник.
- Над проектом работает более одного программиста, желательно больше трех.
- Вы попробовали все эти Scrums и Agiles, почувствовали их прелесть, но есть определенные претензии к догматическому следованию методологии.
Возможно, настройкой процессов вообще никто не занимается и задачи просто «подбрасываются».
- Команда устала (от проекта, от стресса,.
) и скоро всем придется столкнуться с кнутом и пряником.
Внутри команды воссоздается небольшая экономическая модель рыночных отношений, а приоритеты регулируются с помощью внутрикомандного курса валюты.
.
Преамбула
Мир ИТ изобрел множество подходов к построению процесса разработки программного обеспечения, заимствовав лучшие идеи у своих допостиндустриальных коллег.На определенном этапе профессионального развития мы столкнулись с проблемами мотивации, управления качеством и визуализации работы для команды и заказчика.
Взяв лучшее из всего лучшего, что было до нас, мы организовали работу над некрупными проектами в виде старбана.
Историческая справка
Наш долгий путь по вселенной разработки коммерческого программного обеспечения познакомил нас с множеством подходов к управлению проектами.Мы видели водопады и работали вдоль них.
РУП , попробовал применить основные понятия MSF , а вот гибкие методологии оставили самые теплые воспоминания.
В рамках одного проекта, который длился 2 года, мы перешли от scrum к kanban, разделили и объединили команды и подогнули их под свои нужды.
Из Scrum мы взяли методы командного общения и оценки задач в безразмерных (условных) единицах.
Итеративный характер процесса не менее важен, но его можно корректировать.
Также в Scrum отлично детализируется визуализация текущей работы (тактическое планирование).
Канбан хорошо владеет теорией ограничений, гибкостью их адаптации к изменениям внутри команды и визуализацией текущей работы на стратегической карте.
Полностью разделить эти две методологии сложно, поскольку они редко встречаются в своем каноническом воплощении.
Многие программисты, например, испытывают затруднения с оценкой задач в Story Points, поэтому часто создают таблицы для перевода человеко-часов в Story Points или сразу дают оценку в часах.
Вместо этого мы решили оценивать задачи по их текущей ценности для проекта и назвали эту ценность звездами.
Так появилось название Старбан.
Когда необходим STARban?
- Есть проект с не всегда готовым и понятным техническим заданием, которое необходимо представить в осязаемой и оценочной форме.
- Размер проекта достаточен, чтобы у команды не было времени отслеживать изменения в проекте, вносимые другими участниками, и текущий статус проекта.
- Проблемы коллективной ответственности (Зачем мне это делать? Я оставлю такой комментарий, может тестер не найдет? Опять кто-то сбросил билд, пойду обедать.
Это не баг.
)
- Снижение мотивации со временем из-за перехода проекта в статус поддержки или из-за переквалификации.
(слишком хорош, чтобы работать, слишком уродлив, чтобы заниматься проституцией).
Ок, у нас есть проект с участием 5-15 человек, с необходимостью подтянуть стратегическое планирование и несколькими уставшими программистами, воспринимающими любую задачу как рутинную работу.
Остальные воспринимают любую задачу как бремя и ставят своей целью формальное выполнение задач с минимальными усилиями.
Что необходимо, что называется, подчеркивается.
Прежде всего, следует отметить, что старбан — это не полноценная методология разработки программного обеспечения, а набор расширений, позволяющих повысить производительность и не дать проекту погрузиться в кризис.
Уставший разработчик может покинуть проект и забрать его с собой.
уникальные недокументированные знания .
Менеджер может предложить более выгодное предложение, и тогда разобраться в текущем состоянии проекта может оказаться весьма проблематично.
Отдел тестирования закроет задачу и проведет приемочное тестирование таким образом, чтобы все пользователи продукта прочитали инструкции полностью и поклялись своей кошачьей могилой никогда их не нарушать.
Отдел разработки спорит с отделом тестирования, перекладывая ответственность на аналитиков и проводя масштабные встречи, где можно по 2 часа слушать, 1 час составлять протоколы совещаний и по результатам назначать следующую встречу с акционер рассказать ему все еще раз.
Кнут и пряник редко бывают сбалансированы, поскольку каждому члену команды требуется индивидуальное сочетание этих компонентов.
Итак, рассмотрим по порядку дополнительные правила, соблюдение которых принесло нам спокойствие и неизгладимую пользу проекту.
Принцы разработки STARban
Разделение на команды
Даже если в команде всего 4-5 разработчиков, есть смысл разделить их на 2 команды, так как более 3 человек вряд ли смогут одновременно разрабатывать одну фичу (пользовательскую историю).Чаще всего над фичей задействованы 1-2 человека; третий человек может в это время готовиться к разработке следующего функционала.
Если усреднить, то наш опыт почему-то всегда показывал, что идеальные команды всегда состоят из трех человек.
Возможно, это субъективный смысл, но наши коллеги тоже часто приходили к такому же выводу.
Быть универсальной автономной единицей сложно и плохо из-за отсутствия внешнего контроля за принимаемыми решениями, а более крупная команда может заблокировать себя.
Кроме того, каждый член команды должен знать, что делают другие.
Использование доски для визуализации прогресса проекта и команды
Совет должен выполнять следующие функции:- Покажите наиболее полную дорожную карту проекта.
Команда будет видеть, куда движется продукт, и использовать это во время разработки, чтобы применять наиболее оптимальные решения со стратегической точки зрения.
Владелец продукта может корректировать приоритеты по той же схеме и при этом понимать, что дополнительные срочные задачи повлияют на сроки других.
- Проиллюстрируйте набор неотложных задач разработки.
Это дает стимул для выполнения текущих задач.
Задачи разработки должны быть оценены в ИП.
- Отображение статуса текущего выполнения задач командами.
Это позволит членам команды координировать свои действия, информировать других членов команды о проблеме и видеть мгновенный статус.
На основе динамики этих данных менеджер может увидеть проблему и вмешаться в ее решение.
- Готовые задачи можно разделить на версии при выходе следующего релиза, что позволит ориентироваться в функционале конкретного релиза продукта.
Доска является важной частью оптимизации процесса и должна быть максимально информативной.
Самый левый столбец — это дорожная карта проекта, отсортированная по приоритету задач.
Он также должен содержать глобальные технические задачи по поддержанию и модернизации инфраструктуры развития.
В нем также может содержаться срочная просьба исправить функциональность, но оно должно подчиняться тем же правилам, что и другие карты.
Мы приняли для себя два правила: карточки в этом столбце разделены по цветам и для каждой карточки указан ее числовой приоритет, что поможет при сортировке в системе управления проектами.
Эту графу следует заполнить максимально подробно, чтобы все участники могли видеть ожидаемый результат разработки и учитывать будущие потребности при выполнении текущих задач.
Очередность выполнения задачи может быть изменена исключительно заинтересованной стороной (заказчиком, его представителем, владельцем разрабатываемого программного обеспечения).
При изменении приоритета он может сразу оценить потери — какие функции высвободятся в результате его изменений.
Следующий столбец — бэклог продукта — содержит задачи по изменению функционала, багам и техническим задачам, формализованным в виде пользовательских историй.
Детали здесь могут различаться, как и типы задач.
Например, слияние ветвей в системе контроля версий может быть связано с пользовательской историей, но это также может быть отдельная карточка, оцениваемая в зависимости от контекста.
Приоритет в этом столбце больше не играет роли, а порядок получения задач должен настраивать менеджер с помощью «звездного рейтинга».
О звездах мы поговорим позже, а пока просто стоит знать, что командам выгоднее брать побольше звездных карт для своего развития.
Вы можете установить ограничение на количество карт в нем одновременно в этом столбце, чтобы избежать спекуляций.
Мы опробовали правило кошачьих туалетов, где количество карточек должно быть на одну больше, чем количество мини-команд, участвующих в разработке (количество туалетов, если у вас дома несколько кошек, также должно быть на одну больше, чем их количество).
).
Если в этом столбце недостаточно задач, следует провести предварительное планирование.
В предварительном планировании участвуют представители каждой команды, менеджер и при необходимости представитель заказчика.
Разработчики делятся оценками сложности выполнения задачи, а заказчик или менеджер оценивает ее актуальность для проекта.
При этом окончательный звездный рейтинг выставляется менеджером исходя из текущих приоритетов и ситуации на проекте.
Задачи также могут добавляться и оцениваться менеджером индивидуально, но делать это следует только при критических ошибках.
Также не стоит забывать о цветовом кодировании в этом столбце — это позволит вам, беглым взглядом на плату, понять, стоит ли ожидать выхода новых функций в ближайшем будущем, стабилизации продукта или же команда возиться с инфраструктурой развития.
Хорошо, предположим, что все умеют декомпозировать и оценивать проблемы, и цвета выбраны подходящие для дальтоников.
Следующие четыре столбца разделены по горизонтали.
Каждая команда владеет своим участком доски и ведет на нем записи.
Когда команде нужно взять для разработки очередную карточку из бэклога продукта, она осуществляет планирование — декомпозирует задачу на задачи, выясняет детали реализации и оценивает время реализации.
Задание принимается в работу – и все карты кладутся сюда.
Декомпозиция должна быть достаточно подробной, чтобы обеспечить соблюдение правила одного человека на задачу.
Иерархическая нумерация .
или разделение цвета по функциям также работает хорошо.
Как удержать команду от ненужных задач, для которых нет свободных рук? Необходимо ли это делать? Должно ли быть ограничение на количество карт? Скорее, его нужно регулировать методом звездного рынка, о чем речь пойдет позже, но если возникнут проблемы, то ограничения Голдратта можно будет ввести без проблем.
Для задач из графы «в работе» можно использовать значки — это дополнительные пометки к карточкам, заметные издалека.
Наклейки с жирными символами подойдут. Примеры: "!" — задача выполняется дольше, чем по первоначальной оценке; "?" — есть вопрос по заданию, требующему встречи с другими командами.
Вам следует как можно чаще обновлять эту часть доски и следить за значками по заданиям.
Когда действия по задаче завершены, она перемещается в столбец «Проверка».
Команда тестирования видит, что все задачи по одноцветной функции перешли на проверку, и начинает тестирование.
Ошибки на доске можно отобразить с помощью наклеек на карточках или просто добавив значок.
Когда тестирование завершено и ошибок нет, задачи перемещаются в графу «выполнено».
Здесь их можно снова сгруппировать в объект, обычно просто склеивая карты лесенкой.
Некоторые значки, например, о просроченном сроке, здесь еще могут пригодиться.
Периодически в рамках процесса приемки команда устраивает демонстрацию задач, попавших в эту колонку, для владельца продукта или ответственного аналитика.
Принятые задачи в детализации графы «Отдел продукта» перемещаются в графу «Принято».
Столбец «Принято».
Если в системе много ошибок (а мы говорим о долгосрочных проектах, поэтому ошибок в трекере будет много) и нет смысла оценивать каждую, в этом столбце фиксируется текущий рейтинг рейтинга.
на ошибки в звездах, общие для всех команд. Например, четверть звезды за один баг или звезда за каждый баг.
Желательно не менять это число в пределах одного релиза, поэтому постарайтесь заранее подобрать баланс между новым функционалом и стабилизацией продукта.
Стоит отметить, что в этой колонке упоминаются только ошибки, пришедшие из бэклога, а не те, которые были созданы в ходе тестирования функций, реализованных командой.
Но везде есть исключения.
При выходе очередного релиза продукта все карточки из «принято» переносятся в общий для всех команд столбец «принято» и отмечаются номером следующей версии.
Самый простой способ визуализировать это — сортировать по номеру версии, цветовому кодированию по номеру версии или группировать в столбце.
Одна последняя вещь.
Конвейер бывает с зонами ожидания или без них.
Вы можете обнаружить, что новые задачи невозможно передать в тестирование из-за ограничений, но они уже готовы.
Такая ситуация может возникнуть по разным причинам.
Если команда не хочет исправлять ошибки своей фичи во время тестирования, то это проблемы команды, и ей нельзя давать возможность передавать новые задачи на тестирование до закрытия старых.
Если отдел тестирования не справляется с потоком задач или плохо распределил приоритеты, то за тестирование фичи можно назначить дополнительную цену в звездах — и тогда одна из команд может взять эту фичу на тестирование.
Этот подход также поможет обмениваться знаниями между командами.
?Экспоненциальная шкала времени
Это также можно перефразировать как «одна доска для всего».Бывает, что доска с Product Roadmap используется совместно со Scrum-доской, а распределение фич по релизам вообще не визуализируется.
В этом есть свои преимущества, например, дорожную карту можно проиллюстрировать как настоящую карту, показывая зависимость элементов вместо не всегда очевидных числовых приоритетов или плоского списка.
ОК, никто вас не ограничивает в пространстве (точнее, никто вас не ограничивает в пространстве-времени)! 
Магнитной маркерной доски площадью 2-3 квадратных метра достаточно, чтобы сделать двухмерную модель большого проекта со всеми необходимыми колоннами и еще оставить место для декора.
Если вы используете электронную версию с масштабированием, то ничто не мешает вам детализировать задачи до необходимой степени.
С точки зрения временной шкалы доска будет выглядеть так: «месяцы -> недели -> дни -> месяцы».
Рейтинг задач в звездах
Как оценивать задачи – в часах или в стори-пойнтах? Существует множество попыток определения сюжетной точки и методов оценки в безразмерных величинах (слоны, попугаи).Большинство из них приводят к концепции сложности и, в конечном итоге, к внутренней (а иногда и официально утвержденной письменной) конструкции таблицы соответствия SP -> часы.
Гуляя между проектами, вы можете сначала увидеть оценку из расчета 1 SP == 8 часов работы команды, а затем, в следующем кабинете, увидеть 20 SP == 8 часов работы на 1 человека.
Иногда зависимость нелинейная.
И никогда с первого раза не понимаешь, в чем заключается эта сюжетная точка.
Все, как говорится в книгах, в сравнении.
Было бы с чем сравнить.
«Звездная точка» или просто «звезда» — безразмерная величина для оценки задач в проекте исходя из их текущей значимости для проекта.
Можно провести аналогию с деньгами.
В звездах работает команда разработчиков, которая постоянно работает по договорной ставке.
Менеджер предлагает новую задачу — необходимо добавить в продукт версионирование и сделать назначение версий полуавтоматическим при сборке на билд-сервере.
Предлагает цену 10 звезд. Программисты оценивают задачу и понимают, что легче исправить 10 ошибок, каждая из которых сейчас оценивается в 1 звезду.
Поскольку указание версии срочно требуется службе поддержки для нужд исправления ошибок, данный функционал имеет более высокий приоритет, чем стабилизация продукта, поэтому менеджер устанавливает цену в 20 звезд и первый попавшийся разработчик спешно берет эту задачу себе или свою команду, чтобы заработать сразу 20 звезд. Через некоторое время руководитель проекта понимает, что разработчики атаковали большие задачи, а в службу поддержки стало поступать множество жалоб на мелкие ошибки при работе с приложением.
Это могут быть опечатки, отсутствие сортировки в списочных формах и множество подобных мелких, но неприятных недостатков.
Поскольку торг по отдельным ошибкам обходится слишком дорого, менеджер принимает решение и объявляет команде, что со вторника и до конца недели любая закрытая ошибка будет оцениваться в тройном размере.
В этом случае вам не придется давать прямые указания, а команда разработчиков сама изменит вектор развития, чтобы не упустить шанс заработать дополнительные звезды.
Может показаться, что у программистов нет мотивации решать важные или сложные задачи, но это не так.
Рынок
Когда очередная карта принимается менеджером, ее стоимость в звездах переводится на счет разработчика или команды, которая занималась внедрением.Прелесть звезд в том, что их можно не только копить, но и тратить.
Здесь есть проблема, называемая экономикой, а из нее вытекает несколько других проблем — инфляция, рынки, спекуляция.
Это и хорошо, и плохо одновременно.
И, к сожалению или к счастью, именно здесь похоронен величайший друг человека.
Руководитель проекта должен запустить рыночные отношения между сотрудниками, работающими над проектом, и регулировать систему не авторитарными указаниями, а невидимой рукой.
На что можно потратить звезды? Все зависит от проекта и компании; нематериальная мотивация варьируется.
Не обязательно на каждые пять тысяч звезд учитывать отгулы, Xbox One, спортзал и прогулки на яхте – ведь ваша компания предоставляет это своим сотрудникам без каких-либо условий.
Внутри проекта есть много другой рутины, которая может быть товаром.
Не все задачи интересны, а интересные могут быть не столь актуальны и поэтому иметь низкий приоритет. Две команды могут столкнуться с одной и той же проблемой.
На это задание можно устроить торги и право взять его на себя имеет тот, кто даст больше звезд. Команда перегружена фич-багами, но вы хотите взять на себя какую-то задачу, которая не укладывается в ограничения рубрики? Пусть он продаст ошибки этой функции другой команде! И они договорятся о цене.
Или пусть купят дополнительное место в колонке на неделю.
Но если они опоздают вовремя, их оштрафуют на звездный эквивалент, чтобы на следующий месяц им достались только самые неприятные задания (их подкупят другие команды).
Некоторым людям не нравится слияние, а другим не нравится писать тесты.
За отсутствие тестов нового функционала предусмотрен штраф, но можно найти того, кто напишет эти тесты за половину стоимости штрафа.
Подойдет и пример с загруженностью команды тестировщиков и самотестированием задач.
Задача менеджера здесь – сохранить баланс звезд, не обесценивая их и прозрачно указывая приоритеты, манипулируя рынком.
Необходимо установить определенные правила, например, скорость обмена багов на звезды, но при этом проявлять постоянную гибкость и поддерживать инициативы команды.
Если кто-то решит продать свою очередь на мытье кофемашины – почему бы и нет! Комиссия за сделки со звездами? Может. Но желательно сохранить желание получать больше звезд, потому что иначе ничего не получится.
Если этот пункт еще вызывает затруднения, то настольная игра от Мосигры и Хабрахабра» Запускать » может дать хорошую пищу для размышлений и еще раз порадовать ваших коллег, уставших от Xbox One и плавания на яхтах.
Технические задачи важны
Да.Вам просто нужно это помнить.
Обновление версий используемых библиотек, ревизий, конфигурации КИ И CD , параметр система контроля версий , поддержка Team-Wiki, модификация трекера задач.
Эти задачи необходимо учитывать в общем объёме работ, они должны иметь свой приоритет и стоимость в звёздах.
Команда приобретет навыки DevOps , и проект немного сэкономит.
Постамбула
Мы попробовали Scrum, но нам он не понравился.
И все равно у нас все работает
А тимлид не хочет ничего менять
Менеджер сказал перестать играть в игрушки и писать код
У нас слишком мало программистов, зачем это вообще нужно?
Но там не сказано, что делать, если.
.программисты не захотят зарабатывать звезды
.мы постоянно сталкиваемся со срочным исправлением ошибок в производстве
.мы неправильно оцениваем задачи, стоит ли вообще тратить на это время?
.все горит, а ограничения не позволяют ничего исправить
.у нас нет доски
.Мигалкин хомячит всех звезд и не хочет их отдавать
Ах, да.
Разработка программного обеспечения — это область, где скептицизм является необходимым качеством для выживания как специалиста, так и проекта.
Ну а старбан предназначен скорее для тех, кто испытал горечь разочарования в каноническом Agile, но также знает о существовании особого места в аду, где ты продолжаешь работать программистом, один над проектом, с менеджером, имеющим Еще 4 подобных проекта.
И у вас может быть еще один.
Или на одном проекте у вас одна команда, а на другом совсем другая, частично укомплектованная заказчиком.
Короче говоря, лучше бы тебе в этой жизни вести себя прилично.
Гибкие методологии разработки создавались для решения определенных задач — защиты разработчиков от заказчика, обеспечения конвейерной обработки задач, адаптивности к меняющимся требованиям.
Есть полезные практики, которые полезно использовать всегда, независимо от конкретной методологии.
Старбан постарался объединить их, чтобы сделать развитие проекта комфортным и интересным для всех участников процесса.
В то же время он остается адаптивным к различным условиям.
Бывает, что на проекте всего пара разработчиков, но и для них можно организовать звездное соревнование, заменив командное соревнование личным.
Доска может адаптироваться к реалиям постановки задач и возможности формализации в проекте.
Никто даже не удосуживается привязать старбан к конкретному проекту — если задачи можно представить в рамках единого бэклога (что часто случается в ИТ-отделах компаний-производителей) и разместить на одной доске, то проект — это всего лишь условный делитель.
И в конечном итоге каждый получит тот процесс разработки программного обеспечения, которого он заслуживает. Теги: #разработка на основе #требований #scrum #agile-менеджмент #agile #геймификация #agile
-
Важность Компьютерных Обоев
19 Oct, 24 -
Волна Хабр Ммм
19 Oct, 24 -
Сброс Стилей С Помощью Css Reset
19 Oct, 24 -
Сайт Законопроекта Об Образовании
19 Oct, 24
