В очередной раз анализируя запас по настраиваемости разных трекинговых систем (надо, надо тренинг сделать) задумался а так ли уж необходим функционал изменения категории. я работал и в тех и других системах. Мысли во многом совпадают с изложенным здесь:
http://www.trackstud...749.html#p22749
С одной стороны. Сложно настраивать, сложно отловить все дыры безопасности.
С другой стороны. Заказчик действительно ставит неправильный тип задачи, а от этого зависит схема и сумма оплаты. Баги правятся бесплатно, доработки оплачиваются согласно контракта на конкретную доработку, консультации оплачиваются скопом, в рамках оговоренных в месяц часов.
И вот подумалось мне, что одно из решений выглядит так:
* Заказчик. Я заказчик. Мне плевать на вашу типизацию. "Я хочу!"
* И в системе создается запрос с категорией "хотелка". С простым жизненным циклом типа: "Новое желание" / "Исполнено" / "Передумал"
* В ее рамках уже ведутся все остальные работы со строгой типизацией.
Что скажете, коллеги?
смена категории у таска (issue)
#1
Отправлено 15 апреля 2014 - 11:58
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#2
Отправлено 15 апреля 2014 - 12:30
Спасибо за интересную тему!
Вопрос - вот заказчик создал "хотелку", он же за нее и денег не хочет платить, потому что думает что это "баг" :) как до него донести факт существования других типов задач, если не сменой задачи в багтрекере? Ну то есть на мой взгляд, инженеры как раз меняют типы задач, чтобы заказчик осознавал что баг,а что фича. Так сказать, "тыкаем носом", чтобы вопросы возникали сразу после наших исследований, а не когда мы ему счет выставляем.
В общем, на мой взгляд важно самому заказчику тип задачи показывать. Хотя это может быть и лейбл какой-нить, а сам тип - customer request, например (ну потому что часть - просто вопросы наверняка, а не баги и фичи), но как-то показать хотелось бы.
Не знаю, ответила ли:)
#3
Отправлено 15 апреля 2014 - 14:13
Спасибо за интересную тему!
Вопрос - вот заказчик создал "хотелку", он же за нее и денег не хочет платить, потому что думает что это "баг" :) как до него донести факт существования других типов задач, если не сменой задачи в багтрекере? Ну то есть на мой взгляд, инженеры как раз меняют типы задач, чтобы заказчик осознавал что баг,а что фича. Так сказать, "тыкаем носом", чтобы вопросы возникали сразу после наших исследований, а не когда мы ему счет выставляем.
В общем, на мой взгляд важно самому заказчику тип задачи показывать. Хотя это может быть и лейбл какой-нить, а сам тип - customer request, например (ну потому что часть - просто вопросы наверняка, а не баги и фичи), но как-то показать хотелось бы.
Не знаю, ответила ли:)
Нет, не ответили. Вы описали какого то мифического бизнес заказчика. Адекватным заказчикам до фени инструменты разработки ПО. И про интеграцию с Git или там сервер непрерывной интеграции он тоже ничего знать не хочет. И думает он в терминах результатов, а не работ. А начнет думать в терминах работ... нужно подумать, может ему из бизнес подразделения в IT уйти.
Да, можно на хотелке сделать доп поля, которые указывают платно/ бесплатно и сколько стоит. Это не проблема. Главное, чтоб ЖЦ не менялся.
PS. И чем еще это хорошо, тем что для реализации "Хочу!" может понадобиться провести 4 консультации исправить 15 багов и сделать 19 доработок. И все это сделать в 9 системах, причем договора SLA (соглашение по уровню поддержки) по этим 9 системам кардинально различаются. Какие-то относятся к этапу внедрения системы, заказчиком не оплачиваются и бюджетируются из бюджета проекта внедрения. А по каким-то договор по исправлению багов (вне зависимости от того, кто ее нашел) такой зверский, что после не исправления в течении 2 рабочих дней начинает начисляться штраф. Скажем евро по 200 в день. С зарплаты отдела. Ну и да, все 9 систем имеют собственную систему версионирования и свой график релизов. И чтобы заказчику продемонстрировать на демо стенде его хотелку, нужно на демо стенде обновить все 9 систем и убедиться, что они стали нужной версии.
Вот как-то так.
PS. Крыша не едет?
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#4
Отправлено 15 апреля 2014 - 14:52
Вы описали какого то мифического бизнес заказчика. Адекватным заказчикам до фени инструменты разработки ПО. И про интеграцию с Git или там сервер непрерывной интеграции он тоже ничего знать не хочет. И думает он в терминах результатов, а не работ. А начнет думать в терминах работ... нужно подумать, может ему из бизнес подразделения в IT уйти.
Я очень конкретного заказчика описывала:) Он заводил задачи определенного типа, потому что от этого типа зависело будет он дополнительно оплачивать или входит в обычную поставку.
Про интеграцию с гит и тд он действительно знать не хотел. А вот платить ему или нет - очень важно, потому что если надо платить - хотелка может и отойти на задний план. Это вопрос вовлечения заказчика в ваш процесс, мы старались вовлечь.
ЖЦ - ему было важно, что если сделано - то протестировалось + были свои приемочные тесты на будущих конечных юзерах. И обо всех этих стадиях он хотел знал и получть нотификации.
для реализации "Хочу!" может понадобиться провести 4 консультации исправить 15 багов и сделать 19 доработок. И все это сделать в 9 системах, причем договора SLA (соглашение по уровню поддержки) по этим 9 системам кардинально различаются. Какие-то относятся к этапу внедрения системы, заказчиком не оплачиваются и бюджетируются из бюджета проекта внедрения.
Ох, 9 систем - уже отдельная проблема:) у нас была многомодульная система, но одна, всей разработкой 1 компания занималась. И да, если для решения 1 проблемы нужно несколько задач - понятно что они к ней линкуются и живут себе в других проектах, изначальная может быть любой, особенно если для заказчика от этого типа ничего не зависит. Да, в JIRA для этого есть например Structure :))
Вопрос - какую задачу решаете) Судя по вашему ответу, заказчик вообще не видит багтрекер - тогда откуда взялась проблема с изменением типа? Я просто поняла вопрос как "нужен ли тип задачи для кастомерских хотелок". Поясните немножко в чем вопрос, пожалуйста
#5
Отправлено 15 апреля 2014 - 14:53
Этот запрос для кого? Для вас или для заказчика?
Если для вас, то как типизируется статус задачи, если проведено 3 консультации и исправлена половина багов?
Или это верхнеуровневый срез по хотелкам заказчика?
#6
Отправлено 16 апреля 2014 - 05:46
Этот вопрос пока для меня. Звучит он примерно так: "Если трекинговая система не имеет штатной процедуры смены категории объекта, то в каких случаях это препятствует ее выбору для внедрения."
Да, в JIRA для этого есть например Structure :))
Который является костылем и не решает проблему нормально. И да, отсутствие нормальной иерархии в Jira является достаточным основанием для отказа от нее в ряде ситуаций.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#7
Отправлено 16 апреля 2014 - 12:55
"Если трекинговая система не имеет штатной процедуры смены категории объекта, то в каких случаях это препятствует ее выбору для внедрения."
- у вас есть новички, они путают типы задач, потом лиды хотят их менять
- у вас есть "старички", они создают задачи "на автомате", потом сами хотят поменять
- у вас есть девелоперы, которым обидно когда заводят багу, а она на самом деле не бага
- у вас есть менеджеры, которые любят красивые графики, и графики эти в том числе строят по количеству найденных багов, записанных фич,...(тут можно кучу вариантов придумать)
- у вас есть админы/hr/еще кто-то, кто пользуется той же системой для своих задач. Они тоже ошибаются.
наверняка есть еще причины.. Мне кажется, не особо правильно так вопрос ставить. Обычно не думаешь почему бы мне чего-то не хотелось, а думаешь какие у тебя есть задачи и ищешь что их решает лучше всего..
отсутствие нормальной иерархии в Jira является достаточным основанием для отказа от нее в ряде ситуаций.
Для кого-то проблема, кому-то абсолютно все равно, у всех разные задачи:) Считаю прекрасным примером к тому, что идти лучше "от своих нужд"
#8
Отправлено 17 апреля 2014 - 04:19
по мне так, нельзя конечному пользователю (заказчику или кому там ещё) давать создавать задачи которые потом уходят в разработку (ну если у вас не маленький коленочный проектег).
должно быть именно так:
С простым жизненным циклом типа: "Новое желание" / "Исполнено" / "Передумал"
А уже на основе этих мини задач делаются баги/фитчи/Исследования/Документации/и тд.
#9
Отправлено 17 апреля 2014 - 07:11
по мне так, нельзя конечному пользователю (заказчику или кому там ещё) давать создавать задачи которые потом уходят в разработку (ну если у вас не маленький коленочный проектег).
должно быть именно так:
С простым жизненным циклом типа: "Новое желание" / "Исполнено" / "Передумал"
А уже на основе этих мини задач делаются баги/фитчи/Исследования/Документации/и тд.
Мы может про разные системы работы говорим. заказчик != конечный пользователь. Если заказчик - другая контора например, которая вам что-то аутсорсит, она почти наверняка захочет видеть типы задач. Если заказчик - дядя Ваня из 5го подъезда - да, ему скорее всего все равно как вы назовете его хотелку в своем багтрекере
Ну и остается вопрос: если для заказчика от типа задачи зависит оплата, как вы ему объясните, что какие-то хотелки денег стоят, а какие-то нет?
#10
Отправлено 17 апреля 2014 - 11:07
Мы может про разные системы работы говорим. заказчик != конечный пользователь. Если заказчик - другая контора например, которая вам что-то аутсорсит, она почти наверняка захочет видеть типы задач. Если заказчик - дядя Ваня из 5го подъезда - да, ему скорее всего все равно как вы назовете его хотелку в своем багтрекере
Ну и остается вопрос: если для заказчика от типа задачи зависит оплата, как вы ему объясните, что какие-то хотелки денег стоят, а какие-то нет?
Элементарно. Предоставлю смету в разрезе видов работ, которые были сделаны по хотелке.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#11
Отправлено 23 апреля 2014 - 09:50
Элементарно. Предоставлю смету в разрезе видов работ, которые были сделаны по хотелке.
какого размера будет этот документ? Заказчику нужен быстрый ответ типо "платно/бесплатно", а потом уже может быть какие-то сметы.
Ну и плюс нужно отслеживать чтобы девелоперы не запилили фичу, которую заказчик не захочет покупать, и при этом если захочет - могли сделать ее быстро.. Много проблем)
#12
Отправлено 24 апреля 2014 - 04:54
ну как бы, я бы внутреннюю разработку вёл бы как минимум в другом проекте, который не виден заказчику, это не правильно, когда заказчик видит процесс изнутри. Хочет видеть процесс изнутри, пусть самостоятельно занимается управлением, не хочет управлять, не увидит внутренности. И это нормально.
#13
Отправлено 24 апреля 2014 - 07:36
Остановился на том, что отсутствие функционала смены категории - это нормально. Тонкой настройкой разрешений создания тасков определенной категории только в рамках папки определенной категории проблема решается.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#14
Отправлено 24 апреля 2014 - 08:00
Я вижу здесь два варианта взаимодействия:
1. Заказчик озвучивает свою задачу (не вдается в особенности приложения)
В этом случае нужна роль presales/аналитика, человека, который разберет задачу: напишет пользовательские сценарии, определит перечень компонент и исправлений, составит смету (нужное подчеркнуть).
2. Заказчик близко знаком с системой
Если заказчик конкретно формулирует задачи на языке системы (здесь поменять иконку, там добавить столбец), тогда удобно оформлять через customer request внутри вашей трекинговой системы. Но и в этом случае запросы изменений проходят через аналитика/менеджера продукта.
BadMF,
В обоих случаях, если у клиента будет доступ к трекингу (с ограниченными правами), это положительно скажется на доверии. В скраме клиенты - это "курицы" (смотрим, но не трогаем).
#15
Отправлено 24 апреля 2014 - 14:01
Есть еще варианты. Минимум два.
3.
а) Заказчик пишет письмо вида: "Я девочка, я хочу платье." на tracker@companyname
б) по письму создается задача категории "Желание заказчика". В зависимости от обратного адреса определяется раздел бюджета и если месячная квота условных часов не исчерпана, то письмо отправляется диспетчеру IT (ну не менеджер это, а стрелочник)
в) диспечер отправляет тому, кто может декомпозировать задачу.
г) декомпозитор говорит: "Раз платье такое то, нужно: выточить из дерева пуговицы, купить кружева и крючки, сделать выкройку из вототого веселенького ситчика, ..."
Далее все понятно, а заказчику в конце говорят: "Желание исполнено"
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#16
Отправлено 25 апреля 2014 - 04:56
BadMF,
В обоих случаях, если у клиента будет доступ к трекингу (с ограниченными правами), это положительно скажется на доверии. В скраме клиенты - это "курицы" (смотрим, но не трогаем).
В скраме человек который может работать в трэкинговой системе со стороны заказчика, это "продукт оунер", и он(а) является непосредственным участником процесса, то бишь свиньёй, из приведённой вами ссылки.
У клиента (любого представителя заказчика), в общем случае, нет права заводить какие-либо задачи в трэкинговой системе.
Скрам это не хаос, это очень чёткий порядок, достигающийся непрерывным опытом работы внутри одной команды (в том числе продукт оунер и тд). Допускать внутрь скрам команды людей которые не участвуют в процессе довольно глупо.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных