Больше всего меня порадовало то, что с работы легко отпустили с сохранением зарплаты:-)
Повестка конференции была такая: http://softwarepeople.ru/sp2010/pro
В общем, на первый день я чуток опоздал, в торопях забыл взять устройство для синхронного перевода и поэтому пришлось три часа слушать доклады на английском без перевода.
С гордостью за себя, отмечу, что я понял почти все что говорили докладчики.
Первым выступал Питер Хрущка (которого одна тетенька постоянно объявляла как Питер Хрюшка), автор книги "Зомбированные шаблонами" и "евангелист" Agile методологии.
В общем-то, по Agile я еще проекты не разрабатывал, вся эта тема для меня нова. Кстати, а вы, читатели-программисты, используете Agile в своих компаниях?
Далее, оказалось, что мы пали жертвой вулкана Эйая.....кудль и программа поменялась
В общем, два докладчика к нам приехать не смогли.
Товарищ Дон Сайм (F#) вел доклад удаленно, а Дон Смит вообще был неизвестно где, посему слушали доклад "Разработка игр на XNA для X-BOX", за часик набросали кажуал игру-стрелялку.
Потом был обед, на который я опоздал, т.к. участвовал в обсуждении, можно ли юзать SQLLite в Silverlight в out-of-browser приложении.
Кстати, вспоминая, Microsoft Dev Days могу сказать, что на SWP еды раза в два меньше:-)
После обеда пошел на "Кто такой менеджер продукта и что он может дать компании разработчику?". Тут обсуждалась роль Product Manager в Agile процессе разработки.
Вообще, вся конфа прошла под флагом Agile, в котором я к тому моменту ни в зуб ногой:-)
Далее пошел на "Облачные вычисления. Сценарии использования" - интересная для меня тема. Думаю за этим будущее, очень жалею, что ну никак не дойдут руки до этих облаков ("я тучи разведу руками":-))
Во время кофе послушал "Из исполнителя в руководители. Первые шаги по граблям", докладчик был из Киви. В общем, идея в том, что в самом начале надо узнать, какими ресурсами вы владеете и чем вы можете руководить. По-крайней мере, мне запомнилось только это:-)
Второй день конфы оказался поинтереснее.
День начался с "Типичный день эффективного лидера". Тут я узнал, какой должен быть менеджер проекта и что он должен делать:
1. Уверенным в себе и самокритичным
2. Усиливать команду
2.1 использовать любую ситуацию как teaching moment, следить за своим подчиненным, записывать промахи и потом давать ему как feedback
2.2 давать кросс-функциональные задания, чтобы человек не застаивался
2.3 ставить невыполнимые сроки! да-да, специально, чтобы команда открыла для себя скрытые ресурсы
2.4 привить работнику привычку критиковать себя, а не менеджера и команду
2.5 мыслить в реальном времени (не до переговоров, а в самом ее конце)
3. Самостоятельность
3.1 Думать как владелец бизнеса
3.2 Лидер уходит, команда продолжает развиваться
4. Энергия
4.1 обещать светлое будущее и конкретные сроки
4.2 работать больше всех и не показывать усталости
4.3 проактивно реагировать на инициативы
4.4 допускать легкую конкуренцию среди сотрудников
4.5 приводить клиентов и топ-менеджеров в офис, чтобы сотрудники видели для кого пишется продукт
4.6 жить успехом сотрудников
5. Атмосфера
5.1 искренность и открытость
5.2 синхронизация слов и действий
5.3 непоколебимые принципы
5.4 ответственность, боевой дух
5.5 быть в курсе работы других сотрудников, это мотивирует людей
6. Вопросы
6.1. задавать вопросы
6.2. выучить досконально некую часть проблемы, задать самый сложный вопрос по этой части сотруднику, тогда у последнего будет чувство, что вы все знаете и халтура не пройдет:-)
Далее был доклад по "Технологии командообразования", достаточно интересный взгляд и инфа.
Доклад "Разработка архитектуры приложений и систем" был какой-то вялый и скучный
А вот "Как начать Scrum в один день" на его фоне очень легким, быстрым и доступным. На этом докладе я понял, что це за скрам. Кстати, сайтец у них тут - http://scrum.ee/
Далее я опять заслушался в сессии с вопросами и опоздал на обед:-)
Следующий доклад был от паренька из Люксофта "Управление знаниями организации". Было приятно услышать слова, что тормознутость Шарепоинта не позволила построить БД знаний, и коллеги из Люксофта построили решение на Конфлюэнсе (http://www.atlassian.com/software/conf
Последними докладами были "Обучение, развитие и оценка руководителей ИТ" (да, у меня большие планы:D лол) и мастер-класс "управление конфликтами в команде". Тут ничего интересного не было.
В конце была пивная пати, получил сертификат, антивирус от Eset, VS 2010, книгу по построению архитектуры приложений от MS.
Конфу оцениваю на 4-ку....как-то не так много полезного отхватил
April 27 2010, 09:39:17 UTC 2 years ago
)))
Это всё равно что обучаться «Эффективное катание на лисапеде». Как бы красиво и хорошо тебе теорию не объясняли, научишься ты за такое же кол-во времени)
Главное — мотивация. Рекомендую книгу Ричарда Брэнсона «К чорту всё! Берись и делай!»
April 27 2010, 09:41:44 UTC 2 years ago
April 27 2010, 17:18:46 UTC 2 years ago
Насколько помню, никакого особого восторга не испытал
Может еще раз послушать?
April 28 2010, 14:32:44 UTC 2 years ago
April 27 2010, 18:48:17 UTC 2 years ago
уже около 3-х месяцев по нему стараемся работать, но не все получается.
Самое сложное - выписать все фичи перед началом итерации. ну никак у нас не получается этого достичь, всплывает посередине постоянно что-то. Фактически эта вот неделя первая, когда реально все фичи выписаны и видимо будут сделаны по графику. Ура. :-)
мы вот вместо шарепоинта юзаем redmine (redmine.org) + самописная считалка потраченного времени.
April 28 2010, 04:43:55 UTC 2 years ago
А какие книги стоит почитать, чтобы получить представление о скраме? Ну или сайт какой?
У меня вот сперва такой вопрос возникал, куда вписывать исправление багов? Это ведь никакой не user-story, но потом, узнал, что не только US выставляются на доску, но и Defect
Насколько я понял, вот это "посредине" лучше отложить на след итерацию, иначе можно запутаться в определении скорости разработки.
Взглянул на redmine, возьму на заметку
April 28 2010, 05:20:29 UTC 2 years ago
можно поглядеть описание тут
Вообще, Agile и Scrum в частности, это просто конкретная методология из разряда сначала делай то, потом это. Как и любую методологию, их надо очень аккуратно привязывать к конкретной практике.
Ты прав про "посередине", в теории сразу надо на следующий этап переносить. На практике же иногда надо пофиксить сразу же, потому что многое может быть завязано на конкретный баг или фичу. Поэтому осторожно.
April 28 2010, 17:44:12 UTC 2 years ago
Кстати со Скрамтрека там тоже был Асхат Уразбаев(?)
Даже жаль чуток, лучше бы на его семинар пошел
May 7 2010, 06:18:04 UTC 2 years ago
http://gaperton.livejournal.com/44830.h
там еще предыдущие посты можно почитать :-)