Slider Background

Мы на SoftwarePeople 2011

Мы на SoftwarePeople 2011

C 7-9 апреля в столице нашей Родины прошла конференция "Software People 2011" (http://softwarepeople.ru/2011/).
От нашей фирмы там была делегация из четырех человек: Парфенов, Липатов, Маурин, Трешников Паша.

Программу семинаров и тезисы докладов можно посмотреть тут: http://softwarepeople.ru/2011/program/
Скоро ожидается публикация видео докладов и презентаций.

Личные впечатления

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