Качественный код и методология Agile

Переезд

2011-05-24T23:05:00.001+04:00

Переехал в http://agilizt.livejournal.com/

97 этюдов для архитекторов программных систем

2010-08-28T13:56:00.003+04:00

Пришла книга, заказывал на books.ru... Не заметил как пролетело время и пришла повестка... из почты :)

Делюсь результатами беглого просмотра. Книга напоминает блог из 97 постов от различных людей. Преимущественно архитекторов. Прочитав выборочно несколько этюдов, кажется сообразил уровень книги. А уровень очень абстрактный - в своих этюдах авторы делятся принципами и ценностями, которыми нужно руководствоваться при разработке ПО.

Подумалось, что книга интересна мне потому что, обладая опытом, интересно сравнить свои выводы/принципы с выводами авторов. И немного расширить своё понимание. Дополнительные штрихи, которые позволяют улучшить своё понимание.

Но в то же время возникли сомнения, что человеку без опыта эта книга будет интересна. Ведь без опыта нету почвы куда могут авторы посадить своё семя знания. То есть для неискушённого читателя книга может показаться простой и нудной. Но чтобы такое не случилось, думаю стоит попробовать применить советы авторов к текущим проектам/или к прошлым своим проектам. Попробовать посмотреть на свои проекты с точки зрения авторов. Чтобы бы они сказали относительного того, что вы делаете и как вы думаете?

Скорость разработки

2010-08-24T20:31:00.003+04:00

Умудрился я ввязаться в флеймо-войны - http://habrahabr.ru/blogs/pm/101906

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

Даже получилось толкнуть "парное программирование" в его команду. Теперь жду репортов об успешном внедрение.

Началось обсуждение с оценки эффективности программиста. В этот миф я не верю. Но вот попалась цитата, в которую я 100% поверю:

“Poor management can increase software costs more rapidly than any other factor.”
—Barry Boehm (Software Engineering Economics)

После этого я поменял свою точку зрения - людей мерять можно :)

Размер рубашек при оценке в проекте

2010-08-23T11:56:00.006+04:00

Соответствие аджайл оценок требований с размерами рубашек.

Story Point	T-shirt Size
0	Просто, или уже сделано
1	XS (экстра-маленькая)
2	S (маленькая)
3	M (средняя)
5	L (большая)
8	XL (экстра-большая)
13	XXL (громадная)
20	XXXL (американец)

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

Шаг 1. Классический менеджмент признаёт, что ряд фибоначи лишь калька с размеров рубашек. Пусть аджайл-детки балуются тем, что уже давно выдумано.

Шаг 2. Классическому менеджменту нужно подсказать, что оценку лучше давать не экспертную/индивидуальную, а коллективную - через планнинг покер.

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

Очередные версии Agile

2010-08-22T23:30:00.002+04:00

Обнаружил парочку новых книг, которые поместил в TODO список.

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition by: Lyssa Adkins

После этого я вспомнил, что так и не прочитал:

Agile Coaching by Rachel Davies, Liz Sedley

И сразу вспомнилось, что и новое нужно почитать тоже:

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation By: Jez Humble; David Farley

Agile Software Development: Best Practices for Large Software Development Projects (дорогущая книженция судя по амазону)

Enterprise-Scale Agile Software Development (Applied Software Engineering Series)

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

Шутки, шутками - а план развития на год получился неплохой.

Внимание - что это такое?

2010-08-22T20:23:00.003+04:00

Всегда задумывался - что такое "внимание"? Спрашивал людей, что значить "быть внимательным"? Мне отвечали... Ну... Это когда проявляешь интерес к людям. А что это значит? И тут происходил ментальный взрыв, и никто не мог объяснить.

А вот случайно обнаружил для себя английское слово - thoughtful:

thoughtful - always thinking of the things you can do to make people happy or comfortable

После этого я прозрел! Внимательный - это означает "думающий о других". И у меня встало всё на свои места. Ведь и действительно, такие вещи как "внимание", "проявление интереса" и т.п. лишь следствие внутреннего процесса. То есть это внешнее проявление чего-то, что происходит внутри. "Внимание" - это существительное, в НЛП для этого есть термин - номинализация (процесс превращается в существительное). А основа этому есть процесс мышления внутри нас. А "думать о других" и есть этот процесс. И тут я всё понял!

Очень приятный инсайт.

PMI vs Agile

2010-08-19T21:30:00.002+04:00

Антиаджайловские настройения воинстующих PMI-истов переровсли в явную конфрактацию.

http://pdu.pmi.org/features/agile/agile.html - съёмка с поля битвы.

Новые книги от Символ-плюс

2010-08-19T18:50:00.005+04:00

Заказал книжечки, жду с нетерпением:

97 этюдов для архитекторов программных систем

Идеальная архитектура. Ведущие специалисты о красоте программных архитектур

ПРОШИВКА ДЛЯ МОЗГОВ

2009-12-07T00:37:00.002+03:00

Февраль 2010! 1 час промывания мозгов!

ПРОШИВКА ДЛЯ МОЗГОВ
Безшабашные практики вытягивания проекта из ... для хлюпиков, карьеристов и лидеров.

Надоело вкалывать? Начни получать удовольствие!

Бонус! Вы сможете улучшить свою сексуальность!!!

Когда? Где? Кто? О чем? А мне пять киллов!
Ищите в январе подробности своей гениальности! :)

PS. Для танкистов - в январе опубликуем адженду и где будем проводить встречу. Будет он-лайн трансляция. Мы рады будем ответить на все ваши вопросы!

Новый сайт - Agile Guru!

2009-11-27T17:44:00.002+03:00

Коллектив бесшабашных практиков и философов в сфере ИТ решили создать общий ресурс для своих битв и идей! Приглашаю вас подключиться к ресурсу и вносить/выносить доброе-полезное и светлое!

http://agileguru.ru

Individuals and interactions over processes and tools

2009-10-29T23:29:00.000+03:00

Сегодня я хотел бы рассказать, какими убеждениями руководствуется аджайлист в различных ситуациях и как они помогают быть ему эффективней, а команде успевать в срок производить качественное ПО. Простому человеку и вотерфолщику преимущественно убеждения и ценности навязаны телевидением, школой, институтом, семьей и рабочим коллективом. Убеждения складываются стихийно и не контролируются, а отсюда много недоразумений, несбывшихся ожиданий и т.п. Аджайлист же, чтобы повысить свою эффективность, получать удовольствие от работы и участия в проекте воспитывает в себе "правильные" убеждения. Основу этих убеждений заложили 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: ссылка

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

2009-10-27T22:03:00.000+03:00

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

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

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

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

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

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

Паттерн "@"

2009-10-25T20:21:00.000+03:00

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

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

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

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

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

Time Management & Agile

2009-10-05T16:44:00.003+04:00

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

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

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

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

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

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

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

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

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

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

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

2009-10-05T02:31:00.003+04:00

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

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

5G

2009-09-13T22:21:00.002+04:00

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

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

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

Денис, 5G

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

2009-08-22T17:43:00.001+04:00

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

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

Agile Guru

2009-08-22T14:53:00.002+04:00

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

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

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

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

Kanban vs. SCRUM

2009-08-21T20:42:00.006+04:00

Запись встречи: 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. И вообще мне усматривается, что менеджмент, как средство управления процессом (придумать документы, поставить практики, мотивировать людей в разборках тет на тет), а не продуктом, исчезает. То есть практика Канбан и Лин делает так, чтобы менеджмент процесса убрать за счет способности команды стопорнуть процесс и его улучшить, как только обнаруживается дырка. Что очень хорошо в канбан видно. Просто форсируются изменения как только обнаружены дырки процесса.

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

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

2009-07-05T19:18:00.000+04:00

Мэри Поппендик, 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 судья процессов

2009-06-24T01:59:00.003+04:00

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

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

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

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

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

2009-06-20T12:51:00.001+04:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2009-06-15T01:20:00.004+04:00

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

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

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

2009-06-11T01:32:00.003+04:00

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

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

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

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

2009-06-08T11:24:00.004+04:00

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

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

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

2009-05-29T12:57:00.005+04:00

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

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

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

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

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

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

2009-05-27T22:52:00.004+04:00

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

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

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

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

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

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

2009-05-25T13:09:00.003+04:00

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

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

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

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

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

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

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

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

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

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

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

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

2009-05-21T16:12:00.004+04:00

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

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

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

2009-05-16T17:58:00.005+04:00

public interface Null
{
}

internal class NullWord : Word, Null
{
}

if(word is Null)

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

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

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

100% Coverage Driven Design (CDD) - борьба с тухлым кодом

2009-05-16T15:52:00.026+04:00

Всем известно, что для качественного ПО покрытие должно быть более 70%. Я не знаю, кто это придумал и причем тут качество, но мне не понятно какая польза от этой цифры. Ещё смешнее слышать, как менеджеры привязывают покрытие к качеству. Если рассуждать в плоскости менеджеров, что и на мелководье и рак рыба, то этого качества конечно же для успокоения самолюбия менеджера достаточно. Но истинные войны света должны понимать, что на этом качество не останавливается... Качество кода - это целая культура разработки, в которую вовлечены клиенты, разработчики, тестировщики и много других людей. Но об этом я уже писал неоднократно, а сегодня остановлюсь на новом подходе. Подходе дающим ещё один мощный инструмент разработчику (ни менеджеру, ни тестировщику) для написания качественного кода.

Я же хочу раскрыть другую замечательную вещь, которая повысит качество кода во много раз. Один нюанс - вам придётся делать 100% покрытие :)

Эту идея пришла во время парного программирования с Кириллом Медведевым в рамках одной из стади-групп.

Эту разработку я называл "100% Coverage Driven Design" (или сокращённо CDD). Суть этого подхода есть сложение TDD, общего подхода написания тестов (ключевая фраза здесь - TestLast) и инструмента покрытия кодом.

Напомню цикл TDD:
1. Пишем тест (формализуем ожидания от будущего кода)
2. Реализуем код
3. Рефакторим

В "100% Coverage Driven Design" цикл такой:
1. Тест
2. Код
3. Рефакторим
4. Добиваемся 100% покрытия

Какие бонусы даёт такой подход
1. Все бонусы TDD
2. Вы всегда контролируете, что ваш код используется и нету лишнего, мертвого, того кода, который будет тухнуть из-за дня в день. Покрытие будет следить, как только что-то лишнее появляется и не используется - сразу выкидываем.

Возникает вопрос. А что делать с тестами, которые устаревают. Ведь их с помощью покрытия нельзя выявить, а тем более сказать что код, который покрывается устаревшими тестами уже начинает потухать. А решение простое - смирение. Если тест устарел, то первым делом он начинает из зеленого превращаться в красное. И вы тут же решаете, что с ним делать. В красное он может превратиться по множеству причин. Но если одна из причин - устаревший и ненужный тест. Мы его удаляем. Запускаем Code Сoverage и проверяем, где произошли смещения от точки 100% покрытия.

Покажу на маленьком примере. С помощью TDD цикла создали библиотечку. Проверили её покрытие и выяснилось не 100%. Начинаем разбираться и видим, что появился тухлый код. Сначала комментирую тухляк, а потом лопатой все убираю.

Успешно справившись с продуктами собственной жизнедеятельности (удалив тухлятину), я сталкиваюсь с автогенерённым тухляком:

Мне приходиться напрячь мозги и понять, что components объект никогда и не используется! Такое открытие позволяет мне удалить столь запутанную тухлятину тоже.

Результат не заставляет ждать. Идеально чистый код! Я с уверенностью продолжаю дальнейшую разработку.

Теперь немного GUI-шного, про разработку через TestLast и как техника рефакторинга приводит ухудшению Code Coverage.

1. Конечно же, когда добавляется новый функционал, то используем TestFirst:

public void MainForm()
{
     SetUpClass.PrepareTestFile();

     var form = new MainForm();
     var mocks = new MockRepository();

     var dialog = (OpenFileDialog)mocks.CreateMock(typeof(OpenFileDialog));
     Expect.Call(dialog.FileName).Return("filename.ew");
     Expect.Call(dialog.ShowDialog()).Return(DialogResult.OK);
     mocks.ReplayAll();

     form.openFileDialog = dialog;
     form.MenuItem_Open(null, null);

     mocks.VerifyAll();
     Assert.AreEqual(2, form.dicGridControl.Count);
}

2. Реализуем функцию

public void MenuItem_Open(object sender, EventArgs e)
{
     if (openFileDialog.ShowDialog() == DialogResult.OK)
     {
         Dic dic = new Dic();
         dic.Load(openFileDialog.FileName);
         dicGridControl.Bind(dic.ToList());
         }
}

Покрытие: 100%

3. Проводим рефакторинг Replace Nested Conditional with Guard Clauses (кстати, мой самый любимый)

public void MenuItem_Open(object sender, EventArgs e)
{
     if (openFileDialog.ShowDialog() != DialogResult.OK)
         return;

     Dic dic = new Dic();
     dic.Load(openFileDialog.FileName);
     dicGridControl.Bind(dic.ToList());
}

Покрытие: 97%.

Проведение рефакторинга привело к снижению покрытия. Мы столкнулись с усложнением кода с точки зрения поддержки покрытия. Но в тоже время облегчили с точки зрения понимания, сделав линейность выполнения основного блока. То есть основной блок в первом примере разбился на два: проверка условия выполнения и основной код.

В общем снизили покрытие. Что делать. Я останусь верным принципам рефакторинга и оставлю проверку входного условия. Но я должен дотянуть покрытие до 100%. Тут на помощь приходит старая практика Test Last. Если раньше, эта техника была вызвана сообращениями разработки тестов для уже разработанного кода, сейчас эта техника изменит своё предназначение. Используя эту технику я подтяну покрытие до 100%.

После мелких рефакторингов я добавил второй тест, используя технику TestLast:

[Test]
public void MainFormCancel()
{
     Expect.Call(dialog.ShowDialog()).Return(DialogResult.Cancel);
     mocks.ReplayAll();

     form.MenuItem_Open(null, null);

     mocks.VerifyAll();
     Assert.AreEqual(0, form.dicGridControl.Count);
}

Результат: покрытие 100%

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

Другой нюанс, если я пойду дальше и подстрахуюсь от проблем с файловой системой:

public void MenuItem_Open(object sender, EventArgs e)
{
     if (openFileDialog.ShowDialog() != DialogResult.OK)
          return;

     try
     {
          Dic dic = new Dic();
          dic.Load(openFileDialog.FileName);
          dicGridControl.Bind(dic.ToList());
     }
     catch (Exception ex)
     {
          MessageBox.Show("Error: Could not read file from disk. Original error: " + ex.Message);
     }
}

Этот кусочек кода пишется даже без теста легко. Я нарушил правило TDD и добавил строчку кода без теста. И кара настигла меня моментально - покрытие упало, плюс протестировать статический метод MessageBox.Show - это целая проблема (ни моки, ни что либо другое здесь не поможет - в морг). А представьте сколько проблем мы делаем, когда разрабатываем более менее серьезное приложение?

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

Вывод: Данную методику изобрёл буквально вчера. За вчера её опробовал, очумел от эффективности и продолжаю праведно работать по ней. Методика 100% покрытия стала для меня точно так же как запускать юнит тесты. Стала родной и без неё уже свет не мил. Теперь не то чтобы у меня тесты есть согласно TDD, но и код очищается от мертвого кода очень удобно и легко. Теперь я не только уверен в функционировании (этому мне помогает TDD), но и что код чистый (этому помогает 100% покрытие). В общем я доволен как маленький ребёнок от такой простои и в тоже время мощной игрушки. Сейчас нарабатываю опыт от применения, о чем буду делиться и буду ждать последователей, кто готов проверить предложенный метод.

Скобочки для if в одну строчку

2009-04-30T19:58:00.008+04:00

(DRAFT)

Здесь расскажу про такое заблуждение как обрамление фигурными скобочками оператор if с одним простым действием.

if(condition)
{
return 0;
}

вместо

if(condition)
return 0;

Мифическая причина идущая от Стива Макконнела (Code Complete). К ней все обращаются, когда начинают мне её называть. Такое ощущение, что это единственная книга, которую горячие стороники скобочек читали :) Кстати, советую тогда заглянуть на http://agileconsulting.ru/wiki/Books - тут множество книг о качестве кода.
1. Защита от дурака, что кто-то в будущем добавит строчку и сделает баг в программе.

А теперь демистификация скобок. Итак, почему скобки это пережиток:
1. Отступы явно указывают на логический блок из одной строки.
2. Отступы проставляются автоматически средой разработки.
3. Тесты не дадут написать код неправильно. У вас нету тестов? Тогда улучшать качество кода начали не от туда :)
4. Скобки кушают 2 линии
5. Мы бизнес-разработчики, и должны свести к минимум все инженерные ухищрения. Ведь в любом языке фраза: "если наступит утро, то я проснусь" не содержит скобок.

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

Если вы используете современную IDE и TDD и утверждаете, что скобки полезны по названой мифической причине - просьба дайте конкретный пример. Иначе рассуждаем о коне в ваккууме.

Вебкасты про Agile

2009-04-29T01:20:00.000+04:00

http://www.autumnofagile.net/
http://www.summerofnhibernate.com/

«Agile по-крупному!» — ВИДЕО

2009-04-25T20:25:00.002+04:00

Во вторник, 21 апреля, прошла аннонсированная ранее встреча сообщества AgileRussia.ru, озаглавленная «Agile по-крупному!». Изначально тема заявлялась, как разбор сложностей Agile в крупных командах и проектах, обсуждение тонкостей масштабирования, ведь все, что выходит за максимальный размер стандартной Agile-команды в 9 человек, уже требует специальных подходов.

«Waterfall2Agile — Agile для Большой Waterfall компании: нужен? как и что внедрять?» — это пришли ребята из широкоизвестной компании «C», они детально описали свой цикл разработки и структуру проектного управления своего Большого Продукта (достаточно заметить, что цикл тестирования релиза занимал у них 18 месяцев), пояснили возникающие проблемы, и запросили у сообщества предложений по улучшению процесса — включая как Agile-практики, так и технические/инструментальные решения.

«AgilePostmortem» — это была посмертная ретроспектива распределенного Agile-проекта, интересного высокотехнологичного стартапа, к сожалению, «не дожившего до весны».

Оригинал: http://team.custis.ru/2009/04/agile-agilerussiaru.html

Строки-ресурсы или магические строки (draft)

2009-04-21T23:12:00.007+04:00

В продолжение предыдущего поста возникли логичные вопросы. А что делать с
String.Format(StringResourse.TotalString, total)? Кстати, вам легко понять это? А я ещё не начал перечислять минусы :)

Итак, начну с переносом строк в ресурсы. Начнём сначала. Какой смысл был у строки? Если смысл кокатация строчек. То первичный вопрос - накой козе баян? Зачем делать форматирование строке "Всего: " + total + " штук"? А потом повышаем косвенность, закидывая строку "Всего: {0} штук" в ресурсы?

В отличии от string, StringBuilder, String.Format назначение ресурсов в предоставление вариационности. Вариационности в способе отображения, а для строк это либо другой язык, либо другая система отображения значений (пример: дата, дроби и т.п.). Вы часто имеете дело с мультикультурными приложениями? :) Да и там чуток по другому делают. Причем не на стадии программирования, а это свойство относится к всем процессу разработки. Другой нюанс - некоторое множество сообщений, которое на каждом углу программы используется. Некое постоянное магическое множество. Типа "Всего: {0} руб.". Тут ещё можно подумать. Но вредно. Для этого есть специальные классы. Которые должны сразу выплёвывать такие строчки и мы не должны волноваться как это получилось.

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

А теперь какие бонусы мы получаем от такой системы (не для варианта мультикультурной платформы, а для нашей простой разработки)
Бонус 1. Попробуйте посчитать количество ваших действий, чтобы внести изменение в вашу строчку. Ужас на крыльях ночи. И это только ради того, чтобы внести маленькое исправление в строчку. Боюсь если вы уделяете столько внимания строчкам, то время на полезный код у вас не остаётся вообще :) Мне намного легче править то, что я вижу непосредственно.
Бонус 2. Даже если не менять. Чтобы читатель мог понял, что тут написано и что ожидается, вам прийдётся скакать как минимум по двум файлам. Кстати, поиск таких вещей и мест их потребления - это другая тема. А разговор идёт не об одной сущности, а просто об одной строчке кода. Да к тому же ещё среди кучи строчек вам нужно ещё вашу. Упасть не встать.
Бонус 3. Я молчу, насколько это эффективно программируется по сравнению с простой строчкой кода :)
Бонус 4. Нарушение ценностей и принципов Implementation Patterns и Simple Design.
Бонус 5. Программирование ради неопределенного будущего. Какой то технический

Задайте себе вопрос - что вы чаще меняете: кучу сообщений без привязки к месту использования или конкретное сообщение в конкретном коде. И из этого делайте вывод. Если вы днями программируете текст в ресурсном файле. То ресурс это ваше все. А если вы пишите код программы и добавляете в него сообщения - то вывод очевиден. Что данные (а строка это данные) должны быть в непосредственной близости от места потребления.

Следующий вопрос - Magic String. Звучит очень странно. Но давайте вернёмся к аналогии. У нас есть Magic Number. Пример: 12. Конечно, любой скажет, что нужно напрячься, причем очень сильно, чтобы найти СМЫСЛ этого. Поэтому СМЫСЛ мы заключаем в название переменной int interest = 12. Ещё раз подчеркиваю, чтобы не искать смысл числу 12 по крупицам в коде окружающем это значение мы вводим переменную, в название которой перенесли смысл числа. В нашем примере 12 означает interest (процент). Теперь взглянем на наши Magic String:

string errorMessage = "Произошла ошибка. Повторите операцию";

Вот скажите, а чего вам не понятно в исходном сообщение? Смысл? Там же по-русски написано :) Я понимаю, что фраза "@#$#@$^%$" может запутать и нужно ввести поясняющую переменную. Но в примере то чего сложного?

Теперь пошли нюансы Magic String:
Бонус 1. Переменная, у которой область видимости максимум круглые скобочки в качестве параметра вызова в MessageBox, почему то становиться видна всей нашей функции. Как будто без этого мало строчек кода.
Бонус 2. При чтение кода нам нужно прыгать сначала к тексту применения, а потом к определению. Хотите скачи - идите на ипподром.
Бонус 3. Некоторые умельцы ещё и форматирование туда запихивают. Мозг выносится напрочь, когда обнаруживается код типа:
string totalString = "Всего: {0} штук";
....
String.Format(totalString , total);

Итог, использование Magic String и ресурсов в большенстве своём плохой и неоправданный стиль программирования. Но когда же их исползовать? Ресурсы - когда вариационность текстовой составляющей (языки, отображение и т.п.), Magic String - ну когда одно и тоже в многих местах или ну совсем длинная или непонятная строчка :)

String vs StringBuilder

2009-04-20T21:13:00.029+04:00

Сегодня в microsoft study-group обсуждали стринг. Собственно эта тема всех интервью - что нужно использовать для "оптимального" хранения строчек? И все хором говорят - используем StringBuilder. А на вопрос, что использовать для кокатации строк - String.Format. И все напрочь забывают, что мы программируем не для оптимизации, а для того, чтобы поддерживать код и развивать. То есть делать код понятным даже первокласснику, что не скажешь про "профессионально" оптимизированные без надобности куски творчества.

Так вот про вопросы интервью. Я с ними полностью не согласен. Люди! Не то чтобы на пороге 21 век, он уже дома! Преждевременная оптимизация - зло и порождает ДОРОГОСТОЯЩИЙ код! Качественный код приравнивается к самодокументируемому коду. Оптимизация здесь не рассматривается - она здесь не обсуждается. Так как мы бизнес-разработчики, а не любители оптимизнуть что под руку попадёт. Бизнес-разработчик пишет код, где каждая строчка отражает НАМЕРЕНИЕ, а не хитро-вычитанные фичи платформы :)

Начну развеивать заблуждение с конкатацией через String.Format. Цель функции String.Format форматирование строки, а не конкатация. То есть привращать 1 в 001,00 например. С точки зрения качественного программирования запись с целью конкатации String.Format("Total: {0} dollars", total); выглядит настолько неэкономично, что ужас. Конечно микроскопом можно гвозди забивать :) У некоторых это даже получается. Во-первых, чтобы понять это, нужно чтение слева-направа заменить на скачкообразное чтение с актвацией ячейки памяти в моём мозгу. Во-вторых, добавление новых переменных вызывает дополнительное напряжение - теряем время, за которое нам платят деньги. В-третьих, чтобы добавить новую переменную - мне нужно делать 2 (!!!!) изменения.

Исходя из этих соображений. А мои соображения основываются на принципах Implementation Patterns & Refactoring и трёх простых ценностях (коммуникация, простота и гибкость). В данном случае используем самую первую и самую важную ценность - коммуникация. Напомню: Коммуникация (communication) - разрабатываемый код должен явно отражать намерение создателя. Этот принцип подчёркивается и в рефакторинге. Так вот начиная читать строку String.Format - я чётко фиксирую себя на мысле "форматируем"!, а когда плюсиками - то конкатируем. Просто и разумно.

Ужасная конкатация через форматирование: String.Format("Total: {0} dollars", total);
Поэтому намного лучше и приятней: "Total: " + total + " dollars";
Хотя, перед PHP код снимаю шляпу: echo "Total: $total dollars";

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

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

Итак с точки зрения качественного кода (а это код, которых легко читать):
StringBuilder - вещь хорошая, но его стоит применять, когда мы подходим к объекту как механизму с накапливанием значения, а результат будет снят как сливки намного дальше от кода наполнения. То есть в одном месте явно накапливаем (сложный код... преимущественно бывает в циклах), а в другом вы забираете результат (особенно часто встречается со словом return ;).
String.Format - для форматирования кода, но не конкатации. Причем в отличие от String.Builder результат забирается в месте форматирования.
+ (любимый плюсик для строк) - приятный и дешевый способ конкатации

PS. "Экономично", "дорогостоящий" и "дешевый" читать с точки зрения разработки и поддержки. Меньше тратим время, чтобы "врубиться", значить дешевле. Время - деньги.
PS2. А оптимизация делается на заключительной стадии. Ключевое слово: профайлер.

Что такое Agile?

2009-04-13T15:33:00.010+04:00

Часто задается вопрос, что такое Agile или XP. В чём ключевое отличие от других подходов. Ответ очень простой. Agile - это культура разработки, включает гармонично подобранные ценности, принципы и практики. Мета-методология, которая определяется входящими в неё методологиями. Эти вещи уже проверены по отдельности различными командами. Но в совокупности они порождают нечто большее. Синергию. Другие подходы ориентируются преимущественно на практики, иногда на принципы. Про ценности же забывают напрочь. То есть на то, что человека отличает от болтика.

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

Натянутые попытки использовать ряд практик, без комплексного подхода, приведёт к неудаче. И это нельзя назвать работаю по Agile. Потом неудачники с радостью и гордостью рапортуют о своих неудачах. Кстати меня удивляет, почему он обсуждая только практики делает столь поспешные выводы. Полностью забыв про принципы и ценности. Да и существует 1000 способов делать неправильно, а постарайся сделать так, чтобы получилось!

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

Да... а для работы с ценностями можно использовать практику - Team Value Sync-up Practice, о которой я писал ранее.

Кстати, в тему цитата Кент Бека (link):

There is 3 legs on the stool: practices, values and principles and I think people who are successful applying XP are paying attention to all 3. This gets back a little bit to some of my disenchantment with the direction of agile development in general, people are now asking the question: "How am I going to do agile development?" and agile development isn't a thing you do, it's an attitude, it's a set of personal values about responding to the real world, being open to the information that is there and being willing to do something about it.

That is agility. Yes, there is a lot of practices that come out of that but to me that is where it starts, it's this attitude. If somebody understood a bunch of practices and tried to do them, you could do agile development without being agile and it's a disaster because you're acting out of harmony with what you really believe when you do that.

И в заключение: весь мир делится на два лагеря - 1) те кто работает в новом стиле и 2) те кто работает постаринке. Честно говоря я рад, что вторых больше. Потому что именно вторые оплачивают мою работу :)

Эмоциональный интеллект

2009-04-11T11:49:00.018+04:00

Уже сложно найти сайт и специалиста в области менеджмента, которые не говорят о важностях эмоционального интеллекта применительно к проектной деятельности. Я спрашиваю их - а делать то чего? Разводят руками или начинают говорить о красивых абстракциях и грандиозных результатах. Но я опять не понимаю. Тогда говорят, это сложный вопрос, а тебе стоит найди правильного человека для своей команды, он чувствует это всё. А другие советуют почитать Кови или книгу о сабже, после этого ты и поймешь.

Мне кажется можно организовать все проще. Основная идея - потенциал команды складывается из ментальных и эмоциональных усилий команды. IQ + EQ. Если с IQ понятно, то вот как прокачивать EQ?

Предлагаю простую практику, которая начнёт прокачивать ваш эмоциональный интеллект и интеллект вашей команды. Эта практика послужит мощным толчком в построение истинных командных отношений.

Исходные материалы для развития эмоционального интеллекта:

Делаем простой уголок, который потом будем ставить себе на стол. C одного листа А4 вырезается 5-6 полосок, таким образом получаем 5-6 уголоков с листа.

И в итоге получаем тренажёр для эмоционального интеллекта:

Вот и инструмент готов.

Как это работает? Перед тем как что-то делать, вы садитесь и чувство-думаете:
Я ЧУВСТВУЮ ________, ПОТОМУ ЧТО __________

Чувства: РАДОСТЬ, ГРУСТЬ, СТРАХ, РАЗДРАЖЕНИЕ. Других недопустимо. Важно объяснить себе, почему я это чувствую. Важно называть минимум 2 чувства. В "ПОТОМУ ЧТО" немного напрягшись нахожу причину своего чувства. Понимая причину, я повышаю осведомленность. Ибо только зрелые личности испытывают чувства и осознают причины их побудившие. Таким образом мы повышаем осведомленность как на уровне EQ, так и IQ. А дальше либо миримся с причинами, то есть забиваем на свою осведомленность, либо решаем возникшую проблему :)

Теперь о правилах. Они простые, как всё эффективное и работающее:

1. Перед каждой активностью говорить себе "Я чувствую..."
2. Минимум 2 чувства
3. Ставить уголки на стол, чтобы другие видели
4. Если кто-то интересуется "почему" - отвечать честно.
5. Запрещено врать и убирать под давлением.

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

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

Жду ваших отзывов о внедрение :)

Об этих и других практиках развития эмоционального интеллекта слушайте в подкасте Agile Study Group: ссылка сообщества Study Group.

PS. Практика называется "Вход" (Check-in). То есть я ментально и эмоционально вхожу в работу.

PS2. Alexander Lipatov: У меня в аське частенько раньше спрашивали что-то вроде Как дела? Как настроение? :) Я теперь отвечаю: я чувствую радость, что на улице хорошая погода и чувствую раздражение, потому, что на работе много мелких дел, которые никак не хотят заканчиваться

govnokod.ru

2009-03-15T14:36:00.001+03:00

Срочно всем на http://www.govnokod.ru/.

Без слёз не взглянешь :)

5th value to Agile Manifesto "Craftsmanship over crap"

2009-03-12T11:38:00.007+03:00

Agile Manifesto является путеводной звездой, которой руководствуются корабли Agile команд в достижение целей. Дополнительно к этому, спустя 8 лет, Роберт Мартин (дядя Боб, автор книги PPP, которая обсуждается в стади-групп Design Pattern Study Group и один из соавторов Agile Manifesto) создал новые принципы. Принципы мастерства - которые показывают, как нужно грести :)

Я считаю, что эти принципы более конкретно отвечают на вопросы организации команды, культуры разработки и качества продукта. Поэтому маст хэв.

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

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

http://manifesto.softwarecraftsmanship.org/main

© 2009, the undersigned.
this statement may be freely copied in any form,
but only in its entirety through this notice.

Система бонусов как механизм демотивации

2009-03-03T11:28:00.010+03:00

Если спросить программиста, что его мотивирует, то он честно ответит: "достойная зарплата, бонусы, изучение новых технологий, обучение, засылка на тренинги и семинары, возможности карьерного роста". Звучит достойно? Вот только, где здесь хотя бы слово о работе и заинтересованность в результате??? Ах, да иногда говорят "интересный проект" - но это о работе, а не о мотивирование :)

Паттерн: Мотивирование
Назначение: Понижение качества труда, снижение заинтересованности, эмоциональное увольнение.

Описание: F -> R -> B, где
F - усилие, которые оказывает работник на работе
R - результат, который ожидается от человека
B - если результат хороший, то начальник платит бонус

Суть этой формулы такова. Что только глупый человек не оптимизирует процесс. Люди настолько изобретательны, что лишнее выкидывается. Получаем формулу: F -> B, а R (результату) здесь не место - зачем на него тратить время? :)

То есть. Если вы любите мотивировать работников различными системами бонусов, дополнительные материальные вознаграждения или даже похвала с барского плеча. То вы готовите себе могилу. Краткосрочное получение выгоды приучит участников ориентироваться не на результат, а как сделать так, чтобы получить бонус.

ТО ВНЕШНИЙ СТИМУЛ (МОТИВИРОВАНИЕ) РАЗРУШАЕТ ВНУТРЕННИЙ ИМПУЛЬС (МОТИВАЦИЮ)

Мотивация, в отличии от мотивирования, свойственно человеку. Мы созданы по подобию Бога. А Богу свойственна работа, так как она определяет его бытиё. Ему только нужно довериться, дать ответственность, дать возможность принимать решения.

Кстати, практикуется очень хорошая практика у менеджеров. Мотивировать работников за их же деньги. Как это делается? Очень просто. Схема такова. Пусть у вас есть 1000 рублей для человека. Менеджер говорит, что 800 рублей будет зарплата, а раз в квартал будет бонус в размере 200 рублей x 3 = 600 рублей при условии, если будешь хорошо работать. Выходит, что МЕНЕДЖЕР НЕ ВЕРИТ, ЧТО ЧЕЛОВЕК БУДЕТ РАБОТАТЬ! Получив такую схему оплаты труда человек чётко понимает формулу F->R->B и оптимизирует работу не исходя из ориентации на результат, а ориентируется на достижение бонуса. Не говоря о чувствах человека, когда его сосед получил бонус, а он нет. В результате мы получаем: команду зависливых людей, ложь, подлог, забивание на цели проекта и команды, текучку и провал.

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

Что делать? Думайте сами :) А можете спросить у команды, раз вы уже сделали правильный шаг :)

Или зовите меня, будем вместе проводить профилактику :)

PS. Другой вопрос. Если у вас есть лишнее бабло, и вы решаете так от него избавиться в надежде поднять лояльность сотрудников. Бростьте это неблагодарное дело. Просто сделайте зарплату выше средней по рынку. Меня бы разбирало чувство собственной значимости, когда каждый месяц я за работу бы получал больше, чем средний работник на рынке... Поголовную безусловную 13-ую зарплату никто не отменял, как ежегодная прививка для поднятия настроения :) Но тут я ещё до конца не продумал :)

Адаптивная точка зрения

2009-03-01T01:21:00.001+03:00

Это один из последних рефреймингов, который я проделал над собой (никакого нлп, просто рассуждал сам о себе), почему мне иногда хочется в форуме пофлеймить с народом :)

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

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

Зачем Story Points?

2009-02-27T18:03:00.003+03:00

В дополнение к http://denismiller.blogspot.com/2008/12/story-points-vs-ideal-hours.html появилось несколько вопросов. Редакция отвечает :)

Мой посыл такой. Требования имеют разный размер. От большого до маленького. В зависимости от игры декомпозиции. Моё предложение и единицы измерений выбрать для разных уровней декомпозии свои. То есть

User Story - условная единица своя - Story Point
Tast - условная удиница своя - Task у.е. в простонародии часы идеальные :)

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

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

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

Как расстояния. Между городами в киллометрах. А между точками на листе в сантиметрах. Просто нам уже вдолбили в голову что соотношение между ними 1 к 100000. Так и размеры sotry point очень хорошо соотносятся с часами. Только нужно набрать статистику :)

А когда статистика приобретает глобальный масштаб - её называют стандартом :)

1. Почему в пирамиде фичи продукта выше User Story?
Должно быть наоборот - на основе User Story вырабатываются конкретные фичи. Собственно User Story нужны именно для того чтобы от общего представления о продукте с помощью конкретных описаний применений перейти к фичам продукта.

2. По ссылке "Об agile по-русски: User Stories" описаны фактически Use Cases, а не User Stories.

User Stories = история пользователя. Я как пользователь хочу пользовать ту или инную штучку. User Story маркер-напоминалка, которую можно расписать до Use Case.

Фича это сумма вариантов использования чего-то. Поэтому и выше поставлено.

Можно фичу называть User Story но очень крупную :) Которая требует декомпозиции. Кстати, User Story так же бьются на юзер-стори или таски. Критерий классно подсказан Сергеем Назаренко в одной из стади-групп по Agile: пока юзер-стори имеет бизнес-значимость - это юзер стори, как потеряла в результате декомпозиции - стала таской :)

Задавай ещё вопросов, попробуем найти истину :)

Обязанность Agile-коучера: фасилитация

2009-02-25T15:06:00.005+03:00

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

Было бы здорово получить список тех практик, которые должен выучить коучер, а потом предложить команде. Вот давеча нашёл сайт, на котором собраны практики фасилитации :)

Facilitation comes from the latin facile, which mean easy. In fact, the role of a facilitator in a group setting is to “make things easy”. It involves planning, organizing, and setting or supporting rules and goals within such groups. It is my goal here to collect and share many of the tricks, techniques and practices that facilitators use in their work.

Более подробнее читайте на сайте: http://facilitationpatterns.org

А inquisitor_rus подсказал суперскую статью - http://ru.wikipedia.org/wiki/Consensus_decision-making

Правильные разработчики

2009-02-24T11:54:00.008+03:00

Интересный термин предложен Сашей Орловым - "правильные" люди. Я конечно у него спросил, что это значить. А пока он не ответил попытаюсь порассуждать.

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

Во-вторых, а как же набрать народа в свою команду? Честно говоря лучшие компании мира дают свои рекомендации. см. процесс рекрутинга в Microsoft. Они ищут людей, которые проявляют определенный набор качеств и точка. "Правильный" он, или "неправильный", да какая разница. Главное, чтобы он хорошо интегрировался в контекст! А контекст как раз задаёт компания. То есть "правильность" определяется лишь контекстом её оценки. Если компания успешна в ней есть механизмы находить людей, которые так же могут думать так же как ребята из компании. И это их локальная "правильность".

В-третьих. Чаще оценку делают менеджеры своим разработчикам - а насколько человек "правильный". Эта правильность конвертируется в бонусы, карьеру и т.п. Читайте книгу на тему "карьеризма" и можете приравнять правильность к этому слову. Кстати вопрос - а менеджеры считают себя правильными?

В-четвертых. Не понятно какая цель приследуется разделив всех людей на правильные и неправильные. Разделить команду на хороших и плохих. Вместо того чтобы людей объединять менеджер вводит искусственное поле напряженности. Даже если он это не высказывает но принебрежительный взгляд на одного разработчика и часовые беседы с другим сделают своё дело. Сформируется потенциальное поле "правильности". Народ будет осозанно и неосозанно либо одобрять (те кто "правильные") и не одобрять (тех кого обделила барская рука). Это создаст основу для будущих конфликтов как явных, но и опасных - неявных. А ещё хуже - эта куча народу лобает ОДИН продукт. Как ребята, которые действуют несогласовано, желания, цели и чувтсва которых задеты могут сделать ЦЕЛЬНЫМ продукт. Вывод: продукт можете сразу выкидывать - качества там не будет, пока в вашей голове живёт желание оценивать и разделять.

И это только аргументы на горячую голову. Если подумать - то вообще лучше не думать :)

Что же делать? Повышать осведомлённость, присутствие, вовлеченность, стремление к целям, взаимозависимость, эмпатия и взаимопомощь. Даже слабое звено делает команду командой, а не кучкой нанятых людей. Становится вопрос, а слабое ли оно? Про силу слабых звеньев можете посмотреть в тренингах по "командообразованию" :)

Александр Орлов: Я пояснил, что говорил про правильных программистов и пояснил, что я имел в виду. Оценивать правильность программистов мне довольно легко, потому что я имел многолетнюю возможность ими руководить и наблюдать их со стороны.

И как я понимаю сделав вывод ты уже им руководствуешься. Полностью исключив возможность человеку достичь большего. Только вот так просто исходя из твоего субъективного “правильного”. Кашмар, чесслово! :)

Александр Орлов: Возможности наблюдать себя со стороны - я не имею.

Объясню. Исходя из некоторой совокупности критериев ты делаешь оценку людей. Почему ты эту совокупность критериев не можешь наложить на себя?

В общем я понял, что истина где-то рядом и написал:

Денис: Жаль. Только началось то, что настоящим командам не хватает… Открытые чувства и эмоциональный интеллект…
Любой вопрос можешь задавать мне - я отвечу.

На что получил странный ответ:

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

Я так и не понял, как и кого я вывел на чистую воду, и у кого недостаёт эмоционального интеллекта :)

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

Скажи, что тебе задело и я скажу, что я подразумевал :)

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

Кстати по поводу зрелости хорошая информация лежит здесь: http://denismiller.blogspot.com/2009/02/blog-post.html

В общем я не понял почему Александр решил "Вот на этом предлагаю дискуссию и завершить. Этот сайт не для обсуждения моей личности, копания в моей жизни или игры в “убей автора”. Мне это не интересно. Full stop.".

В общем, я полностью потдеживаю работу Александра, но считаю её можно улучшить выкинув этот термин - "правильные" разработчики :)

Принципы здравого менеджмента

2009-02-24T11:33:00.004+03:00

Очень поучительный список принципов для менеджера. Каждый пункт требует отдельного раскрытия я думаю. Мне очень понравился четвертый принцип :) К пункту пять я бы ещё добавил, что и хорошие вещи протухают, если к ним не обращаются :)

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

The Principles of Common Sense Project Management

1. The process of Project Management is basically the same on EVERY project; it is the intangibles that make the difference in the success of the project.
2. LEADERSHIP is not synonymous with Project Management.
3. CREATIVE PROBLEM SOLVING is essential to Project Management. The SIMPLEST answers are usually the best one.
4. If you are not part of the SOLUTION, then you are part of the PROBLEM.
5. Bad news is not like an expensive bottle of wine; it DOES NOT get better with age.
6. Communication should never be MANAGED from stakeholder to stakeholder.
7. Of all of the project constraints … TIME controls the Cost, Quality, SOW (Statement of Work) and Customer Satisfaction.
8. It is better for your project, if the TECHNICAL EXPERT is not the Project Manager.
9. Your TEAM is the most important resource you have on a project.
10. Documented Lessons Learned are MANDATORY after the closure of a Project.

Common Sense is not common; otherwise more people would have it !!

Copyright © 2009, A.Sloan Campbell, MBA, PMP, P.Mgr, F.CIM
Additionally: if you don't have time to do it right...how will you find the time to do it over? - Tim Bidlack PMP

Оригинал: ссылка

Битва гигантов Spolsky vs Robert Martin

2009-02-23T15:45:00.004+03:00

Интересное пришло сообщение от Асхата. Гиганты программирования и гуру всего и вся столкнулись в битве за TDD и PPP.

Начало положил подкаст Scott Hanselman. Не нам их судить, но ряд цитат приведу:

Spolskyit seems to me like a lot of the Object Oriented Design principles you're hearing lately from people like Robert Martin and Kent Beck and so forth have gone off the deep end into architecture for architecture's sake.

Kent Beck: He has worked hard to become famous, but he hasn’t figured out that along with notoriety comes responsibility. He is a bright, experienced guy and certainly capable of more accurate, thoughtful, and constructive conversation.

На что ответили все мною почитаемые гуру: Кент Бек, Рон Джефрис.

В общем не понятно, почему Спольски подлил эмоционального огня. Видать его книги стали плохо продаваться. И по его выпадам видно, что он не читал книгу Роберта Мартина, и подавно Кента Бека. Жаль там очено много идей на фоне которых его эмоции просто детский лепет... Но устами младенца :)

К слову:
Роберт Мартин - человек, который собрал ребят в далеком 2001 году и они сделали AgileManifesto. Он так же автор книги про PPP. В ней кстати достаточно ошибок и приколов, которые мы очень хорошо обсудили и посмаковали над Design Patterns Study Group.
Кент Бек - стоял в основе Desing Patterns и идеи wiki-сайтов. Автор eXtreme Programming.

Развитие сотрудников

2009-02-23T15:37:00.002+03:00

Александр заметил предложил тему за развитие персонала. Но мне показалось он немного односторонне осветил этот вопрос переложив ответственность за развитие не на HR-отдел или линейного менеджера (скрам-мастера), а на самих сотрудников.

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

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

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

А развивать нужно всех - не судите и судимы не будете. А правила 40 часовой недели никто не отменял. Хотя если менеджер мне выходной оплатит. А так очень нехорошее предложение. Я бы послал такого менеджера куда подальше :) Пусть сам в выходные работает, даже под эгидой тренинга. Исключения конечно составляют Agile-тусовки за счёт компании.

Продукт - творчество командного интеллекта. А если одна часть его развивается, а другая пожизненно пребывает в зачаточном состоянии. Ведь все ребята программят и делают вклад в продукт. А как наполовину развитый командный интеллект сможет выдать качественный продукт?

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

Блин, спеллчекер нужно поставить какой-нить :)

Книги о качественном кодирование

2009-02-22T22:41:00.004+03:00

Случайно решил проверить на сафари какие книжки от Diomidis D. Spinellis. Оказалось он написал ещё две новых! Теперь у этого автора три книги, которые рекомендую для чтения:

Diomidis Spinellis. Code Quality: The Open Source Perspective. Addison Wesley, 2006. ISBN 0-321-16607-8.

Diomidis Spinellis. Code Reading: The Open Source Perspective. Addison Wesley, 2003. ISBN 0-201-79940-5.

Diomidis Spinellis and Georgios Gousios. Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design. O'Reilly, 2008. ISBN 9780596517984.

Кстати, если тема книжек пошла, то хотелось бы добавить ещё пару ссылок на тему качественного кода:

Code Craft, 1st Edition by Pete Goodliffe
Clean Code: A Handbook of Agile Software Craftsmanship by Robet Martin

Agile Software Factories by Damon Wilder Carr

2009-02-22T12:41:00.002+03:00

In this book I attempt to show the reader my experiences on projects wanting to go beyond Agile, and actually leverage Factories. The Agile approach is a natural fit in describing a process for factories (something few have fully done and I attempt to do).

To be more specific, I show my experiences in applying Agile practices in a software factory environment (mostly in the factory construction phase but also in the use of the factory) with great success. Many taking a factory approach can slide back down into a ‘waterfall’ type mentality due to the misconception that ‘factories are not iterative’. In fact they must be in almost all cases.

I will also discuss the commonalities between factories and broader ‘Lean Manufacturing’ concepts. A full example will be presented with hands-on examples. This is not so much a ‘theoretical’ book as one which explores what can be done today using the technologies available.

Also explored (in addition to much more) is the idea that Software Factories for the Agile-enabled company today will have a smaller learning curve then others in adopting factories.
---

На горизонте появилась новая книга, которая упоминалась ещё в 2007 году (но может это только реклама).
Ссылка на магазин. К сожалению пока никакой информации о книге нету. Будем следить за событиями :)

Об опыте автора на linkid.
Блог автора: здесь
Его проект на codeplex: SOA Framework for Silverlight/WCF Cross-Platform (This code is used in our five day master's class immersion in 'Domain Driven .NET using C# 3.0'.) и хорошое известного модуля статистики для Cruise Control (ссылка)

Эффективная работа с унаследованным кодом

2009-02-22T01:06:00.005+03:00

Наконец-то появился русскоязычный перевод классической книги для разработчика "Working Effectively with Legacy Code" Michael Feathers. Как написать новую строчку кода, куда её помещать, как написать тест под наследованный код. Множество вопросов - и в этой книге ответы.

Аннотация:
Учитесь извлекать максимум пользы из унаследованных систем, повышая их производительность, функциональность, надежность и сопровождаемость!
Можете ли вы без особого труда изменить код и тут же получить ответную реакцию на внесенные изменения? Насколько понятен этот код? Если вы ответите на эти вопросы отрицательно, значит, вы имеете дело с унаследованным кодом и понапрасну тратите время и средства на разработку.
В своей книге Майкл Физерс предлагает полноценные стратегические приемы эффективной работы с крупными базами унаследованного нетестированного кода. В основу этой книги положен материал, подготовленный автором к известным семинарам, организуемым компанией Object Mentor, включая приемы, которым автор обучил сотни разработчиков, технических руководителей и тестирующих программное обеспечение подчинять себе непослушные унаследованные системы.
В этой книге освещаются следующие вопросы:

* Представление о механизмах внесения изменений в программное обеспечение, включая ввод новых свойств, устранение программных ошибок, улучшение структуры кода, оптимизацию производительности.
* Перенос унаследованного кода в средства тестирования.
* Написание тестов, препятствующих внесению новых ошибок в код.
* Применение методов, подходящих для любого языка или платформы, с примерами кода на Java, C++, C и C#.
* Точное выявление мест в коде, где требуется внести изменения.
* Работа с унаследованным кодом, который не является объектно-ориентированным.
* Обращение с приложениями, у которых, на первый взгляд, нет вообще никакой структуры.

Кроме того, в этой книге представлены 24 способа разрыва зависимостей, помогающих работать с элементами программного обеспечения обособленно, чтобы сделать внесение изменений в код более безопасным.

Майкл К. Физерс работает в компании Object Mentor, Inc., занимающей ведущее в мире место в сфере предоставления услуг обучения, повышения квалификации, распространения знаний и руководства проектами по разработке программного обеспечения. В настоящее время он занимается обучением разработчиков со всего мира методам разработки за счет тестирования, реорганизации кода, объектно-ориентированного проектирования, программирования на языках Java, C++, C и C#, а также экстремального программирования. Майкл является автором первоначального варианта среды тестирования CppUnit, перенесенной на C++ из среды JUnit, а также среды интегрированного тестирования FitCpp, перенесенной на C++ из среды FIT. Он состоит членом Ассоциации по вычислительной технике (ACM) и Института инженеров по электротехнике и электронике (IEEE), а также председательствовал на трех конференциях разработчиков программного обеспечения CodeFest и OOPSLA.

Эта книга посвящена практическим вопросам эффективной работы с унаследованным кодом. В ней освещаются механизмы внесения изменений в унаследованный код, включая ввод новых свойств, устранение программных ошибок, улучшение структуры кода и оптимизацию производительности; способы переноса фрагментов кода в среду тестирования, особенности написания тестов для безопасного изменения и реорганизации кода, приемы точного определения мест для подобных изменений, а также подходы к обращению с унаследованным процедурным кодом. Кроме того, в книге на конкретных примерах кода, написанного на Java, C++, C# и C, демонстрируются способы разрыва зависимостей для работы с обособленными фрагментами кода и безопасного внесения в них изменений.
Книга адресована тем, кто имеет опыт разработки прикладного программного обеспечения и его сопровождения.

Рекомендую к изучению: ссылочка

Краткий экскурс в Agile (аудио запись, mp3)

2009-02-20T12:47:00.007+03:00

Мы с Олегом проработали около года в одной команде. Там я был Agile Coach, а теперь разъехались по разным городам. Теперь Олег стал Agile Coach в своей команде. Мы созвонились, чтобы кратенько синхронизировать практический опыт и теоретические знания об Agile.

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

- Управление требованиями в Agile (пирамида требований)
- Принцип "Разделяй и властвуй" (декомпозиции)
- Планирование релиза, итераций и конкретной итерации
- Оценка требований и задач
- Практика "AgileManifesto" (освоение командой принципов адаптивной разработки)
- Практика "DONE"
- Обратная связь
- Архитектура в Agile
- CRC карточки и моделирование
- Техническая поддержка (CI, xUnit ...)
- Культурные особенности в команде
- Командное образование

Аудио-запись: файл (mp3, 22Mb)

Краткий конспект, сделанный Олегом:

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

Цитаты для менеджеров: прокачиваем эмоциональный интеллект

2009-02-19T20:03:00.005+03:00

Руководители, которые не обладают достаточной зрелостью и часто просто не понимают причин своих неудач – отчасти потому, что никто честно не говорил об их посредственных результатах.

Настоящий комфорт никогда не возникает в результате сокрытия истины. Защита других сотрудников от правды никого не спасет, а вред принесет всем. Разве не важно перед выходом на сцену знать о том, что молния на брюках расстегнулась?

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

Ценность вашего вклада в меньшей степени является функцией времени, потраченного на предприятии, и в большей степени зависит от интеллектуальной вовлеченности (комментарий: ну как вам ещё нужны таймшиты?)

Люди, которые заявляют о своих навыках или постоянно ссылаются на свое образование, но не применяют ни то нидругое, не разумны. Истинные специалисты продолжают повышать уровень своей образованности и стремятся развить свои умения. Они не размахивают дипломами, а применяют свои знания на практике. Они ищут пробелы в своем образовании и первыми признают неполноту своего опыта.

Джим Маккарти, пэкаде

Agile Study Group: Джим и Мишель Мак-Карти. Программируем командный дух

2009-02-13T22:30:00.005+03:00

Мы начали обсуждать самую любимую мою книгу по динамке развития команд. Эта книга питает меня в нелёгкой работе Agile евангелиста. Книга сложная, но очень важная!

Книга номер 1 для меня.

Книга: Джим и Мишель Мак-Карти. Программируем командный дух
Глава: Введение

Адрес подкаста с обсуждениями: http://study-group.rpod.ru/96956.html

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

Слава говорит: Мне нравиться что есть вполне конкретные практики как бороться с общей командной закомплексованностью

Кирилл говорит: Я в восторге от этой книги! Щас заплачу прям)

Принципы управления проектом в Agile (Agile Management Principles)

2009-02-13T14:41:00.006+03:00

Часто слышиться вопрос - что такое Agile? А весь Agile заключён в манифести и 12 принципах. А дальнейшая интерпретация у каждого своя. Можно проинтерпретировать и сделать Scrum, а можно XP. Но не конкретная методология важна, а сам подход.

Чтобы проверить - вы Agile менеджер или Agile команда посчитайте сколько раз сказали "да это про нас" в списке главных принципов Agile для менеджеров:

1. Deliver something useful to the client; check what they value.
2. Cultivate committed stakeholders.
3. Employ a leadership-collaboration style.
4. Build competent, collaborative teams.
5. Enable team decision making.
6. Use short timeboxed iterations to quickly deliver features.
7. Encourage adaptability.
8. Champion technical excellence.
9. Focus on delivery activities, not process-compliance activities.

Highsmith, J. 2004. Agile Project Management: Creating Innovative Products, Addison-Wesley

Жирным я отметил очень интересные вещи. Действительно ли в вашей команде решения принимает команда (п.5)? Или вы берёте на себя ответственность и решаете, что и как делать? Например назначая задачи на этих пройдох программистов :)

Или п.1 что для вас важнее поставить 100% выполненную работу оттягивая сроки, но борясь за каждую запятую в ТЗ и доскональной реализации даже формочки About? Либо 20% но самое главное и как можно быстрее, чтобы помочь клиенту уже начать работать, а не ждать 100% функционала в том числе и супер полезной формочки About?

Странная политика Russian Podcasting

2008-12-21T19:16:00.003+03:00

Материалы встреч стади-групп сообщества выкладываются на первом подкасте. Я просил их перевести нас в сообщество, чтобы каждый мог публиковаться из наших. На что получил забавный ответ:

1. Права на чтение книги - на support@rpod.ru плиз
и да - сообществ нам и так хватает...

1. Я не понял, зачем на обсуждение книги нужно право? :(
2. И сервис у них не для участников сайта, а ради, чтобы хватало...

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

... добавлено через 4 часа ...
Нашёл выход, просто завёл фэйковый адрес и подписался на все подкасты в качестве ленты друзей. Получилось: http://u19376.rpod.ru/friends. Вроде неплохо. Остаюсь на первом :)

О целях использования Study-Group

2008-12-21T17:31:00.003+03:00

Кратенько выскажусь о сути явления :)
Вопрос был поднят в стади-групп обсуждениях.

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

Study-group - всего лишь определённый инструмент добывания теоретических знаний (даже если это опыт участников), объединяющий структурный (фильтр восприятия) и системный (обсуждения) анализ. Это способ изменения мышления на системный. Когда мы критериально оцениваем информацию. Возможно развитие этой практики в стороную формирования целостного восприятия. Кстати, подготовка, встреча, резюме по главе, резюме по книги формирует цепь закрепляющей обратной связи и глубокого освоения материала.

Касательно целей. Думаю, у инструментов врядли есть цели. Цели есть у желающего пользоваться этим инструментом (например для персонального использования я повышаю свой теоретический уровнь, а если используешь в команде - синхронизация и выравнивание командного инженерного видения на подходы, принципы и способы решения проектных задач). Цели нужны для мотивации объединения вокруг общей задачи. У нас такой задачи нету, каждый сам решает свои цели в стади-групп. Я усматриваю другого рода мотивацию - плановость и предсказуемость. А сама стади-групп состоя из двух этапов: подготовки и встречи. Отражает разные варианты мотивации. Например, неменуемость встречи и желания плодотворно в ней поучаствовать толкает нас к нахождению времени на подготовку. Без стади-групп это бы носило несистемный характер, к тому же нужна была бы сила воли. Встреча смещает акцент в область взаимоотношений. И связана с самореализацией и самоидентификацией каждого участника.

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

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

То же самое в цифрах.
1. Читая один книгу я получу пусть 80% информации от автора.
2. Работая в стади-групп я потенцильно могу получить 80% из п.1 + 20% между строк через обсуждения и доосмысления авторской информации+ 100% (и более) информации из группы и её опыта.

А для максимизации п.2 система заметок должна спровоцировать появления 20% и 100%. Система заметок как ключ для подключения и аккумулации этих процентов.

Цифры взяты с потолка. Опять же важная сейчас не количественная составляющая, а качественная.

Сопротивляемость изменениям или про тюрьму опыта

2008-12-21T00:18:00.007+03:00

Просто приведу цитату, которая просто вызывает благоговенный лепет в моей душе:

Идея о тюрьме впервые была исследована Платоном в «Республике» в знаменитой аллегории пещеры, где Сократ рассуждает о связи видимости, реальности и знания. Перед входом в подземную пещеру пылает костер. В пещере находятся люди, закованные цепями и лишенные возможности двигаться. Они видят только ту стену пещеры, что прямо перед ними. Она освещена пламенем, и тени людей и предметов видны на ней. Обитатели пещеры думают, что тени - реальность, дают им имена, говорят о них и даже связывают звуки, доносящиеся снаружи, с движением теней на стене. Истина и реальность для пленников заключаются в этом мире теней, поскольку они не знают другого.
Однако, считает Сократ, если бы одному из жителей пещеры позволили покинуть пещеру, он понял бы, что тени - всего лишь отражение более сложной реальности, а знания и восприятия его товарищей неверны и искажены. Если бы он вернулся потом в пещеру, он никогда уже не смог бы жить по-старому, поскольку для него мир был бы уже другим. Несомненно, ему трудно было бы смириться со своим затворничеством и стало бы жалко других пленников. Однако если бы он попытался поделиться с ними своим новым знанием, его, вероятно, осмеяли бы. Для пленников знакомые образы пещеры имели бы гораздо большую значимость, чем тот мир, который они никогда не видели. Более того, поскольку человек, получивший новое знание, больше уже не сможет функционировать с прежней убежденностью относительно теней на стене, его сотоварищи, скорее всего, посчитают внешний мир опасным. Это происшествие приведет к тому, что они станут жестче придерживаться знакомого образа мыслей.
Герет Морган. Образы Организации. с.235

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

Теперь я полностью понимаю своих не-Agile оппонентов, видать им в пещере уютней :)

Story Points vs Ideal Hours

2008-12-20T23:46:00.003+03:00

Для многих возникает неоднозначность и недопонимание, зачему вводить такую характеристику, как Story Point. А так же в продолжение предыдущего поста.
Объяснения очень просты. В Agile используется и то и другое. Но для разных уровней декомпозиции требований и реализации.

Я выделяю следующую пирамиду требований к разрабатываему продукту. От верхнеуровневой бизнес идеи до задач для разработчиков. В этой пирамиде требования к продукту (1-3) постепенно разбиваются до требований разработчика к коду (4-5) :)

1. Метафора продукта
2. Фичи продукта
3. User Story
4. Task
5. Task List

Каждый нижний пункт является декомпозицией верхнего. Мерить п.1 и п.2 очень сложно. Так как это очень высоко и тяжело оценить хоть как-то. п.5 (декомозиция задачи на мелкие шаги; Test List - шаги по задаче) слишком мелкий для оценки и нецелесообразен для оценок.

Рассмотрим п.3 и п.4
3. User Story оцениваем в Story Points с использование Planning Poker.
4. Tasks оцениваем в Ideal Days/Hours используя одну из схем: индивидуально (старый подход) или коллективно (новый с 2004 года).

В переводе на русский
3. Функциональные требования оцениваются в единицах трудоёмкости
4. Задачи оценивают в идеальных часах задачи (до 2 дней)

Продолжительность Ideal Hour адаптивно выбирается. В классике отталкиваются от 6 часов. Остальное адаптируется по ситуации.
Во время планирования на выходе мы получаем
1. Плановую суммарную Story Points
2. Плановое суммарное Ideal Days/Hours

Управление скоростью разработки легче вести с более высокоуровнего пункта. А так как у нас оценке подлежит только п.3 и п.4 - выбор очевиден. К тому же Story Points непосредственно связаны с функциональными требованиями и бизнес ориентированы. В тоже время под Ideal Hours может подпасть много не входящее в User Story, и носят инженерный оттенок реализации. Далее вводится фокус-фактор, но об этом смотрите в предыдущем посте.

Это классическая схема работы. Опыт показывает, что изобретать альтернативы не имеет смысла. Но это не должно останавливать.

Дополнительные ссылки:
1. Об agile по-русски: User Stories
2. Planning Poker

Мотивация в три шага

2008-12-20T22:18:00.004+03:00

По эволюции развития существует три шага:

Шаг 1. Принуждение
Шаг 2. Стимулирование
Шаг 3. Прямая мотивация

Принуждение - моральное, экономическое (премии, бонусы, штрафы и т.п.) и физическое принуждение. В общем смотрим на наши команды в ИТ и понимаем. Мы здесь! Здраствуй принуждение :)

Кстати, яркий пример шага 1 это командно-административная, карьерная и бюракратическая машина. Если в вашей организации есть карьерная лестница, бонусы и т.п. - вы на шаге 1.

Нас всю жизнь учат этому способу работы. Паутина подчинения проявляется во всём: учёба, семья, институт и т.п. создают и культивируют в нас "подчинение". И потом удивляемся, почему бывшие рабы становясь начальниками используют этот вариант с большим усердием.

Кстати, В.И.Ленин знал только такой способ мотивации работников: записка В. И. Ленина: «…а Ильина… и весь фабком этого завода… и весь состав комячейки… объявляем виновниками… и объявляем строгий выговор и общественное порицание, с предупреждением, что только на первый раз так мягко караем, а впредь будем сажать за это профсоюзную и коммунистическую сволочь (суд, пожалуй, помягче выразится) в тюрьму беспощадно» (Ленин В. И. Полн. собр. соч. Т. 54.)

Стимулирование - когда мы обеспечиваем достаточный уровень мат.потребностей, создаём независимость работников от эконом. характеристик его бытия. Некоторые продвинутые команды разработчиков, да и вообще в России робко говорят и смотрят в эту область мотивации. Жаль, что многие менеджеры, тим лиды (специально не обученные) и бывшие программисты только используют шаг 1. И просто не понимают, как передвинуться к шагу 2.

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

Прямая мотивация - удовлетворенность содержанием, процессом и смыслом, значимостью труда (Р. Шпренгеру). Когда создаётся вовлечение участников разработки в процесс, в коллективное творчество.
Этот шаг и создаётся Agile-коучером.

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

Dependency Inversion Principle, Dependency Injection и Inversion of Control

2008-12-20T20:31:00.005+03:00

Кратко напишу так
Dependency inversion principle (DIP) - разрыв ЗАВИСИМОСТЕЙ через абстракцию
То есть, когда мы выводим интерфейс IA и скармлеваем потребителю B, мы отрываемся от зависимости, когда потребитель зависит от изменений конкретного класса A. А рассуждая далее, получаем, что логичней переименовать IA и IB, то есть клиент B определяет, что ему нужно от А:

B использует IB
A реализует IB

Dependency injection - механизм использующий DIP, DIP создает возможность использования DI

Inversion of control (IoC) - Don't call us, we'll call you (Hollywood principle) - принцип, когда основной поток управления (алгоритм) определён, и мы кастомизируем части. Частный случай, когда поток управления скрыт в базовом одном классе - паттерн Template Method. Более сложный вариант - модель Framework и частичная передача управления выполнения нашему приложению.

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

Ссылки по теме:
- http://igor.quatrocode.com/2008/09/solid-top-5.html

Образы организации

2008-12-20T00:11:00.005+03:00

Случайно зашёл в книжный, а там случайно открыл случайную страницу этой книги - прочитал. Автор дельные мысли написал. Купил. Читаю... Расстраиваюсь.

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

Конечно, тем людям, которые любят строгую иерарихию, планы, распределение обязанностей и т.п. в разработке ПО. Книга будет полезна. Её объём достаточный, что потихой убедить этих людей в их ограниченном восприятии. Книга покажет им все многообразие смыслов и восприятий. Глубина и важность человеческого фактора выварачивается вдоль и вширь :)

С точки зрения Agile там мало чего полезного. Если вы практикуете Agile вы сами будете думать ещё похлеще автора. Отличие автора от вас лишь в его научном описании, то что вы знаете и так :)

Очень порадовали библиографические заметки. Единственно насыщенная информацией часть книги :)

Для Agile-истов: не рекомендую
Для не-Agile-истов: обязательная к прочтению.

Проектирование Static Verbs английского языка

2008-12-19T23:58:00.005+03:00

Лог переписки English Grammar Study Group. Использованы все принципы проектирования :)

[23:11:49] Ilya говорит: Нашел - эти слова, которые не употребляются в continious по научному называются статические, нединамические (stative verbs). Вот список http://www.perfect-english-grammar.com/stative-verbs.html
[23:12:41] Ilya говорит: Т.е. нельзя сказать I hating или I wishing
[23:21:35] Кирилл говорит: прям не полиморфные глаголы, статика :) Избегаем её всеми силами и несилами :)))
[23:21:47] Ilya говорит: :)
[23:45:22] Denis говорит: sealed к тому же :)
[23:45:46] Denis говорит: хотя нет, need есть наследник - needed ;)
[23:47:08] Кирилл говорит: а может "ed" - это агрегируемая часть класса need :) Neet.ToString() = "Needed"
[23:47:10] Кирилл говорит: )
[23:47:33] Denis говорит: не это врапер
[23:48:06] Кирилл говорит: не, просто булево поле IsInPast = false, и поэтому ToString по-другому работает))
[23:48:26] Denis говорит: class Needed
{
Need need;
ToString() { MakeItInPast() }
}
[23:48:50] Denis говорит: хотя чё-то не так
[23:48:54] Denis говорит: но смысл понятен
[23:49:00] Denis говорит: :)
[23:49:11] Кирилл говорит: class Need
{
bool IsInPast;

}
[23:49:21] Denis говорит: Неее
[23:49:22] Кирилл говорит: override string ToString()
[
[23:49:39] Кирилл говорит: return IsInPast? "Needed" : "Need"
[23:51:02] Denis говорит: фуууу
[23:51:05] Denis говорит: :)
[23:51:08] Кирилл говорит: Я понимаю, но всё же :)
[23:51:45] Denis говорит: понял!

Verb
virtual PresentContinousForm()
{
return "to be" + name + "ing";
}

Need : Verb, IStaticVerb
{
override PresentContinousForm()
{
return PresentSimple();
}
}
[23:52:25] Denis говорит: а нет гоню
[23:52:42] Denis говорит: StaticVerb : Verb

Need: StaticVerb
[23:53:01] Кирилл говорит: мм... IPresentContiniousable, IPresentSimpleable, ... :)))
[23:53:05] Denis говорит: даже ещё хуже!
[23:53:13] Denis говорит: Need - как класс нужен ли?
[23:53:36] Кирилл говорит: таак... Надо подумать. Так как слова - это тоже абстракции, которые что-то означают, то.... да)
[23:53:39] Denis говорит: конструктор - Verb(string name)

и пораждаем need:

need = new StaticVerb("need");
[23:54:12] Кирилл говорит: Ну это смотря что нужно от приложения. Если ИИ строить, то нужны классы на каждое слово)
[23:54:30] Denis говорит: Другой вопрос, будет мина:

fly = new StaticVerb("fly");
[23:54:36] Denis говорит: вроде код корректен, а неверный
[23:54:43] Denis говорит: поэтому нужно где-то словарь заложить
[23:54:49] Denis говорит: а!!!!
[23:54:54] Denis говорит: исопльзуем flyweight! ^)
[23:54:58] Кирилл говорит: Словам нужно атрибуты сделать, либо абстрагировать атрибуты до состояний
[23:55:41] Denis говорит: можно конечно все спрятать в StaticVerbFactory
[23:55:58] Denis говорит: с сылкой на http://www.perfect-english-grammar.com/stative-verbs.html
[23:56:07] Denis говорит: сорри, в VerbFactory
[23:56:16] Кирилл говорит: )))
[23:56:50] Кирилл говорит: А как синонимами управлять... Каждый объект слова должен хранить списки синонимых, антонимых и тд
[23:57:17] Denis говорит: ну это другая юзер стори :)
[23:57:22] Кирилл говорит: :)

Коммитмент и ответственности в разработке

2008-12-08T14:49:00.004+03:00

Я не держу слово. Да такая фигня случается. Я не держу слово перед командой, когда обещаю сделать работу за 6 часов, а выполняю за 12. Я не держу слово родными, когда обещаю купить хлеб, но забываю. Я не держу слово перед самим собой, когда обещаю встать в 9 утра и дрыхну без задних ног. Я часть системы. Системы, которую создаю я. В этой системе таких как я рать. Мы придумываем кучу оправданий, почему это не вышло, почему я не смог или не успел. Мы переносим ответственность на других, делегируем им нашу ответственность за себя. А потом удивляемся миру, который образовался вокруг нас.

Вопрос становится - почему я так поступаю? Почему я принимаю решения и возлагаю ответственность на себя и не выполняю её. Будет ли чувство доверия, чувство, что можно положиться на меня и планировать уже свои активности. Нет!

Мне это сходит с рук. Может быть везёт. Но если не я один такой? Если ты тоже так поступаешь. Если поступает сосед, коллега, партнёр. То какой мы мир строим?

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

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

Петр 1 говорил: Кто хочет у него тыща возможностей, кто не хочет тыща оправданий.

PS. Но не забываем адаптивность никто не отменял, но мы должны стремиться к идеалу.

Study Group Community: Нас слушают!

2008-12-08T13:04:00.009+03:00

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

График скачивания подкастов сообщества: http://study-group.rpod.ru

А что ждёт нас впереди? Уже через месяц работы участники сообщества решили сделать проект Study Group Portal, который покроет нужды сообщества для организации комфортных встреч, работы и просто социальной сети профессионалов.

Даже страшно загадывать, что нас ждёт впереди! :)

Как тестировать приватные функции класса?

2008-12-07T02:19:00.007+03:00

Знакомый вопрос? И какие у нас есть решения
1. Использовать рефлекшн
2. Директивы компиляции #if DEBUG - ужас
3. friend и его альтернативы
4. Возможности встроенного xUnit фреймвока в IDE который делает чёрную магию (см VS.Net)
5. Ваше любимое :)

Если первое решение смерть всему поколению поддержки, а второе ужас на крыльях ночи, то стоит вопрос - а чего делать-то?

TDD нас учит - пишите тесты и всё будет пучком. Действительно будет, но жизнь не идеальна. И появляются приватные методы и конечно же возникает желание их потестить.

Почему многие бьются, но не находят решения? А потому как мы находимся в такой парадигме программирования, которые не предполагает решения. Там его просто нет. Спросите, а что не так с нашей парадигмой? Да всё просто - мы со своей теорией знания ООП лезем в бизнес-разработку. Теория ООП - это академически дисцеплина. А наш код - это бизнес-реальность.

Что говорит теория - инкапсулируй, скрывай и т.п.

А что говорит бизнес? Гони нам качественное и дешевое решений! А почему же теория делает нам решение не дешёвым? А все просто - нету тестов, запутанный код, неясная логика, неадекватные называния и огромная связанность даёт прибавки в стоимости нашего кода в части поддержки и развития. Мы платим огромные сумма за поддержку и развитие кода, нежели его создания. Пусть икает тот разработчик, который первый породил тот или инной класс. И получил свои 10$ за него. Теперь мы дни тратим понимая, почему он вызывает отъезжание в другом месте и днями на пролёт эксперементируем как к этому делу прикрутить чуть больше функций. И платим за это сотни, а может быть даже тысячи баксов.

То есть задача бизнес кода - получить дешевое решение. Которое легко развивать, сопровождать, читать, анализировать и оно обладает минимальной связанностью. Конечно же TestFirst, TDD, Refactoring, Patterns, Continuous Integration здесь наше спасение. Но вернёмся к приватам.

Парадигма "бизнес разработки" такова, что нужно посмотреть, кто является клиентами нашего кода. Кто использует продукт нашего творчества? Мы должны сделать все возможное и невозможное, нарушая теоретические полёты мысле теоретиков от ООП, с целью удешевления поддержки и развития.

А клиентами нашего кода являются: конечные пользователи и разработчики. Причем ещё не ясно, кто больше наш код использует. Пользователи тыкают конечно приложение. Но кто вас чаще вспоминать будет, если вы нагородили подлянок на каждом шагу, не проводили рефакторинги и вообще оставили тучу смеллов не покрытых тестами?

Итог. Клиенты кода - это заказчик + разработчики. Причем последний в большей мере. Так какого мы тресёмся за теоретическую инкапсуляцию и забиваем на тесты открывая нужные функции, делая их protected (шунтируя для теста класс, например) или даже public? Кончайте голову себе и другим пудрить! Делайте дело и используйте всё многообразие подходов, чтобы качество кода было 101% и его цена минимальна!

Я выделил 3 парадигмы разработки, который порождает рассматриваемый случай
1. "Теоретическая" (когда неуклонно следуем ООП и придумываем обходные манёвры о которых в ООП ничего не говорится и считаем их хорошими — см. п.1-п.5 выше). Максимальное количество private.
2. TDD — уже смещает парадигму мышления и на выходе получаем изолированные модули. Но и там проскакивает приват. Который приводит к одному из п.1-п.5
3. "Бизнес-программирование". Используем TDD + открываем (protected|public) методы для нужд тестирования. Так как я являюсь пользователем своего кода и мне важно его качество выраженное через 1) покрытие тестами, 2) простоте чтения.

Я работаю по методу 3.

Выбранный мною подход разработки делает мой код дешевле и качественнее.

Почему мы используем Story Points?

2008-12-07T01:29:00.008+03:00

Ответ простой. Посмотрим на альтернативы.

А альтернатива - это идеальные часы, дни или что-то другое со вренем.

Кстати, проясню, идеальный день равен 6 идеальным часам. Сами ведь понимаете, что нужно и по нужде сбегать, и с коллегами поговорить, и звонки могут быть, да и просто мой блог почитать и на курс ко мне сходить :)

Story Points - это трудоёмкость оцениваемая командой во время планирования. Это не время, очень большая ошибка перейти на оценку в идеальных часах. Почему?

Расказываю.

Вариант 1. Идеальные дни.
Напомню, функциональные требования (User Stories) оцениваются в идеальных днях. А задачи, на которые разбиваются требования в идеальных часах.

Итак у нас команда из 5 разработчиков. Итерация 2 недели. Сколько мы наберём работы? Посчитаем - 5 разработчиков x 2 недели x 5 дней x 6 идеальных часа в день = 300 часов. Ну мы собственно и набираем задач. В конце итерации выясняется, что мы сделали работы на 200 часов.

Стоит вопрос - нужно переоценить требования? или укоротить идеальный час? или набирать теперь часов не 300, а на 200 в следующий раз? А что делать с новыми задачами? Их сразу домножать на коэфициент? или ввести термин "идеальная итерация" состоящая из 200 часов. Куча вопросов и у меня нет на них ответа. Потому что это не Agile ;) А заниматься классическими расчётами, как учат нас книги по менеджменту и придумывать теории производительности - крайне неэффективно.

Поэтому рассмотрим вариант 2.

Вариант 2 (по Agile). Меряем User Stories (функциональные требования) с помощью Story Points.

Во время обучения меня срашивают, что такое Story Points? А я отвечаю
1) это сипульки
2) прошу понаблюдать за игрой слов - User Stories -> Story Points
3) мера трудоёмкости
4) мера не времени, а бизнес-значимости, так как бесполезные вещи для бизнес не оцениваются в Story Points. график убывания (burndown) показывает как значимые вещи реализуются в коде.

А теперь вернёмся к нашей команде в 5 человек. После планирования они поняли, что трудоёмкость итерации 150 Story Points. Итерация. Результат - 100 сделали.
А теперь магия корректировки скорости.
фокус фактор = сделанные Story Points / ресурс в идеальных часах = 100 / 300 = 33%

Что значит 33%? Это соотношение стори-поинтов к идеальному времени. В следующий итерации один разработчик ушёл в отпуск. Как вы посчитаете сколько вы за итерацию осилите? берём идеальные часы (ресурс) - 240 часов и множим на 33% - получаем нужно набрать требований на 80 Story Points.

Причем заметьте:
1) нам не нужно адаптировать свои оценки сложности
2) мы не задумываемся о своей неверной оценке одного требования, как впрочем и целого набора
3) 1 проработанный час не всегда равен 1 выработанной Story Point. Банально много много времени бесполезно сидеть, а бизнес-выхлопа никакого. Если ежедневно считать, сколько осталось Story Points сделать до конца итерации. То можно заметить - время течёт, а бизнес стоит. Сразу можно оперативно реагировать.
4) если каждую итерацию мерить свою скорость в story point можете увидеть очень интересную картинку. особенно меня радует, когда команда занимается рефакторингом, тогда просест графика в ноль гарантирован :) хуже, когда график проседает в итерации, где добавляются полезные фичи.

А дальше обширное поле игры с фокус-фактором. Хотим время на стабилизацию - делаем цифирку поменьше. Хотим поработать по выходным - побольше :)

Продолжение: http://denismiller.blogspot.com/2009/02/story-points.html

Планирование продукта в Agile

2008-12-06T17:24:00.004+03:00

Agile - это хаос, никакого планирования и т.п.

Это ложь и происки демонов!

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

Как выглядят требования? Их можно представить в виде треугольника. Вершина самые высокоуровневые требования. Основание… предпред-последний слой это многочисленные документы, детальные требования, SRD, BRD, TRD. Предпоследний слой большое количество документации инженерной и самый нижней слой - код проекта. Код проекта тоже документация  Такую схему можно использовать это не запрещается, но мы ищем эффективные пусти.

Сделаем два предположения:
1. Документация делится на документированную и недокументированную
2. Участники проекта участвуют достаточно продолжительное время, чтобы их можно было считать носителями знания и не страдают амнизией :)

Теперь вспомним, что является средней частью. Большая стопка мукалатуры. Вязкая документация, наводящая Такие предположения позволяют более эффективно построить пирамиду требований вырезав среднюю часть (детальные требования и тонны архитектурной документации). Правда приятно сэкономить тонны времени на написания этой муккалатуры? А сколько времени сэкономили на поддержания её? :)

Но такой подход вызывает изменение процесса разработки
1. Все участники должны быть в курсе высокоуровневых требований
2. Код программы должен быть качественным.

"Все участники должны быть в курсе высокоуровневых требований" это означает, каждый должен въехать в видение продукта, видение релиза, итерации и понимать все требования, которые отражаются в кратких заметках-маркерах (User Story Index Card). Почему маркеры? Да потому, что они нужны лишь для игры в покер и должны служить напоминанием о той или иной хотелке клиента. А когда дойдём до планирования хотелки - у него и спросим :)

Про качественный код здесь говорить нечего. Код программы является самым низкоуровневым, детальным требованием. Поэтому он должен быть таким, что квалифицированный разработчик его будет читать как документ. В общем эффект самодокументированного кода здесь имеет место быть. Каждый Agile-разработчик должен обладать навыками TDD, Refactoring, шаблонами и т.п. Ну и конечно моей любимой альтернативой "конвенции наименования" - Implementation Patterns.

Теперь какова анатомия верхней части пирамиды. Тут вариантов туча. Очень хорошая практика из RUP. Но по мне главное в этом деле, чтобы клиенты, менеджеры и т.п. вне-командные личности смогли договориться в самых крупных своих ожиданиях, выраженном в видении продукта и релизов. И другой важный момент – видение является критериями выбора приоритетов клиентом первоочередных функциональных требований (User Stories). Видение становится картой, используя которую мы движемся в нулевой итерации сбора и анализа требований при составлении Product Backlog’a. И эти видения помогают понять, что нужно в самое ближайшее время. Во время подготовки достаточно понять видение на 2-3 релиза и это будет достаточно.
После того как мы договоримся о целях (видении) релизов. Нам уже легче отсортировать требования пользователей. Самый важный конечно же, это ближайший для разработки релиз. Там нужно быть очень внимательным. К остальным тоже внимательность не помешает. Но нужно участь, что после первого релиза может все изменится. Второй и третий нам интересен лишь для тенденций. О четвертом не имеет смысла вообще говорить. И его можно называть «всё остальное» 

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

Соберём всю пирамидку требований от видения до ежедневных задач:
1. Видение продукта - управляем метафорами
2. Планирование релизов - управляем features
3. Планирование итераций - управляем user stories
4. Планирование дня - управляем задачами

Extract Superdirectory (Configuration Refactoring)

2008-12-06T02:43:00.006+03:00

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

build
- Release
- Debug

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

Для этого рекомендую применить рефакторинг:
Extract Superdirectory
You have two directory with similar files.
Create a superdirectory and move the common files to the directory.

В результате получаем несоколько папок:
build
- Common
- Release
- Debug

Другой вопрос, если в файлах папки Common нужно кастомизировать часть файла исходя из типа сборки. Ну тут чуть сложнее, используем Configuration Adapter паттерн. Который в зависимости от сборки вырезает и заменяет секции файла исходя из типа сборки. Реализация совсем проста - это исполняемый файл, который натравливается на, например, конфигурационный файл, он ищет секции заключённые в нужные теги (@Release@, например), а остальные стерает (@Debug@).

О конструировании социальной реальности

2008-12-05T02:50:00.004+03:00

Что такое реальность? На этот вопрос никто из живущих на земле ответить не может. От реальностью мы отделены нашими органами. Мы испльзуем их, чтобы в голове отобразить. Лишь отобразить картину реальности. Это с одной стороны. С другой стороны мы выстраиваем внутреннюю реальность - убеждения, ценности, свои правоты и истины. Эта конструкция строится в нас с помощью улицы, двора, садика, школы, университета и даже работы. Из нас делают биороботов для работы. Нам прописывают как мы должны работать и кому подчиняться. Так было всегда.

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

Тут я отойду в другую сферу. Сферу не ИТ, а других реальностей. Других реальностей построенных людьми, которые небыли посажены на рельсы подготовки инженеров-программистов. Людей, которые были отделены от мира штамповки биороботов, своими недостатками. Я хотел бы рекомендовать вам интересную историю одной девочки - http://rodon.org/other/vmitssh/

Чтобы заинтересовать читающих блог приведу две цитаты девочки:
Наука – система знаний, основанных на сомнении (Соня, 10 лет)

Кто знаком с науками изнутри, удивится точности слов. Сомнение – один из методологических столпов науки (другой – вера. Речь, конечно, не о религиозной вере)

Что заставляет уходить в бессмертье
Мельчайшие частички бытия?
Их разделяют звезды и столетья,
И вместе с ними исчезаю я.

Но исчезая, во Вселенской книге
Я оставляю четкие черты.
И в каждом атоме, и в каждом миге
Меж мной и Вечностью наведены мосты
(Соня, 13 лет)

Мои выводы. У девочки хорошо поставлен слог. Она хорошо передаёт другой вкус... другой социальной реальности. Которая возможно ближе к той, реальной реальности. Она не проходила процесс штамповки граждан государства. Но судя по её творчеству она теряет свою исходную модель... Её "учат" нашей социальной реальности.

Другая жизнь – вторая Я

Другая жизнь, вторая Я.
Ваш мир мне видится иначе.
Вторая Я у вас своя,
А первая в нём горько плачет.
Мне вскоре радость надоела
От похвалы моих стихов.
Я жду не слов, мне нужно дело –
Молитвы дело и трудов.
Вторая я – как есть малышка,
Почти что девяти годов.
И в жизни, и во всяких книжках
Портрет её давно готов.
Другая жизнь работать заставляет
Не столько сердцем, сколько головой.
Вторая Я прекрасно это знает,
Но аутизм не даст быть деловой.
Мне дан талант слагать слова.
Зачем – я это понимаю.
Вторая Я обычно не права,
Когда меня другой быть призывает.

Он чувствует, что её меняют. И она сопративляется этим измененям.
Но похоже она проигрывает игру. Её первоначальная картина мира изменяется мужами истинной реальности :)

Не верь, не гадай и не бойся
В крови уже есть ответ.
Чужие неясные свойства –
Откуда и чей привет?

Так странно смешалось и глупо –
Готовый взорваться вулкан.
Не кот на цепи у дуба –
Сошедший с ума ураган.

Но так уже прежде бывало
Рвалось полотно пелён
И я из себя прорастала
Сбегая из плена времен.

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

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

Всегда ли прав клиент?

2008-12-05T02:38:00.005+03:00

Часто звучит лозунг "клиент всегда прав!". Но насколько эффективен такой лозунг? Позволит этот лозунг писать качественный код и гордиться массовостью использования хорошего решения?

Давайте взглянем подробнее. Когда кто-то "прав", то кто-то значить "не-прав". Если прав клиент, то не права команда разработки. Но кто же создает продукт? Конечно же команда разработке. А в голове этой команды своя "правота", которая отличается от "правоты" клиета, а по сути является "не-правотой" клиента. Стаёт вопрос ребром - насколько я качественно сделаю продукт, если я считаю одно, а должен делать другое? Создаётся шизофреническая ситуация: думаю одно (истинное я), говорю второе (ну раз заказчик всегда прав - то буду говорить его же словами), а делаю третье. Что же такое третье? Симбиоз. Сибиоз, который готов взорваться. Некая субстанция, которая насильно скована контрактными обязательствами и деньгами. Проект может быть будет сделан. Но вы будете гордиться таким проектом? Будет ли каждый день работы приносить удовольствие от работы над ним? Я бы не стал так работать - жизнь одна, чтобы её портить на такую мелочную постановку задачи.

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

Вывод: В общем для меня критерий "правоты" это неверный критерий. И вообще зло. И в этом я на 100% прав :)

Касательно верификации требований или немного о кризисе

2008-12-03T18:21:00.007+03:00

Для оценки, что происходит вокруг нас есть несколько вариантов.

1. Я оцениваю с точки зрения своей точки зрения. Своей правоты.
К сожалению этот уровень очень подвержен влиянию внешних и внутренних факторов. Внешний - нам навязали те ценности, которые не являются важными и нужными. Например см. предудыщий пост касательно "штрафов". Когда я придумываю что-то, мне сложно отказаться от своего решения. Чувство важности (я же автор решения) не позволяет мне адекватно оценить ситуацию. Если работать по оценки на этом уровне мы получим много криков, обид и все будут расстроены. Только мудрецы могут изменять своё мнение и поскупиться авторством ради лучшего решения на этом уровне.

Что делать нам? простым разработчика?
2. Оценивать с точки зрения другого человека.
Представьте, что вы тот человек, которому вы хотите донести своё решение. Ну как?
Думаю у нас достаточно хорошо работает абстрактное мышление и все хорошо можем дебажить, чтобы продебажить свои ощущения к такой позиции №2.

Но есть ещё круче
3. Примените глобальную точку зрения. Глобальность подразумевает точку зрения: продукта, клиентов, коллектива, общества и самое мощное глазами собственной смерти :)
А смерть всегда говорит одно и тоже, не парься, получай удовольствия от жизни. Хуже меня ничего нет. И твои проблемы сегодня или религиозные войны в обуждениях по поводу стиля программирования или архитектуры лишь пустая трата времени и твоей энергии. А этой энергией питаются деструктивные личности твоей души. Тебе это нужно? Ну если нужно - то корми их :)

Цитата: "обращайтесь к смерти за советом, чтобы избавиться от бездарной мелочности, свойственной людям, которые живут так словно смерть их никогда не коснётся" (Your death will tell you that you’re wrong; that nothing really matters outside its touch. Your death will tell you, ‘I haven’t touched you yet’.)

Ты с другой стороны, чувствуешь, что ты бессмертен. А решения бессмертного человека могут быть изменены, или о них можно сожалеть или подвергать их сомнению. Время имеется только для того, чтобы делать решения. (“You, on the other hand, feel that you are immortal, and the decisions of an immortal man can be canceled or regretted or doubted. In a world where death is the hunter, my friend, there is no time for regrets or doubts. There is only time for decisions.”)

(С.Castaneda, Journey to Ixtlan)

Как связано с кризисом? Примените третью точку зрения к нему

Позитив vs Негатив в User Story. Проверка качества продукта на социльную ценность.

2008-12-02T20:14:00.008+03:00

Сейчас подготавливаются функциональные требования к новому продукту. Я там выступаю как product owner (и заодно коучером) и поэтому пытаюсь ценность нового продукта сделать как можно больше. Клиентом является команда разработки. Поэтому мы периодически играем в роле "клиент". В разговорах с "клиентами" показалось очень интересным одно обсуждение. Сегодня поговорили по поводу отрицательной мотивации как следствие работы нескольких фич продукта. Я отрицательное неприемлю на корню. И считаю, что осознанная личность выше этого. Может это называется позитивная психология. Так иногда озвучивают мою точку зрения знающие люди. Я не знаю. Я знаю одно эффективность и кайф от работы превыше всего 

4 юзер-стори и мои комментарии

Я как ведущий группы хочу иметь возможность отмечать пропуски участниками SG (например один пропуск - "шарик" пропуска в статус или его половинка) для того чтобы давить на сознательность

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

Я как участник группы хочу видеть свой статус по пропускам каждой конкретной SG (количество "шариков" пропуска) для того чтобы давить на сознательность

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

Я как пользователь портала хочу видеть количество пропусков у другого пользователя для того чтобы давить на сознательность

Денис: пользователь онанист? :)
Автор: дело пользователя

Я как пользователь портала хочу видеть список топ-прогульщиков портала для того чтобы давить на сознательность

Денис: цель топ рейтинга отрицательных качеств не понятна. происходит культивация культа "прогульщиков", вместо развития заинтересованности и вовлечения в полезное дело саморазвития
Автор: так а кто сказал что нельзя сделать механизм уничтожения этих шаров - вот и положительная мотивация.
Денис: зачем придумывать механизм уничтожения негатива, когда можно получить непосредственный позитив от участия? С какой целью я прихожу на сайты? За удовольствием или за негативом?
Автор: в SG есть определенные правила - например, обязательная подготовка одно из них. появление на встречах - думаю тоже. если ты для удовольствия прийдешь на SG неподготовленным или сорвешь встречу - это вред группе.
Денис: право поддерживать своё "обязательство" это право давшего обязателство - это раз. это же относится к неподготовшимся. А встречу можно провести и одному -- мы активны, позитивны и нам ничего не мешает самообучаться :) как ты думаешь - почему люди сейчас приходят и участвуют? боятся пропусков или есть другие мотивы? Почему не использовать другую систему мотивации - позитивную? причем, чтобы её реализовать ничего не нужно. просто поднять портал - а там сами потянутся.
Автор: мне нравится аналогия с SG=agile проект. Есть цель к которой стремимся, есть митинги, на которые все дали обещание появляться вовремя и вообще, есть опоздавшие/пропустившие, с которых взимается штраф.
Денис: штраф в Agile - никогда не взимается. Такой практики никогда не было. То что придумывают некоторые люди - это их дело. Штраф - это не Agile.
Автор: см. "Dealing with latecomers " Henrik_Kniberg_-_Scrum_And_Xp_From_The_Trencheson
Денис: я этот источник знаю. Вопрос в другом - если у тебя есть два вида мотивации: положительная и отрицательная? зачем ты хочешь развить отрицательную? а не приложишь усилия развить положительную? не понимаю
Автор: не вижу как можно развить положительную мотивацию в подобном ключе. если есть такая US - давайте ее развивать.
Денис: создать другие US - которые привносят положительную мотивацию посящения ресурса, нежеле отрицательную мотивацию... типа я пошёл на каторгу, иначе будут считать прогулы.
Автор: как автор US не могу придумать позитивную US подобной силы эффекта разве что IPODы раздавать.
Денис: как ты думаешь люди с радостью пойдут на сайт, где их отрицательно оценивают?
Автор: людей оценивают объективно, по прогулам :) сорри, аут оф тайм нау.
Денис: вопрос а зачем оценивать людей?
Автор: людей оценивают объективно, по прогулам :) сорри, аут оф тайм нау.
Денис: вопрос а зачем оценивать людей?
Автор: оценок людям никто не дает, отмечаются пропуски.
Денис: а это не оценка ли? было действие: участника не было. а вот интерпретация уже другого человка в виде оценки - количество пропусков. кстати, наличие пропусков вызывает другую оценку... допущу о надёжности этого человека. вот так много мыслей возникает на пустом месте. зачем?
Денис: повторю вопрос: ты с радостью пойдешь на сайт, где считаются твои прогулы и сообщается это всем? а ещё есть шанс, что тебя могут исключить?
Автор: я пойду. радости мне это не доставит, горя тоже. гугл собирает мои поисковые запросы, одноклассники знают что я учил. это всего лиш фича, не больше.
Денис: а если этой фичи бы небыло - уже удовольствия от посещения было бы больше? а может если оценивались бы твои активности - например плюсами твои цитаты и ты попадал бы в рейтинг самых-самых с присваиванием статуса гуру и рекомендаций коллегам как эксперта в области? (кстати щас запишу US)
Автор: нет. надо?
Денис: не понял. если бы не было этой фичи, ты бы больше удовольствия от сайта получал бы?
Автор: эээ, мне фичи сайтов удовольствия не приносят. я работаю с тем что есть. оно может быть удобным или нет. если неудобно - это досадно. если удобно - значит так и должно быть.
Денис: как ты понимаешь, что тебе что-то удобно или нет? когда тебе удобно тебе приятней? или приятней когда неудобно?
Денис: да, ещё один нюанс. юзер стори пишется от первого лица. то есть ты реально этого хочешь? это реальное пожелание или выдуманное, а может кому нужно? формируя список требований к системе мы являемся её пользователями - свойство нашего проекта. то есть ты реально хочешь этим пользоватся и тебе важно наличие такого функционала?
Автор: я ж придумал это исходя из вопроса - "что надо сделать чтобы я всегда старался учавствовать в группе или хотя бы предупреждал владельца вовремя"
Денис: ну так реальную потребность нужно писать :) а там уже решения сами прийдут :) И это правильно - когда мы осознаем, что же реально мы хотим - это очень эффективно.

Стирание личной истории с точки зрения Agile

2008-12-02T18:41:00.004+03:00

В Карлос Кастанеда - Путешествие в Икстлан (1972) говориться, что практика стирания личной истории очень полезная штука. Суть её в том, что ожидания других людей по отношению к моим действиям и бездействия уже запрограммированы в их головах. А если так, что мне из раза в раз нужно объяснять то или иное мое поведение/решение. Чтобы программы в головах у людей синхронизировались и поддерживались up-to-date. Это стиль "почему?".

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

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

Кстати, для программиста желания обладать личной истории грозит психологическим заболеванием (или просто пофигистическим отношением к работе). Например программер набедокурил, что-то отъехало. Что мы делаем? Обвиняем - то есть используем историю. Лучший вариант разобраться в истинных причинах и самое главное выработать стратегию поведения, чтобы в следующий раз работать эффективней.

Кто что выбирает?

ЗЫ. На этот счёт есть русская пословица - "кто старое помянет, тому глаз долой".

Refactoring Study Group - подключайтесь, чтобы знать больше!

2008-11-27T03:43:00.001+03:00

29 Ноя	Refactoring Study Group г. Москва Сб, 29 Ноября 2008 в 20:00

Две новые Study Group! Подключайся!

2008-11-25T12:24:00.001+03:00

01 Дек	Две новые Study Group для профессионалов! г. Москва Пн, 01 Декабря 2008

Отзыв о Study-Group

2008-11-25T01:27:00.002+03:00

И начну я с себя.

К этой форме повышения своего уровня я шёл давно. Чтобы быть на пике
современных вещей, я шёл в преподаватели. Учил студентов несколько
лет. Но на самом деле учился сам. Каждый раз готовясь к лекциям и
семинарам я обучался. С переездом в Москву стало мало времени и я
начал искать варианты самообучения в команде. Но это превращалось в
подобие семинаров с несколькими заинтересованными людьми и остальной
зевающей массой. Я стал задавать себе вопрос - что нужно сделать,
чтобы участие в семинарах было со 100% эффективностью каждого
участника. Постепенно переквалифицировался в тренера в области
инженерии программного обеспечения. Но год работы там не дали мне
ответы на мои вопросы. Вернулся в разработку. Я продолжал искать.
Прошёл год. Год работы в очень интересной команде. И в какой-то момент
времени моя идея, которую я пытался организовать в далёкие 90-е под
названием "пушкинских чтений" начала выресовываться. Начало появлятся
необходимость такого явления. И я предложил попробовать.

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

После долгих поисков эффективной системы самообучения. Понял, что
нашёл её. Используя книгу как путеводителя мы проникаем в коллективный
опыт группы. Обмениваясь знаниями, точками зрения, идеями, инсайтами и
просто опытом я понял, что лучшей системы придумать невозможно. Каждый
участник находя интересную информацию делится ей с коллегами, а в
замен получает ещё больше идей. Чем вовлеченней каждый, тем насыщеней
поток информации, знания и опыта. 100% вовлеченность каждого
участника. Чем больше отдаёшь, тем больше получаешь.

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

Денис Миллер
Организатор SGC

Секрет успешной архитектуры в Agile

2008-11-24T17:24:00.004+03:00

Обсуждая задачи управление проектами в рамках Scrum с ребятами из Agile Study Group я решил обобщить своё видение на проектирование и построение архитектуры в стиле Agile. И почему оно лучше, чем существующие альтернативы.

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

Но, я раскрываю секрет, как можно повысить защищённость архитектуры от незапланированных изменений. И главный секрет находится в Команде.

Самообучающееся общество Study Group Community

2008-11-22T14:45:00.008+03:00

Study Group Community объединение профессионалов, желающих развивать свои познания в области разработки ПО (шаблонов проектирования, рефакторинга и других практик) и других областях (философия, психология, культура и искусство). Мы детально разбираем классические книги. Книга становится не просто источником знания и поводом встретиться в голосовой конференции, где мы обмениваемся точками зрения, идеями и собственным опытом. Получается очень интересно. Подключайтесь!

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

Сайт сообщества: http://study-group.net
Гугл-группа: http://groups.google.com/group/study-groups?hl=ru

Простое объяснение работы
По-русски - это "пушкинские чтения"
1. Читаем каждый главу книги
2. Потом собираемся и обсуждаем в течении часа
Наши встречи похожи на тренировки в спортзале. Только мы прокачиваем другие мышцы Smile
Не страшно, если у вас нет опыта. главное желание учиться и обмениваться опытом.

Аудио и видео объяснения стади-групп:
* http://rutube.ru/tracks/1225529.html
* http://study-group.rpod.ru/86608.html

Аудио-записи прошедших встреч:
* http://study-group.rpod.ru/86685.html - Hello, World! по Agile через TDD, XP и т.п.
* http://study-group.rpod.ru/86680.html - обсуждаем Scrum

Подкаст для Study-Group

2008-10-31T21:27:00.004+03:00

Создан подкаст сообщества самообучающихся профессионалов - http://study-group.rpod.ru

Присоединяйтесь к своему саморазвитию : http://study-group.net

Синхронизация работы, самые мощные заметки, ретроспектива на форуме.

Описание работы групп в вики.

Сейчас действует 4 группы: по шаблонам проектирования, архитектуре, agile и даже философии :)

Эрих Гамма в Москве (интервью)

2008-10-30T10:24:00.002+03:00

Эрих Гамма (Erich Gamma) был в Москве несколько дней. В последние минуты пребывания в Москве мне удалось взять у него интервью.

Запись: http://agile.rpod.ru/83919.html

Эрих Гамма - один из авторов широкоизвестной книги "Шаблоны проектирования", является ведущим инженером Цюрихской лаборатории IBM Rational Software, где он осуществляет техническое руководство проектом Jazz. Эрих был первоначальным руководителем проекта Eclipse. Кроме этого, совместно с Кентом Беком Эрик стоял у истоков JUnit, ставшего сегодня стандартным инструментом тестирования Java-программ, и является соавтором книги об Eclipse.

Интервью:
- понимание Agile и его перспективы
- новая платформа разработки Jazz
- секреты шаблонов проектирования
- советы с чего начать изучение

Ссылки
http://en.wikipedia.org/wiki/Erich_Gamma
http://jazz.net/
http://en.wikipedia.org/wiki/Design_Patterns

Календарь StudyGroup

2008-10-14T01:13:00.006+04:00

Календарь для действующих StudyGroup.

Подробности о StudyGroup:
http://agileconsulting.ru/wiki/Study_Group

На текущий момент объявлен набор в группу по изучению "Шаблонов проектирования".

Виртуальный тренинг "Тайм-менеджмент"

2008-10-10T23:59:00.000+04:00

11 Янв	Виртуальный тренинг "Управление временем" г. Москва Вс, 11 Января 2009 в 21:00

Зарабатываем деньги по Skype.

2008-10-01T23:41:00.003+04:00

Интересный сервис открыл Skype. Теперь не нужно нанимать человека, звать его в гости. А просто взял - набрал номер и получил консультацию по интересующему вопросу. Теперь я знаю, где буду брать уроки репетитора английского языка. Интересно а будут профессиональные разработчики свои консультации давать? Я например нуждаюсь в советах профи в php, а то часами сижу над скриптом и не пойму чего делать. А так заутсорсил проблему человеку - он объяснил и я рад, и человеку приятно.

Каталог услуг:
http://directory.skype.com/ru/skypeprime

И меня тоже посчитали:
http://directory.skype.com/ru/skypeprime/listing/denis_miller

Есть ли Agile?

2008-09-30T21:45:00.004+04:00

Странно видеть на форумах воинствующих проповедников анти-Agile движения. Выкрики, скажем хором нет Agile вызывают только улыбку. Но напор анти-аджайлистов не убывает и со временем разрастается, подкрепившись страшными аббревиатурами PMI, PMBOK и другими. Но так ли Agile хорошо, чтобы такие вещи ему противопоставлять, а может быть Agile нету?

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

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

И взрыв произошёл. Takeuchi, Hirotaka; Nonaka, Ikujiro (January-February 1986). "The New New Product Development Game" обобщили понятие эффективной команды. Команда тогда эффективна, когда она самоорганизуется. А дальше и наука и практика показали, что эти догадки были верны...

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

Вот и свойства эффективной командой (доказано формально и научно, а так же подтверждено практическими фактами):
* Неформальная и открытая атмосфера;
* Задача хорошо понята и принимается;
* Члены группы прислушиваются друг к другу;
* В обсуждении принципиальных вопросов участвуют все члены группы;
* В ходе обсуждения поощряется как высказывание идей, так и выражение чувств;
* Конфликты и разногласия между членами группы цен-трируются вокруг идей и методов, а не личностей;
* Группа осознает, что делает, решение основывается на согласии, а не на голосовании большинства

Вопрос к вам: насколько ваша команда эффективна?

Да, хочется добавить. Вернёмся чуток раньше. А ведь уже в 1968 году D.Cartwright и A.Zander говорили, что : "Группа – это объединение индивидов, поддерживающих взаимоотношения, которые делают их взаимозависимыми, и стремящихся к общей цели". Опять вокруг да около :)

Теперь уже понятно. Решение наших проблем найдено. Но как сделать эту команду? Определение есть, признаки эффективной команды тоже написаны. Но крайне не понятно чего делать то? Как организовываться так, чтобы всё заработало. Можно поступить просто отдать на откуп команде. И пусть команда сама изобретёт те практики, которые приведут её к эффективности. Но постойте, команда будет изобретать то, что уже давно изобретено. А давайте всего лишь обратимся к мировому опыту. К мировым коллекциям лучших практик, которые уже проверены тысячами команд и не одним десятилетием. Просто обратимся к Agile...

В Agile дисциплина лучше, чем в Waterfall

2008-09-30T19:24:00.003+04:00

Будьте внимательны, когда говорите, что waterfall дисциплинирует. Вотерфол прост и структурирует, но не дисциплинирует. Конечно там «дисциплина» воспринимается как следованию некоторым заранее определённым шагам, но не «дисциплине» в творчестве. А второй вариант «дисциплины» наиболее важен для нас.

Разработка в стиле Agile предполагает, что вы работаете профессионально, дисциплинируете себя в малом, и делаете это из-за дня в день. В вотерфоле нам сказали: в какое время и что делать (подготовка требований, разработка, тестирования) и как и кому передавать результаты своей деятельности. А на вопрос как это делать отнесли к компетенции работника. Agile, здесь я говорю больше об XP, плотно отвечает на вопрос как делать: как писать качественный код (TDD, Simple Design, YAGNI, парное программирование, постоянная сборка), как работать с требованиями (user stories, планирование итераций, приёмочные тесты FIT) и что делать с тестами. Я не хожу часто на левые совещания, я редко обновляю документацию, которую никто не читает (а если нужно, то это делается таской), но всё же моя работа более дисциплинирована чем в прошлой вотерфольной жизни.
Вотерфол демонстрирует «внешнюю» дисциплину – поставка чего-нить или какая-нить процессная церемония. Agile дисциплинирует участников проекта через их поведение и ежедневные активности. Лучше или хуже, но Agile оказывает большее внимание на стиль разработки и личную дисциплину.

Agile становиться Agile’ом, когда мы честно отказываемся от процессных церемоний, которые малоэффективны или не имеют значения, и концентрируем своё внимание на тех вещах, которые помогут повысить качество и продуктивность в нашем проекте.

За основу взят пост: link

Хотите знать архитектуру современных сервисов?

2008-09-26T18:20:00.002+04:00

Сегодня обнаружил афигенный блог Ивана: http://www.insight-it.ru/highload/

На этом блоге опубликована целая серия статей об архитектуре высоконагруженных систем на примере крупнейших интернет-проектов:

Архитектура Google
Архитектура Flickr
Архитектура Amazon
Архитектура YouTube
Архитектура Friends for Sale
Архитектура Wikimedia
Архитектура Digg
Архитектура LiveJournal
Архитектура Twitter
Архитектура Google Talk
Архитектура 37signals
Архитектура Mailinator
Архитектура LinkedIn

Видео отчёт AgileSummer 2008

2008-09-25T18:44:00.002+04:00

Видео отчёт о событиях недельной давности в Минске.

http://www.itv.by/search/search/agile#videocontentanchor

Обзор литературы (сентябрь 2008)

2008-09-23T11:54:00.005+04:00

Мини-обзор литературы, попавшейся мне на глаза и достойной нашего внимания

Growing Object-Oriented Software, Guided by Tests by Steve Freeman

Многообещающее название

The ThoughtWorks Anthology: Essays on Software Technology and Innovation by ThoughtWorks Inc.

Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin

Самая поздняя книга по качеству, смесь советов и smells, покрытых рядом рефакторингов. В общем ответ на моду выработки принципов кодирования уровня Code Style. Рекомендую как и остальные, но ставлю в конец моего списка :)

Самый последний список рекомендаций: http://agileconsulting.ru/wiki/Books

Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений (3 издание)

2008-09-23T11:31:00.008+04:00

Решил приобрести классику - почитать, полистать. Всё таки уже третье издание, всем советовал, а сам его и не читал не разу.

Выводы. Неплохая книга для начинающих. Солянка на типовые темы. Правда Agile там маловато (ни TDD, ни Refactoring, ни другие подходы не описываются), да и некоторые вещи явно уже устарели (с точки зрения процессов). Но общий подход к моделированию симпатизирует. В общем всё по верхам, но этого достаточно, чтобы начинающий разработчик понял что к чему в профессиональной (коммерческой) разработке.
Как всегда перевод Вильямся хромает.

По структуре книги:

* 200 страниц теории ООП в картинках (очень толковые определения)
* 100 страниц про UML
* 100 страниц по процессу (жизненный цикл, примеры XP & Scrum)
* 200 страниц примеры анализа и проектирования

Ссылка на все рекомендации: http://agileconsulting.ru/wiki/Books

Agile wiki

2008-09-18T09:53:00.003+04:00

По каким-то причинам не хочет открываться вики на AgileRussia, пришлось продублировать на своём сайте - http://agileconsulting.ru/wiki. Пока дублировал возникло неистовое желание туда чего-нить добавить. Поэтому ожидаю систематизацию существующей информации и пополнение вики новой :)

Подключайтесь :)

В ближайшее время добавлю информацию по командообразованию и ряду интересных практик (Agile Modeling, Emo-Cards, Квота идей и ещё чего-нить)

Кент Бек. Шаблоны реализации корпоративных приложений (Implementation Patterns)

2008-09-17T17:47:00.008+04:00

Я решил, что несколько рассуждений, которые вырываются из моей души после прочтения этой книги, помогут вам избавиться от деревянных символов (рублей) и приобрести за бумажки что-то более важное. Читал я ещё английский вариант, поэтому рекомендую русский. Хотя ещё не ознакомился с качеством переводом.
Не секрет, что руководители и разработчики не против повышения качества кода. Например, руководители, чтобы уменьшить количество денег на дальнейшее развитие, а разработчики, чтобы просто гордиться результатами своей работы. Сколько бы мы не проектировали, не анализировали, не планировали, но последнюю жирную точку ставит разработчик. Он воплощает идеи многих людей в конечный код, конечный продукт. Крайне опрометчиво не замечать важности участия разработчика в процессе создания результата. А вы уверены, что жирная точка будет идеальной? А может быть это будет клякса? Я нет :)
Многие ведущие разработчики знают различные современные технологии, получают огромные зарплаты за свои знания (и это хорошо), но они создают такой код, в котором разобраться в здравом уме невозможно (а это плохо). Требуется погружать себя в медитативное состояние созерцания реализации мыслей творческого человека. Но не забывайте, каждая минута, час, сутки, которые я трачу на созерцание запутанного кода, выходит работодателю в огромные суммы. И простое исправление ошибочки становится грандиозным исследовательским трудом по лабиринтам спагетти кода и неограниченной фантазии автора исходного кода.
Почему мы вынуждены писать сложный код? Почему мы создаем код, цена которого увеличивается с каждой новой строчкой? Почему поддержка кода становится в порядки раз дороже его создания?
Ответ простой. Нас не учили писать качественный код. Мы прячемся за качественные собранные требования или детально проработанную архитектуру. А как же код? Это пустяк и не требует профессионального к себе отношения. Но были попытки многих авторов давать советы в области написания кода. Были попытки сделать уравниловку, предлагая оградить разработчика самопальной или скопированной с прошлого места работы "Конвенцией по наименованию".
Сообщество Agile-разработчиков стремилось решить эту диллему качественного кода. Ведущие эксперты максимально заостряли внимания на лучших практиках в мире программной инженерии. Они первые внедрили и продвигали идеи "Шаблонов проектирования", "Рефакторинга", TDD и др.. Постепенно гуру Agile мира приближались к тому, кто больше всего времени проводит над конечным продуктом. Конечного и настоящего создателя ПО - разработчика.
Книга "Шаблоны реализации корпоративных приложений" (Implementation Patterns) от Кента Бека заполняет самую важную нишу создания программного обеспечения. Теперь Agile покрывает весь цикл разработки и даёт отточенные мировым опытом самые современные практики. Эти практики начинаются с наименования переменной, до управления проектами разработки корпоративных приложений. Замечу, это не серебреная пуля, а всего лишь набор успешных практик и шаблонов, использование которых повышает ваш шанс на успех.
Я считаю, что книга "Шаблоны реализации" произведёт революцию в качестве кодирования. Она должна вытеснить неуклюжих бегемотов под названием "Coding and Naming Convention" (конвенции по наименованию и кодированию). Конечно, бегемотики не исчезнут полностью, но изменят масштабы, превратившись в настольные сувениры. Важность "Шаблонов реализации" в том, что качество кода определяется общим пониманием каждого разработчика единых ценностей и принципов высокопрофессионального кодирования, а не сухими структурными правилами (конвенцией) любителей излишней формализации.
Самый главный секрет создания качественного кода и проекта - это писать программы не для компьютера, а для людей. Это прописная истина, которая около сорока лет не имела реализации. Шаблоны реализации говорят как реализовать эту истину. Эта реализация состоит из трёх уровней: уровня ценностей качественного кода, уровня принципов и уровня паттернов.

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

Эта книга будет достойным пополнением в коллекцию изданий для профессиональных разработчиков. Если вы хотите, чтобы каждый разработчик писал качественный код, то эта книга должна быть куплена из средств выделяемых на развитие персонала. Я работал в крупных компаниях, там всегда обещают, что компания гарантирует профессиональный рост своим работникам, но редко когда компании реализовывали свои обещания. Купив эту книгу каждому разработчику, вы сможете выполнить обещанное, а в отместку разработчики смогут улучшить архитектуру проекта, микродизайна и самое главное качество кода улучшится в порядки.
Материалы книги послужили мне хорошим источником для тренингов по качественному кодированию и сформировали багаж знаний, которым я делюсь во время проведения коуч-сессий.

Денис Миллер
Независимый Agile тренер и коуч.
Microsoft Certified Trainer
http://www.AgileConsulting.ru

Agile - утопия для утомлённых менеджеров

2008-09-17T17:47:00.005+04:00

Эффект ореола…и другие восемь иллюзий, вводящие менеджеров в заблуждение
Розенцвейг Ф.

Розенцвейг утверждает, что наиболее популярные идеи в бизнесе ни что иное, как успокоительные банальности, обещающие обеспокоенным менеджерам быстрый успех.
Эти "бизнес-иллюзии": общепринятые и глубоко укоренившиеся убеждения являются результатом "эффекта ореола", или, говоря иначе, нашей потребности приписывать исключительно положительные качества любой компании, достигшей успеха. Вера в эти иллюзии служит менеджерам успокоением, помогающим обосновать решения, а также позволяет значительно упрощать реальность и игнорировать постоянные требования меняющихся технологий, рынков, и потребителей. Книга также разрушает мифы об успехе, построенные на эмпирике, и говорит о вещах, о которых долгое время никто не решался говорить вслух. Автор обращается к здравому смыслу, и к статистике, чтобы критично взглянуть на многочисленные "пяти-" или "четырех-" ступенчатые мифы построения успешной компании. Книга доказывает на примерах, что a) секретного рецепта корпоративного успеха не существует и b) успех – вещь изменчивая.

Отзывы: http://markus.spb.ru/biblioteka/rozencveig.shtml

Квота идей

2008-09-16T14:32:00.008+04:00

Интересная практика для адаптации существующего процесса, да и просто интересная практика развития команды и проекта обнаружена у Джона Паттерсона, президента компании "Нэшнл кэш реджистер". Он всё время записывал :)

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

Практика "Квота идей"
Установите квоту: в день столько-то новых идей, касающихся вашей работы или проекта, - например, по пять идей в день в течении одной недели.

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

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

Дополнительно:
1. Майкл Микалко. Игры для разума
2. Технологии шевеления мозгами
3. Советы по генерации идей

Agile English (как учить английский по Agile)

2008-09-15T21:41:00.003+04:00

Мини-инструкция по изучению английского языка. Идея родилась вчера и уже мною заиспользована.

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

2. Услышал новое слово - выписал на карточку (3x4 см)
- с одной стороны слово
- с другой стороны всё предложение, в котором это слово встретилось (вместо слова в предложении оставляю пробел)

3. Оцениваю в English Points сложность изучения этого слова (см. Story Points у Mike Cohn)

4. Переслушиваю абзац, в котором было обнаружено новое слово.

5. Повторяю над каждым незнакомым словом по тексту.

6. Повторно прослушиваю запись.

В результате на руках у меня будут карточки. В свободно время я их перебираю, вспоминаю слова, контекст рассказа. То что запомнилось откладываю. В конце дня подбиваю суммы выученных слов в English Points и радуюсь результатам рисуя диаграмму Velocity ;)

* Ничего не мешает по этому же принципу учить грамматику. Маркер правило на одной стороне карточки, пример правила на другой.