twitterfacebookrss

Проектные ошибки

ошибки

Ошибки – это прекрасно. Ошибки позволяют нам расти. Конечно, порой, они рушат сроки, бюджеты, здоровье, но, в целом, они являются одной из разновидностей тех кирпичиков опыта, на которых вырастает наш профессионализм.

На мой взгляд, каждый проект является в некотором роде полигоном для разработчиков – все участники пытаются применить все свои навыки, все лучшие практики, которые они освоили в предыдущих проектах. А конкретно программистам приходится тяжелее всего – технологии развиваются с огромной скоростью, и пока пару лет пишется последний проект, обязательно выйдет несколько новых фреймворков, которые уж точно решат все проблемы. Ну как их не опробовать в новом проекте?!

На самом деле, я уже перешёл к первой, типичной ошибке, встречающейся в проектах – надежда на новую технологию\платформу\фреймворк.

Основная проблема новых технологий в том, что они новые – в программировании обычно это значит, что обязательно в процессе эксплуатации выявятся какие-либо проблемы, ошибки, или на освоение уйдёт слишком много времени (хотя на освоение обычно закладывается время). Соответственно, неизвестность это всегда большой риск, а риски всегда пытаются минимизировать.
В нашем Проекте 1 я решил отказаться от стандартного механизма постраничной выборки (пейджинга), который предлагает Microsoft, из-за того, что этот механизм накладывает ограничение на архитектуру. Было решено взять стандартный GridView и добавить к нему функциональность пейджинга. Работа заняла больше время, чем я изначально рассчитывал, плюс был найден баг Microsoft, что также попортило крови. Я даже твёрдо пообещал себе, что если с новым GridView возникнут неразрешимые проблемы, я пару ночей буду переписывать всё на стандартный Grid. К счастью, нашего профессионализма оказалось достаточно.

Итак, эта была первая ошибка.

Идём дальше:

  • Следующая ошибка заключалась в том, что изначально не был разработан и принят единый стиль оформления пользовательских форм и пользовательских сообщений. Когда, наконец, волевым решением был принят дизайн, были утверждены сообщения, масса времени ушла на приведение всего этого в соответствие.
  • Не была принята единая стратегия обработки ошибок. Опять же, ушло время на переписывание.
  • Процесс разработки осуществлялся по методологии waterfall, и его большой недостаток, в плане того, что тестирование осуществляется после всей разработки, вдарил по нам со всего маху. Могу в своё оправдание сказать, что на тот момент у нас в кампании даже не было штатной единицы тестера, но в любом случае, это вина руководителя проекта, что он не смог обеспечить проект всем необходимым.
  • Мы не успели сделать интеграционное тестирование. Это добавило бы качества проекту.

Это все крупные ошибки.

Выводы:

  • «потом» обычно означает «никогда».
  • все ошибки должны быть проанализированы и записаны в виде «check»-листов на будущее.
  • новые технологии в проекте = новые риски.
  • waterfall пусть он даже и хорошо подходит для проекта, лучше заменить на что-нибудь итерационное, чтобы тестирование началось как можно раньше.
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс
Автор статьи: Александр Шибанов

Александр Шибанов IT - предприниматель с более чем 10 летним стажем в индустрии. Принимал участие в различных по сложности проектах, на позициях программиста и руководителя проектов. С 2011 - года индивидуальный предприниматель.

Комментарии:

1 Comment

Написать комментарий