Хочу поделиться своим практическим опытом внедрения гибких методологий на проектах веб-разработки высокой и средней сложности и предостеречь от коварных рисков.
В большинстве простых интернет-проектов «упрощение» классических процессов разработки работало хорошо, помогала гибкость, но в относительно крупных и сложных наблюдались «искры высокого напряжения» с частичным летальным результатом.
Идти.
Гибкий и «жесткий»
Существуют гибкие методологии разработки (Agile), такие как Scrum, которые просты и их можно освоить за пару дней.А есть «жесткие», весомые, требующие месяцев погружения, такие как RUP. Гибкие методологии убеждают нас «поверить», что из-за того, что требования постоянно меняются, мы можем выбросить многолетний опыт разработки программного обеспечения, поглощенный классическими методологиями, тот самый «водопад», радикально все упростить и броситься в объятия «коммунистическая» свобода, справедливость и равенство.
Чего бояться? Сумасшедшие бородатые специалисты рассказывают о процессах, артефактах, матрицах зависимостей (Requirements Traceability Matrix) — а мы в рубашках с рукавами, босиком и.
любой интернет-проект запрограммируем за 3 спринта! Ура, товарищи, победе.
Итак, «упрощение», предлагаемое гибкими методологиями, весьма условно и коварно.
«Расслабившись», с одной стороны, вам придется сильно поднапрячься, с другой.
Мы используем Agile, но забыли практики XP?
Худшее, что я видел в сфере разработки ПО, — это бестолковое внедрение простых фреймворков управления типа Scrum с практически полным игнорированием требуемых в таких случаях инженерных практик экстремального программирования (XP), что приводит к катастрофическим последствиям как для качества, так и для качества программного обеспечения.реализованные проекты и сроки их выполнения.
Проекты быстро превратились в хлам и были немедленно отправлены в дом престарелых умирать, так и не начав полноценной жизни.
Именно жёсткие практики XP, выработанные кровью и потом, практики выживания в хаосе — единственные, способные сбалансировать ситуацию и запустить успешный процесс разработки, ведущий к цели! В свете вышеперечисленных «ужасов» хотелось бы по частям рассказать о рисках, таящихся в гибких методологиях разработки ПО, на примере Scrum и известных мне способах их снижения.
Начнём со сбора команды в реальных условиях суровой реальности.
Кадровые риски
Давайте посмотрим на типичные роли в проекте веб-разработки PHP/MySQL.PHP-программист
Помимо общего технического образования и знаний основ прикладной математики, сотруднику необходимо детально разбираться в технологии/языке программирования, а не лазить по Google по любому поводу.К сожалению, у нас пока нет профильных высших учебных заведений, готовящих веб-разработчиков.
В основном это самоучки, у которых нет необходимого минимума.
Иногда это бывшие верстальщики/тестеры, желающие повышения зарплаты — коллеги часто не понимают, зачем нужно добавлять индексы в SQL-таблицы, а про реляционную алгебру, ООП и теорию алгоритмов и говорить нечего.
При этом люди «уверенно» пишут «объектно-ориентированный» код, иногда связанный с обработкой финансовых транзакций, и быстро :-) Выход один — обучить самостоятельно, поручить разработчику, знающему теорию и закаленному в проектах, и отправить на сертификацию Zend. Хорошие, опытные программисты, часто знающие другие, «сложные» языки программирования типа Java, C# и случайно изучившие PHP, иногда конечно попадаются, но редко.
В вашей команде обязательно должны быть такие люди, позже расскажу почему.
Чтобы контролировать качество работы «в основном неопытных» программистов, я настоятельно рекомендую поручить аудит вашего кода опытному, дорогому программисту, хорошо разбирающемуся в вопросах безопасности, и использовать вспомогательные инструменты для частичной проверки стиля кода.
Если код не проверять, то возникнут и начнут размножаться объектно-ориентированные извращения, и код сгниет, не успев родиться.
«Специалист по SQL»
Я взял это в кавычки.В общем, программист должен хотя бы раз в жизни прочитать стандарт SQL и уверенно проектировать и работать с СУБД, но, к сожалению, это происходит редко.
Разработчик, как правило, может хорошо знать одну СУБД, но очень свободно владеть другой СУБД.
Поэтому иногда особая роль отводится специалисту по SQL, который может быть аналитиком, архитектором или системным администратором — при условии, что он хорошо разбирается в реляционной теории и конкретных СУБД.
верстальщик
Также нет университета для верстальщиков.Самоучка.
Декларативная теория «верстки» гораздо проще программирования, но требует знания большого количества особенностей и тонкостей, поэтому стала особым ремеслом.
Для контроля качества работы в принципе можно частично использовать автоматизированные средства проверки на соответствие веб-стандартам (w3c) и проверять визуально в разных браузерах.
Программист может со временем и после прочтения нескольких увесистых книг по теории разработки ПО и усердной практики стать программистом, но это случается редко.
Аналитик
Особая роль для «особо умных и думающих».Требуется аналитический склад ума и внимание к деталям.
Из физиков и математиков получаются хорошие аналитики, но существуют и другие специальности.
Если аналитик изучит UML или любую другую методологию проектирования, он станет супераналитиком, который сможет выражать требования на языке, понятном разработчику.
Архитектор
Очень ответственная роль, требующая глубоких знаний паттернов проектирования, значительного опыта разработки и, что немаловажно, поддержки программных систем.К сожалению, люди становятся архитекторами только благодаря опыту, провалив не один проект. Причем определить, что в системе есть проблемы с базовой архитектурой, иногда можно не сразу, а через определенное время, когда уже поздно что-либо менять.
Тестер
Некоторые считают, что самую глупую и неблагодарную работу в проектах делает тестировщик.На самом деле это происходит от незнания.
Хороший тестировщик (профильных вузов тоже нет), занимающийся самообразованием, может составить качественный план тестирования и написать автотесты, а плохой будет вяло и бесцельно ковыряться по страницам сайта, оставляя ошибок в живых.
Сисадмин
Есть курсы от некоторых вендоров, например RedHat, которые обучают системных администраторов, но без углубленной практики вы вряд ли станете настоящим системным администратором.А проверить качество работы можно, как правило, только после серьезной аварии при восстановлении данных из резервной копии.
Теперь применим полученные практические знания о ролях в команде к методикам, заявленным в Scrum/XP, и попробуем получить работающее решение.
Кросс-функциональность в проектных командах — миф
Как видите, роли все очень разные, требующие глубоких специфических знаний и опыта.На практике сотрудники лишь частично взаимно обогащают друг друга знаниями из разных областей, но от кросс-функциональности, о которой нам говорит Scrum, не осталось и следа.
Говорить о взаимозаменяемости только среди представителей одной роли можно с натяжкой, но и там люди имеют разную квалификацию и опыт, и это не всегда работает.
Контроль качества – иерархия обязанностей
Если специалист неопытен, его должен контролировать более опытный.Не советую ставить двух неопытных людей (практика ХР) - сделают в 2 раза хуже.
Получается, что за представителями каждой роли, по-хорошему, должен следить «старший наставник».
Это может быть функциональный руководитель (руководитель отдела) или старший специалист (ведущий разработчик/аналитик/системный администратор), обладающий необходимой компетенцией и несущий прямую ответственность за качество работы контролируемого лица.
Мы понимаем, что если не обеспечить должный уровень контроля качества работы профильных сотрудников, то в итоге получим плохой и дорогой в обслуживании код, поверхностную аналитику, дурацкую архитектуру и дырявое тестирование.
Так что от парного программирования мы получили «полупарное», с наличием профильных ответственных специалистов, а от кросс-функциональной команды мы получили лишь призрачный обмен опытом (кто посмеет позволить верстальщику поправить код биллинга) .
Итак, были учтены некоторые практические риски.
В следующем посте мы поговорим об управленческих рисках — лидерстве, невнимательности в командах, коллективной безответственности, псевдопрогрессе и о том, как с этим эффективно бороться.
Теги: #scrum #agile #agile
-
Гибкая Система Управления Проектами Acunote
19 Oct, 24 -
Экспорт Данных Mocap В Unity3D
19 Oct, 24 -
Обучение Ruby И Rails, Частные Уроки
19 Oct, 24
