А вот кому backlog в Excel! :о)

by on 12:32 pm in Инструменты

Рано или поздно приходит мысль, что пора перейти от стопки бумажных карточек к цивилизованному бэклогу в Excel или Calc. Переходим. Получаем автофильтры, суммирование эстимейшнов и всякие другие вкусные и полезные вещи.Но! Теряются сами карточки, исчезает физический объект торговли. При общении с некоторыми заказчиками это может быть фатально :о)А вот этот эксельный бэклог позволяет вести  бэклог в Excel, но одним кликом печатать бумажные карточки. При необходимости его можно легко подсоединить к Windows SharePoint Services и поиметь еще и веб-интерфейс. Чувствуете мощь?  :о)

Tags: ,

Post Author

This post was written by who has written 29 posts on Agile.by.

  • idispatch

    цивилизованному бэклог? в Excel? это не Agile.
    для этой задачи есть свой софт.

  • Денис Петелин

    Для всего на свете есть свой инструмент.
    Однако не всегда стоит забивать гвозди паровым молотом.

    Ровно так же далеко не всегда под задачу нужно покупать спецсофт.
    Зачастую – достаточно бэклога в эксель.
    Еще чаще – листочков на доске.

    Но софт – есть. Однако использование или неиспользование этого софта – не позволяет классифицировать проект как agile или не agile.

  • firefalcon

    вообще использовать Excel смысла нет. Или карточки на доске или тул типа XPlanner или TargetProcess. Excel не дает никаких преимуществ. Он обладает всеми минусами софтверных тулов, но не обладает плюсами этих тулов (не дает шарить бэклог онлайн например).

  • Денис Петелин

    Вообще использовать эксель смысл есть.
    Вот например три killer features которые делают эксель мега-инструментом для бэклога.
    1. SUM().
    Когда надо просчитать, какого размера эффорт уже наэстимирован для проекта в пять человек работающих двухнедельными спринтами над stories размеров в 1,5-2 часа, то с карточками можно повеситься. С экселем – вопрос решается одной кнопкой.
    2. Filter -> AutoFilter.
    Как определить, какие фичи будут реализованы в текущем билде? Как определить, какие stories были реализованы в 1.1.67? Элементарно! Заводим поле Target Build, потом выполняем по нему фильтрацию – вуаля!
    3. Sort -> Smallest to Largest.
    Заказчик написал приоритеты. Теперь надо определить порядок исполнения. Выполняем сортировку – вуаля. “А если мы сделаем вот так: …” говорит Заказчик и переставляет приоритеты. Да пожалуйста – отвечаем мы и пересортировываем список.

    И шарить в онлайн бэклог в экселе – одно сплошное удовольствие. Для этого надо поставить себе на сервер (кстати забесплатно) или купить за $25 хостед эккаунт (или даже получить бесплатно: http://enroll.freesharepoint.com/uddi/freesharepoint/) с Windows SharePoint Services. Я например пользовался всякими планнерскими тулами, но нигде не видел представления удобнее DataSheet в SharePoint.
    И он легким движением руки цепляется к экселю: http://office.microsoft.com/en-us/sharepointtechnology/HA011608621033.aspx

  • firefalcon

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

  • Денис Петелин

    Пользоваться надо строго тем тулом, который подходит под задачу, команду, проект и Заказчика. Это могут быть стики ноутс, эксель или лысый чОрт.

    Это может быть специализированный тул.
    А может и не быть.

    Может быть эксель.
    А может и не быть.

    В каждом конкретном случае рекомендуется думать головой. Во многих случаях голова подскажет что стики ноутс или эксель -это то, что надо.

    Но при желании можно и тул купить. Однако покупка тула – совершенно необязательно действие. Более того – во многих случаях вредное.

  • firefalcon

    ну тут собственно не поспоришь :)

    >>Во многих случаях голова подскажет что стики ноутс или эксель -это то, что надо.

    Инициатива по внедрению какого-либо инструмента может исходить как снизу, так и сверху. В случае ПМ тула обычно сверху. Но решать должна вся команда, включая скрам мастера, включая продукт оунера, включая всех заинтересованных лиц. Если продукт оунер аргументированно не любит эксель, надо к этому прислушиваться и решать проблему. Если все довольны тем, что есть, – то все супер, не надо ничего искать.

  • Денис Петелин

    Все верно.

    Еще бы я бы осторожно занимался внедрением сверху – очень много нюансов.

    Лучше сделать так, чтобы команда сама выбрала тул.
    Ну то есть в какой-то момент времени незаметно все решили, что нужен тул, и через некоторое время он появился…
    А затем был узаконен менеджером. Но вообще про выбор тулов – это тема отдельной статьи :)

  • Валера Совпель

    + 1 голос в пользу Excel как тула для sprint planning and tracking. Кроме SUM, Sort и Filter, о чем очень верно написал Денис, не так уж сложно добавить burn-down chart, который, считаю, является мощным мотивирующим фактором для команды.
    Конечно, it depends (опять-таки, Денис верно заметил). На одном проекте мы даже использовали Excel для ведения sprint backlogs 3 команд (тогда на проекте было около 20 человек). Там всё сошлось. Заказчик был “за” и был вовлечен как product owner, scrum master и рядовой team member (distributed teams). Проект не предполагал долгосрочного планирования. Наоборот, курс мог резко поменяться после каждой итерации (и менялся несколько раз!). Команда…эээ… со временем вошла во вкус и прониклась. Была попытка внедрения супер-пупер тула. Но он не прижился. Во-первых, Excel’я как раз хватало, во-вторых, тот тул навязывался сверху.
    Но, на другом проекте нужно постоянно обновлять и приоритезировать product backlog из порядка 1000 items (и это еще не конец!). Для этого Excel не очень-то “катит”. Тут бы просто перетаскивать backlog items – чем выше в списке, тем выше приоритет. Планировать спринты на основе product backlog тоже не очень удобно – copy/paste. Либо макросы писать.
    Кстати, Денис, по линку эксельный бэклог не открывается, а моих знаний шведского не хватило, чтобы найти :) . Локальная копия осталась?

  • Денис Петелин

    Привет!
    А вот прямо линк на него даю: http://blog.crisp.se/henrikkniberg/2007/12/18/1197973740000.html