Войти
Регистрация
1
Часть 1. Постановка процесса разработки и поддержки.
Опубликовал: Иксилимьюз,
18 Август 2012
·
2 157 Просмотров
Сразу хочется разделить два понятия: разработка и поддержка ПО.
Разработка это когда мы начинаем писать что-то с нуля, когда нет никакой реализации, есть только идея, и план следую по которому мы можем достичь поставленной цели. Это и проектирования, и разработка архитектуры ПО и все сопутствующие моменты.
Поддержка ПО, это когда в целом и общем проект уже сдан в эксплуатацию. Он работает, функционирует, но с течением времени, периодически у клиентов возникают пожелания, либо меняются законы и что бы программа работала правильно нужно менять какие-то расчеты, либо придумали новую фичу, которая позволит сделать программу более удобной - это все поддержка. То есть по сути, не нужно писать все с нуля, нужно просто дорабатывать имеющийся код, архитектуру, поддерживая таким образом проект, в актуальном состоянии.
Таким образом, отдел программистов очень важно изначально поделить на два подотдела. Часть программистов должны заниматься поддержкой готовых и работающих проектов. Другая же часть программистов всегда занимаются разработкой новых проектов, архитектур и так далее. Ведь для успешного бизнеса не обойтись одним проектом. Всегда появляются новые идеи, возможности и ниши, где можно что-то автоматизировать.
Очень важную роль играет корпоративная система, система контроля задач и ошибок.
То есть процесс должен идти не так что вот мы собрались. Обсудили. Кто что записал или на память запомнил, так и делаем. Такой вариант сразу можно выбросить из головы.
Да, собрания должны быть. Но результатом каждого обсуждения должна быть конкретно сформированная задача. И эта задача должна быть не на бумаге, а в корпоративном портале, где каждый может на неё посмотреть. А вообще назначается ответственный за задачу, который уже выбирает исполнителя. Исполнитель в свою очередь видит у себя список задач которые ему необходимо решить. И делает все для того что бы этот список не увеличивался, а уменьшался. Путем выполнения этих самых задач.
Таким образом мы легко можем отследить, кто чем занимается, у кого какой загруз, и кто занимается фигней вместо того что бы работать.
Корпоративная система распространяется не только на программистов, но и на других участников компании. А именно на тестировщиков, аналитиков, постановщиков задач. На мой взгляд будет правильно если начнет составлять тех задание аналитик. Затем направит его на доработку главному разработчику, или главному программисту поддержки. Тот уже откорректирует его и либо возьмет на исполнение, либо назначит другого исполнителя.
Далее, когда задача реализована, протестирована самим программистом, она отправляется на тестирование в отдел тестирования.
Теперь важный момент. Тестировщику может не понравится внешний вид выполненной задачи. Например некрасивая или не удобно расположенная кнопка. Либо надпись на форме не отражает сути. Он возвращает на доработку со своим комментарием. Этот случай можно считать не злокачественным возвратом. То есть программист не виноват что не умеет красиво рисовать кнопки. Ему простительно.
Но вот если программа выдает ошибки, не правильно себя ведет, и не выполняет своих функций, в таком случае конечно же виноват программист. И вот тут стоит фиксировать в корпоративной системе - количество возвратов. Допустим один-два возврата, это взять за норму. На то и есть отдел тестирования что бы контролировать ошибки. Но когда количество возвратов вырастает до 5-6, тут уже дело в программисте. То есть он либо не качественно пишет код, либо тянет резину, тем что сдает в тестирование задачу, которая заведомо не решена полностью. За такое нужно придумать меру наказания. Например если срываются сроки выполнения, по причине что задача летает туда-сюда, то пусть программист выходит в субботу и исправляет положение по срокам.
Ещё такой момент. Сборку версий, лучше всего так же переложить на тестировщика. Это сэкономит рабочее время программистов. А тестировщику не составит труда скомпилировать проект и собрать билд в нужном месте.
Считаю не будет лишним изложить тот факт, что программисты люди не обычные, и условия для них лучше всего создавать лояльные. Есть среди них индивиды которые могут продуктивно работать лишь в определенные часы суток. Поэтому не стоит заставлять их сидеть на работе с 9 до 18. Если у него в это время снижена продуктивность, вы его ни премией ни кулаком не заставите сделать больше работы. Пусть лучше если он может, делает часть работы дома. Затем приходит в офис в удобное для него время. И уходит тоже в удобное время. Самый главный показатель для программиста - это то как он укладывается в срок с выполнением задач. Поэтому если человек почти не появляется в офисе, но у него все в порядке с работой, то почему бы и нет. Пусть что хочет делает, лишь бы работа была выполнена.
Далее, тестирование.
Тестирование должно производиться в различных условиях. Во первых тут не обойтись без множества виртуальных тестовых стендов. То есть нужно тестировать работу программы на различных операционных системах, в различных условиях. Тестировать быстродействие, тестировать то, как корректно ведет себя программа на маленьких мониторах, то есть с низким расширением экрана. Доступны ли важные кнопки на таких экранах. Важно понять как это заработает если установить программу с нуля, и что будет если уже есть какая-то версия что будет после обновления, возникнут ли какие-то проблемы с совместимостью или нет. То есть тестировщик должен разработать специальны планы тестирования для каждого проекта отдельно. Что бы исключить перед выпуском максимум возможных исключительных ситуаций.
После того как тестировщики все протестировали, продукт или версия продукта направляется на тестирование аналитикам. После того как там дают добро, версию можно отдавать клиентам. Если обновление не критическое, можно в таком случае дождаться еще каких-то доработок. Все это уже согласовывается людьми разных отделов.
Далее готовую версию выкладывают клиентам. Либо через интернет либо другими способами. Думаю логично было бы возложить эту функцию на отдел технической поддержки. Таким образом они будут в курсе обновления и смогут об этом сказать клиентам, создать новость на сайте и просто это будет на мой взгляд правильнее.
По поводу информационного сопровождения. Если обновление не критическое то тестировщики могут сразу исправить пользовательское руководство, а потом уже выкладывать на сайт обновление. Если критическое, то сразу после выкладывания, тестировщикам важно заняться обновлением пользовательского мануала.
Именно такая последовательность действий на мой взгляд является верной и успешной.
Хотя конечно многое зависит от специфики проектов и других различных нюансов которые в обобщенной статье и не описать так сразу. Но стоит их учитывать в реальных ситуациях.
На мой взгляд такой подход позволит максимально эффективно организовать разработку проектов, доведение его до конечного результата. А так же именно такой контроль качества, как прохождение продукта через ряд тестирований, позволит доказать клиентам что Наши проекты действительно надежны и стоят своих денег.
Разработка это когда мы начинаем писать что-то с нуля, когда нет никакой реализации, есть только идея, и план следую по которому мы можем достичь поставленной цели. Это и проектирования, и разработка архитектуры ПО и все сопутствующие моменты.
Поддержка ПО, это когда в целом и общем проект уже сдан в эксплуатацию. Он работает, функционирует, но с течением времени, периодически у клиентов возникают пожелания, либо меняются законы и что бы программа работала правильно нужно менять какие-то расчеты, либо придумали новую фичу, которая позволит сделать программу более удобной - это все поддержка. То есть по сути, не нужно писать все с нуля, нужно просто дорабатывать имеющийся код, архитектуру, поддерживая таким образом проект, в актуальном состоянии.
Таким образом, отдел программистов очень важно изначально поделить на два подотдела. Часть программистов должны заниматься поддержкой готовых и работающих проектов. Другая же часть программистов всегда занимаются разработкой новых проектов, архитектур и так далее. Ведь для успешного бизнеса не обойтись одним проектом. Всегда появляются новые идеи, возможности и ниши, где можно что-то автоматизировать.
Очень важную роль играет корпоративная система, система контроля задач и ошибок.
То есть процесс должен идти не так что вот мы собрались. Обсудили. Кто что записал или на память запомнил, так и делаем. Такой вариант сразу можно выбросить из головы.
Да, собрания должны быть. Но результатом каждого обсуждения должна быть конкретно сформированная задача. И эта задача должна быть не на бумаге, а в корпоративном портале, где каждый может на неё посмотреть. А вообще назначается ответственный за задачу, который уже выбирает исполнителя. Исполнитель в свою очередь видит у себя список задач которые ему необходимо решить. И делает все для того что бы этот список не увеличивался, а уменьшался. Путем выполнения этих самых задач.
Таким образом мы легко можем отследить, кто чем занимается, у кого какой загруз, и кто занимается фигней вместо того что бы работать.
Корпоративная система распространяется не только на программистов, но и на других участников компании. А именно на тестировщиков, аналитиков, постановщиков задач. На мой взгляд будет правильно если начнет составлять тех задание аналитик. Затем направит его на доработку главному разработчику, или главному программисту поддержки. Тот уже откорректирует его и либо возьмет на исполнение, либо назначит другого исполнителя.
Далее, когда задача реализована, протестирована самим программистом, она отправляется на тестирование в отдел тестирования.
Теперь важный момент. Тестировщику может не понравится внешний вид выполненной задачи. Например некрасивая или не удобно расположенная кнопка. Либо надпись на форме не отражает сути. Он возвращает на доработку со своим комментарием. Этот случай можно считать не злокачественным возвратом. То есть программист не виноват что не умеет красиво рисовать кнопки. Ему простительно.
Но вот если программа выдает ошибки, не правильно себя ведет, и не выполняет своих функций, в таком случае конечно же виноват программист. И вот тут стоит фиксировать в корпоративной системе - количество возвратов. Допустим один-два возврата, это взять за норму. На то и есть отдел тестирования что бы контролировать ошибки. Но когда количество возвратов вырастает до 5-6, тут уже дело в программисте. То есть он либо не качественно пишет код, либо тянет резину, тем что сдает в тестирование задачу, которая заведомо не решена полностью. За такое нужно придумать меру наказания. Например если срываются сроки выполнения, по причине что задача летает туда-сюда, то пусть программист выходит в субботу и исправляет положение по срокам.
Ещё такой момент. Сборку версий, лучше всего так же переложить на тестировщика. Это сэкономит рабочее время программистов. А тестировщику не составит труда скомпилировать проект и собрать билд в нужном месте.
Считаю не будет лишним изложить тот факт, что программисты люди не обычные, и условия для них лучше всего создавать лояльные. Есть среди них индивиды которые могут продуктивно работать лишь в определенные часы суток. Поэтому не стоит заставлять их сидеть на работе с 9 до 18. Если у него в это время снижена продуктивность, вы его ни премией ни кулаком не заставите сделать больше работы. Пусть лучше если он может, делает часть работы дома. Затем приходит в офис в удобное для него время. И уходит тоже в удобное время. Самый главный показатель для программиста - это то как он укладывается в срок с выполнением задач. Поэтому если человек почти не появляется в офисе, но у него все в порядке с работой, то почему бы и нет. Пусть что хочет делает, лишь бы работа была выполнена.
Далее, тестирование.
Тестирование должно производиться в различных условиях. Во первых тут не обойтись без множества виртуальных тестовых стендов. То есть нужно тестировать работу программы на различных операционных системах, в различных условиях. Тестировать быстродействие, тестировать то, как корректно ведет себя программа на маленьких мониторах, то есть с низким расширением экрана. Доступны ли важные кнопки на таких экранах. Важно понять как это заработает если установить программу с нуля, и что будет если уже есть какая-то версия что будет после обновления, возникнут ли какие-то проблемы с совместимостью или нет. То есть тестировщик должен разработать специальны планы тестирования для каждого проекта отдельно. Что бы исключить перед выпуском максимум возможных исключительных ситуаций.
После того как тестировщики все протестировали, продукт или версия продукта направляется на тестирование аналитикам. После того как там дают добро, версию можно отдавать клиентам. Если обновление не критическое, можно в таком случае дождаться еще каких-то доработок. Все это уже согласовывается людьми разных отделов.
Далее готовую версию выкладывают клиентам. Либо через интернет либо другими способами. Думаю логично было бы возложить эту функцию на отдел технической поддержки. Таким образом они будут в курсе обновления и смогут об этом сказать клиентам, создать новость на сайте и просто это будет на мой взгляд правильнее.
По поводу информационного сопровождения. Если обновление не критическое то тестировщики могут сразу исправить пользовательское руководство, а потом уже выкладывать на сайт обновление. Если критическое, то сразу после выкладывания, тестировщикам важно заняться обновлением пользовательского мануала.
Именно такая последовательность действий на мой взгляд является верной и успешной.
Хотя конечно многое зависит от специфики проектов и других различных нюансов которые в обобщенной статье и не описать так сразу. Но стоит их учитывать в реальных ситуациях.
На мой взгляд такой подход позволит максимально эффективно организовать разработку проектов, доведение его до конечного результата. А так же именно такой контроль качества, как прохождение продукта через ряд тестирований, позволит доказать клиентам что Наши проекты действительно надежны и стоят своих денег.
