Согласен, что Rails не дает десятикратного прироста. Всем кто думает, что дает читать эссе Брукса "Серебряной пули нет".
Rails реально дает прирост в два, максимум три раза и только начиная со второго проекта, когда разработчикам не нужно лазить в книжку каждые пять минут.
В России - значительно. В мире не так сильно как вы думаете.
Количество людей в отрасли почти не изменилось (падение после кризиса доткомов скомпенсировано последующим ростом), некоторое повышение продуктивность отдельного программиста съедено повышением сложности типичного "сложного" проекта. С чего бы в этих условиях увеличиваться числу крупных проектов?
PHP *специализированный* язык для веб-разработки. Поэтому сравнивать фреймворки для веб-разработки с PHP гораздо корректнее, чем с языками общего назначения (например, Java).
> Официально PHP/FI 2.0 вышел только в ноябре 1997 года, после проведения большей части своей жизни в бета-версиях. Вскоре после выхода его заменили альфа-версии PHP 3.0.
> PHP 3.0 был официально выпущен в июне 1998 года после 9 месяцев публичного тестирования.
Скажите, много ли было в 2000-м году (1997 + 3 года) крупных и известных ресурсов, написанных на PHP? Мне что-то все C++/CGI вспоминается...
О больших приложениях на Rails вы не услышите еще пару лет... Просто потому что ресурсы такого масштаба, как перечисленные вам, создаются по нескольку лет. Причина не в том, что невозможно написать движок мега-ресурс за несколько месяцев, а в том, что раскрутка требует времени.
Так что большие системы на Rails уже вовсю создаются и раскручиваются, просто их еще, по причине молодости, не заметно.
Как всегда, приходится выбирать либо гибкость (подзадачи), либо удобство работы (статусы).
В контексте хорошо технологизированного процесса разработки программных продуктов я предпочитаю удобство работы.
Многие системы issue tracking'а предоставляют возможность настроить свой набор статусов и переходов между ними. Даже если эти настройки общие для всех проектов, то это позволит закрыть более 80% случаев, если, конечно, в организации есть какая-то технология работы. Если нет - то workflow инструменты этой огранизации тоже не нужны
- Багтреккинг, issue tracking - workflow инструмент, используется всеми участниками проекта для учета багов, проблем, задач и т.п.
- Planning, project tracking - высокоуровневый взгляд на планы и текущее состояние. Используется менеджером, иногда еще и лидами. В идеале данные берутся из системы issue tracking'а, либо это вообще одна и та же система.
- CRM - учет клиентов, их представителей и взаимодействия с ними. В идеале сюда же вносятся все обещания, сделанные заказчику (управление требованиями). Используется только теми, кто общается с заказчиками.
Соответственно, CRM для меня никак не касается темы данного обсуждения.
Вопрос в том, как удобнее представлять этапы выполнения задачи - связанными подзадачами, назначаемыми отдельным людям или одной задачей, передаваемой дальше по цепочке вместе со сменой статуса.
В первом случае информационная модель задачи гораздо сложнее. Подзадача категории "Проверить как Илья реализовал функцию X" не самодостаточна - для проверки нужно знать как эта задача ставилась. Эта информация будет либо дублироваться в нескольких подзадачах, со всеми вытекающими из дублирования данных аномалиями, либо нужно будет смотреть постановку в другом месте: предыдущей задаче, либо родительской задаче. Не уверен, что такое усложнение оправдано.
По поводу статуса - разные люди работают с задачей на разных этапах. Кто-то вносит новую задачу, менеджер или дев лид назначают приоритет и исполнителя, разработчик реализует, тестировщик проверяет и т.д. Каждому нужно, в идеале, видеть только те задачи, которые _сейчас_ требуют его участия. Именно это и достигается с помощью статуса (new, assigned, implemented, verified) и фильтрации по оному. В общем, типичный workflow.
Да, можно хранить данные в двух системах. Но я пока не видел на практике ни одного нормального способа синхронизации, а иметь рассогласованные данные - небольшое удовольствие. Лично я предпочитаю единую систему, пусть и несколько менее функциональную чем сумма двух других.
Как вариант - можно импортировать данные из Issue Tracking в Project и использовать его только для мониторинга и отчетов. Такое использование Project'а выглядит вполне осмысленным.
«Project позволит вам случайно поменять ID задачи». Не очень понял о каком ID говорит автор – как такового ID в Project не припомню. А вообще он позволяет удалять задачу, ай-яй... Наверное думать надо прежде чем что-то делаешь, а не списывать на случайности.
«Надо что-то делать с жизненным циклом задачи». Надо – делаем. Например, добавляем новые подзадачи. В чем проблема – не совсем понятно. Если мы хотим спланировать работу по каждому из исполнителей (один уровень детализации) – добавляем отдельные подзадачи.
Насколько я понял, мы оба при обсуждении этих пукнтов подходим к Project как к хранилищу информации. Мои претензии сводятся к тому, что Project - плохое хранилищу информации, потому что не соответствует нескольким базовым требованиям. А именно:
Один из базовых принципов хранения информации состоит в том, что информация не должна удаляться безвозвратно. То что в большинстве систем учета чего бы то ни было вместо физического удаления записи используется поле `deleted` - пример реализации этого принципа. Я не знаю аналогичного механизма в project'е
Данные должны быть структурированы. Project плохо справляется со структурированием информации о задачах в области разработки ПО, что и ведет к необходимости эмулировать статус через подзадачи и другим подобным фокусам. Напомню, что основная проблема неструктурированных данных не к том что их неудобно вносить или читать, а в том, что по ним практически невозможно построить отчет или сделать поиск. Между тем, повседневная работа со сколько-нибудь большой базой задач заставляет каждого участника проекта пользоваться поиском по многу раз в день.
Rails реально дает прирост в два, максимум три раза и только начиная со второго проекта, когда разработчикам не нужно лазить в книжку каждые пять минут.
Количество людей в отрасли почти не изменилось (падение после кризиса доткомов скомпенсировано последующим ростом), некоторое повышение продуктивность отдельного программиста съедено повышением сложности типичного "сложного" проекта. С чего бы в этих условиях увеличиваться числу крупных проектов?
> Официально PHP/FI 2.0 вышел только в ноябре 1997 года, после проведения большей части своей жизни в бета-версиях. Вскоре после выхода его заменили альфа-версии PHP 3.0.
> PHP 3.0 был официально выпущен в июне 1998 года после 9 месяцев публичного тестирования.
Скажите, много ли было в 2000-м году (1997 + 3 года) крупных и известных ресурсов, написанных на PHP? Мне что-то все C++/CGI вспоминается...
Так что большие системы на Rails уже вовсю создаются и раскручиваются, просто их еще, по причине молодости, не заметно.
В контексте хорошо технологизированного процесса разработки программных продуктов я предпочитаю удобство работы.
Многие системы issue tracking'а предоставляют возможность настроить свой набор статусов и переходов между ними. Даже если эти настройки общие для всех проектов, то это позволит закрыть более 80% случаев, если, конечно, в организации есть какая-то технология работы. Если нет - то workflow инструменты этой огранизации тоже не нужны
Для меня терминология выглядит следующим образом:
- Багтреккинг, issue tracking - workflow инструмент, используется всеми участниками проекта для учета багов, проблем, задач и т.п.
- Planning, project tracking - высокоуровневый взгляд на планы и текущее состояние. Используется менеджером, иногда еще и лидами. В идеале данные берутся из системы issue tracking'а, либо это вообще одна и та же система.
- CRM - учет клиентов, их представителей и взаимодействия с ними. В идеале сюда же вносятся все обещания, сделанные заказчику (управление требованиями). Используется только теми, кто общается с заказчиками.
Соответственно, CRM для меня никак не касается темы данного обсуждения.
Вопрос в том, как удобнее представлять этапы выполнения задачи - связанными подзадачами, назначаемыми отдельным людям или одной задачей, передаваемой дальше по цепочке вместе со сменой статуса.
В первом случае информационная модель задачи гораздо сложнее. Подзадача категории "Проверить как Илья реализовал функцию X" не самодостаточна - для проверки нужно знать как эта задача ставилась. Эта информация будет либо дублироваться в нескольких подзадачах, со всеми вытекающими из дублирования данных аномалиями, либо нужно будет смотреть постановку в другом месте: предыдущей задаче, либо родительской задаче. Не уверен, что такое усложнение оправдано.
Да, можно хранить данные в двух системах. Но я пока не видел на практике ни одного нормального способа синхронизации, а иметь рассогласованные данные - небольшое удовольствие. Лично я предпочитаю единую систему, пусть и несколько менее функциональную чем сумма двух других.
Как вариант - можно импортировать данные из Issue Tracking в Project и использовать его только для мониторинга и отчетов. Такое использование Project'а выглядит вполне осмысленным.
Согласен, что в качестве отчетника Project хорош.
Насколько я понял, мы оба при обсуждении этих пукнтов подходим к Project как к хранилищу информации. Мои претензии сводятся к тому, что Project - плохое хранилищу информации, потому что не соответствует нескольким базовым требованиям. А именно:
Я добавил в текст небольшой обзор issue tracking систем, которые можно использовать в качестве своей первой системы такого рода