Хочу поделиться практическим опытом внедрения гибких методологий на проектах по веб-разработке высокой и средней сложности и предостеречь от коварных рисков.
В большинстве простых интернет-проектов «упрощение» классических процессов разработки работало хорошо, гибкость помогала, но в относительно больших и сложных наблюдались «искры высокого напряжения» с частичным летальным исходом.
Поехали.
Есть гибкие методологии разработки (Agile), такие как Scrum, простые и постигаемые за пару дней. А есть «жесткие», увесистые, требующие многомесячного погружения, такие как RUP.
Гибкие методологии убеждают нас «поверить», что из-за того, что требования постоянно меняются, можно к черту отказаться от многолетнего опыта разработки программного обеспечения, впитанного классическими методологиями, тем же «водопадом», все решительно упростить и броситься в объятья «коммунистической» свободы, честности и равенства.
А чего бояться-то? Сумасшедшие бородатые специалисты говорят о процессах, артефактах, матрицах зависимости (Requirements Traceability Matrix) — а мы в рубахе, босиком, раз и… запрограммируем любой интернет-проект за 3 спринта! Ура, товарищи, к победе.
Так вот, «упрощение», предлагаемое гибкими методологиями, очень условное и коварное. «Расслабились» с одной стороны, придется хорошенько поднатужиться с другой.
Самое ужасное, что мне приходилось лицезреть в сфере разработки ПО, это бестолковое внедрение простых управленческих фреймворков типа Scrum при практически полном игнорировании необходимых в таких случаях инженерных практик экстремального программирования (XP), ведущее к катастрофическим последствиям как для качества реализуемых проектов, так и их сроков выполнения.
Проекты быстро превращались в помойку и сразу направлялись в дом престарелых чтобы умереть, так и не начав полноценную жизнь.
Именно жесткие, выработанные кровью и потом практики XP, практики выживания в условиях хаоса только и способны сбалансировать ситуацию и запустить успешный, ведущий к цели процесс разработки!
В свете вышеуказанных «ужасов», хочу порционно рассказывать о рисках, которые таятся в гибких методологиях разработки ПО на примере Scrum и известных мне способах их снижения.
Начнем с комплектования команды в реальных условиях суровой действительности.
Рассмотрим типичные роли в проекте по веб-разработке на PHP/MySQL.
Кроме общего технического образования и знания основ прикладной математики, сотруднику необходимо детально разобраться в технологии/языке программирования, а не лазать по любому поводу в google.
Профильных высших учебных заведений, готовящих веб-разработчиков у нас, к сожалению, пока нет.
В основном встречаются самоучки, не обладающие необходимым минимумом. Иногда это бывшие верстальщики/тестировщики, которые хотят повышения зарплаты — коллеги часто не понимают для чего необходимо добавлять индексы в SQL-таблицы, а о реляционной алгебре, ООП и теории алгоритмов и говорить нечего. При этом люди «уверенно» пишут «объектно-ориентированный» г… код, иногда связанный с обработкой финансовых транзакций, причем быстро :-)
Выход один — учить своими силами, прикрепить к знающему теорию и закаленному в проектах разработчику, отправить на сертификацию Zend.
Хорошие, опытные программисты, часто знающие другие, «сложные» языки программирования типа java, C# и мимоходом изучившие PHP иногда конечно попадаются, но редко. Таких нужно обязательно заиметь в команде, дальше расскажу для чего.
Для контроля качества работы «в основном неопытных» программистов настоятельно рекомендую проводить аудит кода опытным дорогим программистом, хорошо разбирающимся в вопросах безопасности и использовать вспомогательные инструменты для частичной проверки на кодестайл.
Если код не проверять, то возникнут и начнут размножаться объектно-ориентированные извращения и код не родившись — протухнет.
Взял в кавычки. Вообще то программист должен хотя бы раз в жизни прочитать SQL-стандарт и уверенно проектировать и работать с СУБД, но, к сожалению такое случается редко. Разработчик как правило может хорошо знать одну СУБД, но сильно плавать в другой СУБД.
Поэтому иногда выделяют особую роль специалиста по SQL, который может быть и аналитиком, и архитектором, и системным администратором — лишь бы разбирался хорошо в реляционной теории и конкретных СУБД.
ВУЗа для верстальщиков тоже нет. Самоучки. Декларативная теория «верстания» значительно проще программирования, но требует знания большого количества особенностей и тонкостей, поэтому и выделилась в особое ремесло.
Для контроля качества работы можно, в принципе, частично использовать автоматизированные средства проверки на соответствия веб-стандартам (w3c) и проверять визуально в разных браузерах.
Верстальщик может со временем и после прочтения нескольких увесистых книг по теории разработки ПО и усердной практики стать программистом, но это бывает редко.
Особая роль для «особо умных и задумчивых». Требуется аналитический склад ума, внимание к мелочам. Неплохие аналитики получаются из физиков и математиков, но и другие специальности встречаются. Если аналитик выучит UML или любую другую методологию проектирования, то получится супер-аналитик, способный выразить требования на языке, понятном разработчику.
Очень ответственная роль, требующая углубленных знаний шаблонов проектирования, серьезного опыта разработки и, что важно, поддержки программных систем. К сожалению, архитекторами становятся только опытным путем, завалив не один проект. А определить, что в системе проблемы с заложенной архитектурой иногда можно не сразу, а через определенное время, когда уже поздно что-либо менять.
Некоторые люди думают, что тестировщик выполняет в проектах саму тупую и неблагодарную работу. На самом деле это от незнания. Хороший тестировщик (профильных ВУЗов тоже нет), занимающийся самообразованием, может составить качественный план тестирования и написать автоматизированные тесты, а плохой — будет вяло и бесцельно тыкать по страницам сайта, оставляя баги живыми.
Есть курсы от некоторых вендоров, например RedHat, готовящих системных администраторов, но без углубленный практики настоящий системный администратор вряд ли получится. А проверить качество работы можно, как правило, лишь после серьезной аварии при восстановлении данных из бэкапа.
А теперь применим полученные практические знания о ролях в команде к декларируемых в Scrum/XP приемах и постараемся получить работающее решение.
Как видим, роли все очень разные, требующие глубоких специфических знаний и опыта. На практике сотрудники лишь частично взаимно обогащают друг друга знаниями из разных областей, но кроссфункциональностью, о которой говорит нам Scrum — и не пахнет. С натяжкой можно говорить о взаимозаменяемости лишь среди представителей одной роли, но и там люди с разной квалификацией и опытом и это не всегда работает.
Если специалист неопытный, за ним нужно обязательно следить более опытному. Не рекомендую сажать вместе (практика XP) двух неопытных — сделают в 2 раза хуже.
Получается, что за представителями каждой роли, по-хорошему, должен следить «старший наставник». Это может быть функциональный менеджер (руководитель отдела) либо старший специалист (ведущий разработчик/аналитик/сисадмин), обладающий необходимой компетенцией и несущий прямую ответственность за качество работы контролируемого.
Понимаем, что если не обеспечить должного уровня контроля качества работы профильных сотрудников мы получим плохой и дорогой в поддержке код, поверхностную аналитику, бестолковую архитектуру и дырявое тестирование.
Вот и получили из парного программирования — «полупарное», с наличием профильных ответственных специалистов, а из кроссфункциональной команды — лишь призрачный обмен опытом (кто решиться дать верстальщику поправить биллинговый код).
Итак, некоторые практические риски рассмотрели. В будущем посте поговорим о рисках управления — лидерстве, раздолбайстве в командах, коллективной безответственности, псевдо-прогрессе и как с этим эффективно бороться.
В большинстве простых интернет-проектов «упрощение» классических процессов разработки работало хорошо, гибкость помогала, но в относительно больших и сложных наблюдались «искры высокого напряжения» с частичным летальным исходом.
Поехали.
Гибкие и «жесткие»
Есть гибкие методологии разработки (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 — и не пахнет. С натяжкой можно говорить о взаимозаменяемости лишь среди представителей одной роли, но и там люди с разной квалификацией и опытом и это не всегда работает.
Контроль качества работы — иерархия ответственности
Если специалист неопытный, за ним нужно обязательно следить более опытному. Не рекомендую сажать вместе (практика XP) двух неопытных — сделают в 2 раза хуже.
Получается, что за представителями каждой роли, по-хорошему, должен следить «старший наставник». Это может быть функциональный менеджер (руководитель отдела) либо старший специалист (ведущий разработчик/аналитик/сисадмин), обладающий необходимой компетенцией и несущий прямую ответственность за качество работы контролируемого.
Понимаем, что если не обеспечить должного уровня контроля качества работы профильных сотрудников мы получим плохой и дорогой в поддержке код, поверхностную аналитику, бестолковую архитектуру и дырявое тестирование.
Вот и получили из парного программирования — «полупарное», с наличием профильных ответственных специалистов, а из кроссфункциональной команды — лишь призрачный обмен опытом (кто решиться дать верстальщику поправить биллинговый код).
Итак, некоторые практические риски рассмотрели. В будущем посте поговорим о рисках управления — лидерстве, раздолбайстве в командах, коллективной безответственности, псевдо-прогрессе и как с этим эффективно бороться.
