Comments 35
задача и ошибка имеют разный «воркфлоу». задача перед выполнением согласуется с заказчиком и менеджером. ошибка же ни в каких согласованиях не нуждается. соответствено, у ошибки также нет этапа «сдачи» — только тестирование её отсутствия.
позвольте не согласиться:
1. ошибка заведенная заказчиком еще может ошибкой и не являться, это нужно проверить действительно ли поведение системы противоречит исходным требованиям. Следовательно нужен этап согласования, часто он пропускается, но это лишь добавляет нервозности в работе.
2. исправленная ошибка требует того, чтобы ее перепроверили QA, а часто и сам заказчик, поскольку коммуникационные шумы и невсеобъемлющее владение предметной области вносят свою погрешность в реализацию. Следовательно нужен и этап «сдачи» для ошибки.
1. ошибка заведенная заказчиком еще может ошибкой и не являться, это нужно проверить действительно ли поведение системы противоречит исходным требованиям. Следовательно нужен этап согласования, часто он пропускается, но это лишь добавляет нервозности в работе.
2. исправленная ошибка требует того, чтобы ее перепроверили QA, а часто и сам заказчик, поскольку коммуникационные шумы и невсеобъемлющее владение предметной области вносят свою погрешность в реализацию. Следовательно нужен и этап «сдачи» для ошибки.
более того — в большинстве случаев ошибка обязательно нуждается в согласовании, так как ее исправление может занять достаточно много времени, которое уже распланировано в итерации на другие работы, которые могут так и оставаться более приоритетными, чем найденная ошибка.
соответственно ее исправление может быть запланировано как в текущей, так и в любой другой итерации — а это один в один жизненный цикл задачи, так что здесь расхождений нет.
соответственно ее исправление может быть запланировано как в текущей, так и в любой другой итерации — а это один в один жизненный цикл задачи, так что здесь расхождений нет.
все таски просто сортируются по приоритетам, а для текущей итерации ставится +1 к приоритету. если приходит обычная ошибка, то она испраляется по остаточному принципу. если серьёзная, то обязаельно в этой итерации. если критикал — хотфиксом.
исполнитель ставит эстимэйт, после чего менеджер может понизить или повысить приоритет таска.
исполнитель ставит эстимэйт, после чего менеджер может понизить или повысить приоритет таска.
если исполнитель или разгребатель багов видит, что это не ошибка — он трансформирует её в импрув и отправляет на согласование.
заказчик сдохнет проверять каждую ошибку. а если у него есть желание самолично перепроверить отсутствие какой-либо ошибки — это не относится к её жизненному циклу.
заказчик сдохнет проверять каждую ошибку. а если у него есть желание самолично перепроверить отсутствие какой-либо ошибки — это не относится к её жизненному циклу.
«если исполнитель или разгребатель багов видит, что это не ошибка — он трансформирует её в импрув и отправляет на согласование.» — а если это ошибка? что делать?
«желание самолично перепроверить отсутствие какой-либо ошибки — это не относится к её жизненному циклу.» — при профессиональном подходе в жизненном цикле ошибки есть стадия «проверки»/«приемки», как ее выполнять: через QA или заказчика — это дело конкретного проекта, но факта не убрать — жизненный цикл ошибки является частью жизненного цикла доработки.
«желание самолично перепроверить отсутствие какой-либо ошибки — это не относится к её жизненному циклу.» — при профессиональном подходе в жизненном цикле ошибки есть стадия «проверки»/«приемки», как ее выполнять: через QA или заказчика — это дело конкретного проекта, но факта не убрать — жизненный цикл ошибки является частью жизненного цикла доработки.
Если инструмент действительно не ограничен в возможностях настройки, значит его можно настроить так, чтобы он был простым (минималистичные скины в проигрывателях, например).
Однако его простота не сделает его более гибким в настройках.
Однако его простота не сделает его более гибким в настройках.
тут скорее проблема несколько в ином:
1. на личном опыте убедился, сколько команд, столько и вариантов настройки процесса разработки. Гибкость в настройке workflow, заложенная в инструменте, является «дьявольским» искушением.
Вопрос настройки процесса далеко не праздный и когда им начинают заниматься команды, не достаточно погрузившиеся в детали процесса разработки, то настройка занимает массу времени (на одном из мест работы команда из 10 человек несколько дней по паре часов придумывала и каждый доказывал друг другу свое понимание как же должно быть).
Результат: состояния перемешиваются с переходами и резолюциями, появляется более 10 состояний дефекта (если о Jira), в которых без отдельного процессного документа и не разобраться, а при обычной текучке процесс просто перестает работать.
2. речь скорее не о простоте, а о фиксированности и упрощенности (до уровня необходимого), достаточной для постановки эффективного процесса.
Суть в том, что хорошо продуманный (но фиксированный) процесс гораздо лучше для массового использования, чем изначально не соответствующий действительности (в смысле Jira — это трэкер, а нужно управлять проектом), но настраиваемый неспециалистами.
1. на личном опыте убедился, сколько команд, столько и вариантов настройки процесса разработки. Гибкость в настройке workflow, заложенная в инструменте, является «дьявольским» искушением.
Вопрос настройки процесса далеко не праздный и когда им начинают заниматься команды, не достаточно погрузившиеся в детали процесса разработки, то настройка занимает массу времени (на одном из мест работы команда из 10 человек несколько дней по паре часов придумывала и каждый доказывал друг другу свое понимание как же должно быть).
Результат: состояния перемешиваются с переходами и резолюциями, появляется более 10 состояний дефекта (если о Jira), в которых без отдельного процессного документа и не разобраться, а при обычной текучке процесс просто перестает работать.
2. речь скорее не о простоте, а о фиксированности и упрощенности (до уровня необходимого), достаточной для постановки эффективного процесса.
Суть в том, что хорошо продуманный (но фиксированный) процесс гораздо лучше для массового использования, чем изначально не соответствующий действительности (в смысле Jira — это трэкер, а нужно управлять проектом), но настраиваемый неспециалистами.
Самый простой процесс — todo list :) И что самое интересное, в нем ничего не надо менять.
А те проблемы, о которых говорите вы (настраиваемость vs простота) — это все человеческое. Конкретный менеджер, конкретная организация. Кто как сумеет, так и использует инструмент. Да, Jira это не совсем для управления проектами. Но использовать можно? Можно так повернуть свой мозг? Да.
У нас, к примеру, в Comindwork долгое время были ненастраиваемые процессы (cases). И я, сравнивая использование двумя разными компаниями, был просто в шоке. Они абсолютно не похожи. Даже несмотря на то, что поля одни и те же, функционал один и тот же.
А те проблемы, о которых говорите вы (настраиваемость vs простота) — это все человеческое. Конкретный менеджер, конкретная организация. Кто как сумеет, так и использует инструмент. Да, Jira это не совсем для управления проектами. Но использовать можно? Можно так повернуть свой мозг? Да.
У нас, к примеру, в Comindwork долгое время были ненастраиваемые процессы (cases). И я, сравнивая использование двумя разными компаниями, был просто в шоке. Они абсолютно не похожи. Даже несмотря на то, что поля одни и те же, функционал один и тот же.
согласен, в случае с проигрывателем все будет именно так.
но jira — инструмент несколько другого уровня, и для ее грамотной настройки (даже чтобы только все упростить) нужен отдельный человек, немало времени на нее отдавший. а иначе будет бардак и соответственно проблемы в вашей с ней работе.
но jira — инструмент несколько другого уровня, и для ее грамотной настройки (даже чтобы только все упростить) нужен отдельный человек, немало времени на нее отдавший. а иначе будет бардак и соответственно проблемы в вашей с ней работе.
Подскажите как специалисты — почему правая кнопка мыши не используется? Контекстное меню же должно быть удобнее чем checkbox'ы и кнопки?
где именно не используется контекстное меню, в девпром? на хабре его тоже нет — специфика веб-приложений.
В девпром. А при чем тут хабр?
Вот очень интересует что такого в веб-приложениях специфического что не позволяет в project management приложении использовать контекстные меню по правому клику мыши. Насколько я знаю, javascript на современных браузерах это позволяет, или я где-то ошибаюсь?
Вот очень интересует что такого в веб-приложениях специфического что не позволяет в project management приложении использовать контекстные меню по правому клику мыши. Насколько я знаю, javascript на современных браузерах это позволяет, или я где-то ошибаюсь?
Технически сделать контекстное меню не представляет трудности — но станет ли более удобнее, это вопрос. Нужно тогда весь интерфейс приводить к такому стилю, иначе 99% пользователей просто не догадается, что где-то на нашем сервисе можно вызвать контекстное меню.
Было бы здорово, если бы вы через форму обратной связи описали места, где добавление такого меню имело бы смысл — тогда это пожелание попадет к нам в список задач и мы будем иметь его в поле зрения.
Было бы здорово, если бы вы через форму обратной связи описали места, где добавление такого меню имело бы смысл — тогда это пожелание попадет к нам в список задач и мы будем иметь его в поле зрения.
но станет ли более удобнее, это вопрос
а, вот где собака зарыта :). Это да, вопрос сложный. К сожалению, у меня в юзабилити ранг не особенно высокий, поэтому про удобнее обсуждать ничего не смогу. Как говорится, упс.
Простота. А где опрос?
Однозначно простота. Противоположное свойство у нас есть априори — можно вести, скажем, те же задачи, каждый раз отписывая запросы к базе. А «изначально максимально простого» у нас нет.
Для инструмента важно только то, что бы он помогал выполнять нужную работу максимально эффективно.
Простым инструмент будет, или с кучей настроек — надо выбирать в зависимости от стоящих задач.
Простым инструмент будет, или с кучей настроек — надо выбирать в зависимости от стоящих задач.
это не вина инструмента, что его коверкают так что он становится неудобным.
JIRA сложна в настройке. JIRA требует отдельного человека (людей) для поддержания и подгонки под конкретные задачи конкретной фирмы. JIRA не для всех. JIRA для толстых и небедных. JIRA великолепна.
Не понял комментарии, где люди пытаются отвечать на вопрос «важнее ли простота или возможности настройки». Это же не настоящий вопрос, это же просто риторический приём, не более. Важнее ли, чтобы еда была дешевой или вкусной? Что важнее: ширина, высота или глубина параллелепипеда?
Это хорошо, что вы делаете альтернативу JIRA. У людей есть возможность выбирать. Но не стоит преподносить свой продукт как кафтан, который удобен и к лицу всем и каждому.
Увы, нет «действительно необходимых» состояний. Workflow очень разный не только у разных фирм, а даже у разных отделов одной фирмы. В фирме, где работаю, JIRA пользуются не только разработчики, но и, например, кадровики (HR). У них свой workflow, и состояния задач свои, совершенно не похожие на разработческие. У них нет «утверждено» и «выполнено», у них есть «получено резюме», «назначено интервью», «принят на работу», «отклонен по результатам интервью» и т. п.
… В общем, дай бог здоровья и вам, делающим упрощенную систему, и разработчикам JIRA, делающим систему, которая реально нужна и «по зубам» лишь крупным фирмам, и возможности по кастомизации которой впечатляют.
Не понял комментарии, где люди пытаются отвечать на вопрос «важнее ли простота или возможности настройки». Это же не настоящий вопрос, это же просто риторический приём, не более. Важнее ли, чтобы еда была дешевой или вкусной? Что важнее: ширина, высота или глубина параллелепипеда?
Это хорошо, что вы делаете альтернативу JIRA. У людей есть возможность выбирать. Но не стоит преподносить свой продукт как кафтан, который удобен и к лицу всем и каждому.
Состояния задач только действительно необходимые: Добавлена, Утверждена, Запланирована, В работе, Выполнена, Закрыта и Отложена
Увы, нет «действительно необходимых» состояний. Workflow очень разный не только у разных фирм, а даже у разных отделов одной фирмы. В фирме, где работаю, JIRA пользуются не только разработчики, но и, например, кадровики (HR). У них свой workflow, и состояния задач свои, совершенно не похожие на разработческие. У них нет «утверждено» и «выполнено», у них есть «получено резюме», «назначено интервью», «принят на работу», «отклонен по результатам интервью» и т. п.
… В общем, дай бог здоровья и вам, делающим упрощенную систему, и разработчикам JIRA, делающим систему, которая реально нужна и «по зубам» лишь крупным фирмам, и возможности по кастомизации которой впечатляют.
Антон, спасибо за развернутый комментарий! То, что вопрос в заголовке риторический — вы поняли абсолютно верно.
Касательно workflow здесь вот какая особенность — в статье я говорил исключительно про разработку приложений.
Я знаю десяток действительно великолепных решений на базе Jira для HR, ServiceDesk и прочих служб, в основе которых лежат так называемые «заявки», с жестко заданным и крайне редко меняющимся workflow.
В случае проектной деятельности по разработке ПО процесс должен эволюционировать, чтобы оставаться эффективным, и часто начинают вносить исправления именно в инструмент, а не в сам процесс. И получаются те проблемы, которые я описал в статье.
Люди важнее инструментов, поэтому нужно сдерживать себя и не поддаваться искушению кастомизации инструмента, а сначала попробовать привнести новые идеи в жизнь и убедиться, что они действительно необходимы и эффективны.
Ну и не стоит забивать гвозди отверткой — управление проектом сводится не только к issue tracking, но так же требует и работу с требованиями и нормальное планирование и многое другое, для чего инструменты вроде Jira просто не предназначены.
А используются. Как помните, было «ежики кололись и плакали, но продолжали есть кактус».
Касательно workflow здесь вот какая особенность — в статье я говорил исключительно про разработку приложений.
Я знаю десяток действительно великолепных решений на базе Jira для HR, ServiceDesk и прочих служб, в основе которых лежат так называемые «заявки», с жестко заданным и крайне редко меняющимся workflow.
В случае проектной деятельности по разработке ПО процесс должен эволюционировать, чтобы оставаться эффективным, и часто начинают вносить исправления именно в инструмент, а не в сам процесс. И получаются те проблемы, которые я описал в статье.
Люди важнее инструментов, поэтому нужно сдерживать себя и не поддаваться искушению кастомизации инструмента, а сначала попробовать привнести новые идеи в жизнь и убедиться, что они действительно необходимы и эффективны.
Ну и не стоит забивать гвозди отверткой — управление проектом сводится не только к issue tracking, но так же требует и работу с требованиями и нормальное планирование и многое другое, для чего инструменты вроде Jira просто не предназначены.
А используются. Как помните, было «ежики кололись и плакали, но продолжали есть кактус».
Issue tracking system без настраиваемого workflow — это как дрель с несменным сверлом.
Если говорить только о сверлении дырок (отслеживание запросов) — то да.
Но попробуйте, имея в руках только дрель и набор сверел, сделать полный ремонт во всей квартире (разработка проекта) — вряд ли у вас что-то получится сделать это хорошо и быстро, согласны?
Мы же пытаемся сделать скорее доступный всем «набор для ремонта» — ящик с наиболее часто необходимыми инструментами, которые максимально подойдут большинству команд, разрабатывающих приложения. И который может заменить покупку и интеграцию трех или пяти различных инструментов.
Но попробуйте, имея в руках только дрель и набор сверел, сделать полный ремонт во всей квартире (разработка проекта) — вряд ли у вас что-то получится сделать это хорошо и быстро, согласны?
Мы же пытаемся сделать скорее доступный всем «набор для ремонта» — ящик с наиболее часто необходимыми инструментами, которые максимально подойдут большинству команд, разрабатывающих приложения. И который может заменить покупку и интеграцию трех или пяти различных инструментов.
Я не понимаю подхода «упрощение за счет отказа от функциональности». Я бы понял «упрощение за счет прятания большинства редко используемых настроек и удобной настройки по умолчанию».
То, что вы описали, для меня, как разработчика, выглядит так:
Мы предлагаем вам IDE, она очень простая, вы можете писать программы на любом любимом вами языке, но не можете настраивать параметры компиляции. Мы заранее позаботились и создали 2 действительно необходимые конфигурации: Debug и Release, параметры которых вы менять не можете, мы уже подобрали оптимальные. Пути, куда будут складываться временные файлы и артефакты, вы менять тоже не можете, ведь 80% пользователей удовлетворится параметрами по умолчанию, ну а остальные 20% пусть покупают монстров конфигурации.
Желаю вам найти свою аудиторию. Наверное я просто вхожу в те 20%.
То, что вы описали, для меня, как разработчика, выглядит так:
Мы предлагаем вам IDE, она очень простая, вы можете писать программы на любом любимом вами языке, но не можете настраивать параметры компиляции. Мы заранее позаботились и создали 2 действительно необходимые конфигурации: Debug и Release, параметры которых вы менять не можете, мы уже подобрали оптимальные. Пути, куда будут складываться временные файлы и артефакты, вы менять тоже не можете, ведь 80% пользователей удовлетворится параметрами по умолчанию, ну а остальные 20% пусть покупают монстров конфигурации.
Желаю вам найти свою аудиторию. Наверное я просто вхожу в те 20%.
в плане безопасности даже у jira все плохо. Например у trakstudio (http://www.trackstudio.ru/) имхо лучше.
jira используется далеко не компаниями в 2-4 человека, и они могут себе позволить IT подразделение, которое и настроит как нужно и что нужно. А мелкие комманды возьмут готовые решения (web) которые будут поддерживтаься за 24$/year.
jira используется далеко не компаниями в 2-4 человека, и они могут себе позволить IT подразделение, которое и настроит как нужно и что нужно. А мелкие комманды возьмут готовые решения (web) которые будут поддерживтаься за 24$/year.
В трэкинговых системах нишу «все включено и настроено» занимает Mantis.
И работает именно так: по умолчанию 5 ролей 8 статусов. Все поля уже включены и настроены.
Если не подходит — жаль. Немного настроек присутсвует, но не более того.
Зато начать использовать можно сразу.
И работает именно так: по умолчанию 5 ролей 8 статусов. Все поля уже включены и настроены.
Если не подходит — жаль. Немного настроек присутсвует, но не более того.
Зато начать использовать можно сразу.
1. За последние неделю я опробовал достаточно много систем управления проектом, в том числе и вашу, и мне не понятно почему все забивают на дизайн. Вам самим ваш дизайн нравиться?
2. Отказаться от настроек круто! Ну раз вы делаете простой инструмент, так надо делать и понятный интерфейс, я не смог разобраться с вашей системой, с jira же разобрался моментально.
2. Отказаться от настроек круто! Ну раз вы делаете простой инструмент, так надо делать и понятный интерфейс, я не смог разобраться с вашей системой, с jira же разобрался моментально.
В основном нас беспокоит юзабилити, сейчас пытаемся его улучшить, одновременно и дизайн подтянется. Сервис постоянно развивается, мы ни в коем случае не говорим, что уже закончили работу над ним.
Насчет того, что не смогли разобраться — какой момент оказался самым непонятным? Если вам действительно нужна система управления проектом — с удовольствием помогу разобраться.
Насчет того, что не смогли разобраться — какой момент оказался самым непонятным? Если вам действительно нужна система управления проектом — с удовольствием помогу разобраться.
Дело в том, что вы делаете просто баг-трекер, а некоторым людям нужен issue-трекер. Например, наш отдел HR ведёт свою работу в JIRA. У них не бывает багов и фичер-реквестов и ваш подход им не подходит.
Нужнее всего эффективность. Гибкость настроек хороша тогда, когда эти настройки позволяют создать максимально удобное рабочее окружение. Есть даже поговорка «простые вещи устроены сложно».
Sign up to leave a comment.
Что важнее — простота инструмента или безграничные возможности его настройки?