Один старый друг задал мне хороший вопрос - как подготовить программный проект к передаче другому менеджеру - какая документация необходима?
Исходя из своего прошлого - описал ему свое видение - "на мой выпуклый глаз" (с) - как обычно это происходит в больших разработках. Потом подумал и решил оставить это тут - мало ли кому еще пригодиться?
Итак, хороший тон - есть корпоративная wiki + feature/bug-тракер, в которых ведутся документация и разработка соотвественно - они и есть основной источник всех знаний о проекте.
Большие компании обычно используют связку Jira+Confluence (но не обязательно) - есть и много других вариантов (Redmine, MantisBT и прочие). Хотя на мой вкус, сравниться с грамотно настроенной Jira, которая проинтегрирована в Конфу - не может никто ;-)
В Wiki и ведется общая документация, то есть - составляются изначальные технические требования к продукту, пишется roadmap по версиям, рисуются usecase использования и т.д.
Исходя из тех требований и версий - собственно, потом и расставляются задачи по людям в зависимости от версий и так далее.
Степень готовности проекта оценивается исходя из "выполненности" задач разработчиками и тестерами.
Все вышесказанное - хороший путь - если ресурсы позволяют делать "по уму".
Если же нет - то от продукта "в общем" необходима следующая документация - что-где-когда? - я тут смешаю технические и менеджерские знания.
Что имеет смысл запросить от предыдущего владельца?
Исходя из своего прошлого - описал ему свое видение - "на мой выпуклый глаз" (с) - как обычно это происходит в больших разработках. Потом подумал и решил оставить это тут - мало ли кому еще пригодиться?
Большие компании обычно используют связку Jira+Confluence (но не обязательно) - есть и много других вариантов (Redmine, MantisBT и прочие). Хотя на мой вкус, сравниться с грамотно настроенной Jira, которая проинтегрирована в Конфу - не может никто ;-)
В Wiki и ведется общая документация, то есть - составляются изначальные технические требования к продукту, пишется roadmap по версиям, рисуются usecase использования и т.д.
Исходя из тех требований и версий - собственно, потом и расставляются задачи по людям в зависимости от версий и так далее.
Степень готовности проекта оценивается исходя из "выполненности" задач разработчиками и тестерами.
Все вышесказанное - хороший путь - если ресурсы позволяют делать "по уму".
Если же нет - то от продукта "в общем" необходима следующая документация - что-где-когда? - я тут смешаю технические и менеджерские знания.
Что имеет смысл запросить от предыдущего владельца?
- изначальные технические требования к продукту и список того, что поменялось за время разработки - чего должно быть?
- архитектура и используемые технологии - как оно работает?
- usecases использования - желательно в UML - как используется?
- расписанный roadmap по версиям - когда, собственно?
- текущее положение проекта - что уже сделано, что осталось?
- estimate - когда сделается?
- схема и описание инфраструктуры проекта. Это список репозиториев с кодом, production/staging/test серверов, баз данных и так далее с доступами. Собственно - где и что крутится?
- How-to / база знаний - например, как настроить/развернуть новый сервер?
- имеющиеся проблемы в проекте"в-общем" и предлагаемые способы их решения - как технические, так общие и по людям, занятым в проекте (например, тестер Ипполит пьет горькую и опаздывает на работу ;-) )
Ну вот как-то так...
