Комментарии 8
Ну сколько можно одно и тоже писать?
0. Не прикрывайте отсутствие аналитики гибкими методологиями разработки
«Документируйте планирование с помощью подходящей программы багтреккинга»
Пожалуйста, замените багтрекинг на тасктрекинг. Вы, вероятно, не видите разницы, но вообще баг не может быть спланирован. Могут быть спланированы задачи для устранения этого бага, и их связь с багом — многие ко многим.
Пожалуйста, замените багтрекинг на тасктрекинг. Вы, вероятно, не видите разницы, но вообще баг не может быть спланирован. Могут быть спланированы задачи для устранения этого бага, и их связь с багом — многие ко многим.
1. Планировать сроки должны программисты, а не менеджеры
Планировать сроки должны программисты, совместно с QA. Зачастую однострочное изменение тянет за собой пару дней на изменение тестов, не говоря уже об их прогоне.
> 4. Члены команды должны максимально плотно взаимодействовать друг с другом
На практике это тяжело сделать. Если команда маленькая и проектов больше чем людей, то каждому суждено вариться в своем хозяйстве и на вникание в чужое тупо не будет времени. Если команда побольше, то уже будет разделение по обязанностям и все равно проектировщик базы вряд ли будет вникать в нюансы фронтэнда. Не было опыта работы в совсем больших коллективах, наверное, там это применимо.
От себя добавлю любимый принцип «Сокращать асапы». Всякий раз когда мы на практике пытаемся применить методологии разработки вместо банального выделения приоритетных задач в трекере, обязательно возникают задачи плана «баг в проекте нужно закрыть не позднее вечера» или «клиент заплатил нам за эту функциональность, запуск уже завтра» и вся методология ломается. Асапы — это, конечно, неизбежное зло, но с точки зрения менеджера/аналитика нужно понимать последствия (говнокод, в продакшн без тестирования — как в Марсианине ракету запускали, куча нервов) и выставлять задачу как критическую только в критическом случае.
На практике это тяжело сделать. Если команда маленькая и проектов больше чем людей, то каждому суждено вариться в своем хозяйстве и на вникание в чужое тупо не будет времени. Если команда побольше, то уже будет разделение по обязанностям и все равно проектировщик базы вряд ли будет вникать в нюансы фронтэнда. Не было опыта работы в совсем больших коллективах, наверное, там это применимо.
От себя добавлю любимый принцип «Сокращать асапы». Всякий раз когда мы на практике пытаемся применить методологии разработки вместо банального выделения приоритетных задач в трекере, обязательно возникают задачи плана «баг в проекте нужно закрыть не позднее вечера» или «клиент заплатил нам за эту функциональность, запуск уже завтра» и вся методология ломается. Асапы — это, конечно, неизбежное зло, но с точки зрения менеджера/аналитика нужно понимать последствия (говнокод, в продакшн без тестирования — как в Марсианине ракету запускали, куча нервов) и выставлять задачу как критическую только в критическом случае.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
8 принципов планирования разработки, упрощающих жизнь