Кто что порекомендует для команды в несколько человек?
Когда-то давно пользовался MS Project. Его функционал полностью устраивает, думаю, что там даже больше необходимого. Но надо бесплатное и на Линуксе запускать. В процессе подумал, что было бы здорово иметь в нём интеграцию с Гитхабом или Битбакетом. Как-то совсем не в курсе современных тенденций.
Пока делаю всё в Google.Sheets, но там надо много писать, чтобы поддерживать зависимость сроков и зависимость фичей между разными разработчиками. Неудобно, короче. Почитал список, но глаза разбегаются и не понятно с чего начать. Хочется услышать личные впечатления.
N>Когда-то давно пользовался MS Project. Его функционал полностью устраивает, думаю, что там даже больше необходимого. Но надо бесплатное и на Линуксе запускать. В процессе подумал, что было бы здорово иметь в нём интеграцию с Гитхабом или Битбакетом. Как-то совсем не в курсе современных тенденций.
Jira нормально работает как таск/багтрекер. А что тебе вообще надо от софта?
Здравствуйте, SkyDance, Вы писали:
SD>Jira нормально работает как таск/багтрекер. А что тебе вообще надо от софта?
Мне надо видеть список (или граф) задач к очередному релизу. Какая задача от какой зависит, её сроки, ставить процент выполнения. Например, если один разработчик затянет сетевую часть, то будет простаивать другой, сдвинутся сроки у тестеров и у всего релиза.
Как уже написали, Jira, вроде, не бесплатная.
Здравствуйте, Nuzhny, Вы писали:
N>Кто что порекомендует для команды в несколько человек? N>Когда-то давно пользовался MS Project. Его функционал полностью устраивает, думаю, что там даже больше необходимого. Но надо бесплатное и на Линуксе запускать. В процессе подумал, что было бы здорово иметь в нём интеграцию с Гитхабом или Битбакетом. Как-то совсем не в курсе современных тенденций. N>Пока делаю всё в Google.Sheets, но там надо много писать, чтобы поддерживать зависимость сроков и зависимость фичей между разными разработчиками. Неудобно, короче.
Если сотрудников меньше 10, то проще всего поставить линейку от Atlassian, это будет по 10$ в год за Jira и Confluence, можно считать бесплатным. Но Jira сложно и дорого настраивать, надо быть к этому готовым.
А без Confluence все равно необходим, важнее всего прочего для проектов. Кстати, планы можно и в нем же и вести, там есть всякие плагинчики )
Для простых процессов неплохо подоходит YouTrack, он для маленьких компаний практически бесплатный, а подходит лучше Jira.
Еще можно пробовать все в GitLab делать, там какой-то issue tracker появился, насколько я помню.
Но судя по "зависимость сроков и фичей" тебе нужна диаграмма ганта и прочие тяжелые вещи, это всюду сделано или плохо или очень плохо (хотя хвалили какую-то локальную софтинку под мак, но не пробовал никогда). Оно тебе точно надо?
А, еще есть Redmine, он уродливый, но знакомые использовали, вроде бы хватает на основные задачи.
Здравствуйте, Nuzhny, Вы писали:
SD>>Jira нормально работает как таск/багтрекер. А что тебе вообще надо от софта? N>Мне надо видеть список (или граф) задач к очередному релизу.
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Если сотрудников меньше 10, то проще всего поставить линейку от Atlassian, это будет по 10$ в год за Jira и Confluence, можно считать бесплатным. Но Jira сложно и дорого настраивать, надо быть к этому готовым. ДФ>А без Confluence все равно необходим, важнее всего прочего для проектов. Кстати, планы можно и в нем же и вести, там есть всякие плагинчики ) ДФ>Для простых процессов неплохо подоходит YouTrack, он для маленьких компаний практически бесплатный, а подходит лучше Jira.
Багтрекинг и управлене проектом это все таки не одно и тоже. Там и там, конечно, тикеты, но вот требования к ним разные, иногда противоположные. Натягивание управления разработкой на багтрекер, ровно как и обратное зачастую довольно печально выглядит.
Здравствуйте, Nuzhny, Вы писали:
N>Кто что порекомендует для команды в несколько человек?
я зависим от редмайна, поэтому посоветую его.
отзывчивость меня радует, на баги не напарывался.
можно совместить с гитлабом(редмайн ставится потом а ля плагин). гантт есть, канбан-доска есть, простая вики есть(очень простая, и это минус — нужны плагины).
про jira можно тоже сказать много хорошего в связке jira+confluence+bitbucket.
в свежих версиях есть плагины для ганта, канбана и прочих штук.
но мне не нравится, что оно довольно тяжёлое, с кучей медленного жалкоскрипта, неудобной канбан-доской и кучерявыми настройками.
в маленьких командах также популярны trello и asana. по рейтингам хвалят toggl.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Дельгядо Филипп, Вы писали:
НС>Багтрекинг и управлене проектом это все таки не одно и тоже. Там и там, конечно, тикеты, но вот требования к ним разные, иногда противоположные. Натягивание управления разработкой на багтрекер, ровно как и обратное зачастую довольно печально выглядит.
Угу. Но с учетом ужасности большей части (всех, что я видел) продуктов управления проектами все обычно сводится к Confluence и календарю )
Хотя часто в компании формально внедрен тот же MS Project или что-то еще более дорогое и пафосное — но все равно вся реальная работа в wiki, почте и календарях.
У нас организация больше по Бруксу: небольшая команда, каждый член которой достаточно узко специализирован, нет взаимозаменяемости и все пилят свои части.
Организация процесса свойственна для R&D: цикл исследование-реализация-тестирование, пока не найдётся хорошее решение. Оно потом переписывается, оптимизируется и интегрируется в проект.
Поэтому все эти ругательства не нужны.
Здравствуйте, Nuzhny, Вы писали:
НС>>У вас водопад, аджайл, скрам? Канбан нужен? N>У нас организация больше по Бруксу: небольшая команда, каждый член которой достаточно узко специализирован, нет взаимозаменяемости и все пилят свои части.
Это не то о чем я спрашивал. Откуда появляются требования? Кто их одобряет? Кто задает приоритет реализации? Как планируется разработка. Как и кто определяет когда и в каком виде будет релиз?
N>Организация процесса свойственна для R&D: цикл исследование-реализация-тестирование, пока не найдётся хорошее решение. Оно потом переписывается, оптимизируется и интегрируется в проект. N>Поэтому все эти ругательства не нужны.
А по моему у вас просто бардак и отсутствие организации процесса. И начинать надо с его устранения, а не с выбора софта.
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Хотя часто в компании формально внедрен тот же MS Project или что-то еще более дорогое и пафосное — но все равно вся реальная работа в wiki, почте и календарях.
Обычно все таки реальная работа в багтрекерах, которые затем докручивают до управления проектом за счет гибкости. А MSProject ... это, скажем так, просто некое упрощение ручного процесса. Ключевое отличие — нормальный софт это прежде всего коллаборация кучи разного народа с разными компетенциями, а MSProj это индивидуальный инструмент.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это не то о чем я спрашивал. Откуда появляются требования? Кто их одобряет? Кто задает приоритет реализации? Как планируется разработка. Как и кто определяет когда и в каком виде будет релиз?
Это стартап, в котором участвуют заинтересованные в результате коллеги. Требования и планирование — демократическая процедура, основанная на совещаниях и консенсусах.
НС>А по моему у вас просто бардак и отсутствие организации процесса. И начинать надо с его устранения, а не с выбора софта.
Наоборот, это достаточно грамотно организованный R&D процесс разработки.
Здравствуйте, Nuzhny, Вы писали:
НС>>Это не то о чем я спрашивал. Откуда появляются требования? Кто их одобряет? Кто задает приоритет реализации? Как планируется разработка. Как и кто определяет когда и в каком виде будет релиз? N>Это стартап, в котором участвуют заинтересованные в результате коллеги.
И что? Раз стартап, то давайте забьем на организацию и будем изображать лебедя рак и щуку?
N> Требования и планирование — демократическая процедура, основанная на совещаниях и консенсусах.
Ну вот скрам, к примеру, как раз про такое. Хочется абсолютной анархии — нет проблем. Есть Канбан, который хотя бы позволит понимать что в принципе у вас происходит.
НС>>А по моему у вас просто бардак и отсутствие организации процесса. И начинать надо с его устранения, а не с выбора софта. N>Наоборот, это достаточно грамотно организованный R&D процесс разработки.
А, ну тогда ради бога. Ответ на твой изначальный вопрос — никакой тебе не подойдет, ни один из них не рассчитан на абсолютный хаос. Продолжай пользоваться msproject или вообще забей на управление.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>И что? Раз стартап, то давайте забьем на организацию и будем изображать лебедя рак и щуку?
Нет, организация у нас есть, есть команда единомышленников, которая хочет добиться успеха. Ты когда-нибудь участвовал в стартапах в самом их начале? Планы есть, финансирования практически нет, но, если работает команда профессионалов, то хаоса практически нет. Все работают с большой степенью самоотдачи и эффективно.
N>> Требования и планирование — демократическая процедура, основанная на совещаниях и консенсусах. НС>Ну вот скрам, к примеру, как раз про такое. Хочется абсолютной анархии — нет проблем. Есть Канбан, который хотя бы позволит понимать что в принципе у вас происходит.
Ты, видимо, помешан на ярлыках. Но представь время, когда скрама не было, а существовали другие процессы. Кто-то в своей команде придумал что-то скрамоподобное и оно показало себя эффективным. Но все остальные смотрели на это, как на анархию! Для R&D проектов, завязанных на одну достаточно сложную фичу (которая может получиться, а может и нет) процесс разработки организуется не так, как для обычных. Тут работа идёт в двух направления, самых рискованных: сделать работоспособной саму фичу и узнать, кому её продать. То есть нужен MVP, у которого может быть ужасное юзабилити и вообще ничего, кроме самой фичи. И нужен первый покупатель, который даст деньги. Если команда небольшая, то работает исследователь, а ему помогают все остальные, пусть даже кофе подносить, и работает продажник, а все остальные генерируют идеи о применимости фичи. Какая-нибудь одна удачная встреча продажника может перевернуть позиционирование продукта, поэтому никакой код, кроме самой фичи, писать нет смысла. Определённый успех или неуспех исследователя может точно также перевернуть позиционирование, открыть или закрыть определённые рынки для продукта.
Это вполне стандартная ситуация для стартапа, которая вполне организовывается и планируется.
N>>Наоборот, это достаточно грамотно организованный R&D процесс разработки. НС>А, ну тогда ради бога. Ответ на твой изначальный вопрос — никакой тебе не подойдет, ни один из них не рассчитан на абсолютный хаос. Продолжай пользоваться msproject или вообще забей на управление.
О, я работал в условиях абсолютного порядка, где на написание функции необходимо было писать и согласовывать документы у нескольких уровней начальства. Вот там была организация, так организация, но профукивались многие возможности из-за неповоротливости процесса.
Нормальный человек понимает, что надо не свой проект натягивать на скрам или другую методику, а, наоборот, подбирать оптимальные процессы, откидывать или менять их под себя.
Здравствуйте, Nuzhny, Вы писали:
N>Кто что порекомендует для команды в несколько человек?
Гмм. Простой аналоговый блокнот и аналоговую же авторучку использовать не пробовал? (Есличо, я серьезно.)
Разного рода софтины стоит использовать, если уже понимаешь, что простой блокнот и авторучка не справляются со сложностью управления процессом. (Но при команде всего в несколько человек это что-то сомнительно...) А я всегда вспоминаю, что и Л.П.Берия, и С.П.Королев вели свои проекты вообще без всякого софта....
Здравствуйте, Vlad_SP, Вы писали:
V_S>Гмм. Простой аналоговый блокнот и аналоговую же авторучку использовать не пробовал? (Есличо, я серьезно.) V_S>Разного рода софтины стоит использовать, если уже понимаешь, что простой блокнот и авторучка не справляются со сложностью управления процессом. (Но при команде всего в несколько человек это что-то сомнительно...) А я всегда вспоминаю, что и Л.П.Берия, и С.П.Королев вели свои проекты вообще без всякого софта....
Команда распределённая, фото листочка не удобно рассылать. Есть табличка в Google.Sheets, но как-то не хватает.
Вообще с тобой согласен, мой любимый инструмент — это блокнот А4 в клетку и механический карандаш. Очень часто помогает как в решении алгоритмических проблем, так и для объяснения другим.
Здравствуйте, Nuzhny, Вы писали:
N>У нас организация больше по Бруксу: небольшая команда, каждый член которой достаточно узко специализирован, нет взаимозаменяемости и все пилят свои части. N>Организация процесса свойственна для R&D: цикл исследование-реализация-тестирование, пока не найдётся хорошее решение. Оно потом переписывается, оптимизируется и интегрируется в проект. N>Поэтому все эти ругательства не нужны.
по-моему, вам тогда подойдёт любая довольно простая(и даже бесплатная) штука с диаграммой гантта, где можно сводить задачи к определённой контрольной точке.
в таком трекере должна быть возможность связывать задачи, указывать жёсткость связей(например, на кого-то срыв сроков влиять не будет), иметь внятный markdown-редактор для описания задач с предпросмотром и блок комментариев под задачей. документацию вы, возможно, храните в чём-то другом, поэтому вам наличие вики в коробке не принципиально.
конечно, тут надо всё перебирать руками... но чего бы не начать с трелло?
разве только потом, когда придёт успех, придётся менять трекер.
