gifts2017

Управление проектами разработки и внедрения ПО на примере trackstudio

Опубликовал Алексей Какшинский (ETALON-A) в раздел Управление - Бизнес-процессы

Эффективность и успешность работ по внедрению или модернизации системы заказчика напрямую зависит от качества управления задачами по разработке.

Если у вас один клиент, или вы внедряете систему собственными силами, то, возможно, вам и удастся подручными средствами типа переписки по мылу и табличек в эксель управлять этим процессом и задачами. В случае, когда у вас несколько тысяч задач в месяц, то вы никогда не обеспечите требуемый уровень качества работы с заказчиками и собственными разработчиками-программистами без соответствующих инструментариев по управлению проектами разработки. Большинство использует редмайн, джиру и т.д. Мы же используем трекстудио из-за соотношения цены и качества. Неограниченное количество лицензий позволяет бесплатно подключать нужное количество пользователей, как со стороны заказчика, так и внутри компании.

Любые системы для разработки  подразумевают наличие стандартного или уникального жизненного цикла задачи, или требования. В данном примере мы нарисовали блок-схему, которая реализована в наших требованиях-задачах.

Рассмотрим, как это работает на практике:

Куратор заказчика создает требование или задачу, где пишет наименование задачи, и описывает так называемые хотелки, можно приложить нужные картинки. Выбираем исполнителя, и необходимую дату выполнения.

Можем заранее проставить бюджет в часах,  если мы системный аналитик или разработчик.

В описании пишем текст технического задания.

Также можем вставить какую-то картинку. Мозила Файрфокс поддерживает драг энд дроп и копипаст картинок в тело задачи. При сохранении требования статус присваивается «новый», и пока требование не принято в работу.

Для отправки требования в работу куратор заказчика нажимает кнопку «оценить разработчику» - эта задача у нас ставится на разработчика, или «оценить бюджет», задачу выполняет системный аналитик.

Можно задачу отклонить или поставить на паузу. В блок-схеме эти состояния выделены красным и зеленым цветом. Из отклонено возврата в начало нет, из паузы можно вернуться в то состояние, откуда была пауза.
Можно отправить сразу в разработку, если у нас нет необходимости согласовывать бюджет с заказчиком, или по договоренности с заказчиком мы выставляем стоимость после выполнения задачи. Иногда бывают такие задачи, которые заранее не оценить.

При переводе задачи на разработчика в описании мы можем что-то дописать для уточнения, и выбрать нужного разработчика из списка. В список автоматом попадают разработчики, имеющие доступ к данному проекту.

У разработчика задача появляется в списке задач, после чего разработчик должен оценить примерное время на выполнение данной задачи.

Задача приняла состояние Оценка бюджета, и системный аналитик должен проверить адекватность планируемого времени, который проставил разработчик, и конвертировать часы данного разработчика в деньги для заказчика, в данном случае рубли.

После оценки бюджета задача попадает к заказчику для утверждения бюджета (или отклонения)

Если бюджет утвержден, ТЗ может уточниться и переводится в разработку.

В процессе разработки, если задача закрывается не сразу, а выполняется с перерывами, можно отмечать промежуточные часы и результаты.

После завершения кодирования, задача уходит тестировщику, после, на тестирование заказчику.

Задачу можно оправить на доработку разработчику.

После утверждения заказчиком, задача закрывается и попадает в листы учета рабочего времени и акты выполненных работ.

https://youtu.be/cBVRP1PmiYI

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Франко Деллиани (Franco) 14.01.16 13:24
1.Ни один проект не начинается без уточнений. Если у разработчика нет вопросов к заказчику, то это либо гениальная постановка задачи либо «гениальный» аналитик или разработчик. А это всегда не так.У вас же разработчик не общается напрямую с заказчиком. Он общается с аналитиком, у которого с десяток проектов.
2.То же самое касается тестировщика.
3.Куратор заказчика напрямую уточнить требования разработчику - конечно же, для аналитика, разработчика или тестировщика это усложнение - а это изменение требований и изменение времени и изменение суммы. Это никак не оговаривается в программе. В итоге если заказчик что-то забыл изначально - он получит уже не то, что желал. Я не оправдываю такую ситуацию - я просто говорю, что жизнь такая.
В итоге - фигня.
---
А можно разрабатывать так, чтобы куратор заказчика видел результат каждого действия? Все версии сохранялись? Всегда можно было бы подкореектировать разработку? Вернуться к какой-либо версии? Пересчитать время? Изменить бюджет? В любой момент получить уточнения? Все эти уточнения фиксировать? При необходимости найти нужное уточнение? Искать в других проектах схожие задачи и подобные решения, чтобы с'экономить время?
2. Алексей Какшинский (ETALON-A) 14.01.16 17:30
(1) Franco,
В видеообзоре показан самый простой пример, в реальности все сложней. Я специально не вдавался в комбинаторику вариантов. Конечно же менеджер проекта на начальном этапе уточняет все нюансы, а также в процессе все могут обмениваться комментами и вопросами.
Жизненный цикл требования менялся уже не один раз, с учетом возникающих изменений, будет меняться и дальше....потому что как только вы прекратили менять свои процессы - значит вы деградируете...
>>А можно разрабатывать так, чтобы куратор заказчика видел результат каждого действия? - они видят инфу по этапам, могут настроить себе уведомления на каждый "чих", но видят то, что положено по доступу. По практике 99% заказчикам это не надо... нужен конечный результат по задаче, а то и по циклу. Чтобы "приучить" заказчика вовремя согласовывать бюджет, и то проблема. Если он будет отслеживать всю "движуху" - жизни точно не хватит.
>>Все версии сохранялись? Всегда можно было бы подкореектировать разработку? Вернуться к какой-либо версии? - это реализовано не на уровне данного трекера, а на уровне хранилищ. Это реализовано у мелкософта, совмещение изменений и кода, но там ценник лицензий 14 т. евро в год.
>>Пересчитать время? - да
>>Изменить бюджет? - да
>>В любой момент получить уточнения? - да
>>Все эти уточнения фиксировать? - да
>>При необходимости найти нужное уточнение?- да
>>Искать в других проектах схожие задачи и подобные решения, чтобы с'экономить время? - так и и делается, есть специальна кнопка "похожие задачи"
Прикрепленные файлы:
3. Алексей Попов (Aleskey_K) 20.01.16 08:30
использовали трек, перешли на девпром. стало удобнее, но он очень тормозит. функционал не покрывает всех требований.
4. Алексей Какшинский (ETALON-A) 20.01.16 12:05
(3) Aleskey_K,
>>использовали трек, перешли на девпром. стало удобнее, но он очень тормозит. функционал не покрывает всех требований.
Логичный вопрос: в чем тогда удобство...?
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа