От нашей фирмы там была делегация из четырех человек: Парфенов, Липатов, Маурин, Трешников Паша.
Программу семинаров и тезисы докладов можно посмотреть тут: http://softwarepeople.ru/2011/program/
Скоро ожидается публикация видео докладов и презентаций.
Личные впечатления
- Первый день был скучноват. Высокие иностранные докладчики рассказывали азбучные истины или лили воду. Или это мы стали такие умные что все это уже знаем, или проблема в докладчиках.
- Апофеозом первого дня был заключительный доклад тетеньки из UsabilityLab про взаимоотношения в команде. Ждем видео чтобы показать его всем у нас.
- Другим сюрпризом первого дня стал восходящая звезда Самарского и Российского программирования - Кирилл Маурин, который в неравной борьбе (он всех делал как котят) ответил почти на все вопросы в викторине по функциональному программированию, и получил 3 из 10 ценных приза - книжки по языку F#. (дали только три, потому что под конец ему стали давать уже через одну, чтоб досталось и другим)
- Второй день был более насыщенным и интересным, было много хороших докладов, так что мы порой разрывались - куда бы сходить. Временами даже бегали туда-сюда между залами чтобы урвать от двух докладов сразу.
- Хронометраж выдерживался четко - реально было успеть сменить зал между докладами
- Кормили много и вкусно :)
- Мы очень здорово пообщались с нашими Самарскими коллегами, у которых уже несколько лет используется скрам, и даже позвали их к нам в гости обменяться опытом
Записки из блокнотов
Почти записки на манжетах, те важные мысли из докладов, которые мы фиксировали чтобы не забыть.
- Автоматизация тестов - необходимо готовить код к тестам. Возможно выделять собственное АПИ для тестирования логики.
- Статический анализ кода надо делать. В Дельфи ХЕ есть встроенные средства. Пока не перешли - надо найти аналоги для 2007.
- В больших продуктах (читай заявки) полезно разделять команды на две. Первая занимается развитием ядра продукта. Вторая - выпуском и доводкой релизов, багфиксом-поддержкой. Для разных команд разное планирование.
- Creately - онлайн тул для рисования всяких диаграмм (вместо визио). Интеграция с вики
- Любой программист должен уметь подхватить проект.
- Необходимо постоянно "жить" с командой, а не только работать
- Нет плохих заказчиков, отношение к заказчику должно быть всегда исключительно хорошее
- Чем более работа руководителя "незаметна" в команде, тем эта работа лучше
- Команду тестирования необходимо интегрировать с командой разработки
- Крайне желательно осветить подробно ограничения популярных методологий (Agile) и методик (TDD). Очень уж много некритичной рекламы.
- Чтобы команда лучше работала, главное ей ... не мешать
- Людей полезно раз в полгода-год переводить на другой проект
- Большие проекты надо бы пилить на общие библиотеки и конкретные приложения
- Аналитика-разработка-тестирование должны выполняться одной общей командой в одном помещении, а не тремя разными
- Функциональное программирование уже скоро может оказаться не экзотикой, а мейнстримом.
- Работать с требованиями – это как ходить по воде. Удобнее, когда и то и другое заморожено. Но замораживать требования в нашей работе не всегда получается. Необходимо использовать итерационный и инкрементальный процесс разработки. Это позволяет избегать высоких рисков,связанных с "непониманием" клиента, бизнес-процесса и т.д.
- При постановке задачи необходимо:
- описывать что достичь, а не как
- четко оговаривать время выполнения задачи и доступные ресурсы
- объяснять что произойдет если задача не будет решена вовремя
- контроль поставленных задачи должен быть неизбежным, так же как восход солнца
-
- Пул задач команды, который находится в разработке должен быть соизмерим с пулом задач находящимся в тестировании и в аналитике. Не более и не менее, иначе одна из активностей (аналитика, разработка, тестирование) начинает простаивать(задач нет) либо из за перегрузки тормозить вес процесс(задач много).
- При решении задачи отвечать на сначала на вопрос "что должно быть сделано?", "зачем это должно быть сделано", а после этого уже на вопрос "как это должно быть сделано?"
- Не надо увлекаться методологиями(agile круто!) и пытаться их внедрить полностью если это тормозит общий процесс разработки. Надо выборочно использовать полезные практики из различных методологий.
- Поискать описания использующихся бизнес процессов в компании Toyota - бережливая разработка и канбан пришли именно оттуда
#Аналитика
#Обмен опытом
#Программирование
#Тестирование