Управление проектами и продуктами на SECR 2015

Обзор конференции по разработке ПО SECR 2015

Федотов А.В.

CEE-SECR — это научно-практическая конференция. Важная особенность конференции – широкий тематический охват. Процесс разработки ПО рассматривается во всех аспектах: технологии, управление командами и продуктами, образование, найм специалистов, ведение бизнеса в индустрии и многое другое. В 2015 году конференция проходила в Москве, 22-23 октября.

В отчете представлены только те доклады по теме «Управление проектами и продуктами» и те идеи, которые предоставляли интерес для меня лично.

Вся программа с презентациями находится по адресу:  http://2015.secr.ru/lang/ru/program/agenda

Общее впечатление:

  • В целом, был ряд интересных и полезных докладов. Есть, что стоит внедрять в собственной компании. Особенно понравился «десант» из СимбирСофт, которые рассказали про свой опыт роста от 40 до 200 сотрудников.
  • Плохо, что доклады по данной теме проходили одновременно в разных залах. Очень хотелось и мастер-классы посетить, и другие выступления послушать.
  • Сильно разочаровало выступление Антона Семенченко «Треугольник “Принцип открытого кимоно + Delegation + Self-Communication Management” как инструмент мотивации». Всего один слайд и много разговоров, фактически, ни о чем.

Обзор докладов

5 “врагов” командной работы в SAFe и как с ними бороться

Докладчик: Светлана Болсуновская, Координатор проектов, ЗАО “Моторола Солюшнз”. Презентация

Внедрили Agile/Scrum, получили множество проблем, решили с ними бороться с помощью Scaled Agile Framework (SAFe), в которой есть три уровня управления: «команда» (работает по Scrum), «программа» (осуществляет управление разработкой) и «портфолио» (нечто эпическое на уровне компании).

1

Как итог, много разных собраний (от 2 раз в неделю), большие накладные расходы, постоянные попытки улучшить процессы. Совершенно непонятно, затем было все так усложнять в попытке «удерживаться» за Agile/Scrum.

Хорошая идея: Организация доски «прогресса», чтобы все наглядно видели продвижение разработки.


Проблема управления приоритетами задач ИТ в розничном банке

Докладчик: Андрей Сабынин, Руководитель Центра Разработки, Ханты-Мансийский банк «Открытие». Презентация

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

2

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

Вопрос из зала по возможности привлечения к голосованию клиентов банка остался без уверенного ответа.

Примечание: В качестве task tracker используется Redmine.


Внедрение agile в большой корпорации: приключения обыкновенные и невероятные

Докладчик: Оксана Некрасов, Engineering manager, EMC. Презентация

Классическая водопадная модель компанию не устраивала, поэтому три года назад она начала внедрение Agile. Для подразделения, состоящего из более чем 1000 человек, работающих на одной кодовой базе (миллионы строк кода), использующих разные технологий это внедрение провалилось.

3

Тогда компания решила «совершенствовать» Agile (Agile -> SAFe -> SAFe.net), и этот процесс продолжается до сих пор. Создалось ощущение, что они достаточно сильно усложнили процесс разработки и, фактически, стали работать по классической инкрементной модели разработки с элементами Agile.


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

Докладчик: Александр Колесников, Программист, Лаборатория Касперского. Презентация

Главный вопрос, ответить на который должны помочь метрики: «Насколько качественное ПО мы разрабатываем?»

Список метрик:

  1. Покрытие кода тестами (code coverage).
  2. Ошибки абстрагирования (abstract interpretation).
  3. Цикломатическая сложность (cyclomatic complexity).
  4. Предупреждения компилятора (compiler warnings).
  5. Соответствие стандартам кодирования (coding standards).
  6. Дублирование кода (code duplication).
  7. Связность (fan out).
  8. Мертвый код (dead code).

Все метрики достаточно хорошо представлены в презентации, имеет смысл посмотреть ее самостоятельно.

4

Вопрос из зала: Что делать  с унаследованным кодом (старым или полученным из open source)?
Ответ: Оставить, как есть. Исключить из метрик.

Резюме: Данные метрики стоит постепенно внедрять в своих процессах.


Как дорогу из граблей превратить в автобан или как мы внедрили службу качества

Докладчик: Дмитрий Петерсон, Заместитель директора, СимбирСофт. Презентация

В компании наступил момент, когда была осознана необходимость внедрения службы качества, причем не для сертификации («галочки»), а для реального улучшения качества разработки и выпускаемых продуктов. Хотели применить ISO, но не разобрались в нем (перечисленные в презентации «недостатки» ISO, на самом деле, не являются недостатками).

Провели аудит по Capability Maturity Model Integration (CMMI), из которого стало ясно, что именно нужно делать. В частности, создали отдел аналитики.

5

В целом, проведена стандартная процедура создания службы качества. Затраты: 1 год, около 85 000 $.

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


Модель Agile-трансформации крупной компании или когда Scrum бессилен

Докладчик: Дмитрий Лобасев, Тренер и консультант по гибким методологиям. Презентация

У каждой компании со временем появляется своя устоявшаяся культура, которая является неким «резиновым обрамлением» всех подразделений и процессов (слайд №18). Попытка внести нововведения или изменения только в одном месте приведет к отторжению и возврату назад (слайд №19). Кроме того, как во всех процессах, очень важна коммуникации.

6

Улучшение коммуникации за счет предложенной докладчиков практики ежедневной получасовой встречи 50 разработчиков (в том числе и по видеоконференции) сомнительно. Тратить на это 500 человеко-часов в месяц (около 700 тыс. рублей) – это роскошь, которую трудно оправдать.

Резюме: На самом деле, проблемы изменений процессов относятся не только к Agile/Sсrum, а являются общими для любой стратегии разработки.


Почему ТЗ не поможет вашему проекту и что же делать?

Докладчик: Борис Вольфсон, Директор по развитию, HeadHunter. Презентация

Стандартные проблемы технического задания (ТЗ):

  1. Заказчик плохо знает, что хочет.
  2. Заказчик плохо знает, что нужно пользователю.
  3. По ТЗ трудно понять продукт в целом.
  4. Чем детальнее ТЗ, тем больше в нем лишнего (45% функциональности вообще не используется).

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

Что делать?

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

Фасилитация проектных совещаний

Докладчик: Светлана Мухина, Agile коуч, Люксофт. Презентация

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

7


Организация работы отдела аналитики

Докладчик: Алексей Флоринский, Руководитель Web-отдела, ООО “СимбирСофт”. Презентация

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

Идеи, которые стоит внедрять в практику:

  1. Разработка регламента использования Wiki.
  2. Создание начальных страниц Wiki с макро описанием проекта.

Вопрос из зала: Часть задач, которые у Вас выполняют аналитики, являются задачами руководителя продукта (product manager). Не хотите явно выделить эту должность?
Ответ: У них нет таких разносторонних сотрудников.


Применение моделирования во взаимодействии между заказчиком и разработчиком ПО

Докладчик: Дмитрий Дзюба, директор департамента разработки продуктов, NVision Program Solution. Презентация

Когда был достигнут рекорд по объему технического задания (ТЗ) в 500 страниц, стало понятно, что необходимо менять принцип создания и согласования ТЗ. Было предложено использовать Sparx Systems Enterprise Architect и UML 2.0. Заказчик, с которым у них многолетнее сотрудничество, является достаточно прогрессивным и готовым к изменениям, согласился.

9

Переход на новый процесс занял 1 год, но все стороны видят выгоды. Для экспорта официальных документов, в частности, для бухгалтерии, компания разработала собственные генераторы отчетов (plug-in).

Резюме: Хорошо иметь такого заказчика.


5 способов убить команду через Code Review

Артем Коломеец, Разработчик, Лаборатория Касперского.

Были использованы 3 подхода к Code Review:

  1. Чтение: Разработка -> Check in -> Review -> Task done.
    Основные недостатки: Нет цели просмотра, идет накопление эмоций («как он пишет!»), проблема с коррекцией.
  2. Анализ: Разработка -> Review -> Check in -> Task done.
    Основные недостатки те же, только возможна коррекция явных ошибок до записи в репозиторий.
  3. Инспекция: Разработка -> Check in -> Review -> <Возможный возврат к разработке> -> Task done.Ликвидируются недостатки предыдущих подходов, плюс добавляется принятие ответственности за код аудитором (reviewer).

Резюме: Code Review полезен в принципе, и при его внедрении лучше использовать подход «Инспекция».


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

Ксения Стернина, Руководитель юзабилити-лаборатории, Mail.ru Group. Презентация

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

10

Просто понравился доклад.

Опубликовано в: