(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

Правильная организация труда программистов

Источник: tproger

Сооснователь и глава разработки Acronis Станислав Протасов рассказал о том, как это устроено у них и дал советы начинающим командам

Tproger взял интервью у  Станислава Протасова - сооснователя и главы разработки компании Acronis. В первой части читайте о том, чем сейчас занимаются в компании, как в ней организована разработка, какие можно дать советы начинающим командам программистов. 

Станислав, расскажите, пожалуйста, над какими проектами вы сейчас работаете?

Над нашими продуктами, над новыми версиями. Что-то улучшаем, каким-то образом пытаемся сделать так, чтобы все наши продукты были связаны, чтобы была единая платформа.

Недавно у вас появился мобильный бэкап, это одна из частей этой платформы?

Да, это просто одна из частей. Мы хотим защищать данные на всех устройствах: мобильных телефонах, рабочих станциях, домашних компьютерах. Сейчас появляется ещё и такая сущность, как Интернет вещей, там возникают дополнительные источники данных. Например, ваш автомобиль с историей поездок, любимыми маршрутами, настройками.

ati-box_cloudЕсть множество данных, которые мы создаем, но не знаем, пригодятся они нам или нет. И если сохранять их дорого или неудобно, то люди этого и не делают. В частности, потому что они безалаберны, ведь это требует какой-то дисциплины. Вот, например, стоит у меня на столе внешний жесткий диск. Если мне надо его включать каждый раз, для того чтобы сделать копию, то меня обычно, несмотря на то, что я относительно дисциплинированный человек, хватает на месяцы. Потом я незаметно перестаю это делать. А если вдруг из него выбило блок питания и надо лезть под стол, я делаю это месяц. Или диск рассыпался, надо заменить - я об этом думаю, потом опять забываю. Но если сделать процесс сохранения очень удобным, подключить облачные хранилища, то я, конечно, буду это делать.

Но тут встает другая проблема - как найти ту информацию, которая вам нужна. Лично я стараюсь все сохранять, не "убиваю", например, свою почту, но, когда мне надо найти какое-нибудь письмо - это просто мука (тут еще есть такой интересный феномен - обычно почему-то находится письмо из прошлого поискового запроса, и я не знаю даже, как это объяснить). У меня есть почта, которую я заархивировал, есть почта, которая живет на моём Exchange, и есть еще какая-то почта на личных аккаунтах. И если я не помню, где ее искать - шансов найти достаточно мало. Вот мы и пытаемся, например, этот процесс сделать удобным - чтобы данные всегда были доступны со всех устройств и их потенциально было легко найти. Над этой системой мы в том числе и работаем.

Как у вас компании непосредственно организована разработка? Как идёт процесс от постановки задачи до выхода продукта на рынок? Какие методологии применяете?

Мы занимаемся своим делом давно и учились во многом на своих ошибках. К примеру, когда я начинал в первой половине 90-х, не было даже литературы по этой теме - программирование, софтверный инжиниринг и т.д. Советский Союз распадался, индустрии коммерческого программного обеспечения в стране не было, поэтому приходилось учиться самому. Это и хорошо, и плохо. Когда человек учится сам, он пробует много правильных и неправильных вещей, начинает понимать, почему что-то работает, а что-то нет - это хорошо. А плохо, потому что это самый долгий путь. Лучше, когда есть возможность учиться у кого-то по уже разработанным программам.

Когда мы начинали, у нас было совершенно детское представление о методологиях разработки. В одной книжке про историю компании Microsoft я прочитал, что, когда они работали с IBM над IBM PC, MS DOS и прочим, у инженеров IBM уже была высокая культура разработки. В частности, потому что в IBM всегда делали железо, а в железе ошибки стоят гораздо дороже. Так вот, инженеры IBM просто впадали в ступор, когда видели идеологию Microsoft на тот момент: "if it compiles… ship it!". То есть в Microsoft не было тогда ни понимания, что нужен quality assurance, ни тестеров - ничего. Скомпилировалось - вот вам ребята! Не работает? Сейчас починим!

"Не очень важно, какой именно процесс разработки у себя в компании использовать, но очень важна итеративность"

Любая компания, которая начинала очень рано, а мы, по меркам нашей страны, начали очень рано, через это проходила. Мы на собственном тяжелом опыте понимали, почему надо тестировать, почему в ночь перед релизом простой fix, который точно ничего не может сломать, обязательно все сломает. Пример: когда мы делали один из наших продуктов, то в ночь перед релизом обнаружили, что в русской версии продукта название программы на экране написано на английском. И инженер, который, кстати, сейчас работает здесь же, в Acronis, сказал мне: "Давай переведем, я соберу, ведь выглядит некрасиво. Что мы можем сломать, мы просто заменим английский текст на русский". Я ему ответил - хорошо. Он перевел - и все перестало работать. А причина была очень простая - русский текст был на несколько байт длиннее и случился "buffer overrun" ("нехватка буфера"). То есть был баг, который не проявлялся в английском варианте, там был фиксированный буфер, туда клалась строчка, а в русском чуть больше - и буфера не хватало. Так что мы все это проходили. Начиная с базовых вещей, что нужно тестирование, нужно фиксить баги, их квалифицировать.

Я помню, как тяжело было понять некоторые методологии в начале-середине 90-х, описывающие интерактивный процесс разработки. Вот есть waterfall, а вот rational unified process, который предполагает несколько итераций waterfall. Сейчас расскажи это любому инженеру - он это поймет, ведь уже и книг написано куча, все работают в компаниях, где итеративный процесс в том или ином виде присутствует. А тогда было непонятно. Потому что в waterfall начинаем мы с требований, потом пишем код, потом мы тестируем, потом выпускаем продукт. Зачем это делать несколько раз, если мы вот тут уже должны выпустить? Extreme programming мы тоже пробовали и использовали, причем во всех его реинкарнациях: парное программирование и т.д. и т.п.

"Когда люди становятся профессионалами, им надо дать возможность самим выбирать инструменты"

По моему личному мнению, с учетом опыта: не очень важно, какой именно процесс разработки у себя в компании использовать, но очень важна итеративность. У любого итеративного процесса разработки, особенно большого и сложного продукта, меньше шансов не завершиться или "уплыть", чем у такого, который предполагает, что сегодня мы проговорили, какой продукт будет, а последующие два года просто не заходим к программистам и ждём. С итеративным процессом разработка становится предсказуемой. А дальше все конкретные методологии дня или года, наиболее популярные - это зачастую вкусовщина.

На самом деле, когда компания строится, когда формируется коллектив, очень полезно иметь один процесс разработки - тогда становится возможным переключать человека из команды в команду. Он просто приходит и знает, что к чему. Знает, к примеру, как и в какую систему репортить баг, если написал код - куда его надо закомитить и так далее. Но когда компания становится большой, профессиональной и начинает делать хорошие продукты, жесткое поддержание единых процессов разработки и строго унифицированных тулсетов начинает приносить больше вреда, чем пользы. Когда люди становятся профессионалами, им надо дать возможность самим выбирать инструменты. Это как с детьми - когда мы хотим развить ребенка и приводим его, скажем, на бокс, то нельзя разрешать детям бить друг друга так, как они хотят. Должен быть тренер, защита, объяснения того, куда бить нельзя и т.д. Но когда человек становится разрядником или мастером спорта, то объяснять ему, какие перчатки использовать или в каких кроссовках ходить, становится глупо и непродуктивно.

Кстати, по поводу начинающих команд. У нас в сообществе довольно много программистов, только встающих на путь становления профессионала. Они объединяются, выбирают проект и начинают его делать. Могли бы вы посоветовать им перенять какие-то аспекты вашей практики организации разработки? Например, стоит ли им использовать Jira, или не стоит, может быть какие-то ещё инструменты.

Очень тяжело давать советы, потому что у разных людей работают разные вещи. Я скажу так: для меня, когда люди начинают ссориться на тему "Jira или не Jira" - это звучит дико. Конечно, лучше иметь современный стэк тулзов, который позволяет обеспечить то, что называется continuous integration. Выбор этих тулзов - вкусовщина. Если люди знакомы с "джирой" - пусть используют "джиру". Если хотят использовать что-то другое и они согласны - ничего такого в этом нет. Но вот непрерывная интеграция (continuous integration) - это важно, " итерационная разработка" (iterative development) - это важно. Кто-то, играющий роль продакт-менеджера, то есть человек, разбирающийся с тем, что же мы делаем, - это тоже очень важно. "Проверка качества" (quality assurance) - это важно. А дать конкретные рекомендации "берите только джиру или не джиру" - это будет глупо, неправильно и не имеет никакого смысла.

"Лучше иметь современный стэк тулзов, который позволяет обеспечить то, что называется continuous integration"

У команд, которые объединяются, на самом деле и так задача очень сложная. Потому что очень часто эти команды - виртуальны, люди которые расположены в разных городах, зачастую даже никогда лично не встречались, и которые хотят сделать проект. В любом софтверном проекте есть шансы на неудачу и в зависимости от разных вводных эти шансы могут увеличиваться. Команда незнакомых друг с другом людей, расположенная в разных городах, сильно увеличивает шансы на неуспех. Не все способны работать удаленно. Я знаю многих людей, которым тяжело работать дома, потому что дома человек пришел, cел за компьютер, хочет поработать, а тут прибежал ребенок, залез на плечи, попросил купить алмазиков в какой-нибудь игре, затем убежал. Человек отвлекся, вдохновение пропало… и он пошел на какой-нибудь сайт. Время ушло. Работать удаленно тяжелее, чем в офисе, для многих людей. В любом случае человеку удобнее, когда его не отвлекают. А дома с этим проблематично.

Кроме того, когда команда распределенная, нет возможности подойти к коллеге и что-то спросить. Вот ушёл человек, который сидит дома, от компьютера, я ему написал в Skype, и он не ответил, а когда он ответил мне - я пошел ужинать. Коммуникация затрудняется.

Нет никакой волшебной книги, которая бы объяснила, как виртуальной команде собраться в вашем сообществе и стать успешными. Люди должны понимать, что, во-первых, такого рода проекты тяжелее делать, поэтому если у них получается - надо тренироваться дальше, это очень хорошее и важное умение. А, во-вторых, нужно всегда держать в голове простую вещь: что, чем бы мы не занимались - время идет, поэтому, если мы хотим делать какой-то один проект, распределенный или не распределенный, нужно стараться себя заставлять этим заниматься с полной отдачей. Потому что время все равно уходит.

Беседовал Алексей Михайлишин, основатель проекта tproger.



 Распечатать »
 Правила публикации »
  Написать редактору 
 Рекомендовать » Дата публикации: 19.01.2016 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
VMware Workstation 14 Pro for Linux and Windows, ESD
SAP Crystal Server 2011 WIN INTL 5 CAL License
ABViewer Professional пользовательская
Stimulsoft Reports.Ultimate Single License Includes one year subscription, source code
FastReport.Desktop
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Безопасность компьютерных сетей и защита информации
Программирование на Microsoft Access
CASE-технологии
СУБД Oracle "с нуля"
Каждый день новые драйверы для вашего компьютера!
Работа в Windows и новости компании Microsoft
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
 



    
rambler's top100 Rambler's Top100