management

«Хочу свой IT-бизнес!»: советы от экспертов фонда «Сколково»

В Барнауле прогремел стартап-тур «Открытые инновации». Во время тура эксперты фонда «Сколково» и успешные предприниматели много говорили о том, что надо и что не надо делать, когда замыслил запустить собственный стартап. Особое внимание уделили IT-бизнесу. Мы там были как соорганизаторы в рамках Ассоциации поддержки инноваций, помогали, оценивали местные IT-стартапы, и, конечно, внимательно слушали советы экспертов. Теперь мы готовы поделиться тем, что узнали.

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

Пользуйтесь и не благодарите.

1. Выбери нишу

К счастью, выбор большой. Хорошие перспективы открываются в альтернативной энергетике, гибридной электронике и разного рода новейших производствах. Или как их называют в научных и бизнес-кругах, advanced manufacturing. И разумеется, в информационных технологиях, которые стремительно проникают во все другие сферы.

Статистика стартапов в мире. Источник: spark.ru

Инвестиции в IT в России. Источник: rvc.ru

Например, можно попробовать себя в аддитивных производствах и соорудить свой 3D-принтер. Или в роботехнике и сделать экологически чистый агрегат на все случаи жизни. Или составить конкуренцию Тесле и представить миру свой автомобиль на альтернативном виде топлива.

Александр Фертман, директор по науке, технологиям и образованию фонда «Сколково»:

«Почему крупные предприятия поняли, что есть место для малого и среднего бизнеса? Большие могут концентрировать ресурсы, но они недостаточно подвижны, чтобы решать оперативные задачи. Поэтому и стали вкладывать деньги в малые предприятия. И если вам удастся не только создать свое предприятие, но и продать его, не надо расстраиваться. Постройте следующее. Ваша специализация в технологиях, инженерных навыках, специализация крупных компаний – в строительстве заводов и массовых производств. Каждый должен заниматься своим делом».


2. Учись!

Хороший предприниматель – тот, кто постоянно учится. Причем быстро. И не считает это чем-то зазорным.

Например, в конце 1994 года компания Oy Visual Systems Ltd., которую основал нынешний советник президента по работе со стартапами фонда «Сколково» Пекка Вильякайнен, запустила первый в Финляндии интернет-банк, позволявший оплачивать счета в режиме онлайн. Но никто не поверил, что это удачная идея. Каждого жителя страны (5,5 миллионов человек) пришлось учить, как использовать новинку. На это потребовалось шесть лет. Долгий путь, который все-таки привел к успеху – в 2001 году 97% банковских сервисов страны было оцифровано.

Пекка Вильякайнен, советник президента по работе со стартапами фонда «Сколково»:

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

3. Не бойся!

Мы любим прятать свои ошибки. И это нормально. Но мы почему-то всего боимся и поэтому не любим хвастаться и своими успехами.

Делиться своими успехами и достижениями – необходимо.

По мнению Пекки Вильякайнена, такая скрытность – самая слабая сторона российского предпринимательского сообщества. Он уверен: до тех пор пока это будет продолжаться, Россия развиваться не будет, так как связи в сообществе не нарабатываются и обмена знаниями не происходит.

Пекка Вильякайнен, советник президента по работе со стартапами фонда «Сколково»:

«Я написал книгу для предпринимателей «Без страха». Это не значит что нужно безбоязненно ко всему относиться. Это, прежде всего, значит, что ты ни в коем случае не должен бояться людей. Нельзя вести бизнес и бояться, что кто-то что-то у тебя украдет».

4. Избавься от мифов

Жизнь предпринимателя окутана разного рода мифами. Кажется, что свой собственный бизнес – это рай на Земле. Ни забот, ни хлопот. Знай, командуй подчиненными, загорая на Бали, и получай прибыль.

Но в реальности все иначе.

Верить в сказки или строить свой бизнес в реальности? Источник: salnikov.ru

Вместо кучи денег – сплошные убытки, налоги, издержки. Вместо невероятного успеха и уважения в обществе – вечный стресс и постоянно дергающийся глаз. Вместо абсолютной свободы – работа 24/7 без сна и отдыха с непрекращающимися форс-мажорами и тушениями пожаров даже среди ночи. Нет, конечно, четырехчасового рабочего дня и полугодовых путешествий добиться можно. Но только через N лет, когда бизнес встанет на ноги, а ты наберешься опыта.

Так что если уж решил стать предпринимателем, особенно в области высоких технологий, и поправить печальную статистику (сейчас предпринимательством в России занимается 18% трудоспособного населения, но по факту – всего 2-3%), то десять раз подумай, нужны ли тебе все эти заморочки.

Ренат Батыров, генеральный директор технопарка «Сколково»:

«Дорога бизнесмена не устлана лепестками роз. Сегодня конкуренция очень высока, она значительно выше, чем еще 10 лет назад. Вы никогда не достигнете уровня «гуру бизнеса», если хотите просто получать прибыль и не вкладывать себя в свое дело. Успех ждет только тех, кто готов к постоянным переменам и работе над собой».

5. Обсуди все на берегу

Это must do. Со своими партнерами по бизнесу обговори все-все-все важные моменты, от того, кто же здесь главный и у скольких человек есть право голоса до правил внутреннего распорядка, общей стратегии и планов на будущее.

Да, процедура не всегда приятная, так как приходится затрагивать многие щекотливые вопросы, в том числе финансовые. Но ее необходимо провести, даже если вы друзья с детства. Вероятность «развода» со скандалом и дележкой имущества присутствует всегда.

Игорь Ковалев, президент группы компаний DI-Group:

«Будьте занудами – проговорите все возможные варианты. Если вы будете готовы к тому или иному варианту, который вы предвосхитили, вам будет намного проще жить. Это и финансовое планирование, и планирование производственной части, и все варианты «если вдруг». Так вы обеспечите себе защиту. С точки зрения интеллектуальной собственности, с точки зрения юридической чистоты и правовых вопросов, защиту от того, что у вас украдут технологию или что команда разбежится. Здесь нет ничего сверхъестественного. Это фундамент, на котором будет строиться ваш бизнес».

6. Делай продукт для всего мира

Эксперты «Сколково» рекомендуют: создавай такой продукт, который бы подходил для всего мира, не только для России.

Обращать внимание на мировой опыт также не возбраняется. Гиганты бизнеса так и делают. Например, «Сбербанк», когда Герман Греф решил поставить его на путь модернизации.

Пекка Вильякайнен, советник президента по работе со стартапами фонда «Сколково»:

«Все успешные предприниматели, с которыми я имел удовольствие общаться, разрабатывают свой продукт так, чтобы он подходил для всего мира. Неважно, большой это бизнес или малый. Если у вас прачечная, вы рубашки стираете, посмотрите, как построены прачечные сети всего мира».

7. Не тормози!

Реальность мира глобальных технологий такова, что если хочешь в него вписаться, то все нужно делать быстро. Нет времени чесать затылок, курить бамбук и тянуть с запуском и выходом на рынок.

Путь от посева до ранней стадии сегодня занимает уже не годы, а месяцы. Источник: Сколково.

Пример правильно взятой скорости – компания Go Pro, лидер на рынке экшн-камер. Когда они выпускали пятую версию камеры, то публично заявили – цикл жизни этого продукта составит девять месяцев. То есть за этот срок им нужно было не только продать ее всем людям на планете, но в то же время продолжаться заниматься инновациями, разрабатывать шестую версию продукта.

Пекка Вильякайнен, советник президента по работе со стартапами фонда «Сколково»:

«Советский стиль планирования, мышления в пятилетках, не подходит для предпринимателей сегодняшнего дня. Ты не можешь расписать план для своей компании на пять лет вперед. Технологические циклы стали сегодня столь короткими, что пять или три года могут показаться вечностью».

8. Найди ментора

Ментор для начинающего стартапера – друг, товарищ и брат. При этом он сам должен быть практикующим предпринимателем. Конечно, успешным, чьи советы реально будут полезными (согласитесь, зачем вам ментор-неудачник?).

Ключевой момент – при поиске ментора, не найти «дементора», который высосет из вас все жизненные соки. Или разведет на бабки. Такое тоже бывает.

Хороший ментор не требует платы за свою помощь, потому что его главный интерес – вырастить себе коллегу или будущего партнера. Но и ты, в свою очередь, тоже не можешь от него что-либо требовать. По сути, он тебе ничего не должен. Ментор не сделает твой бизнес успешным по мановению волшебной палочки, а только лишь подскажет, что лучше предпринять.

Ментор поможет вам вырасти, но не заменит ни одну из частей команды.

Хорошие менторы на дороге не валяются. Их можно найти в специальных организациях, которые активно развивают институт наставничества:

  • Ассоциация менторов фонда «Сколково»
  • Институт наставничества Бориса Ткаченко
  • Международный форум лидеров бизнеса (IBLF Russia)

И, конечно, стоит присмотреться к бизнес-тусовке и в своем родном городе, участвовать в мероприятиях и движухах. Как знать, может именно там ты встретишь своего ментора.

Анна Брусницына, тренер-эксперт фонда «Наше Будущее»:

«Когда у вас есть наставник, выживаемость бизнеса увеличивается до 80%. Он сэкономит вам десять лет жизни, пока вы будете раскачиваться. Конечно, сейчас в мире полно информации в открытом доступе. Можно узнать что угодно откуда угодно. Но наставник поможет вам разобраться в этом потоке информации и вычленить самое важное. Даст вам именно ту информацию, которую вы сами захотите усвоить».

9. Привлекай инвестиции

Очень важный пункт. Без капитала трудно стартовать. Ведь нужно и зарплату сотрудникам платить, и помещение оборудовать, и многочисленные издержки покрыть.

Если ты – не наследник богатых родителей, не владеешь нефтяной вышкой или если у тебя нет специальных накоплений, финансовый вопрос может встать довольно остро.

Что же делать? Откуда брать деньги на развитие бизнеса?

Пользуйся возможностями специальных институтов

На помощь начинающему стартаперу спешат многочисленные специальные институты. Все вместе они образуют так называемую «экосистему» поддержки предпринимательства. Если кратко, то в нее входят:

  • Фонд содействия инновациям
  • Фонд развития интернет инициатив (ФРИИ)
  • Российская венчурная компания (АО «РВК)
  • Стартап-акселератор Generation S
  • Национальная технологическая инициатива (НТИ)
  • Фонд «ВЭБ Инновации»
  • Российский фонд прямых инвестиций (РФПИ)
  • Корпорация МСП
  • АО «Российский экспортный центр»
  • Группа РОСНАНО
  • Фонд развития промышленности

Как видно, выбрать есть из чего.

«Экосистема» поддержки предпринимательства в России. Инфографика предоставлена фондом «Сколково»

Все вышеперечисленные институты – федеральные и очень серьезного уровня. И, соответственно, требования у них тоже очень высокие. Так что с проектами а-ля «написал вчера на коленке» к ним лучше не соваться.

Подобные институты есть и в регионах, и у нас, в Алтайском крае. У них градус требований уже пониже, однако тут тоже не стоит приходить с чем-то сомнительным.

Всегда помни: так просто денег на твой супер-пупер-мега-класный-офигительный проект никто не даст. Даже если делаешь зарядку по утрам и ешь брокколи на завтрак. Даже если прочитал все книги про Стива Джобса. Даже если патриот.

Инвестиции, чаще всего обличенные в форму грантов, институты поддержки раздают не всем подряд, а только тем, кто докажет, что реально достоин таких вложений.

Для этого потенциальный «грантополучатель» должен пройти все круги ада целый ряд специальных процедур.

Разберем на примере.

Допустим, фонд «Сколково» (который, кстати, тоже входит в «экосистему» и поддерживает предпринимателей грантами).

Сначала определись с тем, какой именно грант от фонда ты хочешь получить. Их в фонде три:

  • Микрогранты
  • Минигранты (до 5 миллионов рублей)
  • Большие гранты (от 5 до 300 миллионов рублей)

Они разительно отличаются и по размерам финансирования, и по критериям отбора проектов, и по срокам рассмотрения заявки. Например, мы решили, что нужен минигрант.

Подаешь заявку, ждешь примерно 50 дней, когда вынесут вердикт – подходит ли твой проект для финансирования в принципе. Если ответ положительный, то потом начинается страшное. Экспертиза.

Нужно предоставить целую кипу разных документов, чтобы доказать состоятельность проекта. Это и грантовый меморандум, который составляет в среднем 35 страниц, и «дорожная карта» проекта, и смета, и различные письма о намерениях, и соглашения с инвесторами и т.д. и т.п.

Все это внимательно, буквально до мелочей, изучают эксперты фонда «Сколково» и решают, давать деньги или нет.

Проекты, прошедшие через экспертизу, получают не только гранты, но и статус резидента «Сколково».

Александр Малявин, старший специалист грантовой и экспертной поддержки фонда «Сколково»:

«Деньги – это не главное. Не надо расценивать фонд как какой-то «денежный мешок». В «Сколково» есть огромное количество инструментов, например, как менторские программы, бизнес-ангелы, консультационная и информационная поддержка, технологические сервисы. Если вы будете грамотно жонглировать этими инструментами, то у вас будет все, что нужно для успешной реализации проекта».

 

Пекка Вильякайнен, советник президента по работе со стартапами фонда «Сколково»:

«Часто ко мне как к инвестору приходит человек и говорит: «Пеккушка, дай миллион долларов на три года, через три года позвони, помощь не нужна». Я его спрашиваю: «Ты точно знаешь, как бизнесом заниматься?». Он говорит: «Да, конечно, я патриот, прочитал книжку Стива Джобса, готов зарабатывать деньги». В таких людей я никогда не инвестирую. Этот человек не понимает природу инноваций и бизнеса вообще».

10. Действуй!

Just do it. Пусть это и звучит как избитая цитата из бизнес-паблика про успех. Сидя на диване, мировую корпорацию не сколотишь.

Так что просто действуй. Без страха, без упрека и с хорошей долей здравого смысла.

И, как знать, может следующим Стивом Джобсом или Илоном Маском станешь именно ты.

Как оценить стоимость разработки при управлении проектом по Agile?

Мы не смогли пройти мимо крутейшей статьи по Agile от главы проектов Toptal. А чтобы было легче ей поделиться, мы ее перевели. Просим любить и жаловать!

Одна из самых сложных вещей при разработке программного обеспечения – определить, как долго потребуется работать над новым продуктом и сколько это будет стоить. Почему это так сложно? Ответ не слишком очевиден.

Оценка стоимости нового продукта в принципе сложна, а люди не слишком хороши в точном предсказании событий. Ни один проект не повторяет другой, каждый уникален не только в своих целях, но и в бесчисленных особенностях, которые его формируют. Часто простая на первый взгляд проблема оказывается намного сложнее изнутри, а порой требует серьезных технических доработок для своего решения. И, несомненно, в любом проекте всегда есть множество неизвестных, которые возникают уже в процессе работы над ним.

К тому же и одинаковых людей не бывает – ни заказчиков, ни разработчиков, ни пользователей. Мы все приступаем к работе со своим багажом знаний, опыта, ценностей, ожиданий, готовности к риску и способности адаптироваться.

Написание качественного ПО – это хлеб с маслом для разработчиков; создание же классного программного продукта – намного более сложное предприятие для всех, кто в него вовлечен.

Разработка крутого ПО требует идеального баланса

Однако, когда мы говорим о ПО, понимание сроков и стоимости является ключевым для принятия стратегических бизнес-решений. Это верно и для стартапов, и для сложившихся бизнес-проектов, и для оптимизации бизнес-процессов. Затраты времени, возврат инвестиций и полученные преимущества могут помочь бизнесу или разрушить его. Логичны вопросы: что мы получим за наши деньги? Можем ли мы предсказать издержки? Сколько будет стоить создание продукта, который мы хотим? Когда мы его запустим? Получим ли мы качественный продукт в результате? Поможет ли он развитию бизнеса? Принесет ли он нам дополнительную ценность?

Итак, как же быть с оценкой масштабов, сроков и стоимости проекта? Давайте исследуем возможности Agile, и то, что делаем мы в Toptal.

Традиционный подход к цене договора и оценке

Традиционно, если вы не используете Agile и создаете ПО с определенным функционалом, для определенной сферы, то допускаете вариабельность сроков и затрат. Это приводит к проблемам:

1. Как вы можете понять, что создаваемый в рамках проекта функционал – именно тот, который наилучшим образом подходит вашему бизнесу или заказчику? Чаще, чем можно представить, требования к функционалу и области применения меняются, а требования к результату определяются уже в процессе работы над проектом, причем это касается необходимых и обязательных компонентов.

2. Когда затраты не определены, мы теряем контроль над возвратом инвестиций, к которому стремимся. Рост стоимости часто возникает из-за не просчитанных рисков или изменивших требований, что заставляет разработчиков расширять команду, чтобы уложиться в заданный срок, или увеличивать затраты времени на разработку. Ни то, ни другое нежелательно.

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

Все следствия вариативных сроков и стоимости отрицательные и нежелательны.

Конечно, большинство заказчиков пытаются решить все эти проблемы. Однако вероятность этого близка к нулю.

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

 

Подход к проектам разработки в Agile

Стоимость – это производное времени и людей (участников команды). Добавьте время, и стоимость вырастет за счет того, что вы дольше задействуете специалистов. Добавьте участников команды, и стоимость вновь вырастет, при этом ценность для бизнеса – нет. Это то, чего мы стремимся избежать. Поэтому принципы Agile предполагают фиксированные затраты времени и размер команды при вариабельности масштабов.

Что лучше звучит и вызывает больше доверия у заказчика – фиксированная или переменная стоимость? При этом важно, чтобы продукт исполнял свое предназначение и удовлетворял нуждам заказчика. Нет никакого смысла в том, чтобы потратить точное количество времени и денег и получить инструмент, который невозможно эффективно использовать.

Поэтому контракты, созданные по методологии Agile, предполагают следующие опции:

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

Ранняя остановка разработки. Это позволяет заказчику остановить работу над проектом на любой стадии, если результат уже получен и дальнейшая разработка не ускорит возврат инвестиций, а только увеличит затраты на работу команды. Преимущество для покупателя в этой ситуации заключается в скорейшем завершении работы над проектом, если он имеет весь необходимый функционал и вполне жизнеспособен. Чаще всего, разработчик получает при этом компенсацию рисков, например, в размере 20% от оставшейся стоимости договора.

Гибкие изменения. Изменения заложены в ДНК разработки по методологии Agile. Мы ожидаем, что в самом начале не знаем всего необходимого для успеха проекта. Поэтому мы поощряем изменения, основанные на релевантных данных и обратной связи. Они помогают убедиться в том, что мы работаем в правильном направлении. В конце каждой итерации мы можем отказаться от функционала, который больше не нужен или не является приоритетным, или заменить его. И если новый имеет ту же стоимость, то это не повлияет на цену договора. Если же стоимость будет ниже, то мы сможем добавить что-то, от чего ранее решили отказаться. Это возможно в любое время, если команда проекта и заказчик поддерживают тесные и доверительные рабочие взаимоотношения.

Дополнительные работы. В жизненном цикле проекта часто выявляются опции, которые невозможно реализовать в рамках фиксированной стоимости контракта. В таком случае возможно добавить новые этапы работы над проектом, каждый из которых получит отдельную оценку стоимости и времени.

Гибкие сметы. В рамках работы по Agile можно создать два варианта гибкой сметы проекта: с гибкими сроками или с гибким функционалом. Первый позволяет сказать, к примеру, что работа над проектом или его частью с указанным списком опций займет от 12 до 16 недель. Однако, увеличение сроков приводит к росту затрат на работу команды, которая не может в это время приступить к работе над новыми проектами. Поэтому мы в Toptal предпочитаем использовать гибкий список опций. Мы гарантируем, что продукт будет иметь определенный минимум функционала, достаточный для достижения целей заказчика, и будет разработан строго в указанные сроки.

Стоит помнить, что функционал всегда можно расширить позже. Например, когда вы начнете получать прибыль, увеличите количество пользователей или снизите издержки использования. В любом случае гораздо проще обосновать затраты ресурсов и времени, если проект уже показал возврат инвестиций и свою ценность для бизнеса.

 

Наш подход к стоимости ПО и ценообразованию

Мы в Toptal очень тесно работаем как с заказчиками, так и с разработчиками. Это помогает нам использовать техники, которые поддерживают у заказчика уверенность в соблюдении сроков и точной оценке стоимости проекта. Мы постоянно работаем над планированием и адаптацией проекта с начального общего уровня и до мельчайших деталей, если это позволяет избежать ненужных затрат и внедрять управляемые изменения.

Чтобы произвести оценку и зафиксировать стоимость проекта, мы предпринимаем следующие шаги:

1. Начальная общая оценка

На этой стадии мы очень мало знаем о том, каким получится проект. Было бы крайне самонадеянно считать, что уже в начале работы мы точно знаем, какие опции нужны нашим заказчикам и пользователям.
Поэтому мы начинаем с общего документации проекта и общего набора эпиков (основных крупных опций), определяя его специфику, исходя из целей и нашего видения.

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

Б. Набор эпиков(epic). Не углубляясь в детали, определите функционал, который необходим для продукта. Это будет структурированный «список покупок», который станет скелетом вашего продукта.

В. Анализ MoSCoW. Это техника, которая позволяет определить, что именно делает продут жизнеспособным, а что необязательно, но просто хочется в нем реализовать. Функции, которые вы определяете как Must – то, что будет привлекать и удерживать пользователей продукта. То, что вы обозначите как Should, будет радовать и удивлять покупателей, однако это можно будет добавить и позже. Функции Could не добавляют значительной бизнес-ценности и не ускоряют возврат инвестиций, поэтому будут в наименьшем приоритете. Наконец, Won’t могут стать важными в один прекрасный день, но на этой стадии развития проекта они не нужны. Таким образом, вы можете заодно определить и потенциал продукта.

 

2. Предложение

Чтобы решить, стоит ли запускать проект, важно иметь всю необходимую информацию о стоимости и длительности. Поэтому вы должны задать себе как минимум два (а лучше три) вопроса. Что потребуется для запуска этого продукта? Когда мы можем его запустить? Как это соотносится с нашей бизнес-стратегией и финансовым положением?

Зная ответы на эти вопросы, мы будем готовы сделать предложение. Мы сможем собирать команду разработчиков с учетом специальных требований проекта и объединить их как минимум с одним проектным менеджером, чтобы создать техническое решение в установленный срок, с обозначенным функционалом по указанной стоимости.

Как мы уже упоминали, в начале работы над проектом мы очень мало знаем о том, что должно получиться в итоге. Мы осознанно размываем описание функционала и масштабов, в противном случае мы должны точно знать, что от нас требуется. Оценка стоимости и сроков на этом этапе будет наименее точной, но она уже позволит понять, стоит ли связываться с проектом.

Предложение – это первый инструмент определения продолжительности и стоимости работы. Как только оно принято, мы можем двигаться дальше к фиксированной цене.

3. Планирование релизов

Следующий этап составления сметы – это разработка плана релизов, который распределит работу над функционалом во времени. Мы создаем его с учетом списка функций, размеров проекта, скорости, с которой наша команда может разрабатывать качественное ПО, отвечающее ожиданиям заказчика, и техник, снижающих риски неопределенности.

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

Б. Оценка. Когда у нас есть список пользовательских историй, команда проводит его оценку, используя технику «Покер-планирование» (Planning Poker). Это очень полезная техника, гарантированно дающая быстрый и надежный результат, основанный на экспертном мнении и оценке аналогов. Каждой истории в списке присваивается определенное число очков в зависимости от масштабов и сложности реализации. Доступны и другие техники оценки Agile, например «Идеальные дни» (Ideal Days).

В результате этой процедуры мы получим точную оценку масштабов проекта и установим зависимости между опциями. Масштаб – это сумма очков всех пунктов, например, 120.

В. Расстановка приоритетов. Теперь, когда у нас есть журнал продукта и оценка масштабов проекта, мы готовы вместе с заказчиком расставить приоритеты. Это касается того, какие элементы продукта наиболее значимы для заказчика с точки зрения желаемых результатов. Самый первый элемент будет наиболее важным, второй – чуть менее, и так далее. Нет двух одинаково значимых элементов, каждый из них имеет меньшую или большую значимость относительно других.

Такой подход крайне важен для грамотного планирования проекта разработки. Теперь мы точно знаем, что важно для нашего клиента и в каком порядке мы должны работать, с учетом всех зависимостей, чтобы создать продукт, соответствующий ожиданиям.

Г. Планирование релиза. К этому моменту мы определили, каким должен стать наш продукт и каких он масштабов.

Теперь нам нужно понять, сколько времени займет создание проекта, готового к релизу. Заказчик и команда, включая дизайнеров, инженеров, тестеров, скрам-мастера и проектного менеджера, вместе определяют, чего можно достичь и как быстро может выполняться работа – в результате мы получаем план релиза.

Он дает, в том числе, понимание того, как проект соотносится со стратегическими планами заказчика. Наконец, этот план подтверждает, что у команды проекта есть маяк, на который она будет ориентироваться, и определяет логическое завершение процесса разработки.

Прежде чем начать, мы должны удостовериться, что все одинаково понимают, что значит «готово». Это некий набор критериев, который является полным для заказчика и одновременно определяет требования к продукту для релиза.

Для начала, мы берем общее количество очков проекта, определенное на стадии журнала продукта, и делим его на скорость работы команды. Обычно скорость определяют как диапазон, но мы для простоты используем одно число. В работе мы используем двухнедельные итерации, поэтому наша скорость определяется как количество работы, которую мы можем выполнить существующей командой за две недели. Если наш проект имеет 120 очков, а мы ожидаем, что за две недели выполним 20 очков, то общее время разработки будет равняться 12 неделям, или шести итерациям. К этому мы добавляем нулевой спринт в две недели и еще один спринт на подготовку релиза. Итого, наш проект будет длиться 16 недель. Есть техники, которые позволяют создать достаточный буфер для рисков при планировании, и их мы обсудим ниже. Но если коротко, то буфер мы используем, чтобы управлять рисками неопределенности и прийти к соглашению о том, какое количество очков проекта мы обязаны предоставить. Итог может варьироваться от 90 до 150 очков, при этом 90 – это тот минимум, который необходим для жизнеспособности продукта.

Когда проект должен быть завершен к конкретной дате, например, за 10 недель, команда должна определить, какой объем журнала продукта можно реализовать за это время. Если мы ожидаем разработку 20 очков за этап, плюс нулевой спринт и релиз, то будем стремиться к реализации 60 очков к концу работы над проектом. И вновь мы должны учесть возможные риски, создав для них разумный буфер, что в итоге выльется в диапазон от 45 до 75 очков выполненной работы к моменту релиза. В 45 очков мы должны уложить минимальный функционал, необходимый для ценного и жизнеспособного продукта. Возможно, при таком сценарии вы сочтете разумным расширить команду, чтобы увеличить скорость разработки.

Конечно, для всего описанного выше необходима качественная коммуникация и совместная работа всех вовлеченных сторон. Только тогда возможно разработать достижимый, реалистичный и приемлемый для заказчика план релиза.

4. Фиксированная цена договора

Как только мы достигли согласия относительно сроков, мы можем назвать стоимость договора. Как уже говорилось, крайне рекомендуется сохранять неизменными срок разработки проекта и размер команды и варьировать функционал продукта.

Цена договора предоставляется вместе с графиком работ и согласованным графиком платежей.

Если мы готовы следовать духу разработки по Agile – доверять, общаться, сотрудничать, то все перечисленные выше шаги позволят нам создать условия, в которых проект будет с максимальной вероятностью разработан в указанное время в рамках бюджета. Конечно, нельзя исключать случаи, когда разработка займет больше или меньше времени, и в этих ситуациях важно сохранять максимальную прозрачность процессов.

Техники оценки

Для планирования и оценки по Agile есть множество техник, которые команда разработки может использовать для уверенности в объемах, сложности, продолжительности и стоимости проекта. Вот некоторые из них, которые используем мы для наших разработок программных продуктов.

Оцениваем масштаб

Масштаб проекта указывает на его область применения, сложность, габариты, риски и значимость. Если проводить аналогии, то нам нужно понять, что мы строим – Эйфелеву башню или Великую китайскую стену. Эйфелева башня – это высокая, тяжелая и сложная структура, созданная в тесной городской среде. А Великая китайская стена – сравнительно простая, но длинная и устойчивая структура, которая тянется на многие мили по холмистой местности. И хотя оба проекта можно назвать большими, их назначение, сложность, габариты и значимость различны.

Очень важно управлять ожиданиями при оценке. Она не является предсказанием, обещанием или гарантией. Когда речь идет об общем масштабе, продолжительности и стоимости, мы всегда работаем с диапазонами, чтобы учесть риски, неопределенность и неизвестные.

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

Очки

Очки – это единицы измерения, демонстрирующие общий объем пользовательских историй. Этот размер при оценке включает все аспекты дизайна, разработки, тестирования, ревью кода, интеграции, и так далее.

Размер каждой истории соотносится с размером всех других. Например, опция А «стоит» 1 очко, опция Б – два, а опция В – три. Таким образом, опция В в три раза масштабнее, чем А, и в полтора раза, чем Б.

Из суммы очков всех историй в журнале продукта мы получаем общее число очков проекта.

Идеальные дни

Эта технология оценивает масштаб в днях. В ней исключены любые отвлекающие процессы – перерывы, планирование, чтение почты и все, что не имеет отношения непосредственно к созданию проекта. Она концентрируется на сроках выполнения задачи при постоянной и непрерывной над ней работе.

Обычно при первичной оценке, когда мы знаем о проекте меньше всего, мы используем идеальные дни, так как эта технология лучше коррелирует с прошлым опытом, чем абстрактные цифры пользовательских историй. Особенно когда эти истории имеют мало деталей, а дополнения с большой степенью вероятности появятся позже.

Когда оценка проводится на более поздней стадии, после разработки журнала продукта, можно использовать любой подход на усмотрение команды разработчиков. Преимущества есть у каждого, и все зависит от предпочтений.

Способы оценки

Совместная оценка. Процесс не проходит в изоляции. Над оценкой совместно работает вся команда разработчиков с привлечением экспертов, и она включает дизайн, создание баз данных, серверную часть, фронтэнд и пользовательский интерфейс, тестирование и другие возможные аспекты. Это позволяет избежать проблем, связанных с тем, что не были учтены все необходимые работы, и удостовериться в том, что масштаб каждой опции не будет недооценен или, наоборот, переоценен.

Оценка по аналогии. Мы берем две отдельных опции и решаем, что одна из них больше или меньше, чем другая. Мы можем взять отдельную историю и согласиться, что она невелика, и если мы используем очки историй, то назначим ей два очка. Следующая может быть больше предыдущей, и ей мы дадим пять очков, если решим, что она больше в два с половиной раза.

То же самое нужно продолжить со всеми оставшимися историями. Закончив, мы распределим все маленькие, средние и большие истории и проверим их размеры, чтобы убедиться, что ни одна из них не выбивается из произведенной оценки.

Покер-планирование. Об этой технологии писали немало. Я упоминал ее в своем блоге. Один из лучших ресурсов для ее понимания вы найдете также по ссылке.

Если коротко, то она комбинирует экспертные мнения, аналогии и командную работу в одном простом, быстром и надежном процессе.

 

Скорость

Скорость – это оценка способности команды выполнять некоторый объем работы в течение заданной итерации (спринта).

Она выражается с помощью диапазона, например, 23-32 очка историй на спринт, особенно на начальных стадиях работы над проектом. В основном это потому, что даже если та же самая команда раньше работала над похожей задачей, всегда сложно точно предсказать скорость работы. Обратите внимание, мы говорим именно о скорости команды, а не отдельного человека!

Мы используем скорость, чтобы планировать релиз и адаптировать планы и отрезки работы по мере развития проекта. Таким образом, мы регулярно улучшаем наши прогнозы по завершению проекта по ходу его действия.

Когда мы запускаемся, то вынуждены определять диапазон скорости, располагая небольшим количеством данных. Мы можем использовать исторические данные, если совпадают команда и проблематика, что случается весьма редко. Мы можем провести тестовую итерацию с помощью команды проекта, но это весьма затратно и не работает, если решение о начале работы еще не принято. Или же мы можем прогнозировать.

Прогноз скорости включает оценку отдельных спринтов с помощью очков историй и разбивку их на отдельные задачи, необходимые для реализации истории. Мы оценим количество часов, которые нужны для завершения каждой задачи, включая дизайн, разработку, тестирование, и так далее, и предположим, какую работоспособность будет иметь команда на протяжение отдельного спринта. Работоспособность в 70% в случае свободной от других задач команды подойдет для начальных расчетов. Поэтому, в простых ситуациях, мы рассчитаем количество часов для команды следующим образом:

  1. 4 участника команды * 2 недели * 40 часов в неделю = 320 часов
  2. Умножаем на 70% = 224 часа
  3. Добавляем все задачи, нужные для реализации, пока не дойдем до 224 часов
  4. Суммируем очки историй для выбранных задач и получаем скорость, например, 36
  5. Применяем коэффициент в 20% в обе стороны и получаем оценочный диапазон скорости в 29-43 очка

Скорость обычно варьируется в течение первых 2-4 итераций, а затем стабилизируется в рамках небольшого диапазона очков. И если наш начальный диапазон был 29-43 очка, то к четвертой итерации он выйдет на плато, например, 34-38. Это позволит нам с большей точностью предсказать дату завершения проекта.

Планируем буферы для рисков и неопределенности

Все проекты разработки сопряжены с некоторой неопределенностью. Она уменьшается по мере того, как продвигается работа над проектом, по мере роста знаний о технологиях, окружении, производительности и потребностях заказчика и пользователей.

Мы учитываем эту неопределенность, или риски, с помощью буфера в графике работы. Он соотносится с вероятностью ошибки при оценке и неизвестными, которые мы не можем предвидеть, начиная работу.

Обычно буфер бывает двух видов: функциональный и временной. И так как мы чаще всего обозначаем фиксированную стоимость и срок релиза, то предпочитаем использовать функциональный буфер.

Такой подход дает нам надежную стратегию управления рисками и вызывает доверие у заказчиков. Они имеют точные ожидания относительного того, что получат по завершению проекта.

Функциональные буферы

Используя такой буфер, мы прогнозируем, что предоставим определенный набор опций, но в идеале завершим большее количество работы. Набор отражает минимальный функционал, который заказчик считает необходимым для запуска жизнеспособного продукта, но позволяет нам при возможности сделать больше, если внешние и внутренние факторы нам это позволят.

Таким образом, заказчик решает, какие приоритетные опции из журнала продукта наиболее важны – например, на общую сумму до 100 очков историй. Затем он может добавить дополнительный функционал еще на 30 очков. Таким образом, команда будет планировать разработку «весом» в 130 очков, с обязательным минимумом в 100, к установленной дате релиза и по фиксированной цене договора.

Некоторые мысли в завершение

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

Я работал с клиентами, которым было тяжело воспринимать адаптивную природу Agile и отказаться от отношений командования и контроля. Непросто отпустить ситуацию и по-настоящему довериться команде, которую ты не знаешь. Часто клиенты просят нас создать спецификацию со всеми требованиями к продукту, который они получат. Это дает им уверенность в том, что масштаб проекта определен. Но такой подход не оправдал себя. Если мы фиксируем свойства продукта и включаем в договор нереалистичные требования, быстро возникают проблемы.

Мы знаем, что объем работы меняются, возникают новые ранее неизвестные факторы или то, чего изначально хотел заказчик, изменилось, порой радикально. Адаптивный подход к ценообразованию, планированию и оценке позволяет клиентам получить именно такой продукт, который требует их рынок. А разработчику он позволяет быть гибким, креативным и одновременно эффективным. Ключ ко всему – максимальное взаимодействие между заказчиком и разработчиком при переговорах.

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

Заключение

Я надеюсь, что этот материал поможет вам при планировании, оценке и определении стоимости проекта разработки по Agile. Все перечисленные подходы и техники созданы, чтобы построить доверие в команде и вселить в заказчика уверенность относительно сроков и цены его будущего продукта. И, конечно же, чтобы уверенно принимать решение о начале работы.

Следуя этим методам, вы будете знать, что находитесь на верном пути при работе над своим программным продуктом.

Автор материала – Paul Barnes, глава проектов Toptal

Оригинал был опубликован в блоге Agile-Nightmare.

У вас здесь ошибка… или о практике инспекций кода в мобильной разработке

Третьяков Илья

Team Lead, отдел мобильной разработки

“Nothing is more important than reviewing each other’s code. Review it to death. That is how you learn. Mandatory code reviews are the religion at Google, and should be at every self-respecting engineering organization. Your stamp of approval on a code review (which we call a LGTM, for “Looks good to me”) means that you stand by its quality just as much as your own code.”

– Kevin Bourrillion, Software Engineer, Google

Практика code review или, если перевести на русский язык, инспекций кода появилась давно и уже успешно встроена в процессы разработки во многих компаниях. В то же время, в еще большем количестве компаний эту практику или совсем не применяют, или применяют от случая к случаю. Это в свою очередь сказывается на качестве проводимой инспекции, на том, как её воспринимает команда программистов, и как ее результат отражается на продукте.

 

Не углубляясь в детали можно сказать, то инспекция кода – это систематическая проверка кода с целью выявления и исправления дефектов в нем. При этом список дефектов, которые могут быть обнаружены, очень велик и может включать в себя как замечания касающиеся стиля кодирования, так и архитектурные ошибки.

Почему важны инспекции кода?

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

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

Программисты, читая код, который был написан их коллегами, неизбежно знакомятся и с ним, и с задачами, которые он должен решать. В результате у команды повышается уровень владения кодом. Разработчики начинают понимать, как работают модули приложения, написанные другими людьми. Уменьшается вероятность дублирования существующего функционала (не кода!). Сокращаются риски, связанные с уходом или временным отсутствием члена команды. В итоге любой разработчик готов к выполнению даже тех задач, которые затрагивают не только его код.

В случае, когда разработчики знают, что их код будет обязательно просмотрен, они начинают относиться к его написанию более ответственно: тщательно продумывают, как встроить функционал в существующую архитектуру, добавляют достаточное количество комментариев и т.д.

Перечисленные выше аргументы очевидны, и с ними обычно никто не спорит. Но, на мой взгляд, наибольшее внимание в инспекциях кода представляют преимущества, которые носят долгосрочный характер. Ведь именно в них должен быть заинтересован руководящий состав или заказчик (в случае заказной разработки).

Во-первых, если инспектирование кода не проводится, то очень легко оказаться в ситуации, когда внедрение нового функционала будет вызывать серьезные проблемы у программистов. В свою очередь заказчик будет недоумевать: почему на добавление небольшого функционала требуется так много времени? Ответ достаточно прост – за качеством архитектуры приложения, его кода и вносимых в них изменений никто не следил.

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

Почему инспекции кода все равно не проводятся?

Программисты, в силу специфики своей профессии, очень умные люди и умеют считать. В особенности они очень хорошо считают свое время и следят за своей продуктивностью. Согласно их мнению, инспекция кода отвлекает от текущих задач и снижает продуктивность. Дефекты, найденные в ходе инспекции кода, также не представляют для них особого интереса, потому что в основном представляют собой список мелких ошибок, допущенных младшими разработчиками. Более того этот список стабильно повторяется, и его обсуждение представляет собой довольно скучный процесс для опытных разработчиков. Проведение инспекции кода предполагает, что все найденные дефекты будут исправлены. Однако, тут проявляется огромное нежелание программистов вносить изменения в работающий код. Также, если инспекции кода проводятся редко, то программист, которому было это поручено, просто теряется в огромном количестве нового кода. И для него это выглядит как наказание. Эти моменты не мотивируют команду к систематическому проведению инспекций кода. Программисты считают, что результат полученный в ходе инспекций кода не стоит затраченных усилий. Это является следствием недочетов в подходе к проведению инспекций кода и нежеланию их исправлять.

Ранее упоминалось, что в проведении инспекций кода должен быть заинтересован и заказчик. Но, как показывает практика, приложение в первую очередь оценивают по заявленному функционалу и результатам тестирования. Практически никто не предъявляет требований к исходному коду и, соответственно, никто его не проверяет. Вопрос же о низком качестве кода появляется в двух случаях:

– при получении проекта от другой команды;

– при постоянном переносе сроков сдачи из-за большого количества ошибок.

К сожалению, что-то менять в этих случаях уже поздно, но существует несколько вариантов выхода из сложившейся ситуации. Первый, очевидный, – поддаться на уговоры программистов «все переписать». Однако, есть шанс довериться слабой команде с неотлаженными процессами и, на выходе, снова получить еще одну мешанину кода. Второй – проанализировать (проинспектировать) существующий код и подготовить стратегию его реанимации. Этот вариант более долгий и требует огромных усилий от проектировщиков и разработчиков.

Типы инспекций кода

Существует несколько типов инспекций кода [1]:

– формальные инспекции (formal inspections);

– инспекция через плечо (over-the-shoulder review);

– инспекция кода с помощью e-mail (e-mail pass-around reviews);

– парное программирование (pair-programming);

– инспекция кода с помощью специальных средств (tool-assisted reviews).

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

При парном программировании два разработчика решают вместе одну задачу за одним компьютером. В случае инспекции через плечо разработчик просто показывает код своему коллеге.

При инспекции с помощью e-mail измененный код автоматически отправляется на анализ другому программисту.

Инспекция кода с помощью специальных средств предполагает наличие утилит помогающих в проведении анализа. Они облегчают:

– сбор внесенных в код изменений;

– сравнение текущего и предыдущего состояний кода;

– ведение диалога, касающегося определенного кода;

– сбор статистики;

– форсирование проведения инспекции кода и исправления найденных дефектов

– и т.д.

Наш опыт проведения инспекций кода

Мобильная разработка начала активное развития после презентации первого телефона iPhone. В силу того, что это довольно молодая область, программистам работающем в ней важна кооперация, адаптация существующих подходов из области веб или десктоп разработки, работа над новыми идеями. И здесь очень сильно выручает практика инспекций кода.

Наша команда мобильной разработки прошла длинный путь внедрения инспекций кода. Все начиналось с периодических формальных инспекций. Сейчас же используются практически все типы инспекций кода. Большая часть однотипных действий при анализе кода автоматизирована, что позволило безболезненно внедрить данную практику в процесс разработки программного обеспечения.

Прежде всего в дополнение к формальным инспекциям кода была интегрирована проверка проектов статическими анализаторами кода. В случае разработки под Android использовались Pmd, Findbug, Checkstyle, Lint. Это позволило в автоматическом режиме находить все проблемы кода, связанные с несоблюдением стиля кодирования, неправильным использованием системных API, ошибок в построении интерфейса пользователя и т.д. По началу интеграция данных анализаторов на билд-сервере полностью удовлетворяла наши потребности. Однако, со временем, данный подход перестал нас устраивать по многим причинам. В особенности нам не нравилось, что:

– каждый анализатор приходилось настраивать отдельно, а при решении использовать новый анализатор – его добавление во все проекты делалось вручную;

– не было удобной и централизованной возможности управлять правилами анализаторов (отключать, добавлять, редактировать);

– отсутствовала возможность игнорировать ложные срабатывания не изменяя код;

– нельзя было хоть как-то взаимодействовать с замечаниями (например, откладывать их исправление, комментировать и т.д.);

– замечания, генерируемые различными анализаторами нельзя было объединить в один отчет.

pdm-result

Результаты анализа проекта с помощью PMD (Jenkins plugin)

22222

Подробная информация о найденном дефекте с помощью PMD (Jenkins Plugin)

Вскоре мы поняли, что дальше так продолжаться не может – команда росла, и каждому новому программисту приходилось усваивать довольно большой объем информации относительно существующих процессов разработки и используемых утилит. Тогда было принято решение попробовать платформу SonarQube[3], которая предназначена для постоянного отслеживания качества кода. Несмотря на наши сомнения, платформа показала себя только с хорошей стороны. Она решила большую часть наших проблем, связанных со статическими анализаторами кода, добавила новые метрики, по которым можно отслеживать состояние проекта. Управление правилами стало централизованным, появилась возможность составлять планы исправления найденных дефектов и т.д.

33333

Результаты анализа проекта в SonarQube

555555555

Подробная информация о найденном дефекте в SonarQube

Статические анализаторы кода, конечно, очень помогают, но полностью полагаться на них нельзя. Они позволяют избавить формальные инспекции кода от обсуждения очевидных дефектов и указать на подозрительные места. Но посоветовать что-то, например, в плане архитектуры приложения они не в силах.

Проведение формальных инспекций кода, даже с учетом помощи статических анализаторов, слишком затратное по времени мероприятие. Поэтому, с одной стороны, если его проводить часто, продуктивность программистов действительно снизится, с другой – если проводить редко, увеличится количество кода, которое необходимо проинспектировать. Согласно же проведенным исследованиям большое количество кода только снизит число найденных дефектов [2].

В поисках решения, которое было бы так же эффективно, как формальная инспекция кода, но не отнимало так много времени, мы пришли к использованию Atlassian Crucible [4]. Фактически это средство взяло на себя всю работу по:

– подготовке изменений кода к проверке;

– навигации в коде;

– ведению диалогов относительно определенных строк кода;

– приглашению разработчиков для проведения инспекции;

– отслеживанию исправлений, согласно замечаниям коллег;

– и т.д.

Самая же интересная возможность, которой мы активно пользуемся в Crucible, состоит в том, что теперь все изменения в коде привязаны к определенной задаче. То есть, это позволяет проводить инспекции кода относительно определенной задачи. В результате замечания коллег-программистов носят более предметных характер и действительно помогают найти и исправить нетривиальные ошибки.

6666666

Пример экрана пользователя при проведении инспекции кода с помощью Atlassian Crucible

77777

Пример экрана создания инспекции кода в Atlassian Crucible

Таким образом, в нашей команде каждый коммит сделанный разработчиком проверяется на билд-сервере статическими анализаторами. Вся собранная статистика аккумулируется в SonarQube и используется всеми заинтересованными лицами: программистами – для самопроверки и определения проблемных мест, руководством – для понимания состояния проекта. Когда программист заканчивает работу над задачей, он начинает инспектирование кода. С помощью Crucible выделяются изменения связанные с завершенной задачей, и приглашаются члены команды. Когда код будет всех устраивать инспекция кода завершается. В результате каждая строчка кода подвергается анализу, и за нее отвечает теперь команда целиком.

Хотя мы и перешли к проведению инспекций кода посредством специальных средств, полного отказа от формальных инспекций не было. Они все равно проводятся, но носят более глобальных характер, т.к. на них обсуждается вопросы связанные с архитектурой приложения. Формальные же инспекции проводятся в обязательном порядке для всех новых проектов, которые поступают к нам.

Что мы имеем?

Инспекции кода несомненно помогают в разработке качественных приложений как со стороны пользователя (приложение не падает, не тормозит, работа с ним интуитивно понятна), так и со стороны разработчиков (отличная архитектура приложения, отсутствие технического долга). В то же время каждая команда программистов уникальна, и поэтому обычно требуется особый подход к внедрению каких-либо новых практик. В нашем случае была поддержка как со стороны программистов, так и со стороны руководства, что позволило успешно встроить инспектирование кода в процессы разработки. Результатом данной работы стало:

– увеличение количества дефектов обнаруженных и исправленных до момента тестирования;

– уменьшение времени затрачиваемого на инспекцию кода;

– уменьшение времени затрачиваемого на тестирование приложения;

– заинтересованность команды в проведении анализа кода;

– отслеживание результатов проведенных инспекций кода;

– расширение области знаний разработчиков о коде проектов;

– более быстрый обмен опытом между начинающими и продвинутыми разработчиками;

– наблюдаться сокращение замечаний предъявляемых к коду (в силу роста общей компетенции команды);

– уменьшение рисков затягивания сроков поставки;

– появление метрик, по которым можно косвенно судить о состоянии проектов.

В итоге

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

Литература

  1. Best Kept Secrets of Peer Code Review / J. Cohen, St. Teleki, E. Brown
  2. 11 Best Practices for Peer Code Review // 11_Best_Practices_for_Peer_Code_Review.pdf
  3. Atlassian Crucible Overview – https://www.atlassian.com/software/crucible/overview
  4. SonarQube – http://www.sonarqube.org

Подводные камни в планировании разработки на GWT

В последнее время к Google Widget Toolkit приковано внимание веб-разработчиков со всего мира. GWT – это прекрасная технология для AJAX-разработки. Она позволяет избавиться от многих проблем, связанных с кросс-браузерной разработкой, взаимодействием с пользователем и циклом разработки.

Библиотека предоставляет невиданные ранее возможности для разработки Web 2.0 – приложений с высокой степенью интерактивности. Но в этом кроется подвох.

Зачастую интерфейс веб-приложения более лёгок для разработки, чем интерфейс десктопных приложений, и тому есть 2 причины. Во-первых, система HTML/CSS предоставляет большое число инструментов для визуального воплощения дизайнерской мысли. Нет нужды многократно проходить цикл сборка/запуск/отладка для каждой страницы. Во-вторых, HTML обеспечивает намного меньше интерактивности, чем заключено в браузере. Поэтому на разработчика ложится меньше задач по отладке.

 

Необычность AJAX-разработки на GWT заключается, в том числе и в том, что оба эти фактора претерпевают изменения. GWT-приложения очень интерактивны и имеют компонентную структуру. Поэтому исходные ожидания лёгкости изменения вида веб-приложений вряд ли оправдаются. Теперь для изменения внешнего вида потребуются значительные усилия. К тому же дизайн компонентов ограничен рамками имеющегося набора настроек. Навороченное поле для ввода текста, созданное веб-дизайнером, может причинить кучу неудобств команде разработчиков. Прямо как в старые добрые времена разработки десктопных интерфейсов.

Таким образом, разработка на GWT требует тесного сотрудничества дизайнеров и разработчиков. Заприте их всех в маленькой комнате с толстыми дверями и маленьким окошком для пищи.

Другое свойство GWT-приложений – интерактивность. Это одновременно и хорошо, и проблемно.
Как было сказано выше, приложения Web 1.0 практически не обеспечивали интерактивного взаимодействия с пользователем. И первым шагом веб-дизайнеров была отрисовка статических частей интерфейса. Здесь такое уже невозможно. Разработчикам нужно конкретное поведение приложения. А поведение приложения – это часть кода. Его не так-то просто изменить. Поэтому нужно иметь в запасе всё необходимое для отладки и доводки интерфейса.

Подытожим вышесказанное. Держите разработчиков и дизайнеров как можно ближе друг к другу. Может, поэтому Google Apps и работают так добротно, что интерфейс создавался в близком сотрудничестве с разработчиками.

Об авторе:

Alexey Kharlamov. Photo Алексей Харламов – эксперт в области разработки приложений на Java. Работает с GWT-проектами с самого начала развития GWT.