Individuals and interactions over processes and tools

Сегодня я хотел бы рассказать, какими убеждениями руководствуется аджайлист в различных ситуациях и как они помогают быть ему эффективней, а команде успевать в срок производить качественное ПО. Простому человеку и вотерфолщику преимущественно убеждения и ценности навязаны телевидением, школой, институтом, семьей и рабочим коллективом. Убеждения складываются стихийно и не контролируются, а отсюда много недоразумений, несбывшихся ожиданий и т.п. Аджайлист же, чтобы повысить свою эффективность, получать удовольствие от работы и участия в проекте воспитывает в себе "правильные" убеждения. Основу этих убеждений заложили 13 февраля 2001 года семнадцать человек. Но все по порядку...

11-13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты семнадцать человек собрались, чтобы пообщаться, покататься на лыжах, расслабиться и попытаться прийти к общему знаменателю и, конечно же, поесть. Что из этого вышло - Agile-манифест разработки ПО. Съехались представители Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming и других подходов, вызванных потребностью в альтернативе к основанным на документации, тяжеловесным процессам разработки ПО. В конце своей встречи они подарили миру "Манифест Agile", определяющий Agile как 4 ценности + 12 принципов + 0 практик.

Далеe: ссылка

Разработка стратегии тестирования

Предлагаю обсудить ситуацию для тестирования. Мы пишем некий модуль для отдела кадров. Наш модуль принимает решение о найме исходя из возраста. Исходя из возраста наша система должна выдавать подсказку: нанимать человека или как. Вот такие у нас требования от кадровиков:

0-16 - не нанимать
16-18 - может быть нанят на полставки
18-55 - нанимаем на полный рабочий день
55-99 - не нанимать

Вопрос: сколько тест кейсов нужно написать? Какие возраста вы покроете?

Понятно, что задача простая. Но все же хотелось бы узнать ваше мнение :)

Гуру, дерзайте!

Ответы будут здесь.

Паттерн "@"

Собака - это единственное животное, которое
не обязано работать для своего существования
Дейл Карнеги

Паттерн @
Предназначен для решения проблем непонимания и неконструктивной критики.

Область применения
Общение.

Проблема
Эмоции - это лакмусовая бумажка любой активности. Разговоры и обсуждения не исключения. Например, начал разговор накаляться. Здравствуйте эмоции. Вы чувствуете, что вас не понимают и продолжают настаивать на своих глупых аргументах. Вы доказываете, что все не так и приводите самый значимый аргумент, которые поставит все точки над I. Но происходит странное, собеседник не только вас не понимает, но начинает повышать голос и настаивать на своём. Он полностью не понял аргумента…

Далее: ссылка

Time Management & Agile

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

Классическая книга, с которой я начал свой тайм менеджмент - это Ален Лакейн "искусство успевать" и его 61 правило. Самое главный вывод сделал из книги - не надо напрягаться :) Как этот вывод во мне появился не знаю, автор на нём вроде не настаиват, но Дэвид Аллен (см. ниже) очень подробно объясняет эту особенность тайм-менеджмента.

Меньше эмоций у меня было к книгам Глеба Архангельского, но когда я читал его первый раз, и то, что представляет собой его работы сейчас - это большая разница. Информации он даёт много. Но это и лучше, вам не нужно выискивать по крупицам практики по интернету и книгам. Все в одном. Поэтому его тоже рекомендую. Энциклопедию тайм-менеджмента от Глеба не читал, но выглядит очень аппетитно.

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

И одна сногсшибательная книга. Практик не очень много, но идеи заряжающие: "Осипенко - 33 способа самомотивации"

Я бы рекомендовал следующий план обучения тайм-менеджменту.

План обучения тайм-менеджменту:
1. Осипенко - 33 способа самомотивации
2. Дэвид Аллен. Как привести дела в порядок. Искусство продуктивности без стресса.
3. Глеб Архангельский "Тайм-драйв"
4. Алан Лайкен "искусство успевать".

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

А дальше у вас появится вкус. Книги простые, поэтому много времени не отнимут. После прохождения курсо молодого бойца можно приступить к классике. О ней как-нибудь потом расскажу :)

Книги нужно не просто читать. А практиковать. Делаете так - читая книгу выписываете полезные практики. Как набралось 3-5 штук. Отложите книгу и попрактикуйте недельку. В конце неделе пересмотрите как вам удалось выполнять практики. Какие получили результаты. Продолжайте читать дальше.

Новая модель мотивирования

Шикарное подтверждение идеи внутренней мотивации:
- автономность
- целенаправленность
- мастерство



PS. Материал найден по наводке Ильи Сербиса:)

5G

Участники стади-групп постепенно синхронизируют свои знания как между собой, так и с такими великими людьми как Кент Бек, Мартин Фаулер, Роберт Мартин, Эрик Эванс и многие другие. Становится иногда сложно отличить (было: отлЕчить :) ), где чьи мысли.

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

Чтобы отстаивать свою точку зрения на форумах и подчеркнуть принадлежность к ордену света было решено подписываться следующим образом:

Денис, 5G

Agile (определение)

Agile - это культура разработки программного обеспечения. Как любая культура имеет четко определенные ценности и принципы. В отличии от методологий не определяет практики, оставляя каждому определить тот набор практик, которые целесообразно применять в данном контексте. Или коротко Agile - это методология с нулём практик.

И краткое определение. Agile - это то, про что пишут в Agile-журналах, -блогах и -сайтах

Agile Guru

Долго пытался понять, что мне не хватает. Регистрил один домен, второй, создавал блоги пачками, чтобы отразить своё миропонимание происходящему. И вчера я понял, как можно объединить все это дело под одной шляпой. Шляпа эта - Agile-гуру.

Цель проекта: выработать критерии понятия Agile-гуру и стать им!

Проект представляет площадку для формирование критериев и набора знаний и навыков необходимых для определения Agile-гуру. То есть здесь мы формируем то, что должен освоить человек и потом торжественно присваиваем ему это звание :)

Так что приглашаю вступить со мной на трудную ступеньку саморазвития - http://agileguru.org

Kanban vs. SCRUM

Запись встречи: http://team.custis.ru/2009/07/kanban-vs-scrum.html (видео)

Просмотрел запись, просто супер! Согласно Core Protocol: 6 баллов из 10
+ 3 балла за классные обсуждения
+ 2 балла что используется принципов Study Group - когда заранее было сказано подготовиться к встрече.
+ 1 балл за запись отличную и отчёт

Чтобы поставить 10 баллов, я бы добавил следующее
+ 2 использовать паттерны StudyGroup, тогда и встреча интересней будет
+ 1 попросить участников потом (так как есть е-мыл) написать отзыв в митинг- статью
+ 1 включить вещание в инет, хотябы через скайп или rutube!!!! (это делается за 5 минут, зато аудитория будет в тыщи раз больше!!!)

Мои мысли по теме:
1. Чтобы понять одну из методологий, нужно понимать скоуп её использование. Это продукт, проект, или только одна разработка. Другой нюанс срез в даже в скоупе. И даже в рамках могут быть разные срезы. Поэтому определив какие области покрываются предлагаемой практикой облегчело бы обсуждение.
2. Был график, когда каждая последующая методология уменьшает количество включенных практик. SCRUM исключил технические, отдав на усмотрение команде, Kanban исключил множество других практик. Каждая следующая методология даёт выбор, чем мы покроим свои активности. Поэтому я бы ввёл следующую методологию - Agile. В которой не одной практики вообще, а другие практики выбираем по усмотрению.
3. По поводу менеджера и улучшения процесса. Кайдзен-команды это альтернатива ретроспективам. То есть Just-in-time по отношению к улучшению процесса, и не нужно ждать ретроспективы.
4. По поводу цепочки задач, и почему хорошо не ложиться вытягивание от маркетинга, через тестирование, к разработке. То тут лучше к Lean в построении цепочки создания ценностей. А тестирование по определению Lean должно быть убито как явление. Так как любые ошибки добавляют потраченное время, поэтому здесь практики Unit Testing для разработчиков, и Acceptence (Fitness) тестирование для тестировщиков. Цель уменьшить время фидбека после каждого чекина. Сюда же идут - ScoreCards, Testable Units, разделение кода и дизайна. Что позволяет работу QA вплести в разработку.
5. И вообще мне усматривается, что менеджмент, как средство управления процессом (придумать документы, поставить практики, мотивировать людей в разборках тет на тет), а не продуктом, исчезает. То есть практика Канбан и Лин делает так, чтобы менеджмент процесса убрать за счет способности команды стопорнуть процесс и его улучшить, как только обнаруживается дырка. Что очень хорошо в канбан видно. Просто форсируются изменения как только обнаружены дырки процесса.

В общем все супер! А можно вебвещание сделать, я хотел бы в следующий раз через скайп поучаствовать тоже :)

Бережливое производство программного обеспечения: от идеи до прибыли

Мэри Поппендик, Toм Поппендик
Implementing Lean Software Development (Signature Series)
Mary Poppendieck, Tom Poppendieck

"Эта замечательная книга объединяет практические советы, готовые к использованию методы и глубокое понимание, почему именно так следует создавать программное обеспечение. Мне приходилось наблюдать коллективы, полностью трансформировавшиеся благодаря идеям этой книги."
— Майк Кон, автор книги Agile Estimating and Planning

В 2003 году книга Lean Software Development Мэри и Тома Поппендика познакомила читателей с революционными методами разработки ПО. Теперь их давно ожидаемая вторая книга призвана показать читателям, как именно следует реализовывать на практике бережливый подход к созданию программного обеспечения.
Данная книга, основывающаяся на уникальном опыте Мэри и Тома Поппендик, поможет организациям, занятым созданием ПО, оптимизировать свои технологические процессы. Здесь читатель узнает, какие вопросы следует задавать в той или иной ситуации, каким проблемам следует уделять больше внимания и какие методы доказали свою эффективность на практике. Авторы также рассказывают об опыте наиболее передовых организаций-разработчиков программного обеспечения и приводят практические упражнения, которые помогут читателям сделать первые шаги по внедрению принципов бережливости.

* Расширять и развивать практику гибкой методологии разработки
* Создавать истинные коллективы разработчиков, а не просто рабочие группы
* Добиваться высокого качества с помощью быстрой обратной связи с потребителями
* Принимать решения как раз вовремя и ни в коем случае не позже
* Осуществлять поставки быстро, как в компании PatientKeeper: 45 качественных релизов приложения ежегодно
* Принимать компромиссные решения, способные по-настоящему удовлетворить заказчиков

Бережливое производство программного обеспечения — это книга, необходимая везде, где требуется создать более эффективные процессы разработки.

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

Об авторах

Мэри Поппендик является специалистом в области менеджмента и разработки продуктов с более чем тридцатилетним опытом использования информационных технологий. Ей приходилось возглавлять коллективы, занятые реализацией разного рода проектов — от управления цепью поставок на предприятии до цифровых медиа, а также участвовать в создании одной из первых бережливых систем производства, ориентированных на поставки "точно вовремя" (на предприятии 3М, где она когда-то работала). Мэри является президентом компании Poppendieck LLC, специализирующейся на внедрении бережливых подходов в разработку программного обеспечения.
Том Поппендик является аналитиком в области предпринимательской деятельности, специалистом по архитектуре ПО и инструктором по применению гибкой методологии разработки с более чем двадцатипятилетним опытом разработки и реализации комплексных систем. В настоящее время он помогает организациям применять принципы бережливости в процессах создания программного обеспечения. Мэри и Том Поппендик также являются авторами книги Lean Software Development (вышедшей в издательстве Addison-Wesley), которая выиграла премию Jolt Software Development Productivity Award (Премия за высшую продуктивность в разработке программного обеспечения) 2004 года.

256 стр., с ил.; ISBN 978-5-8459-1538-2, 0-321-43738-1; формат 70x100/16; твердый переплетсерия Signature Series; 2009, 4 кв.; Вильямс.

Критерий Lean судья процессов

Забавно, но ключевая идея Lean (бережливого производства) может показать кардинальные различия в Waterfall & Agile. Идея заключается в переходе от массового производства, в терминах ПО - поэтапного производства, в производство по требованию.

Действительно разрабатывая по водопадной модели мы заставляем заказчика ждать завершения разработки и тем самым провоцируем его терять деньги. Ведь во время разработки он не может использовать продукт, а только платит за него.

Agile с игрой в планирование (фокусировка на самых приоритетных задачах) и итеративно-инкрементный (причем важнее инкрементная, нежели итеративная разработка) подход фокусируется на поставке как можно быстрее рабочего, хотя не 100% набитого функционалом приложения. Но самое главное - реализующего ключевой функционал. Зная закон Паретто можно сказать, что 20% функционала покрывают 80% потребности. И это факт :) Agile ориентируется на ключевых для бизнеса вещах, нежели поставка через -цать лет и в полном объеме. Это отличие превращает поэтапное производство в производство по требованию. В гармоничный поток создания ценностей. И аджайл позволяет взглянуть на разработку с точки зрения ценностей клиента, нежели ценностей производства (следования этапам и повышения эффективности оных: CMMI, оценки производственных процессов и т.п.).

Исходя из этого можно предположить, что code&fix, самая лучшая практика. Не соглашусь. При уменьшение цикла от заявки до реализации начинают набирать силу муда ( потери, отходы, то есть любую деятельность, которая потребляет ресурсы, но не создает ценности). То есть можно очень мощно рвануть в создании ценностей и выкатить результат. Но каждый следующий шаг будет давать сложнее и сложнее.

Терминология Core Protocol

Словарь базовой системы Джима и Мишель Мак-Карти "Программируем командный дух".
Чтобы догнать, рекомендую пять раз прочитать этот список.

ЧЕСТНОСТЬ – полная согласованность единство чувств, мыслей, слов и действий. Полное присоединение.

ПОЗНАНИЕ – процесс структурирования потока поступающей информации.
Познание можно рассматривать как процесс, состоящий из нескольких стадий:
1. Сомнение в тех или иных убеждениях.
2. Анализ и интеграция информации, содержащейся в мыслях, эмоциях и интуитивных догадках.
3. Формирование гипотетических действий на основе собранной информации.
4. Осуществление «наилучшего» действия из тех, которые были сформированы на стадиях 1–3.

ЗНАНИЕ – знание или уверенность – это патологическая вера. Патология знания проявляет себя в стремлении «знайки» уничтожить собственное восприятие и подавить в себе процесс непрерывного экспериментирования и анализа, который ведет к приобретению опыта. Опыт повышает жизненную силу верующего. Как правило, знание тормозит или даже устраняет процесс познания. Следовательно, знание обычно не так хорошо обеспечивает взаимодействие с миром, как вера.

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

Убеждения, которые вы называете своей верой, не так важны, как ваши истинные убеждения. Очевидно, что вы не верите в методы, которые не применяете. Описание, проповедование или иное выражение своей веры в отсутствие действий может быть довольно веселым занятием, однако оно редко бывает полезным для вас или коголибо еще. Болтовня о ценностях – это способ уйти от достижения цели. Вера служит не только для организации и проведения исследований и экспериментов, но и для реальных действий. Если вы действуете исходя из своих убеждений, вы очень скоро поймете, насколько они истинны. Лучшим показателем истинности является уменьшение усилий или увеличение изобилия.

Вырожденным состоянием веры является постижение – то есть состояние, при котором гипотеза становится «знанием» или «уверенностью». Знание – это вера вне зависимости от истинности.

ИССЛЕДОВАТЬ – непредубежденно изучать что-либо, руководствуясь реальным или воображаемым любопытством.

ИСТИНА – убеждение, которое при практическом применении чаще порождает изобилие по сравнению с другими убеждениями. Истины открывают путь только другим истинам. Причем постоянно и, как кажется, ускоренными темпами.

ВОВЛЕЧЕННОСТЬ – взаимосвязанность с другими сотрудниками, работой и объектами.

ПРИСУТСТВИЕ – влияние личности в данный период времени; ощущение влияния другой личности. Качество и ценность вашего присутствия, а также расходы, связанные с ним, определяются (1) влиянием вашего присутствия, оказанным на взаимодействовавших с вами людей во время и после данного периода времени, (2) влиянием, оказанным на вовлеченные объекты и процессы, (3) влиянием, которое вы оказали на свою жизнь посредством полученного опыта и взаимодействия с другими людьми. Степень вашего присутствия в течение заданного времени, в заданном месте, в составе заданной группы определяет уровень ваших результатов.

В течение некоторого периода времени ваше присутствие из меняется от нулевого воздействия до полного верховенства. Ваше присутствие увеличивается благодаря cамораскрытию – раскрытию, наиболее эффективно осуществляемому в своей рабочей среде. Если вы формируете намерения и осуществляете их, поддерживаете собственную осведомленность, думаете о ценных качествах, которыми вы обладаете, и применяете их, ваше присутствие значительно возрастает. Наибольший рост присутствия происходит при своевременном использовании своих творческих способностей. И наоборот, присутствие уменьшается, если вы себя сдерживаете.

ВОСПРИНИМАТЬ – получать информацию при помощи органов чувств, одновременно сознавая приобретаемый опыт.

ЗАЗОР МЕЖДУ ГОЛОВАМИ (затраты) – увеличение расходов (сверх расходов базового зазора), которые необходимы для при менения способностей другого человека. Затраты на преодоление психологического расстояния между двумя людьми (зазор между головами) – это дополнительные затраты, необходимые для того, чтобы сотрудник А смог предоставить свои способности сотруднику Б, плюс дополнительные затраты (сверх базовых) сотрудника Б на освоение этих способностей. Зазор включает в себя все затраты, связанные с межличностным взаимодействием А и Б, с усилиями, которые А и Б должны предпринять, чтобы повысить свою доступность друг для друга, и с усилиями, которые Б должен предпринять, чтобы применить способность, которой обладает А. Также этот показатель включает в себя затраты, вызванные ошибками в процессе взаимодействия А и Б.

КОМАНДА – разумная надличностная сущность. Она может состоять из некоторого количества людей (или команд), которые стремятся действовать сообща для достижения общей цели с максимальной эффективностью. Командное поведение всегда включает в себя два вида деятельности:
• Аккумуляция личных ресурсов, особенно времени, информации и способностей.
• Эффективное применение этих ресурсов для достижения индивидуального и коллективного успеха и изобилия.
Кроме того, команда всегда способна говорить одним голосом.

КОНФЛИКТ – несогласованность интересов. Для разрешения конфликта зачастую требуется большая идея.

РАЗГОВОР – неструктурированное применение голоса, которое может иметь совершенно различные показатели сигнал/шум. Разговор – это самый распространенный способ не руководить и не быть руководимым. Кроме того, это стратегия, позволяющая помешать другим сотрудникам руководить или подчиняться руководству. Зачастую, когда ктото хочет поговорить, вы чувствуете себя обязанным слушать. Это проявление уже исчезающей формы вежливости. Хотя слушание обычно является полезной стратегией, чрезмерное внимание к пустым разговорам не приносит никакой пользы. Более того, внимание к таким разговорам несомненно вредит всем, кто в них участвует.

БОЛТОВНЯ – разговор, который не приближает команду к поставленной цели. Этот разговор может вызывать интерес людей, а может оставлять их равнодушными.

РУКОВОДСТВО – публичная уязвимость. Смелое раскрытие собственных сил.

РУКОВОДИТЬ – быть первым, кто начал действовать в соответствии со своими убеждениями.

ЭМОЦИИ, ЭМОЦИОНАЛЬНЫЙ – высокоскоростные персональные элементы обработки информации, описываемые одним или несколькими примитивными состояниями: раздражением, печалью, радостью и страхом. Функция эмоций состоит в том, чтобы проинформировать человека быстрее или поиному – по сравнению с рациональным мышлением. Эмоции ярче и медленнее интуиции, быстрее и туманнее, чем мысли.

AgilePodcast 1. Сезон 1. Что такое Agile?

Участники:
Асхат Уразбаев, Денис Миллер, Никита Филиппов

Обсуждаемые темы
* Проблемы разработки ПО
* Что такое Agile?
* Чем приятен Waterfall
* Сравниваем Agile и не-Agile
* Буддизм в Agile

Пирамида требований

Записал несколько подкастов на тему управления требованиями и оценки.

http://agile.rpod.ru/112496.html - здесь я ввёл понятие пирамиды требований
http://agile.rpod.ru/112634.html - тут введено понятие условных единиц измерения для каждого уровня. И показано как условная единица уровня User Story превращается в Story Points.
http://agile.rpod.ru/112772.html - ну а здесь краткое объяснение супер техники коллективной оценки трудоёмкости Planning Poker

Подключайтесь и задавайте вопросы. Будем искать ответы :)

Аджайл активности

Асхат решил создавать обзор аджайл за неделю. Поэтому очень рекомендую заходить на его сайт. Самые интересные моменты с его точки зрения за неделю читайте по адресу: ссылка. Я думаю это приведёт к реанимации agilerussia и ru_agile под флагом ScrumTrek и Асхат выйдет из подполья, куда втянула его работа. А мы будем снимать самые сливки с его блога. Ням-ням. Супер!

Это провоцирует оживить http://agile.rpod.ru для записей не только стади-групп встреч, но и сам подкаст, где выкладывать свои мысли. Кстати, если вы аджайлист и хотите практиковать английский в разговорной и письменной речи. Agile Study Group решили перейти на английский язык, там мы изучаем всякие полезные источники и обсуждаем их по английский. Так же сделан сайт: http://agileexperts.blogspot.com, где мы комбинируем тренировку в English Writing и изучении Agile. Приглашаю к участию!

Share the pain : система мотивирования

Документальный ролик о тесном взаимодействии пользователей программ и разработчиками. Когда пользователь испытывает боль за сбой программы у него есть возможность поделиться этой болью с программистом.

Нечестно, что только программист разделяет боль за некачественное решение. Отдел качества должен быть на передовой взаимодействия с заказчиком. После непродолжительной беседы по чату с Виталием Стаховым, мы решили, что и это не совсем верно. Поэтому предложена схема: клиент разделяет боль с тестером, тестер с программистом. Но стал вопрос, а с кем разделяет боль программист? И поняли, что с аналитиком. А аналитик? С пользователем! Круг замкнулся!

Хитрее всех в данной ситуации находится одна фигура. Эта фигура часто орёт на собраниях, что у него "огромная ответственность перед всеми", и поэтому кстати он получает больше всех денег. Но почему то он выпал из раздачи. Кто это? Конечно же менеджер.

После рассуждений мы поняли. Боль должна разделятся по объёму ответственности. А абсолютная ответственность как выяснилось у менеджера. Поэтому схема упростилась: клиенты, программисты, тестеры, аналитики пинают менеджера.

И это правильно!

Ретроспектива решает конфликты

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

Пару слов о конфликте. Конфликт - это когда точки зрения не совпадают и мы начинаем подключать эмоции, а по сути никуда не двигаемся. Если посмотрите мои посты про эмоции - то знайте - это вы подключили своё подсознательное. Теперь вы стали сильнее и мудрее, когда включили эмоции. Единственное нужно уметь управлять подсознательным (эмоциями). Это умение управлять эмоциональным интеллектом. Подсознательное через эмоции подсказывает - работаем неэффективно. Теперь понятно, что работаем неэффективно, то есть обсуждения зашли в тупик. И это можно оценить по уровню эмоций.

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

Упрощёная схема:
1. Конфликтная ситуация.
2. Остановится
3. Понять свои эмоции.
4. Найти причину (см. технику)
5. Провести ретроспективу на то КАК вы обсуждаете, а не ЧТО вы обсуждали.

Секретная техника действует! Люди меняются и культура разработки растёт!
Приятной ретроспективы!

Эволюция культуры команды - ретроспектива

Как я отличаю аджайл команду от не-аджайл? По наличию одной лишь практики - "Ретроспектива". Мне не достаточно сказать - у нас есть она. Я должен увидеть как происходит это таинство. У меня в загашнике есть ряд критериев по которым определяю качество "ретроспективы". Может быть когда-нибудь напишу :)

Сегодня хотел чуток о другом. Я просто несказанно рад, что Дмитрий у себя на блоге описал эту штучку (ссылка). И этот пост воодушевил закончить находящийся в черновике пост про ретроспективу. Асхат подхватил эстафету про ретро. Рекомендую зайти - ссылка.

Продолжать чтение моего поста нужно после чтения поста Дмитрия.

Я привык использовать облегчённый вариант ретроспективы. Я за упрощение во всем её многообразии. Мои ретроспективы просты по структуре
1. ХОРОШО
2. УЛУЧШИТЬ
3. ИДЕИ

Народ интересуется, почему же есть пункты "Хорошо", "Улучшить" и "Идеи", но нет "Плохо" ) Весь сыр бор вокруг пункта 2. Он показывать отличие в психологии проведения ретроспективы. Готовы ли на свершения (которые оформляются Action-планом, который я забыл упомянуть), или просто "вздыхатели" :)

Для русского менталитета пункт 2 должен быть "ПЛОХО". Для европейского - "УЛУЧШИТЬ".

Разница грандиозна. Во-первых, описать "ПЛОХО" нужно 1 мозго-силу. Констатируем факт и мы в шоколаде. Для описания "УЛУЧШИТЬ" нужно 2 мозго-силы. Первая для описания "плохой" ситуации, а вторая мозго-сила для предложения пути как исправить. Вот и получается пункт "УЛУЧШИТЬ" это посложнее, чем "ПЛОХО.

Во-вторых, "ПЛОХО" характеризует натуру, которая больше любит жаловаться, а не решать проблемы. "УЛУЧШАЮТ" в эффективных коллективах, когда идентифицируют неэффективное поведение, ситуацию и ставят задачи по улучшению. Игра слов. Но все же обращу внимания: жалуются - решают, проблемы - задачи. Можете подумать на досуге к какому поведению приводят две эти стратегии, если ими руководствоваться по жизни.

В общем народ можно разбить на две большие группы по этому критерию. Первая - кто ищет оправдания (для них в ретро нужен пункт ПЛОХО) и другая группа, кто ищет возможности (для этих нужен пункт УЛУЧШИТЬ).

А если получается много "УЛУЧШИТЬ" и улучшения достигаются. Это развивает команду. Команда за счёт "УЛУЧШЕНИЙ" изменяется, изменяется её культура.

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

Секреты построения команды (Team Building)

Использование практик Agile позволяет эффективно управлять созданием продукта. Но создание команды и динамика построения команды в Agile освещены не очень хорошо. В предлагаемом подкасте я рассказываю о практиках, которые ориентированы на развитие командных отношений и повышение эффективности работы. Весь подход состоит из четырёх этапов:
1. Развитие эмоционального интеллекта
2. Коллективное принятие решений
3. Интеграция личных и командных целей
4. Общее видение

Все секреты одним файлом:

Null Object и синтаксический сахар C#

public interface Null
{
}

internal class NullWord : Word, Null
{
}

if(word is Null)

Без комментариев. Красотища! :)

Использованы паттерны: NullObject и Marker Interface

Подробнее: http://agile.rpod.ru/109024.html