Peopleware(Человеческий фактор).

Прочитал недавно классику мировой фантастики менеджмента - сабж От Демарко и Листера)

Коротко расскажу, чтоб было нового и интересног из того, что запомнилось:

Интересное:

1) Книга  наполнена яркими тезисами, которые так и не терпится выписать и наклеить на стену (читал в оригинале потому и тезисы на англиском):

• The major problems of our work are not so much technological as sociological in nature.
• We Haven't Got Time to Think About This Job, Only to Do It
• People under time pressure don't work better; 
• they Just work faster
• Quality, far beyond that required by the end user, 
• is a means to higher productivity.

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

2) Том Демарко и Листер обыденно говорят, что ничего такого волшебного не случиться и никакая мега-нова методология\технология и т.д. не помогут выполнять проекты на 100 % лучше, попутно обсуждая, что "Программы Улучшения Процессов"(на примере CMM) ни разу не помогают , т.к. ведут к эффективному производству того, что вы итак умели делать. Что ведет к снижению рисков, но обратным эффектом будет снижение создаваемой ценности и доходности бизнеса. Довольно спорный момент, т.к. отсутствие таких программ ни разу не дает гарантий улучшений чего-либо в ближайшей перспективе и насколько мне известно ВСЕ программы улучшения процессов нацелены именно на долгосрочное развитие.

3) Целая ЧАСТЬ(2-ая) посвящена вопросам обстановки офиса и обустройства пространства дабы работать было комфортно:

- Удивительно, что ДО СИХ ПОР (проблема с местом\посторонним шумом\постоянными отвлечениями актуальна на всех работах, где мне приходилось работать) такое положение дел еще действует.

- Об этом не высказался только ленивый): например Саша Орлов на PmDays еще в далеком 2008м, где-то еще слышал историю(ссылку не найду) от Славы Панкратова про невозмутимого тестировщика, которого отвлекали по 50 раз на дню.

- Авторы предлагают метрику E-Factor эффективности офисного пространства: количество ЦЕЛЫХ(совсем без отвлечений на посторонние звуки) часов деленное на количество часов проведенное на работе, которое удалось провести без единого прерывания. 

Кто-нибудь готов сказать что он хотя бы дотягивает до 0.5 не говоря уже от 0.8-0.9 ?).

4) Хотя авторы и против всяких монструозных программ улучшений процесса, но меняться всеравно надо иначе отстанешь, станешь древним диназавром ну и т.д.

(Вобще проблема для меня жутко актуальная, т.к. всегда хочется попробовать, что-то новое:  сделать  лучше-выше-сильнее, но научиться продвигать кашерные идеи, это не тоже, что и досконально понимать их) 

Соответственно надо уметь выбрать тех, кто станет твоими союзниками в изменениях:

из 3х групп: 

1) Те, кто слепо последуют за новой идеей

2) Те, кто будут задавать вопрос: что в этом для меня ?

3) Те, кто категорически будут отрицать ее.

И всегда надо выбирать вторых, т.к. только они могут быть реально уверенны в полезности нововведения.

При прочтении вспомнился замечательный доклад на ту же тему от Хенирка Кенинберга Everyone likes change, but nobody likes to be changed (Henrik Kniberg, AgileDays-2011)

Новое:
1) Узнал как же называется подход, когда из работника пытаются выжать максимум рабочих часов, оказывается это называется  -  испанская теория управления. Ответвляется она от испанской теории ценности - ценность конечна и ее надо уметь отбирать(а ля Конкистадоры), знаю пару человек которые могла бы по ней книги писать)

2) Внезапно откровением, оказалась глава  в которой Авторы рассказывают, что закон Паркинсона не совсем работает, и наиболее продуктивными оказываются те команды у которых нет дед-лайнов и оценок размера работ (всетаки оценка работ - waste, в самом тру-lean смысле).
Хотя с другой стороны может быть они уже были настолько круты и продуктивны, что оценка работ действительно не была нужна.

3) Термин TEAMCIDE - описание всех, тех способов на которые идет (или не идет, это как посмотреть) менеджмент, чтобы убить свою собственную команду.
Например:
- физическое разделение
- бюрокаратия
- ориентация на выпуск низкокачесвтенного продукт (ключевые слова: "быстрее-быстрее", "еще вчера надо было", "сделай, чтоб отвязались наконец").
- заранее невозможные дедлайны
и т.д.

3.5) Опять же понравилась история про(внимание барабанная дробь) ЧОРНУЮ КОМАНДУ ТЕСТИРОВЩИКОВ! Суть которой в том, что компания сумела создать такую команду, которая выработала свою философию "деструктивного" тестирования и находила в этом свой fun & lulz, и дух и философия этой команды даже пережила уход ВСЕХ изначальных членов этой команды.

4) Вроде бы очевидная вещь и баян, но все же этому разделу посвящена опять же целая часть:

"IT'S SUPPOSED TO BE FUN TO WORK HERE" - компания должна быть такой, чтоб работать было интересно и не скучно. Дюди должны чувствовать, что компания вкладывает в них и заботится о них и подразумевается, что люди останутся в ней надолго. Соответственно если компания хороша - у нее очень маленький отток людей (Гм, это наверно классный критерий оценки\поиска работы !).

Итого:
Количество полезных идей\на символ (думаю отличная метрика для книги) в книжке зашкаливает, посему - must read (но вы ведь это знали и без меня, так ведь ?).

Инженерные практики: Модель принятия инженерных решений Евгения Кривошеева

Дисклаймер:

Стас Фомин(http://belonesox.moikrug.ru/) регулярно негодует, что последствия конференций как-то не видны: т.к. первые два-3 дня видна отдача в виде отчетов а потом про них все забывают, и как-бы 5-6 отчетов\упоминаний не слишком выдающийся результат для такой огромной кучи усилий как собрать конференцию =)

Потому периодически пересматриваю и пытаюсь отписывать фидбэк)

Так вот вместо того. чтоб слать его лично ему, можно ж написать в блог и пользу от фидбэк`а получат больше чем 1-2 человека =)

Собственно присутствовал на самом докладе (да он настолько хорош, что хочется повторно увидеть), но т.к. где-то только с середины решил пересмотреть (я там где-то даже на 30-й минуте в кадр попал =)).

Полезная часть: =)

Небольшой предварительный список вопросов:

- Я могу сказать - почему у меня столько классов сколько их сейчас ?

- Я могу сказать - что для меня важнее гибкость или просто кода ?

- Я могу сказать - зачем я применяю\не применяю определенный паттерн в данном месте ?

- Я могу сказать - чем обоснована моя стратегия деплоя релизов на продакшен ?

- У меня (в моей компании) знают, что такое architectural guidelane и они есть ?

И т.д., если хоть на один вопрос вы ответили - "нет", то видео надо обязательно посмотреть.

Собственно ссылки на само видео презентации Евгений Кривошеева "Модель Принятия Инженерных решений": ekr's blog: Бухтелово на AgileDays2011 или http://vimeo.com/22162357.

Докладчик говорит вполне живо и бодро потому: максимальное ускорение при просмотре можно выставлять на уровне 1.3х =)

Рассказывает вроде бы и очевидные вещи, которые всем нам (ну точнее всем, кто учился на инженера) преподавали еще в институте: "Сначала думай, а потом делай", и если ты не можешь сказать ПОЧЕМУ ты так сделал и ПОЧЕМУ оно будет работать - то это не инженерное решений (по-моему доказательство и сдача лаб по схемотехнике, это до сих пор самое сложное, что мне приходилось делать за всю свою жизнь, как инженеру =)) .

А в процессе работы все , как всегда сводиться к: "По привычке (из-за лени) сделал, как в прошлый раз, потому, что мозг так натренировался."

Это надо исправлять и не в последнюю очередь смотря такие доклады и просто немножко включая голову при проектировании.

Потому смотреть и запоминать, а через месяц проверить прижилось ли в голове и посмотреть еще раз, и повторять до тех пор пока не приживется!

Тем кому понравилась презентация рекомендую посмотреть еще и видео Архитектура в Agile — переосмысляя идею модульности и компонентности (Андрей Бибичев, AgileDays-2011), про ажайл там ан самом деле ровным счетом ничего =) Но излагаются хорошие инженерные практики и стремление думать головой, а не спинным мозгом.

Послесловие:

Вообще удивительная вещь доклады и конференции: вроде бы рассказывают очевидные вещи, но ты все равно так не делаешь\не задумываешься о том, как делаешь до тех пор пока не ткнут носом.

А на конференцию по ажайлу можно ходить даже вы этот ажайл на дух не переносите хорошие инженерные практики (о которых конференция чуть ли не на 50%) полезные в любой методологии.

Прочел Programming Erlang

Хорошая вещь праздники: появляется время поделать что-то из списка "сделать когда-нибудь")

Прочел: Programming Erlang: Software for a Concurrent World  Joe Armstrong`а.

Книжка читается легко и довольно шустро: видно, что автор знает в каком порядке надо раскрывать тему. 40-60% написанного знал и нещадно пролистал вскользь.

Новым/Интересным оказалось:
- устройство Mnesian и ETS\DETS таблиц. (небольшой LOL: Mnesia произошла от Amnesia, но босс сказал им что название не годное - у них не может быть БД, которая "забывает" вещи)
- описание в приложениях об встроенных дебаггере, инструменте проверки покрытия кода и профилирования: чуваки круты что все это есть из коробки, а не через танцы с бубнами и матюгами
- про работу с "портами"(интерфейсы к другим языкам): все таки работа почти что через отдельный сокет\байтовый буфер - овер-гемморой, теперь понятно почему все предпочитают делать REST/Thrift-интерфейсы к своим эрланговским продуктам.

Думаю ее можно прочесть и сразу приступать программировать: Единственное, что все таки вокруг паттерн-матчинга и местами хитроватых стак-трейсов(особенно если еще и супервизор там есть) стоит завернуть свои мозг.

Обзор Искусства Управления IT-проектами (Making Things Happen) Скотта Беркуна.

Во время прочтения этой книги выработал для себя новый критерий качества чтива: через 5-10 минут продолжения\начала чтения судорожно ищешь карандашь, чтоб подчеркнуть полезную и интересную мысль, а карандашь превращается в закладку, чтобы потом долго его не искать =)

(Да и во время ее, чтения очень пожалел, что не знаю(или даже не существует) ни одной электронной читалки, где можно бы было подчеркнуть или выделить мысль как карандашом в книге =))

И да книжка не про ажайл\лин, а просто про управление проектами =)

Автор не обещает решений всех ваших проблем, или какой-то серебрянной пули, а всего лишь рассказывает о тех практиках подходах к управлению и принятиюрешений к котороым он пришел за время своей работы в Микрософт.
И, черт возьми, неудивительно, что Микрософт доминирует на десктопном рынке с такими управленцами =)

Все написано простым и понятным языком с необходимым минимумом теории и максимальным количество практики и подходов. И включает наверно самое важный пункт, который следует развивать пму:  главу "Как не раздражать людей на работе, в ходе электронной переписки, на совещаниях" =)

Удивительным образом во время чтения замечаешь, что несмотря на то, что описываемые события 90-х годов и во многих повествованиях проскальзывает явная ватерфольщина =), но все актуальные идеи лидерства, постоянного улучшения, ориентации на бизнес и команду и тонна других вещей удивительно актуальны и сродни текущим гибким течениям.
А во время чтения, того как делать НЕ НАДО, и в описании мест совершения самых частых ошибок с удивлением обнаруживаешь свой прошлый опыт работы(и возникает такой Ага-эффект) =)

Еще в книге присутствует 5-ок-другой опросников и чеклистов, чтобы проверять себя на разных стадиях работ и в различных ситуациях, во время чтения мне захотелось все их перенести в электронный вид и пользоваться ими при случаи(даже нашел подходящую онлайн тулзу - checkvist, жаль оффлайн клиента под кпк\андройд нет).


Маленький перечень, того, что особо хотелось отметить и не забыть потом во время чтения:

Цели и концепция проекта:

1)Наиболее распостранненные просчеты в определении конечной цели проекта:
 - мы будем делать то же , что и в прошлый раз
 - мы будем делать, то чем принебрегли в прошлый раз
 - мы будем делать то же самое, что и наш конкурент
 - мы будем делать, то что отвечает модным тенденциям (сделаем веб-два(три)-нольно и стартап !)
 - если мы сделаем этот продукт, он обязательно найдет своего покупателя

2) При формулировке цели можно воспользоваться таким приемом - отнеситесь к ней максимально придирчиво и задатьяс вопросом, не провалиться проект, если его цель будет достигнута в точном соответствии с его формулировкой. Затем нужно подумать, а нельзя ли более точно сформулироваться цель, нет ли какой-нибудь дополнительной, уточняющей информации.

3) Если вы не в состоянии найти какое-нибудть визуальное представленеи того, что изменится в этом мире под влиянием проекта, стоит задуматься не направлен ли этот проект на создание бесполезных вещей. или достаточно ли он понятен, чтобы быть успешно притворенным в жизнь.
3.1) Что концепция всегда была на видном месте, несколько ключевых целей проекта должны быть оформлены в виде плакатов, расположенных в наиболее людных местах (визуальный менеджмент в стиле Лин !)

Выбор Идеи:
 - Какую именно проблему мы пытаемся решить ? (При возникновении споров о том, что и как делать.)

Информированность: 
 - По возможности старайтесь избегать информации из 2-х, 3-х и 4-х рук. Во время разговора часто вскрываются детали и нюансы по тем или иным причинам не попавшие в отчет или презентацию.
 - Люди ценятся выше информации. Человек пишущий отчет, изучил 1000 разных веещй и узнал массу полезной информации, которую невозможно втиснуть целиком в этот отчет, но который он с радоситью поделиться с теми, кто проявит достаточное любопытство.
 - Хорошие решения могут давать плохие результыта.

Общение: 
 - Базовая модель общения:
- Передача
- Получение
- Усвоение
- Согласие
- Превращение в полезые действия
Не факт, что ваше сообщение не остановилось на уровне передачи или получения ! То, что вы что-то сказали\написали ничего не говорит о его усвоении, или о том. что с вашим сообщением согласны.

Почему люди раздражаются: 
 - Не считайте меня идиотом.
 - Доверяйте мне.
 - Не тратьте мое время попусту.
 - Не распоряжайтесь мной без должного уважения.
 - Не заставляйте меня слушать или читать всякие глупости.

Формула хорошего процесса:
Полная стоимость процесса:

• время на выработку замысла процесса(DT),
• время на его освоение командой(LT)
• фактическое время выполнения работы при применении процесса, помноженное на частоту его применения (ATxN)

= DT + LT + (AT x N)
Суммарная выгода процесса:

• стоимость провалов, которые процесс позволяет избежать(FC),
• помноженную на показатель вероятности возникновения провалов(FP) без внедрения процесса в пределах определенных временных единиц
• и помноженное на количество таких единиц в проекте (T). 

 =   (FC x FP) x T
А ценность процесса равна:  ((FC x FP) x T) - (DT + LT + (AT x N))

Итого:
Не зря она занимает свое место а бест-селлерах О`рейли и для всех кто интересуется разработкой ПО должна находитсья в разделе must have & must read.
Думаю перечитаю ее еще не раз через месяц-другой, чтобы освежить в памяти и найти какие-то новые моменты .

Комментарии по книжке Деминга "Выход из Кризиса"

Решил написать обзор очередной книги, пара недель прошла, как прочитал, но с переездами в москву, поисками квартиры и прочим геммороем было не до того)
Отрабатываю долг перед собой)
Это наверно последняя из запланированных книжек из серии agile/lean/etc на ближайшие пару-тройку месяцев.
И она оказалось самой талмудистой =)

Читал и осозновал я соответственно "Выход из крисиза. Новая парадигма управления людьми системами и процессами" Эдвардса Деминга.

Об авторе и книге:
Товарищ Деминг можно сказать является родителем agile & lean подходов по той простой причине, что это он ездил распостранять свои идеи японцам, когда в америке продвинуть их не слишком удалось. И потом уже рекурсивно на волне подъема японской промышленности эти идеи вернулись в америку и добрались в том числе и до разработки ПО.

Автор достаточно скромен и честно признается в свой книге, что на самом деле он не автор всех этих идей, а развивал идеи и мысли Шухарта, и цикл Деминга должен быть не циклом Деминга, а циклом Шухарта =)

Сам себя Деминг называл "специалистом-статистиком" потому в книжке встречается много формул и поддерживается научный подход(много графиков и формул).
Деминг утверждает, что производство и разработка являются либо статистически управляемым (читай можно предсказать, как оно будет работать завтра и соответсвенно улучшить) или нет - считай хаос, бардак, и предсказать что-то точно нельзя(т.е. система построена так, что очень многое зависит от случая).

Книга опять же большая(~300-400 страниц) и потому с наскока не береться, потому лучше конспектируйте ее походу иначе есть вероятность после 2-3х дневного возврщанения к чтению забыть о чем же шла речь.
Одним из самых интересных моментов, книги являеться, то что она написана во первых тем, кто создавал эту теорию, а так же она написана уже ПОСЛЕ того, как теория подтвердилась на практике.
И, благодаря этому, у автора была возможность уточнить и отполировать теорию нового менеджмента и производства во время ее внедрения.

Вобщем можно вольно перефразировать Друкера и сказать "Деминг - это Тейлор сегодня".
Пришел, проанализировал производство и победил, т.е. переубедил(еще переубеждает) весь мир, как надо производить товары\продукцию\услуги.

Что запомнилось:

1) В кратце книгу можно пересказать, как "Стремитесь к максимальному качеству, и вот как это сделать".
Только под качеством надо понимать не только отсутствие ошибок, переделок и лишней работы, но и производство именно того, что нужно потребителю (хинт: делайте прототипы, и тестируйте их в реальных условиях), ведь в конце концов какая разница что предмет не ломается, если он не делает того, что надо или делает это не так.
А уже повышение качества приведет,
к снижению себестоимости(меньше переделок, брака, ошибок)
-> больше производительность
-> предлагаете лучшее качество по тойже или более низкой цене
-> захватываете рынок
-> ПРОФИТ!
-> повторять до бесконечности.

2) Для этого Деминг предлагает 14 пунктов менеджмента (почти теже, что описаны в Дао Тойота +/- пункт-другой, так что опущу сами прочитаете).
И называет "смертельные болезни менеджмента", т.е. то как делать не надо, например : "аттестация и ранжирование персонала" или "нацеленость на сиюмитный результат".
Кстати в книжке встречается, довольно много эдаких вопросников или чеклистов и если есть вопросы а стиле "что я(мы) делаем не так", то можно поробовать пробежаться через вопросник и станет понятно в какую сторону надо копать)

3) Кроме таких философско-менеджментско-общечеловеческих советов Деминг так же расписывает, как понять встали ли вы на путь улучшения: т.е. улучшаете процесс (и всю систему) - исправляете "общие" причины (вариабельности\ошибок), например отсутствие единой системы документации. Или постоянно фиксите "особые" причины (т.е. следствия системных ошибок, или единичные случаи), например некомпетентность отдельного человека (и это скорее следствие системной ошибки системы отбора персонала), либо завышенная сложность, или запутанность определенной процедуры.

Вот тут-то и вступает в силу статистическая теория и статистическая управляемость, т.к. она позволяет отследить общие тренды и понять отклоненеи ли это в пределах нормы или системная ошибка, либо специальная причина.

4) Кроме того, контроль качества не должен быть бездумным, тюею стремиться к идеальному процессу на каждом этапе, если проверка + исправление потенциальной ошибки на этапе А, добавляет 10$ (5 - проверка, 5 - исправление) к себестоимости товара(надо кстати не забывать, что проверка качества тоже стоит денег), а проверка и исправление на этапе Б(этап А входит в него как одна из деталей) стоит 1000$ (10$ проверка + 990$ исправление), то если вероятность ошибки на этапе А - 0.000000001, а вероятность ошибки на этапе Б - 0.00001, то проверяя на этапе А мы добавляем к себестоимости каждого продукта стоимость его проверки на этом этапе, а на этапе Б проверять скорее всего все равно придеться т.к. стоимость нахождения дефекта пользователем обычно гораздо выше проверки и починки у производителя.

Стоит ли почитать:
Книжку можно почитать ВМЕСТО Дао Тайота, чтобы понять все идеи `японского` менеджмента, кроме того более научный стиль изложения создает неявное ощущение верности всех этих идей. Если вы уже знакомы с идеями lean, то стоит читать только отдельные главы + смотреть главы по вариабельность и типы ошибок.

Мысли про Lean/Six Sigma/TOC: Versus или And ?

Намедни, дочитал Leaning into Six Sigma, до этого имел довольно расплывчатое представление что же это за зверь "Six Sigma" и с чем его есть =). Просветился)

Краткая историческая справка:

Six Sigma - метод управление зародивший от Lean в Мотороле:

Если Lean это такой процесс улучшения потока создания добавочной ценности , то Six Sigma - это процесс уменьшения вариабельности отклонений этого процесса, т.е. уменьшение среднеквадратичного отклонения (сиречь сигмы) до 6, попытка достичь 3.4 бракованных изделия на миллион (3 бага на миллион готовых фич, эх нам в разработке ПО о  таком только мечтать =)).

Коротко о самой книге:
Что хорошо - книга короткая (~95 страниц), после 300-400 страничных читается за пару заходов.
Написана от первого лица и в этом чем-то напоминает Deadline.
Очень краткий пересказ:
Консультант пришел на проект и начал вытягивать его из болота, т.е. :

• пришел и научил всех, как жить,
• разъяснил про методы работы: 
• идеологию Six Sigma + Lean, 
• 5S, 
• (D)MAIC (переделанный цикл Деминга-Шухарта PDCA под более статистический подход), 
• сделал рабочих довольными и гордыми за свою работу, 
• менеджмент понимающим и слушающим рабочих,
• и научил людей решать их проблемы/видеть пути улучшения производства/устранять потери.
• + дал статистический мат-аппарат, как следить за отклонениями от идеального процесса.

Итого по книге:
В общем книга дает такое достаточно облегченное понимание Lean-подхода, идеологии SS и как их применять вместе.
Порекомендовал бы пробежать глазами книгу + прочитать key points в конце глав, если вы знакомы с Lean, или почитать, как краткое ознакомление, если не сильно знакомы.

Ах, да чуть не забыл в книге описан очень прикольный подход SS типа, восточных единоборств  есть -  орки, тролли, эльфы 80го уровня, зеленые пояса, черные пояса, чемпионы по степени понимания и умения применять SS.


Мысли по теме:
* Знакомство с темой ОЧЕНЬ желательно, хотя бы прочитайте статью в Википедии. TOC, Lean, Six Sigma.

Lean is Art. Six sigma is Science

LEAN...It is art.  Six Sigma is STATS on STEROIDS 

Сравнивать их между собой в данном посте смысла не вижу (да и лишь перепечатаю пдфку), т.к. самые основные и рабочие подходы и там и там подозрительно похожи.

Если их пересечь то за пределами пересечения останется небольшой кусочек, как в Лине, так и в SS.

TOC правда с людьми вообще особо не считается, потому стоит немного особняком, но в принципе его можно считать частью Lean, ради простоты, т.к. выравнивание работы неявно предполагает применение TOC.

По поводу Versus/And мнения  разнятся от:

1) Только этот метод истинный, а остальные - его потомки/обрезки/мутанты.

2) Выберите тот, который больше всего подходит именно вам из этих 3-х.

3) Все три метода бред - скоро появится новый метод Х, который зажжет.

4) Используйте все - по сути они одно и тоже.

По моему скромному мнению, последнее и есть тру-подход. 

И тут даже следует не смотреть в сторону их объединения, а смотреть от обратного: вся цель любого производства/дела - сделать (пиздато) приятно своему пользователю - предложить наилучшее, бесконечно-полезное и качественно-вечное нечто, будь то услуга/товар/идея/что-угодно. Соответственно можно надергать из кучи возможных подходов - только то, что нужно и применимо в данной ситуации. 

Есть потери - задействуй Lean и постарайся сделать процесс исключительно выполняющим полезную работу .

Есть измеримые данные + неравномерность - натрави SS: что можно померить - можно улучшить.

Есть где-то боттлнек/не хватает ресурсов - примени туда TOC: сделай предложение = спросу (если боттлнек в спросе =)) на всех этапах, либо используй критический ресурс по максимуму.

В разработке ПО на самом деле, все тоже самое: все народившиеся методологии получаются тот-же конструктор:

хочется быстрых релизов - сделай Agile с итерациями, 

хочется кристальной видимости, что делается и не хочется планировать на годы вперед - построй value map и введи Канбан и т.д.

Осталось только понять какие же составные кубики разработки ПО есть, и останется только повторить "Верной дорогой идете, товарищи" =)

Полезные ссылки:
Архи-полезный тред, которое многое прояснил в голове:
http://www.isixsigma.com/index.php?option=com_k2&view=item&id=1511:six-sigma-versus-lean&Itemid=111

Пара пдфок от туда же:
http://asq.org/pub/qualityprogress/past/0302/qp0302nave.pdf
http://asq.org/pub/qualityprogress/past/0403/qp0403smith.pdf

Agiledays: ретроспектива

Буквально пару  дней назад закончился мартовский Agiledays`11, комьюнити активно делиться впечатлениями, выкладывает фотки, обсуждает как прошло - по-участвую то же)

Что понравилось: 

• Комьюнити =) Познакомился не с таким большим количеством люде, как хотелось бы, но тоже не плохо, люди говорили, что не хватает общения, надо как-то двигать народ к активному сотрудничеству и разговорам, может в рамках всей конференции игру какую проводить, чтоб народ узнавал друг-друга.
• Организация, блокнотики, еда были хороши (хотя пакетики со спонсорским спамом можно бы сделать и поменьше, лучше пусть стенды свои развешивают).
• Мастер-классы - были отменны, хочется побольше:
• Командный старт: интересный и позитивный ведущий, интересная тема, достаточно четкий план проведения и желающие слушать и воспринимать участники - бесценно(ц)
•  Agile-игры: Business Value Game  - игры это хорошо=) Почувствуй себя частью команды, зарабатывающей деньги для фирмы: небольшой соревновательный момент и самоорганизующаяся команда => и все нацелены на получение фирмой прибыли/выигрыш. Заняли с командой 2-ое место, эх знать бы раньше на каких условиях вступит в силу ROI). Илье (Кирову) Ириске, Артему Аутентичному, Семену(Молотову) Супермену и паре других чуваков (всех все таки не запомнил) из Скб-контура, привет =)
• Agile-Learning Стаса Фомина: не совсем мастер-класс, но тоже происходил в такой достаточно-интерактивной форме с квестом для тех, кто взял с собой ноутбуки. Стас вообще интересный и умный и сильно ответственный чел, узнал, что практически все, что он записывает он делает по своей инициативе, за свой счет и своими силами.  Рассказывал о том как организовывать обучения и передачу знаний: о тулзах, средствах и подходах. Запомнилось: "Парное программирование оно же от отчаяния, потому что не умеем лучше передавать знания." Большущее ему спасибо за проводимую работу.
• Были интересные доклады:
• Запомнился Евгений Кривошеев с его моделью принятия инженерных решений. все кто учился на инженера помнят, что надо подумать, измерить какие последствия своих решений ты хочешь получить: например: гибкое, но сложное, или топорное, но простое из из этого исходить при проектировании и разработке, но в процессе разработки некоторые вещи переходят в привычку, некоторые просто забываются и получается, что зачастую программа пишется, как придется. Напомнил, для чего инженеру голова нужна)
• Очень хорошо отзывались о докладе Хенрика Кенинберга, но к сожалению я его пропустил.
•  Экстремальнйы Аджайл: танцуют все, от разработчиков "электронного бугалтера Эльбы". Интересно узнать, что у нас есть прям молодые продуктовые команды, которые успешно применяют аджайл во всей компании, в разговоре за обедом выяснилось, что работает это у них просто прекрасно, инвесторы/стейкхолдеры странными идеями их не душат, да и работа у Евгения, чтоб такого как раз не случалось. Докладчики жгли перлами и напалмом, и кажется разошлись на цитаты: "клизма для вдува таска в итерацию", "тз - хз", "разработчики делают маркетинг!" и другие, фишечка на финальном слайде с конец - "конь" была неочевидной! =). В кулуарах заслужили звание "наших" ажайл-гуру.
• Доклад Бориса Вольфсона (Softline) "Масштабируем скрам", оказалось интересным узнать, что подход Scrum of Scrums (описан в книге Кенинберга, полистайте рсс ScrumTrek`a, там есть ссылка) они развили аж до 3х уровней, с product owner`ами & chief product manager`ами.
• Доклад Кирилла Климова, про кунгфу - канбан вс скрам, хотя это только название, что от Скрама они перешли к канбану, т.к. у них была специализация, ретроспективы особо перестали приносить полезные идеи, и они решили преобразить свой процесс в канбан-стайл поток. В общем-то идеи все из тех, же книг, что я читал, а интересным оказалось, что люди смогли применить подход на практике успешно.
• Доклад Александра Лесневского и Никиты Филлипова про то как перевод проекта на ажайл-рельсы помог понять инвестору, что продукт будет убыточным. Оказывается и такое бывает) После того, как agile-подход сделает процесс боле прозрачным ВНЕЗАПНО можно узнать, что он особо то и не нужен.

Было нормально, доклады:

• Доклад Сергея Андржневского об инженерных практиках в принципе ничего особо нового сказано не было, можно любую книжку почитать по тему и там это будет, но и народ откровенно не скучал задавал вопросы, и у них вроде бы почти все (парное, тдд, бэклоги, ...) используется по прямому назначению и вроде хорошо получается. Запомнилось. что сейчас без парного программирования докладчик себя чувствует уже как-то не так)
• Доклад Романа Юферова (http://a-jail.blogspot.com/ ) про поиск гибких разработчиков. В общем-то рассказал верные и интересные вещи: про то, что надо искать кого-то кто не гнушающегося кросс-функциональности, людей которые делают, то что нужно сейчас, умеющих принять помощь и вообще командных). 
• Интересным было замечание, что есть смысл брать либо: 
• сильно молодых, т.к. у них еще взгляд не зашорен собственной крутость,
•  либо зубров, то есть тех, кто уже понял, что разработка ПО, это вообще не главное в жизни.
•  а миддлы-сеньоры - они как дети: 
• эгоцентричны, 
• полируют торпеды (т.е. доводят свой код до совершенства), 
• сомневаются, что кто-то им поможет (т.к. очень круты в своей области) 
• и избалованы своей крутостью.
• Доклад Никиты Филлипова про Lean Startup, идеи были изложены в определенной степени для меня новые, но создалось ощущение, что пересказ пары книжек. Частично подпортило впечатление, что он быстренько пересказал предыдущий доклад из-за того, что докладчик не пришел, который полностью пересказывал "Дао Тойота". Примеров из жизни и какого-то реального опыта применения не хватает, чтобы этот доклад можно было считать True.

Что не понравилось/Хотелось бы поменять:

• Тезисов не хватает, чтоб сделать выбор, и наперед не скажешь будет интересный доклад или нет. Может быть слайды + предполагаемую стенограмму еще стоит выкладывать заранее
• Программа конференции на сайте не удобно работает с тач-пада =)
• Было бы неплохо если б слайды опять же были доступны централизованно: а то получается, что сейчас кто у кого успел спросить контакты или визитку дать, или в твиттер вовремя заглянул - успел получить слайды, неудобно-с. 
• Лично мне показалось, что слишком много обзоров инженерных практик, послушать про чужой опыт применения философии гораздо интереснее, чем про: а вот мы юзаем: это, это и это - у нас работает.
• Люди (за обедом) задавались вопросом: "я, как разработчик/пм понимаю профиты аджайла, но как подойти с этим к руководству - не понятно" или "мы попробывали - натолкнулись на грабли, руководство решило, что это все фигня". Неплохо бы увидеть такие доклады/мастер-классы.
• Не интересные доклады, определенно стоили бы послушать лекцию Стаса Фомина, о том как делать доклады =):
• Доклад Заходяйченко Андрея про ALM системы, народ сидел вялый, людей было мало, докладчик что-то спрашивал, а народ тупил и стремался отвечать, откровенно не зажигающий доклад.
• Борис Вольфсон, Гибкая теория ограничений, предварительно смотрел его вебинар, а цель Голдарата читал до этого, для меня не было чего-то нового и насколько я понимаю доклад то же был такой скорее теоритический, чем практический(не дослушал до конца).
• Николай Гребнев (Custis), DDD в распределенных приложениях, суть доклада сводиться к простому: "в DDD надо вводить распределенность в доменную модель, либо не делать распределенным", довольно очевидная вещь, и я все ждал, что вот сейчас то он расскажет ка-же это правильно делать, оказалось - нет. Откровенно слабый доклад, спросил за обедом у чуваков: как он так выступил выступил, сказали ну вот дали попробовать: не получилось.
• Дмитрий Лайер, Стратегическое планирование через инновационные игры, тема интересная но подана, была как-то уныло, докладчик бубнил про себя и народ в зале чатился в твиттере, смотрел хабру и вобще не был заинтересован. Не слушающий докладчика народ - довольно неплохой показатель интересности доклада. 

Упомянутые книги, названия которых я успел записать =):

Лайкер, Дао Тайота

Luke Hohmann, Innovation Games

Succeding with Agile,

Fearless Change,

Agile Product Managment

и куча других, но буду ждать видимо слайдов, чтобы найти их.

P.s. Следующий Agiledays, планируется в Самаре в июне (приблизительно в числах 9-12х), если есть желание поучаствовать или выступить с докладом, то велкам!
Борис Вольфсон(http://borisvolfson.moikrug.ru/, http://twitter.com/#!/_blv_) выступил с инициативой сбора докладов, либо же пишите и джоиньтесь в группу (https://groups.google.com/group/Agiledays-speakers?hl=ru).