Отзывы о PHPConf 2009
Отзывы о PHPConf 2009
8-9 октября прошел Web Architect WorkShop Day и PHPConf 2009
Как всегда все прошло на высоком уровне ;-)
Отзывы (как всегда без цензуры)
Отчет с первого дня PHPConf 2009
http://khamukhin.blogspot.com/2009/10/phpconf-2009.html
Сегодня мне посчастливилось посетить конференцию для разработчиков на PHP (и не только) - PHPConf 2009. Программа разделена на два дня, сегодня был первый.
Немного размышлял, стоит ли рассказать про докладчиков по отдельности или привести общие выводы о конференции в целом. Объединяя все доклады в общее описание, получится что-то слишком среднее, не оригинальное. Поэтому я бы хотел рассказать о каждом докладе в отдельности, каждый доклад, как и докладчик, по своему интересен, имеет свою индивидуальность.
"10 мантр менеджера веб-проекта", Александр Орлов
Александр с самого начала постарался внушить к себе доверие, рассказав о своем опыте работы в таких компаниях как Sun (начало карьеры) и Intel (почти текущий этап карьеры).
Мантры для менеджера или РП оказались такими:
1. Стратегия проекта - какая прибыль будет у проекта к 2011 году?
2. Риски - у вас есть риск-план?
3. Жесткий отбор кандидатов;
4. WWW - Who, What, When - это то, что нужно спросить сотрудников, которые чересчур увлеклись обсуждением технических аспектов, этот вопрос вернет людей из облаков
5. Четыре причины, почему сотрудники не делают то, что ожидаешь - это нечеткие цели, не умение, отсутствие возможности, отсутствие желания
6. Интерес к работе
7. 4 составляющих лидера - это РАПИ, то есть Разработчик, Администратор, Предприниматель, Интегратор
8. Все люди очень разные - и не только сотрудники, но и заказчики
9. Отношения - не забыть составить список "стейкхолдеров" - лиц, которые касаются вашего проекта, заинтересованные лица (это может быть не только босс, но например и ваша невеста, ведь ей вы наверняка рассказываете о своем проекте)
10. Саморазвитие - читать, читать, и еще раз читать как можно больше
Александр постоянно интересовался у слушателей, прочли ли они ту или другую книгу по теме доклада, и к всеобщему стыду практически никто этим не мог похвастаться. Свою личную библиотеку стоит пополнить такими книгами:
* "Человеческий фактор: успешные проекты и команды", Демарко
* "Мифический человеко-месяц", Брукс
* "Развитие лидеров", Адизес
* "Руководство командой разработчиков программного обеспечения. Прикладные мысли", Архипенков
* http://www.joelonsoftware.com/
Доклад получился интересным, мотивирующим на огромное саморазвитие (чтения многих источников), и одновременно обзорным. Вполне можно было выделить одну из мантр и рассмотреть ее отдельно под мощным микроскопом.
"Обеспечение качества сайта (ПО) на основании глоссария (словаря данных)", Григорий Кочанов
Доклад я выбрал, потому что в своей работе сейчас активно разрабатывается идея проверки программистом документа "ФТ" по списку критериев, так называемому чек-листу. Например, если нужно по ФТ добавить форму авторизации, то соответствующий чек-лист должен содержать список критериев для проверки этого требование на ударопрочность: "указано ли в требованиях, что выводить после безуспешной попытки авторизоваться?", или "имеет ли значение регистр букв?" и т.д. Если требование касается добавления на существующий сайт какой-то небольшого функционала посвященного маркетинговой акции, то чек-лист кроме всего прочего, должен иметь критерий "а есть ли требования, как потом следует убрать эту временную функциональность?".
Оказалось, что доклад не помог мне развить чек-листы, доклад был действительно о глоссарии. Не уверен про большинство слушателей, а вот в моей работе глоссарий активно используется.
Вот некоторые интересные моменты из доклада:
* Разработчики зря уделяют слишком много внимания вопросам верстки и полиграфии, а не архитектуре приложения
* Изменять элементы справочников нельзя - нужно либо сохранять историю изменений, либо... не изменять
* От систем ведения багов, вроде Bugzilla или Mantis, желательно получать график открытых багов во времени
* Стоит прочитать книгу "Записки автоматизатора", Андрея Орлова, а также блог автора доклада, там где-то должен быть пример глоссария
"Практика построения среды разработки, определяющей процесс проектирования", Андрей Петров
Автор доклада очень спокойно и уверенно рассказал огромный кусок из процесса анализа и разработки проекта, если не весь процесс.
Мне кажется, что Андрей хотел рассказать в первую очередь о том, как анализ требований влияет на архитектуру, собственный успешный опыт. В докладе Андрей использовал термин "Хотелки", - это источник требований, то что просит сделать заказчик. "Хотелки" стоит преобразовать в цели, среди которых выделить главную цель. Из всех целей создаются сценарии. Сценарии согласуются с заказчиком и являются "исходниками", как для заказчика (согласуются), так и для разработчика и тестировщика (создаются тест-кейсы).
Сценарии позволяют выделить:
1. Действующих лиц;
2. Объекты, с которыми работают действующие лица;
3. Действия.
Действия определяют основные методы, и вместе с объектами они образуют модель и контроллер из паттерна MVC.
Если построить дерево целей, то в случае изменения одной из целей (то есть изменения требований), можно смело сказать, что потребуется переписать код, который относится к соответствующим сценариям.
К некоторому сожалению, многих слушателей заинтересовала больше не главная, на мой взгляд, идея, а технические детали - собственный фреймворк, который в ближайшее время должен стать открытым проектом.
Последня интересная особенность доклада - это состав идеальной команды по менению Андрея - это, внимание, вот какие роли:
* Аккаунт менеджер;
* Разработчик
* Тестировщик
Как НЕ писать ТЗ и делать успешные продукты, Ольга Белова
Это последний доклад, который я посетил сегодня. Выступление несколько отличалось от других. Дело в том, что Ольга, кажется, была более связана с маркетингом, нежели с разработкой. Кроме того, Ольга рассказала, что последовала примеру автора книги "Все маркетологи - лжецы", где в первой же главе было сказано, что и не совсем лжецы, да и не все. То есть ТЗ писать все же иногда нужно. А название подкупает.
Выступление было очень живым - получился активный диалог с другим докладчиком - Григорием Кочановым (доклад "Профессия - аутсорсер: секреты мастерства", который я к сожалению пропустил). Григорий настаивал, что живое общение Ольги с командой разработчиков, рисование на салфетках, скетч-прототипы - это все как раз и есть подобие ТЗ. Здесь я согласен с Григорием.
Но Григорий также заметил, что доклад Ольги похож на "химию на уровне эмоций". Однако, на мой взгляд, основная идея была в том, что не нужно формальное ТЗ или ФТ на n страниц, если заказчик этого не просит, и команда очень-очень слажена. Главное в такой слаженной команде - это не забыть составить минимальную документацию после написания кода проекта.
Плюс одна книга в личную библиотеку: "Управление безнадёжными проектами", Йордон.
Отзывы о PHPConf 2009
8-9 октября прошел Web Architect WorkShop Day и PHPConf 2009
Как всегда все прошло на высоком уровне ;-)
Отзывы (как всегда без цензуры)
Отчет с первого дня PHPConf 2009
http://khamukhin.blogspot.com/2009/10/phpconf-2009.html
Сегодня мне посчастливилось посетить конференцию для разработчиков на PHP (и не только) - PHPConf 2009. Программа разделена на два дня, сегодня был первый.
Немного размышлял, стоит ли рассказать про докладчиков по отдельности или привести общие выводы о конференции в целом. Объединяя все доклады в общее описание, получится что-то слишком среднее, не оригинальное. Поэтому я бы хотел рассказать о каждом докладе в отдельности, каждый доклад, как и докладчик, по своему интересен, имеет свою индивидуальность.
"10 мантр менеджера веб-проекта", Александр Орлов
Александр с самого начала постарался внушить к себе доверие, рассказав о своем опыте работы в таких компаниях как Sun (начало карьеры) и Intel (почти текущий этап карьеры).
Мантры для менеджера или РП оказались такими:
1. Стратегия проекта - какая прибыль будет у проекта к 2011 году?
2. Риски - у вас есть риск-план?
3. Жесткий отбор кандидатов;
4. WWW - Who, What, When - это то, что нужно спросить сотрудников, которые чересчур увлеклись обсуждением технических аспектов, этот вопрос вернет людей из облаков
5. Четыре причины, почему сотрудники не делают то, что ожидаешь - это нечеткие цели, не умение, отсутствие возможности, отсутствие желания
6. Интерес к работе
7. 4 составляющих лидера - это РАПИ, то есть Разработчик, Администратор, Предприниматель, Интегратор
8. Все люди очень разные - и не только сотрудники, но и заказчики
9. Отношения - не забыть составить список "стейкхолдеров" - лиц, которые касаются вашего проекта, заинтересованные лица (это может быть не только босс, но например и ваша невеста, ведь ей вы наверняка рассказываете о своем проекте)
10. Саморазвитие - читать, читать, и еще раз читать как можно больше
Александр постоянно интересовался у слушателей, прочли ли они ту или другую книгу по теме доклада, и к всеобщему стыду практически никто этим не мог похвастаться. Свою личную библиотеку стоит пополнить такими книгами:
* "Человеческий фактор: успешные проекты и команды", Демарко
* "Мифический человеко-месяц", Брукс
* "Развитие лидеров", Адизес
* "Руководство командой разработчиков программного обеспечения. Прикладные мысли", Архипенков
* http://www.joelonsoftware.com/
Доклад получился интересным, мотивирующим на огромное саморазвитие (чтения многих источников), и одновременно обзорным. Вполне можно было выделить одну из мантр и рассмотреть ее отдельно под мощным микроскопом.
"Обеспечение качества сайта (ПО) на основании глоссария (словаря данных)", Григорий Кочанов
Доклад я выбрал, потому что в своей работе сейчас активно разрабатывается идея проверки программистом документа "ФТ" по списку критериев, так называемому чек-листу. Например, если нужно по ФТ добавить форму авторизации, то соответствующий чек-лист должен содержать список критериев для проверки этого требование на ударопрочность: "указано ли в требованиях, что выводить после безуспешной попытки авторизоваться?", или "имеет ли значение регистр букв?" и т.д. Если требование касается добавления на существующий сайт какой-то небольшого функционала посвященного маркетинговой акции, то чек-лист кроме всего прочего, должен иметь критерий "а есть ли требования, как потом следует убрать эту временную функциональность?".
Оказалось, что доклад не помог мне развить чек-листы, доклад был действительно о глоссарии. Не уверен про большинство слушателей, а вот в моей работе глоссарий активно используется.
Вот некоторые интересные моменты из доклада:
* Разработчики зря уделяют слишком много внимания вопросам верстки и полиграфии, а не архитектуре приложения
* Изменять элементы справочников нельзя - нужно либо сохранять историю изменений, либо... не изменять
* От систем ведения багов, вроде Bugzilla или Mantis, желательно получать график открытых багов во времени
* Стоит прочитать книгу "Записки автоматизатора", Андрея Орлова, а также блог автора доклада, там где-то должен быть пример глоссария
"Практика построения среды разработки, определяющей процесс проектирования", Андрей Петров
Автор доклада очень спокойно и уверенно рассказал огромный кусок из процесса анализа и разработки проекта, если не весь процесс.
Мне кажется, что Андрей хотел рассказать в первую очередь о том, как анализ требований влияет на архитектуру, собственный успешный опыт. В докладе Андрей использовал термин "Хотелки", - это источник требований, то что просит сделать заказчик. "Хотелки" стоит преобразовать в цели, среди которых выделить главную цель. Из всех целей создаются сценарии. Сценарии согласуются с заказчиком и являются "исходниками", как для заказчика (согласуются), так и для разработчика и тестировщика (создаются тест-кейсы).
Сценарии позволяют выделить:
1. Действующих лиц;
2. Объекты, с которыми работают действующие лица;
3. Действия.
Действия определяют основные методы, и вместе с объектами они образуют модель и контроллер из паттерна MVC.
Если построить дерево целей, то в случае изменения одной из целей (то есть изменения требований), можно смело сказать, что потребуется переписать код, который относится к соответствующим сценариям.
К некоторому сожалению, многих слушателей заинтересовала больше не главная, на мой взгляд, идея, а технические детали - собственный фреймворк, который в ближайшее время должен стать открытым проектом.
Последня интересная особенность доклада - это состав идеальной команды по менению Андрея - это, внимание, вот какие роли:
* Аккаунт менеджер;
* Разработчик
* Тестировщик
Как НЕ писать ТЗ и делать успешные продукты, Ольга Белова
Это последний доклад, который я посетил сегодня. Выступление несколько отличалось от других. Дело в том, что Ольга, кажется, была более связана с маркетингом, нежели с разработкой. Кроме того, Ольга рассказала, что последовала примеру автора книги "Все маркетологи - лжецы", где в первой же главе было сказано, что и не совсем лжецы, да и не все. То есть ТЗ писать все же иногда нужно. А название подкупает.
Выступление было очень живым - получился активный диалог с другим докладчиком - Григорием Кочановым (доклад "Профессия - аутсорсер: секреты мастерства", который я к сожалению пропустил). Григорий настаивал, что живое общение Ольги с командой разработчиков, рисование на салфетках, скетч-прототипы - это все как раз и есть подобие ТЗ. Здесь я согласен с Григорием.
Но Григорий также заметил, что доклад Ольги похож на "химию на уровне эмоций". Однако, на мой взгляд, основная идея была в том, что не нужно формальное ТЗ или ФТ на n страниц, если заказчик этого не просит, и команда очень-очень слажена. Главное в такой слаженной команде - это не забыть составить минимальную документацию после написания кода проекта.
Плюс одна книга в личную библиотеку: "Управление безнадёжными проектами", Йордон.
Вроде хозяева нашлись.
