Просмотр исходного текста страницы SoftwarePeople-2010:Отчет Заборова М.А.

[http://mikle.moikrug.ru Моя страница на Круге]

[[Файл:Миша Заборов.jpg|right|100px]]

=  Общие ощущения от конференции =
В целом (на фоне других конференции) организация очень хорошая. Теперь по порядку

== Что понравилось ==
;много народу: По сравнению например в [http://www.arch-labs.ru/ ArchLabs]. Похоже народ не теряет интерес к этим конференциям
;народ новый: Обычно на уже на третей подряд конференции — одни и те же лица и доклады про одно и то же. А в этот раз почти все люди новые (только несколько знакомых докладчиков). — Наверное я давно на конференции не ходил…
;WiFi: Очень хорошо что был. В периодах, где были не интересные(для меня) доклады, удавалось поработать. Основную часть отчета написал на конференции :-), что сэкономило кучу времени. Единственная неприятность, что wifi периодически падал :-((. Обычно это совпадало с попытками Web трансляций кого-нить из Microsoft (например Дона Сайма).
;качество докладов: В общем очень приличное. Было 2-3 доклада ради которых стоило сходить на конференцию, хотя, конечно, были и проходные доклады.
;очень мало организационных накладок: В отличии например от SEC(R), доклады проходили по расписанию. ''Timeline'' выдерживался. Замен практически не было (Только Дон Смит).
;обед сидя: Огромный кармический плюс организаторам за большой холл и столы. В кои то веки за обедом (а также на а кофе-брейках и других перерывах) можно было по-человечески посидеть и пообщаться.
;таблички с докладчиками на обеде: Организаторы придумали фишку — ставить на столы таблички с именем докладчика, что бы посетители могли выбирать с кем сидеть на обеде. Идея наверное хорошая, но реализация получилась так себе (Многие докладчики на таблички забили), а те что не забили, были не очень разговорчивые.
;web трансляция: Вроде как была неплохая вебтрансляция. Иногда доходило до смешного — сидя в холле с кофе народ смотрел, через wifi что происходит за соседней дверью (сам так делал ^-^).

== Что не понравилось ==
; Электрические розетки: В связи с появлением wifi, самым критичным ресурсом стало электричество. Розеток было очень мало... подкормить <s>своего питомца</s> свой laptop можно было только отняв розетку у аппарата подогрева кофе.
; SPAM доклады: Завели совершенно дурацкую практику докладов во время кофе-брейков (например Qiwi, Softline). Выглядело это как группа заезжих коммивояжеров, тщетно пытающихся привлечь внимание отдыхающих... Вещи рассказывали достаточно банальные и спокойно общаться не давали… В общем, сильно раздражало.

;Выложенное Видео: Очень с одной строны удобно.. Начал посмотреть видео Стаса (прослушал классическую часть про SVN+Wiki+Bugzills). Неудобно, что не получается дать ссылку на видео и презентации. Так же, на 15 минуте видео оборвалось. А воспроизвести с произвольного места не получается. :-(. Попробовал второй раз в IE — тот же эффект.
;{{bad-words|Кондиционеры}}: На втором треке были адски злые кондиционеры которые дули прямо в спину.. 3 раза просил организаторов и докладчиков отключить — обещали сделать — так и не сделали. Больше не ходил на второй трек и два дня ел арбидол. Огромный кармический минус организаторам..
;Бубнеж синхронистов: Качество синхронного перевода, как всегда, не очень высокое (можно например посмотреть видео доклада Питера Хрущки для то, что бы понять качество). Мало того, синхронисты находились в том же помещении, что и докладчик и слушатели, и своим бубнежом отвлекали тех, кому перевод не требовался.

;Fail доклада Дона Смита: В связи с [http://news.yandex.ru/yandsearch?rpt=nnews&grhow=clutop&text=облако%20вулканической%20пыли облаком вулканической пыли] благородные Доны (Смит и Сайм) не долетели до конференции... Дона Сайма показывали через Web (Не очень ИМХО удачное решение). А Дона Смита даже не показали. Но наверное неправильно тут в чем-то упрекать организаторов.

;<font color="red">Пивная вечеринка — «Soft Party» — полный отстой </font> :Пиво в банках, хреновое, и всем не хватило (еды вообще хватало не всем), закуски никакой. Лучше бы не позорились и не анонсировали его и не проводили совсем.

= Доклады =

== 1 день ==

=== Питер Хрущка (Atlantic Systems Guild). An Agile Mindset ===
Народ упорно называл его Хрюшка :-). Представляет ''Atlantic Systems Guild'' — это сообщество <s>старых пердунов</s> гуру программирования (состав смотри [http://www.systemsguild.com  здесь]), которые делятся опытом и пишут книги. Из всех я знаю только Toma Demarco.

Очень интересный доклад, в котором он затрагивал актуальную для нас тему: Роли которые управляют Agile-проектом. После доклада еще минут 15 продуктивно [[#Питер Хрущка|общался в холле]]. Говорил разумно, вообще чувствуется в Питер в теме..

Основные тезисы, которые мне запомнились:

==== Эволюция методов разработки ====
Зачем-то привел свою теорию методов разработки.

Началось все со Структурного програмирования (''Structured Methods''), которые подарили нам такие замечательные вещи как [[RuPedia:DFD|DFD]] и [[RuPedia:ER-модель_данных|ER-диаграммы]], и вообще научили вначале продумывать архитектуру приложения, а потом уже кодировать.

Потом появилось OOП (Которые нам принесли Буч, Йордан (? почему он) и еще какой-то народ, которые нам дали Объектно-ориентированный анализ и проектирование
а потом достаточно стандартные «бла-бла» про Agile который пришел на смену (Манифест и так далее).

Самое главная мысль в этом месте, что следующий этап '''не отменяет достижений предыдущего'''. 
В этом смысле '''Agile не отменяет хороший предварительный дизайн приложения''' (и вообще идеи «не проектировать на будущее» и «постоянный рефакторинг» — глубоко чужды Питеру).

==== Роли в Agile ====
Интересно, как Питер определяет основные роли (''Must Have in Agile''):
;Product Owner (PO): ответственный за требования. <tt>PO=Business Analyst=Requirements Engineering</tt>.
:Обычно эту роль исполняет:
:* Руководитель проекта
:* Заказчик
:* Маркетинг

;Software Architect (SA): Ответственный за решение. Это может быть:
:* TechLead
:* Boss of the Developers
:* Lead Programmer
: Это человека, который:
:* разговаривает с заказчиком
:* «продает» архитектуру
:* наблюдает (''Supervise'') за разработчиками.
: Основные скиллы:
:* Анализ
:* Проектирование
:* Коммуникации

;Project Manager (PM): ответственный за проект. Он же Agile Leader.
:Человек который:
:* Следит за тем что все, что нужно сделано (Done).
:* Практикует эндшпили (убирает критические проблемы и принимает критические решения, для того, чтобы сдать релиз к сроку).
:* Обеспечивает периоды стабильности для команды, которые чередуются периодами, в которых можно менять Scope (''Seasons of Change'').
:* Занимается людьми (''Peopleware'').
:* Мониторит риски проекта.
 

{{important}} Питер считает, что никогда нельзя совмещать SA и PO. Естественно, этот вопрос я не мог оставить без внимания и замучал его в перерыве. 
Интересно, что Scrum-Master это еще какая-то другая роль, про которую он не сказал, а на прямой вопрос ответил уклончиво.

==== Agile Requirements ====
Рассказал Питер и про то, что такое ''Agile Requirements''.
* Рассказал то, что мы называем «Методом набегающей волны» (подробно прорабатываем только те требования, которые собираемся делать в ближайшее время, а остальное прорабатываем в крупном).
* Есть 2 способа снятия требований — поверхностный (''snorkeling'') и глубокий (''scuba diving'').
* Все время нужно отслеживать Scope (по аналогии с большим теннисом: ''Whiteline'' — граница проекта)
* Формировать требования нужно в партнерстве с заказчиком (''co-education'')..

=== Анжей Аршавский (IBM). Програмное обеспечение для разумной планеты ===
* Очередной «вендорский доклад» от IBM.
* Не пошел слушать (чему очень рад). Вместо этого общался с Питером Хрущка.
* Народ непрерывно уходил с доклада.
* Когда дошло до Jazz-a не выдержал и Игорь Беспальчук (и мы с ним успели обсудить доклад Хрушки).

=== Дон Сайм(Microsof). F# -функциональное программирование становится трендом ===
* На F# не пошел… Читал почту, писал отчет..
* Зашел уже в момент, когда Дон отвечал на вопросы. Оказывается, это была телеконференция. Дон вещал удаленно (наверное именно поэтому падал WiFi). Качество звука достаточно приличное. Картинка с изображением докладчика подтормаживала.

=== Дон Смит (P&P Team Microsoft). Разрешение конфликтов разработки ===
* Fail — Доклада не было (из-за проблем со связью).
* Вместо него был Дмитрий Сошников программирование игр на платформе XNE.. опять не пошел :-(

=== Дмитрий Безуглый. Кто такой менеджер продукта и что он может дать разработчику? ===
Забавный доклад на тему «продуктовая разработка vs. заказная разработка». В общем ничего нового, но есть провокационные и весьма спорные утверждения (наверное это что-то личное от докладчика):
* Сейчас идет движение от заказной разработки к продуктовой (все хотят делать продукт).
* Зарплата разработчиков в продуктовой разработке выше, чем в заказной.
* Вначале нужно поработать в большой Аутсорсинговой компании, а потом уходить в продуктовую.
* В продуктовой компании используют более новые (и рисковые) технологии, что бы обеспечить себе конкурентное преимущество (см график).

'''s-curve''':

[[Image:s-curve.png|''s-curve'']]
* ''Research & Development'' в заказной разработке '''r&D''' (больше Development-a меньше Research-а), а в продуктовой '''R&d'''.
Все это сомнительно и '''ОЧЕНЬ''' спорно…

Еще интересные и забавные мысли :
* Заказную разработку сложно продать (ее сравнивают с готовыми продуктами).
* PM — расшифровывается как «Прослойка Между» (теми кому чего-то надо и теми кто уже ничего не хочет).

* [http://www.slideshare.net/bredyuk/software-people ссылка на презентацию]

=== Сергей Нужненко (Лаборатория Касперского) Техники и подходы к планированию аналитических работ ===
Ничего не понял. Доклад не структурирован, полон общефилософских категорий и плохо сформулированных идей. В чем основная мысль не понятно. Презентация есть [http://softwarepeople.ru/sp2010/program/ на сайте конференции].

Несвязные тезисы по памяти
* '''Шнурок''' — шнурок нельзя затолкать снизу (от разработчика), все движение должно быть от заказчика.
* ошибки аналитика самые дорогие ([[Участник:Mikle Zaborov|Mikle Zaborov]] 10:56, 23 апреля 2010 (UTC) тоже мне новость) 2 способа бороться:
** внутренняя приемка
** итеративность
* Аналитик всегда работает с неопределенностью
* тяжело проверить и померить результат работы аналитика
* Каналы общения аналитика со всеми остальными (PM, Заказчик, Разработчкик) должны быть доступными
* Качество моделей, которые строит аналитик состоит из 2ух частей:
** полнота
** непротиворечивость
** [[Участник:Mikle Zaborov|Mikle Zaborov]] 10:56, 23 апреля 2010 (UTC)А как же адекватность предметной области и задач?
* проверять качество можно только трассировкой
* Фундамент аналитика:
** должен владеть
*** формальной логикой
*** принципов классификации
** системным подходом (ЛПР, стратификации, состав, иерархия, структура)
** Модели/категории
*** модель сущность-связь
*** сущность/явление
** Кроме того, аналитик должен понимать
*** контекст (истина относительна).
*** понятие границы (объектов не существует).

== Второй день ==

=== Сурен Самарчан (Innova). Типичный день эффективного лидера ===
* 95% менеджеров не знают, чем заниматься в течении дня
Не понятно причем тут распорядок дня менеджера. но доклад очень позитивен,
по полочкам разложено, то, что и так (по крайней мере, мне) было понятно.
Готов подписаться почти подо всем сказанным. 
То что рассказывал Сурен, несколько отличается от того, что написано в презентации, поэтому привожу здесь тезисы, которые успел записать:

<big>'''Основные активности руководителя :'''</big>

'''1. Усиление команды'''
* Поиск лучших/увольнение худших/обучение/повышение в сотрудниках уверенности в себе и самокритичности;
* Компания растет быстрее чем люди (пример Dell);
* Непродуктивные люди это не 0, это минус (от них нужно избавляться как можно скорее).

Лидеры команд (и не только) должны обладать следующими качествами:
* У них есть Vision;
* Бесконечный оптимизм;
* Самокритичность.

Используйте любое событие, чтобы обучать людей. Пример — Парный менеджмент (аналог парного программирования):
* следить за менеджером и записывать его косяки;
* решить совместно задачу (размышлять вслух);
* разложить задачу на серию простых шагов.

Сессии критики (руководитель критикует сотрудника, потом коллеги, потом сам себя)
: [[Участник:Mikle Zaborov|Mikle Zaborov]] 06:22, 23 апреля 2010 (UTC) Хорошо, если самооценка сотрудника при этом не упадет ниже плинтуса.

''' Самостоятельность '''
* Лидер уходит -> команда работает.
* все понятные команде работы должна делать команда.

''' Энергия '''
* Лидер передает собственную энергетику команде.
* Харизма — критично важна (человек без харизмы будет убеждать месяцами сделать то, что харизматичный лидер стимулирует за 1 минуту).
* Лидер передает энергетику личным примером.
** Работает больше всех.
** Не устает (не показывает усталость).
** ''' не жалуется, не унывает, не паникует'''.
* Какой лидер, такая и команда.
* Проактивно относится к инициативе.
* Доступен для сотрудников.
* Искренне ждет результатов от сотрудников.

''' Атмосфера'''

Лидер создает атмосферу уверенности которая состоит из:

на 80 %
* Искренность (что думают то и говорят).
* Ответственность (что говорят то и делают).

на 20 %
* Непоколебимые принципы компании.

Кроме того:
* не присваивайте чужих достижений;
* реагируете на деструктивные высказывания;
* чувствуйте гордость за компанию.

''' Вопросы '''
* интересуйтесь работой людей;
* люди чувствуют ваше присутствие;
* разберитесь хотя бы с одним вопросом детально;
* записывайте вопрос(задачу) который вы задали и проверяйте что ответ(решение) получено.

''' Правила игры '''
* нужно создавать правила игры;
* все правила существуют только в контексте;
* правил которым нужно следовать на 100 % не существуют (очень мало);
* структура управления должна быть максимально плоской.

''' Преграды '''
* Нужно видеть большую картинку.
* Все нужно упрощать.
* Не терять энтузиазм по каждой мелочи (будет много неудач).

''' Думать о будущем '''
* Даже если пожар, нужно думать о будущем.

Кроме того Сурену были заданы вопросы. В частности обсуждалась мотивация сотрудников
(работа за деньги/ на результат, work/life balance). Примеры и вопросов и ответы на них хорошо описаны у [[Software_People_2010:_отчет_Игоря_Беспальчука#Сурен Самарчан. «Типичный день эффективного лидера»| Игоря Беспальчука]]

=== Сергей Архипенков. Технология командообразования ===
Очередной доклад Архипенкова про команды.

Начал за здравие, но в конце начал нести какую-то муть.. и на вопросы отвечал тоже очень странно.


Но народу видимо очень понравилось — Сергея не отпускали 30 минут, и заняли время кофебрейка.

==== Что такое команда ====
* общие цели и ценности;
* взаимное доверие;
* неформальные горизонтальные коммуникации;
* коллективная ответственность.

команда и группа — не одно и тоже:
* команде цели нужно ставить только в общем виде (взять Эверест).

==== Как собирать команду 3 шага ====
''' Шаг 1. правильные люди '''
* эффективность(E)
  E=IQ x EQ^2
  IQ - [http://ru.wikipedia.org/wiki/IQ Интелект]
  EQ - [http://www.hr-portal.ru/article/emotsionalnyi-intellekt-eq  Эмоциональный интеллект]
  EQ = Осознание чего хочет+ Воля воплотить + Эмпатия
* проактивность (чаще всего делают не то, что хочет)
* командный игрок
[[Image:team_player.png]]

===== Шаг 2. Выбрать Лидера =====
«настоящих буйных мало вот и нету вожаков» (с) Высоцкий
* Навыки управленца
* Лидерство
[[Image:leader.png]]
* Садовник

Лидера нельзя назначить — он должен получить признание:
* как профессионала (''Признание'')
* как управленца (''Доверие'')

{| class="wikitable" border="1"
! Признание !! Доверие !! стиль управления
|-
| нет || нет || Директивное управлении
|-
| да || нет || Объяснения
|-
| нет || да || Участие
|-
| да || да || Делегирование
|}
:[[Участник:Mikle Zaborov|Mikle Zaborov]] 07:05, 23 апреля 2010 (UTC) Крайне сомнительная и спорная табличка

* руководитель должен быть частью команды.
* Не ждите от команды вовлеченности больше, чем у лидера.

===== Шаг 3. Точим пилу =====
Опять начал про 4П и какую-то муть про управление процессом :-(

=== Стендовый доклад Дмитрий Лайер (Softline), Борис Вольфсон (Softline) Agile MixFight по правилу Win-Win ===
Очередной SPAM доклад в время кофе-брейка. Попытка привести аналогии между SCRUM в разработке ПО с принципами игры Регби. 
В начале привлекли внимания в виде веселого видеоролика. 
Ролик забавный, но мысли там достаточно поверхностные (фрагменты из игры регби чередовались с прыгающими и 
кривляющимися у SCRUM доски разработчиками).
Т.е дальше мысли о том что и в Регби и в Agile должен присутствовать кураж не пошло… 
Далее последовала очень нудная история о внедрении SCRUM в Softline.

=== Александр Орлов (Happy-PM.ru) 10 проблем обратной связи ===
Очень хороший и бодрый доклад про проблемы с обратной связью.. Не могу сказать что список проблем полон, но про то что рассказал все очень хорошо и по делу

Провел аналогию между управление проектами и нелинейными шахматами:
* Конь демотивирован и теперь ходит на 1 клетку.
* Ладья уходит в декрет.
* Ферзь увольняется.

Типовая ситуация с обратная связью в компании
* ее нет
* есть, но такая
* есть, но не туда
* есть, но не про то..
* есть, но не от туда…
* есть, но не та
* … и т. д.

Далее Александр описал 10 (по его мнению типовых) проблем с обратной связью:
; Отсутствие обратной связи разработчикам от пользователей: Разработчикам важно знать для кого он работает. Нужно понимать что от его действий что-то в мире изменилось (стало больше добра…).
; Нет общения руководителя с сотрудником 1 на 1: 65 % времени нужно уделять внимание на такое общение. Общение с командой не заменяет общения 1 на 1. Когда сотрудники не получают такого общения — они чувствуют себя брошенными.
; Нет конструктивной (ругань) обратной связи: Нельзя только хвалить — нужно ругать.
; Менеджеры не говорят спасибо: тут вроде все понятно.
; Руководитель дает публичную конструктивную обратную связь: Руководитель рвет подчиненного публично (синдром учительницы). Общеизвестный принцип — хвалить нужно публично, ругать лично.
; Руководитель переходит на личность: Принцип сэндвича: Похвалил/поругал/похвалил.
; Обсуждается процесс, а не результат: «Результата нет, а он еще на bash.org сидит». — Не надо бороться с процессом (закрывать сайты, отслеживать посещаемость и т. д.) нужно требовать результат.
; Нет ОС от сотрудников к менеджеру: Есть несколько вещей удерживающих людей там, где они суперкомпетентны, но им не интересно — это з/п, ипотека, …, и менеджер. Нужно получать обратную связь от сотрудников по поводу того как они относятся к тому, чем они занимаются. В некоторых компаниях вводили процедуру оценки сотрудником задачи (интересно/не интересно/тошнит). Agile эту проблему решает частично (решает, пока сотруднику не надоела вся область).

{{note}} [[Участник:Mikle  Zaborov|Mikle Zaborov]] 20:51, 5 мая 2010 (UTC) Наверное было бы интересно и у нас что-то такое попробовать

;Нет ОС снизу вверх: Большой разрыв. Руководство не слышит ОС от сотрудников с низов. Иногда нужно рвать уровни иерархии. Директор должен периодически общаться с техническими сотрудниками.
;Ретроспективы: Нужно проводить личные ретроспективы (анализ своей деятельности постфактум).

Интересные цитаты:
* «проблемы менеджера, не в том, что люди смертны, а в том, что люди '''внезапно''' смертны»
* «Надеяться, что HR замотивирует ваших сотрудников — тоже самое, что надеяться на то, что соседи воспитают ваших детей».

=== Олег Ридченко (Intetics). Обучение, развитие и оценка руководителей проектов в IT компании ===
Достаточно уныло и занудно… Пример механистического отношения к управлению персонала (Ужас!! Ужас!!). Это то куда нам ни в коем случае не нужно свалиться

* процесс обучения и оценки руководителей проектов.
* Intetics (250 человек 2 города Минск и Харьков. 13 руководителей проекта. 3 Года уже работает)

==== Проблемы ====
* управление индивидуальной деятельностью сотрудников (синхронизации векторов развития сотрудника и компании):
** повышение мотивации;
** определение ценности;
** повышение ценности сотрудника для компании;
* для РМ:
** нет измеримых критериев оценки;
** не понятно кто оценивает.

Пробовали ''360 review''. Не получилось:
* потому, что дорого.
* неэффективно (народ относится поверхностно).

==== Система управления индивидуальной деятельностью ====
Состоит из 4ех частей ([[Участник:Mikle Zaborov|Mikle Zaborov]] 21:00, 5 мая 2010 (UTC) странные какие-то части… ну да ладно):
* Система компетенций.
* Цели компании.
* Персональные цели.
* Оценка руководителей.

+ Система автоматизации всего этого добра на <tt>Sharepoint</tt>.

===== Система компетенций =====
* 17 компетенций (описание навыков и критерии соответствия).
* 2 IT специфичные — остальные общеуправленческие.
* у каждой компетенцию с весом (общая сумма 100).
* значение каждой от 0..1
* Оценки ставит сам руководитель и его начальник.
* Компетенции откуда-то тырили ([[Участник:Mikle Zaborov|Mikle Zaborov]] 20:54, 5 мая 2010 (UTC) я попросил прислать — отказали).

===== Цели компании =====
* SCOPE
* Бюджет
* Время

===== Персональные цели =====
* Персональные области для развитие;
* Составление ПЛР (план личностного развития);
* Составление плана развитие — задача самого РП;
** Руководитель '''cам''' анализирует свои проблемные области;
** Cогласует дальнейшие шаги со своим руководителем (тот следит что бы не было никакой лажи).



=== Стас Фомин (CustIS). Knowledge Management: от Склада к Потоку ===
Хотел посмотреть выложенное Стасом видео. То что на сайте SofwarePeople отрубается на 15 минуте, а то что Стас выложил показывается в ужасных кубиках :-(
{{remark|[[Участник:StasFomin|Стас Фомин]] 09:29, 6 мая 2010 (UTC): нашел где смотреть. Им я уже написал. В вебе мог бы посмотреть [http://team.custis.ru/2010/04/knowledge-management-software-people.html тут] или [[Knowledge Management: От Склада к Потоку (Software People-2010)|тут]], или поставь себе нормальный кодек пак. XPCodecPack 2.5.1, например)}}.

=== Станислав Давыдов Мастер-класc: Разрешение конфликтов и налаживание обратной связи в командах ===
В начале была странная игра с разрешением конфликта в группе.
* придумали 5 конфликтных ситуаций (типа менеджеры заставляют программистов тестировать);
* посадили всех в кружки (человек по 10) и сказали: «а теперь решайте конфликт»;
* …
* PROFIT!

: {{note}} [[Участник:Mikle Zaborov|Mikle Zaborov]] 21:03, 5 мая 2010 (UTC) :-(. Все больше убеждаюсь, что такие мастер-классы на конференциях — это какая-то странная попытка развлечь аудиторию.


Далее Станислав предложил методику мотивационных анкет (простая и достаточно интересная):
* выбираются мотивационные факторы (зарплата, технологии, рабочее место, гибкий график и т. д.)
* для каждого фактора ставится 2 оценки (от 1 до 4) — ''важность'' и ''удовлетворенность''.
А вот дальше странно:
* Это информация складывается и выкладывается публично.
* команда обсуждает результаты оценки.
: {{note}} [[Участник:Mikle Zaborov|Mikle Zaborov]] 21:03, 5 мая 2010 (UTC) Первые 2 пункта я бы у нас попробовал…

В конце он рассказывал ОЧЕНЬ странный кейс который от с помощью этой методики решал (и до конца так вроде как не решил): «Тупой быдлокодер, пишуший говнокод, пахнущий грязными носками, которого нельзя уволить». В результате методики удалось полечить только проблему носков …

= Встречи =

== Питер Хрущка ==
Естественно, я не мог оставить без внимания заявление Питера по поводу того, что нельзя совмещать PM и SA. Решил замучать его в перерыве, в результате мы общались во время доклада Анджея Аршавского. Получил от Питера следующие разъяснения:
* Теоретически допустима ситуация, когда руководитель проекта выполняет функции архитектора (руководитель типа «Атлант»). Но только на небольших командах и это совсем не масштабируемо.
* PM должен мыслить в краткосрочных терминах (сдать проект в нужные сроки за нужные деньги).
* SA в долгосрочных (архитектура должна быть устойчивой, надежной и т. д.).
* Бесконечный рефакторинг — это плохо (Стратегия ''Nothing in Advance'' работает плохо, как впрочем и любой другой экстремизм).
* Распределение ответственности между ролями выглядит так:
[[Image:SoftwarePeople2010-AgileRoles.png|400px ]]

* Архитектуру приложения на самом деле создает и PO и SA. Питер считает, что в любой архитектуре есть бизнесовое ядро (20-30%), в котором нет технических деталей, и которое, в идеале, PO проектирует вместе с заказчиком, а SA его верифицирует и дополняет техническими подробностями. Бывают случаи когда PO не в состоянии спроектировать ядро архитектуры и тогда это приходится делать SA.

[[Файл:SoftwarePeople2010-Arch.png|200px ]]

----
Пообсуждали этот вопрос с Игорем Беспальчуком. Поняли, что в таких терминах мы вполне можем с ним договориться (а у нас на эту тему давно идут дискуссии) и весь вопрос заключается в том — насколько сильно PO погружается в технические детали.


[[Категория:SoftwarePeople-2010]]

{{replicate-from-custiswiki-to-lib}}