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

Нил Мейден – Инженерия требований как творческое решение проблем

С самого начала стало ясно, что русское название не совсем верное, скорее это «… творческое решение задач».

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

В качестве референтного творческого процесса он рассматривал CPS Method (Osborn 1953). И на нем построил собственный процесс. На входе процесса – люди и их знания, на выходе – скрипты и пользовательские сценарии для анализа и разработки.

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

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

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

Jutta Eckstein – Agile by Planning Continuously

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

Единственная моя заметка: очень важно, чтобы у user story присутствовали следующие пункты:

• явно обозначен business value
• было четко определено кому именно сдавать результат
• явно указывалось по какому критерию будет оцениваться результат

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

Lasse Koskela – Specification By Example

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

Лично для меня было наиболее важным:

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

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

Юрий Шиляев – Программа обучения на 50 000 часов…

Докладчик очень живо и интересно рассказал, как он построил образовательную программу в, пожалуй, крупнейшей в СНГ outsource компании EPAM. Они не только учат, но и меряют кто как учится. Тренера мотивированы, в т. ч. деньгами. У них в каждом офисе нашлось по человеку, которых был готов учить.

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

Ольга Павлова – Менеджеры и программисты: как перестать обижаться друг на друга?

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

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

PS. Считаю, что первый день прошел полезно, но несколько «жидковато» – к сожалению, именитые гест-спикеры часто надевали фуражку Капитана Очевидности. Завтра ожидается просто взрыв мозга.