Не совсем по теме поста вопрос... А проектные документы вы пишите? Тз, blueprint на основное приложение и интеграцию с другими приложениями/проектами, описание разработок и настроек, матрица полномочий, сценарии тестирования, руководства для пользователей и администраторов?
Если кратко, то да - по всем пунктам. Только может названия немного другие у документов. Стандартный "пакет документов": - Global Reference Model - Functional Requirements Specification - Technical Specification - User Acceptance Test Scripts - документация, в ассортименте.
Декомпозиция, про которое я написал, происходит после завершения FRS. Этот-же документ используется при оценке сроков и стоимости.
Мы столкнулись с проблемой что у нас не работает стандартный скрам и вследствие чего Ривотал тоже шалит.
Грубо говоря, у нас люди не работают над одним или даже двумя проектами одновременно, у нас минимум 5 на брата, а иногда и больше и приоритеты по проектам, а также зависимость от разных вендоров и прочих людей делает невозможным приоритизировать раз и на всегда, приходится постоянно находиться в переприатизационном цикле.
Из-за этого разбитие на проекты не помогает так как невозможно видеть фронт работ и milestones по всем проектам. Делать же из всех проектов метки и работать в одном "проекте" тоже не подходит, так как невозможно нормально следить из-за огромного потока задач.
Ну и оверхед по трэкингу существенный, к сожалению - на наших мелких задачках, слишком уж перевешивает.
Классический скрам, насколько я понимаю, предполагает что задачи ставит и приоритетизирует "владелец продукта" - команда только "разгребает" поставленные задачи. Если у вас люди - "сами-себе владельцы и исполнители, и менеджеры проекта" и так пять раз, то, конечно, при любом формальном управлении расходы на него будут недопустимо велики. Хотя, я боюсь, при таком подходе накладные расходы на переключение между проектами будут еще выше.
Но ведь в любом случае - хотя бы таск-лист надо иметь? Вы как работаете-то? Поделись.
Неа, в результате таск листа нету, но есть список проектов и каждый утром говорит над чем будет работать, плюс мы примерно обсуждаем что поменялось со вчерашнего дня.
Каждый владелец проекта ведет общий список этапов и иногда особенно важных задач (особенно go-live list чтобы минимизировать downtime), но не ведет детальный список задач для себя и всех разработчиков на этом проекте - знать что делать задача каждого девелопера.
Пришлось отдать возможность полностью контролировать процесс (что ввожит нашего прожект мэнеджера в транс), но зато даёт людям свободу и понимание что они владеют и управляют своим куском.
Ну, как ты понимаешь, на всё это накладывается постоянное отсутсвие вразумительных requirements и прототипирование и дадумывание за клиента, но PM и главный девелопер и я (начальник) стараемся дать проект разработчикам тогда когда у проекта есть хоть какая-то форма.
Comments 5
А проектные документы вы пишите? Тз, blueprint на основное приложение и интеграцию с другими приложениями/проектами, описание разработок и настроек, матрица полномочий, сценарии тестирования, руководства для пользователей и администраторов?
Reply
- Global Reference Model
- Functional Requirements Specification
- Technical Specification
- User Acceptance Test Scripts
- документация, в ассортименте.
Декомпозиция, про которое я написал, происходит после завершения FRS. Этот-же документ используется при оценке сроков и стоимости.
Reply
Грубо говоря, у нас люди не работают над одним или даже двумя проектами одновременно, у нас минимум 5 на брата, а иногда и больше и приоритеты по проектам, а также зависимость от разных вендоров и прочих людей делает невозможным приоритизировать раз и на всегда, приходится постоянно находиться в переприатизационном цикле.
Из-за этого разбитие на проекты не помогает так как невозможно видеть фронт работ и milestones по всем проектам. Делать же из всех проектов метки и работать в одном "проекте" тоже не подходит, так как невозможно нормально следить из-за огромного потока задач.
Ну и оверхед по трэкингу существенный, к сожалению - на наших мелких задачках, слишком уж перевешивает.
Короче, Пивотал у нас идёт плохо.
Reply
Если у вас люди - "сами-себе владельцы и исполнители, и менеджеры проекта" и так пять раз, то, конечно, при любом формальном управлении расходы на него будут недопустимо велики.
Хотя, я боюсь, при таком подходе накладные расходы на переключение между проектами будут еще выше.
Но ведь в любом случае - хотя бы таск-лист надо иметь? Вы как работаете-то? Поделись.
Reply
Каждый владелец проекта ведет общий список этапов и иногда особенно важных задач (особенно go-live list чтобы минимизировать downtime), но не ведет детальный список задач для себя и всех разработчиков на этом проекте - знать что делать задача каждого девелопера.
Пришлось отдать возможность полностью контролировать процесс (что ввожит нашего прожект мэнеджера в транс), но зато даёт людям свободу и понимание что они владеют и управляют своим куском.
Ну, как ты понимаешь, на всё это накладывается постоянное отсутсвие вразумительных requirements и прототипирование и дадумывание за клиента, но PM и главный девелопер и я (начальник) стараемся дать проект разработчикам тогда когда у проекта есть хоть какая-то форма.
Вот такая жопа.
Reply
Leave a comment