Весенняя школа ГУ-ВШЭ 2010

Полное название мероприятия - Весенняя школа ГУ-ВШЭ Software Project Management. Было классно. Выступали люди из PeopleMind, из Empatika и Microsoft. Мероприятие открыли руководитель отделения программной инженерии Сергей Авдошин и руководитель центра компетенции PeopleMind Елена Бочарова. Первым выступал Сергей Седов, технический директор «Креатив Медиа». Началось все со слогана "Освободитесь от иллюзии сопричастности к высоким технологиям", с которым я полностью согласен. На мой взгляд, программирование, в большинстве задач никакого отношения к высоким технологиям не имеет. Сравнивались 2 методологии UP и agile. Как оказалось, agile больше подходит для зрелых команд универсалов, в то время как UP основан на четком разграничении обязанностей и использовании узкопрофильных специалистов. Много говорилось о тестировании самих требований о том, что они должны проверяться на адекватность, непротиворечивость и полноту. Звучит красиво, но на сколько реализуемо на практике? Сергей рассказал про стандартные способы оценки длительности:

• экспертная оценка
  
• декомпозиция
• оценка по аналогии
• прототипирование

Экспертная оценка как оказалось - не самый адекватный способ оценки требований, так как он строится на опыте данного конкретного эксперта, на опыте команды с которой он работал, а следовательно эта оценка плохо применима для других команд. На курсе PM в универе нам рассказывали о следующей оценке:


На докладе Сергея мне понравилась эта простая диаграмма:


Также для снижения рисков и экономии времени Сергей советовал автоматизировать процессы тестирования, сборки и выпуска релиза. Еще очень понравилась идея о том, как дисциплинировать свою команду: если кто-то опаздывал на совещание более чем на 10 минут, то он должен был положить 500 рублей, в общую копилку команды. Деньги из копилки тратятся, например, на заказ пиццы для всей команды.

Вторым выступающим был Байрам Аннаков. Почти сразу он смог зажечь весь зал. Он начал выступление с двух забавных роликов c сайта thefuntheory.com. Первый ролик - о том, как заставить людей ходить по лестнице вместо эскалатора на одной из станций метро в Стокгольме. Из лестницы сделали огромное пианино, каждая ступенька - это клавиша.
Второй ролик о мусорке, которая издавала звуки, тем самым удалось в несколько раз увеличить массу собранного мусора (хотя кто знает, что туда кидали). Далее началась игра в ходе которой были названы основные мотиваторы (вспомнил не все, вот что вспомнил):

1. внимание к себе
2. интерес, новизна (обратное - эффект привыкания)
   
3. игра
4. творчество
5. стадное чувство
6. вовлеченность
7. халява
8. обратная связь (т.е. люди всегда делая что-то, ожидают получить обр. связь)

Потом мы все попытались создать отличительные черты команды:

1. атрибутика
2. общая цель (часто это общий враг)
3. кричалки, обряды, ценности
   
4. общий язык, сленг
5. родственные связи
6. своя территория
7. совместная активность
8. наличие механизма правосудия (эффект давления команды)

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

Потом выступил Максим Дорофеев из Лаборатории Касперского.
Он раскритиковал стандартные диаграммы Ганта и предложил другой известный мне из курса PM способ:


Диаграммы Ганга малоэффективны так, как требования - объект постоянных изменений и лишь 20-30%% из них доживут до конца неизменными, еще 20-30%% изменятся, а остальные устареют. Максим предложил рассматривать поток входящих требований In(N) и поток отработанных требований Out(M) как некоторые случайные величины, которые могут быть смоделированы некоторыми законами распределения. Проще всего использовать нормальный закон, так как он легко строится и при больших N и M, любой закон распределения можно аппроксимировать нормальным законом. Используя такой подход, совмещенный с подходом с использованием трендов (см. рис. выше) можно определить наиболее вероятную итерацию, на которой проект будет завершен.

Рецепт Максима:

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