Стандарты и подходы к разработке софта
Обращали ли вы внимание на “двойные стандарты”, которых придерживаются не только политики, но и технари? ;) Ведь с одной стороны люди стремятся стандартизировать и унифицировать все, что попадается им на глаза, а с другой стороны хотят, чтобы было “не как у всех”.
И IT-мир не исключение. При разработке софта необходимо соблюдать четкие правила как при кодинге, так и при управлении командами, а также в проектной деятельности. Особенно это важно при создании сложных информационных систем или платформ, в разработке которых участвуют группы исполнителей с разной квалификацией, опытом и скиллами. Ведь написанный код должен компилироваться в единое приложение, работать без сбоев и легко поддерживаться.
Каждая компания сама решает, как ей работать.
Мы, в Севен Груп, применяем следующие стандарты и методологии:
# Чтобы ПО было чистым, читаемым и легко наследуемым, мы придерживаемся различных конвенций написания кода, которые стандартизируют и упорядочивают процесс разработки приложений. Например, Code Conventions for the Java TM Programming Language. Использование единого стиля программирования облегчает понимание и поддержку исходного кода, написанного более чем одним программистом, а также упрощает взаимодействие нескольких человек при разработке программного обеспечения.
# Чтобы разрабатываемые ИТ-сервисы выходили в срок и с необходимым качеством, внедрена релизная политика. Она определяет порядок выполнения работ, тип версии (плановая или срочная), планируемый набор изменений (в разрезе сервисов и подсистем), а также даты внесения обновлений на TEST, PRE-PROD и PROD контурах.
В частности, определяются взаимосвязи между командами. Собирается единый график для всех групп, которые разрабатывают смежные информационные системы или сервисы. И теперь уже не может случиться так, что функциональность в бэкенде готова к релизу, а во фронтенде — нет и т.д.
В конечно счете такая практика позволяет заранее выявлять проблемы в совместимости, тратить меньше времени на доработку и отладку системы, улучшить качество тестирования, сократить сроки внедрения и уменьшить количество ошибок на проде.
# Для успешной реализации проекта с постоянно меняющимися требованиями клиента, а также для создания качественных софтовых продуктов удобен Agile - набор руководящих принципов, разработанный в 2001 году и опубликованный как Agile–манифест. Он реализует поэтапный и итеративный подход к процессу разработки. Согласно Agile следует, например, разбивать большие проекты на более мелкие (и потому — управляемые) части. Scrum (фреймворк) и Kanban (метод улучшения качества сервиса) — два разных способа управления проектами в соответствии с принципами Agile с «тонкими» различиями. В своей работе мы применяем элементы и того и другого в зависимости от поставленной задачи.
# Scrum разбивает работу на ограниченные по времени части, которые называются спринтами (обычно они длятся две недели) и предполагает четкое разделение по ролям (Product-owner, Scrum-muster, Developer). Кроме этого, тут предписываются конкретные мероприятия - ежедневные встречи/Daily Scrum Meeting (для лучшего командного взаимодействия) и ретроспектива спринта (для разбора ошибок и выявления узких мест проекта).
# В то же время Kanban является менее структурированным, и основывается на списке задач, которые нужно выполнить. Он не имеет жесткого временного ограничения на исполнение элементов. Вместо этого, управление осуществляется приоритезацией задач на доске Kanban. Он может дать визуальное представление о том, что вы делаете сейчас. Доска Kanban играет важную роль в отображении рабочего процесса, и помогает оптимизировать задачи между различными командами. Это хороший инструмент для введения изменений с помощью дополнительных улучшений, а также хороший способ улучшения качества сервиса. Например, мы используем канбан в разработке для выявления узких мест в производстве, соблюдения очередности выпуска “фич” и фокусировки на первоочередных задачах.
Короче, если вы хотите, чтобы ваши проекты были завершены быстрее - то рекомендуется Scrum. Если же вы хотите улучшить производственный процесс, чтобы всё шло как по маслу, лучше применять Kanban.
Но, если ваши проекты требуют более линейного рабочего процесса, никуда не деться от водопадной модели.
# В силу того, что многие проекты, особенно с госзаказчиками, регламентированы жесткими ТЗ, сроками и бюджетом (FixPrice), единственным вариантом для их реализации является WaterFall. Хотя, конечно же, это не мешает внутри проекта устраивать “спринты” для скорости и “канбаны” управления отдельными задачами. Подробнее о проектных методологиях мы рассказываем здесь и здесь.
# Чтобы создавать сложные системы, привлекать различные команды к разработке, радовать клиента соблюдением сроков и качеством, мы используем лучшие практики проектного управления, в числе которых - PMI (англ., PMI — Project Management Institute). Стандарт PMI PMBoK — классификатор процессов, который помогает менеджерам рационально управлять проектами. Это фреймворк - своеобразная энциклопедия менеджмента. Этот свод «живой»: он регулярно обновляется и его можно адаптировать к любым процессам. При этом учитывается «зрелость» компании. Стандарт позволяет упорядочить и формализовать работу, определить требования к реализации и обеспечить документационное сопровождение проекта на всем протяжении жизненного цикла. Для повышения качества проектной деятельности нашей компании мы проводим обучающие семинары для сотрудников по управлению ресурсами, бюджетом, сроками и, конечно, рисками.