Отзыв о Study-Group

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эрих Гамма (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

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

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

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

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

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

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

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

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


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

Есть ли Agile?

Странно видеть на форумах воинствующих проповедников анти-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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 издание)

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

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

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

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

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

Agile wiki

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

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

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

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

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

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

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

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

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

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


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

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

Квота идей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конференция AgileSummer, 19 сентября, Минск

19-го сентября в Минске состоится знаковое событие в мире гибких методологий - пройдет мега-конференция Agile Summer 2008.

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

• Agile: больше денег, меньше рисков Денис Петелин
• Почему менеджеры любят Agile Александр Орлов
• Почему я не верю в Agile Слава Панкратов
• Design with agility Дмитрий Губа
• Динамика развития Agile-команды Денис Миллер
• Роль менеджера проекта в Agile команде Павел Афанасенко
• Agile в больших проектах Асхат Уразбаев
• Психология Agile проекта Юрий Шиляев
• Использование User Stories в Agile проектах Павел Габриэль
• Проектирование пользовательских интерфейсов в Agile Геннадий Драгун
• Continuous Integration для 5000 человек Влад Жидков

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

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

Интересный подход разработки - проектирование по контракту. Основы подхода заложил Бертрана Мейера. Чтобы быстро разобраться рекомендую классную статью:
http://habrahabr.ru/blogs/crazydev/38612/

Немного философии и сопряжения этой идеи с C#:
http://tagirovarthur.blogspot.com/2007/11/1.html
http://tagirovarthur.blogspot.com/2007/11/2.html

Ну и самого великого маэстро можно читать бесплатно здесь:
http://www.intuit.ru/department/se/oopbases/11/

User Group: Изучение качественного кодирования!

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

Цель встреч: изучение и углубление знаний в области design patterns. Мы практикуемся и обмениваемся опытом в сфере качественного кодирования, шаблонов, рефакторинга и т.п. (см. выше).

Study Group – помогает осилить сложные книги и идеи, может помочь там, где другие проваливаются, и он поможет тогда, когда в вашем окружении нету тех, кто хочет учиться и расти.



Место встречи:
Кафе в центре Москвы,
Каждую среду в 19 часов
Контакты: syspo_mail.ru
ICQ: 20079282
skype: denis_miller
+7 917 518 68 12 (Денис)

Принцип проектирования: LSP

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

Как назначать задачи в Agile (Task Volunteering)

Вопрос по назначению задач не даёт спать. В ряде веток Agile задачи назначаются руководителем (см. FDD методологию). Но в основном принято задачи разбирать самими разработчиками. Остаётся вопрос - когда?

Вариант 1 (Tasks ownership). В начале итерации все расхватывают задачи, а потом уже помогают друг другу. Общий пул задач. Каждый, кто освободился, берет себе задачу с наивысшим приоритетом.
+ Ориентация на общее решение (приоритетность задач)
+ Выполняется максимально возможное количество самых приоритеных задач
+ Возрастает мотивация (я выбираю сам согласно приоритету, я являюсь вкладом в командный успех)
+ Командная ответственность
+ При появлении высокоприоритетных задач во время итеррации их легко отправить в разработку
+ Можно "вынашивать" решение: есть время подготовится к решению задачи в свободное от работы время (поразмышлять, почитать лит-ру), а потом поделиться размышлениями с коллегой, взявшим задачу
+ Общее владение кодом
+ Общий стиль программирования
+ Кросс-функционалность
+ Повышение коммуникации

Вариант 2 (Individual Commitments). Общий стэк задач на всю итерацию, и каждый отхватывает самую приоритетную.
+ Ориентация на личные предпочтения
+ Возрастает мотивация (я выбрал задачи сам)
+ Индивидуальная ответственность
+ Специализация разработчиков
+ Можно "вынашивать" решение: есть время подготовится к решению задачи в свободное от работы время (поразмышлять, почитать лит-ру)
- Разные стили программирования
- Незаменимость учатников
- Снижение коммуникации

Я работал в обоих вариантах. Есть свои плюсы и минусы в обоих. Предлагаю послушать эксперта в области оценки в Agile проектах:

Individual Commitments

When assessing the ability to commit to completing a set of new functionality,
some teams prefer to allocate each task to a specific person and
then assess whether each individual is able to commit to that amount of
work. This approach works well and I’ve recommended it in the past
(Cohn 2004). However, I’ve found that by not allocating tasks while planning
the iteration and not doing the personal math needed to make individual
commitments, the team benefits from the creation of a “we’re
all in this together” mindset.

If you do find a need to allocate tasks to individuals while planning an
iteration, the allocations should be considered temporary and subject to
complete change once the iteration is planned and underway.

src:
1. Mike Cohn Agile Extimating and planning
2. Беседа с Ильёй Сербисом :)

НЛП-Практик

Буквально несколько дней назад у меня завершился тренинг "НЛП-Практик", который я проходил под руководством тренеров из http://institutnlp.ru

Тренинг понравился. Оправдал все мои ожидания. А я ожидал тренировок, тренировок и ещё раз тренировок. Информация тренинга хорошо легла с тренингом "Личностного роста", о котором я писал ранее.

Воодушивишись полезностью этого дела я открыл пару сайтиков. Так что присоединяйтесь:
http://wikinlp.org
http://wikinlp.ru (http://ru.wikinlp.org)

Google Reader

Вчера я открыл для себя Google Reader. Я всегда мучался в выборе RSS-читалки, а мне тут показали ЭТО.

Что может:
- в созданном профиле на googl'e делаю коллекцию своих rss
- с любого компьютера, где есть браузер логинюсь к google и читаю свои rss
- ...
- Google Gear - оффлайн читалка
- САМОЕ ГЛАВНОЕ: расшаривать rss между друзьями (когда друг отмечает понравившуюся у себя статью и она попадает в rss ко мне - очень клёво!)

а вот так выглядит RSS-реадер от Гугл:



Приглашаю в друзья, чтобы обмениваться самыми лучшими rss статьями :)
http://www.google.ru/reader/shared/10092112600447100350

Самообучающаяся команда (self-education team). Agile Learning Game (A[g]LeGa)

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

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

И есть 5 дисциплин, которые необходимо практиковать в любой организации (каждому ее члену), чтобы перейти в статус действительно обучающейся и развивающейся:
1. Осознание и исследование ментальных карт и характеристик усвоения.
2. Достижение и поощрение персонального мастерства.
3. Развитие видения и сознания будущего.
4. Поощрение группового общения.
5. Развитие способности системно мыслить.

Реализуя возложенную на команду обязанность мы попробовали разработанную мною практику Agile Learning Game. Результаты которой вы видете на доске. В дополнение были глобальные обсуждения, синхронизации словаря команды. Вовлеченность была огромная. Завтра повторим и разовъём.

Agile (видеотренинг). Agile, Scrum, XP и др. - как не запутаться в современных buzzword'ах (часть 2 / 8)

Почему нужен Agile (материалы семинара "Как продавать Agile")

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

Слушаем :)

Видео тренинг Agile. Что такое Agile (часть 1/8)

Теперь меня в телевизоре можно видеть :)



Здесь рассказываю об истоках Agile. Чем он отличается от Waterfall. Чем отличается от процесса с прототипированием. В общем, певрвая серия сезона "Основы Agile" часть 1.

Приручение БОССа

Great Boss Dead Boss by Ray Immelman



Если ваш руководитель мешает вам играть в Agile, мешает проводить planning game и играть в покер, заказчиков превращает НЛО (все о них говорят, но никто их не видел), а ещё хуже проводит часовые Daily Scrum Meeting и все резинки закончились, а на ретроспективе вааабсче скукотища. То настало время сделать подарок своему боссу! :)

Практическая конференция "Agile дни" (Agile Day)

21 Июн	Agile дни в Москве г. Москва Сб, 28 Июня 2008 в 10:00

Test-Driven Development (TDD) в картинках

| View | Upload your own

Personal Scrum

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

Personal Scrum (тренинг управления собственного времени для разработчиков)
Тренинг повышения личной эффективности. На тренинге рассматриваются способы организации времени на основе Scrum методологии. Уделяется внимание ежедневному планированию и выполнения планов с минимальными затратами. Изучаются всякие хитрые приёмы оптимизации времени.

Краткое содержание:
1. Целеполагание
2. Составление Personal Backlog
3. Проведение Personal Iteration
4. Retrospective (Daily / Iteration)
5. Использование TDD для управления задачей.
6. Приёмы эффективного чтения.
7. Использование тулзов.
8. План персонального развития.

Продолжительность: 2 дня

Повышаем качество проекта и эффективность команды

Приглашаю в гости на новые тренинги:

Тренинг "Самодокументируемый код" - все о нём говорят, но никто не знает, что это такое. Повод разобраться.

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

Тренинг "Шаблоны построения эффективной ИТ-команды" - простые практики, которые проведут вашу команду через формирование и шторминг, к нормингу и перформингу (4 стадии развития) в кротчайшие сроки. На выходе вы получите сплочённый коллектив.

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

agile.rpod.ru (аудио-подкаст)

Буквально совсем вчера :) в сети появлся подкаст! Куда я вас и приглашаю - http://agile.rpod.ru

Цель подкаста - самовыражение. Суть подкаста - публикация того, что я могу делать, что мне нравиться. Список тем: agile, scrum, extreme programming, design patterns, architecture patterns, agile modeling, test-driven development, refactoring, smells и все другие буз-ворды! Подцель - возбуждение интереса и дискуссий!

Вперёд товарищи! На баррикады!

Agile в Ростове

Вчера вернулся домой из Ростова-на-Дону, где всю неделю с ребятами из команды eSignal работали на тему "Инженерные практики Agile". За 6 дней тренингов мы охватили такие направления как Design Patterns и Refactoring. В последний день провели результирующую очень мощную коучинг-сессию, в которой поговорили о тестировании, командном взаимодействии и разработали новую Agile-практику (которую обещали проверить в ближайшее время).

А в один из вечеров мы организовали открытый семинар на тему "Эволюционный дизайн" с точки зрения Agile. В обсуждениях приняли участия около 30 самых прогрессивных ИТ-ростовчан.

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

Так держать!

Соглашаемся на некачественный код

В предверьях семинара http://profyclub.ru/projects/seminars/2588/ я изложил свои мысли в виде статьи. Предлагаю ознакомиться и покомментировать :)

Соглашаемся на некачественный код
Денис Миллер

Что скрывается за качеством кода? Минимально количество ошибок? Правильно оформленные названия полей и методов? Жесткое распределение файлов проекта по папочкам? С точки зрения Стива Макконнела [2] качество системы снижает расходы на её разработку. Чем меньше мы усилий тратим на понимание своего же кода, тем легче мы добавляем новый функционал. Продолжая эту мысль – чем меньше мы допускаем запутанности кода, тем лучше качество. Часто разработчики говорят, чтобы в будущем было легче разобраться в коде, нужно выработать «Соглашение о наименовании». Ниже я покажу , что такое соглашение имеет смысл, но с качеством кода связанно косвенно.

В начале разработки сложных приложений ведущие разработчики и менеджеры проектов ставят перед командой вопрос о принятии «Соглашения о наименовании» (Coding & Naming Convention, сокращённо CNC). Фактически дав разрешение на религиозную войну. Соглашение есть способ документирования опыта, предпочтений и привычек одного из разработчиков. Преимущественно документируется (навязывается) опыт ведущего разработчика. Если бы было не так, то в команде в 7 человек, должно появиться как минимум 7 соглашений. Многие команды, чтобы избежать разногласий выбирают соглашение рекомендуемое авторитетным источником (Java [5], .Net [6]). Другой вариант, когда команда принимает соглашения уровня корпоративного стандарта.

Если посмотреть со стороны на процесс принятия соглашения. То можно заметить, что происходит парадоксальная ситуация. Команда забывает, что суть соглашения не в наименовании, не в авторитете, а в том, чтобы поддержка разработанного кода была легче и самое главное будет легко передан смысл кода. Когда любой разработчик сможет обратиться к написанному мною участку кода и этот участок будет понятен. Проведём аналогию с русским языком. Грамматика и орфография является неким соглашением. Но если так, ТО Сей4ас Я наPушИЛ соГлашеНИЕ По НАИМеноВанИЮ. Но смысл понятен и я легко могу внести изменения.

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

Важнее определить не соглашение. А принципы, из которых должны исходить разработчики, чтобы код был легок в поддержке, сопровождении и дальнейшем развитии. А таких принципов три[3]:
1. Коммуникация
2. Простота
3. Гибкость

Код пишется не для компьютера, а для человека. Первый принцип говорит, что разрабатывая код подумайте: сможет ли его прочитать другой человек? сможет понять его смысл? Второй принцип подсказывает, что требуется выбирать наиболее простое решение. А любую сложную функциональность (например, метод больше 10 строк [1]) декомпозировать на несколько простых. Гибкость – самый сложный принцип, за его реализаций предлагаю обратиться к шаблонам проектирования (design patterns)[7].

Исходя из указанных принципов можно строить уже не стилистическое соглашение CNC, а смысловое. Косвенно о таком соглашении идёт речь в книге «Совершенный код» Стива Макконнела[2] и ещё больше рассказывает о реализации трёх принципов Кент Бек [3].
В семинаре выбран другой, но не менее важный подход. Подход известный в математике «от обратного». Определив соглашение в виде положительных утверждений, мы не определяем случаи злоупотребления теми или иными конструкциями. Которые не несут ярко выраженного отрицательного эффекта для разработчика и даже соответствуют «соглашениям». Такие случаи только потенциально могут привести к сложности кода. Их называют - smells. Так если каждый программист будет допускать их появление, то они будут накапливаться словно снежный ком. И через буквально 1-2 месяца разработки корректный с точки зрения «соглашений» код будет совершенно нечитаемый с точки зрения смысла.

Семинар предлагает командам принять новое соглашение, которые должно сформироваться на основе каталога smells. "Code smells" сигнализирует о потенциальных сложностях кода. Правильная интерпретация этих сигналов позволит вам выявлять некачественный код, затрудняющий разработку и приводящий к удорожанию решений, а также трудности модификации существующего кода. Предлагаемая практика полезна как малым командам, так и крупным предприятиям, вовлеченным в промышленную разработку. На семинаре мы рассмотрим общий каталог Smells, включающий различные уровни: кодирование, базы данных и архитектуру. Особое внимание мы уделим каталогу некачественного кода и способа устранения smell’ов – рефакторинг. Один из первых авторов, кто поднял тему рефакторинга и работы со smell’ами является Мартин Фаулер [1].

Внедрение нового подхода в кодировании требует определённые усилия. Во-первых, нужно изменить порядок принятия соглашения. Заменить принятие правил как цельного документа на постепенное (итерационное освоение, см. принцип итерационного подхода в Agile-методологиях). Так предлагается построить приоритетный список некачественных решений по степени появления. После одобрения всей командой в течении одной итерации осмысленно и целенаправленно избегать пять самых приоритетных smell’ов и проводить рефакторинг над ними. Здесь можно использовать техники парного программирования, code review различного уровня. В завершение итерации добавить встречу для обсуждения (Smell Meeting). Во-вторых , требуется изменения режима разработки. Заменить устоявшуюся цепочку задача-модификация-тестирование на задача-рефакторинг-модификация-рефакторинг-тестирование. А в дальнейшем посмотреть на популярный на западе подход к самоорганизующимся и самообучаемым командам на основе Agile-подхода[7, 8] в разработке.

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

Дополнительно:
1. Мартин Фаулер. Рефакторинг. Улучшение существующего кода
2. Стив Макконнелл. Совершенный код. Практическое руководство по разработке программного обеспечения
3. Kent Beck. Implementation Patterns
4. Э.Гамма «Приемы объектно-ориентированного проектирования. Паттерны проектирования».
5. Code Conventions for the JavaTM Programming Language. http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
6. .NET Framework Developer's Guide Guidelines for Names.
http://msdn2.microsoft.com/en-us/library/ms229002.aspx
7. Российское Agile сообщество.
http://agilerussia.ru
8. Рассылка «Инженерные практики Agile».
http://subscribe.ru/catalog/comp.soft.prog.agile

Новая рассылка

Для придания динамизма теме качественного кода я открыл рассылку http://subscribe.ru/catalog/comp.soft.prog.agile

Присоединяйтесь!

Семинар "Гибкие методологии Agile. Эволюционный дизайн"

13 Фев	Гибкие методологии Agile. Эволюционный дизайн. Бизнес-центр «Купеческий двор» Ср, 13 Февраля 2008 в 19:00

Training Refactoring

28 Янв	Тренинг Рефакторинг Офис Люксофт Пн, 28 Января 2008 в 09:00

Научное исследование эффективности методологии TDD

Сразу с цитат:

We found that test-first students on average wrote more tests and, in turn, students who wrote more tests tended to be more productive. We also observed that the minimum quality increased linearly with the number of programmer tests, independent of the development strategy employed.

За счёт TDD были достинуты:
- лучшее понимание задачи
- лучшее фокусировка на задаче и повышенное внимание к задаче
- лучше обучаемость
- низкий процент переделки

Отчёт: Proceedings of the IEEE Transactions on Software Engineering, 31(1). January 2005.
Ссылка: источник

Инструкция превращения Junior Developer'a в Agile-профи

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

Начинаем
Первым делом нужно дать сводные понятия о таких вещах как
# Agile Software Development
# Scrum
# Domain Driven Design
# Test Driven Development
# Object Oriented Design
# Enterprise Design Patterns
# Secure Development Lifecycle
# Дальше конкретные технологии (ASP.NET/BizTalk/SharePoint/WCF/WPF/etc)

Важные понятия
Чтобы стать сильным Agile объектно-ориентированным разработчиком вам обязательно нужно будет ряд простых понятий:
Separation of Concerns
Liskov Substitution Principle
Law of Demeter
Single Responsibility Principle
Open/Close Principle
Interface Segregation Principle
Dependency Inversion Principle

Закупаем литературу
Чтение статей и участие на форумах не сделает из вас сильного разработчика. Нужно обратиться к фундаментальным работам.
# Agile/Development Principles
  * Code Complete: A Practical Handbook of Software Construction (Steve McConnell)
  * Agile Software Development, Principles, Patterns, and Practices (Robert C. Martin)
  * Agile Principles, Patterns, and Practices in C# (Robert C. Martin)
  * Agile Software Development with SCRUM (Ken Schwaber)
  * User Stories Applied: For Agile Software Development (Mike Cohn)
  * Practices of an Agile Developer: Working in the Real World (Andrew Hunt)
# General Development
  * Release It!: Design and Deploy Production-Ready Software (Michael Nygard)
  * Ship it! A Practical Guide to Successful Software Projects (Jared Richardson)
  * The Pragmatic Programmer: From Journeyman to Master (Andrew Hunt)
# Design Patterns
  * Head First Object-Oriented Analysis and Design (Brett McLaughlin)
  * Patterns of Enterprise Application Architecture (Martin Fowler)
  * Design Patterns: Elements of Reusable Object-Oriented Software (GoF)
  * Head First Design Patterns (Elisabeth Freeman)
# Domain Driven Design
  * Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans)
  * Applying Domain-Driven Design and Patterns: With Examples in C# and .NET (Jimmy Nilsson)
# Test Driven Development
  * Test Driven Development: By Example (Kent Beck)
  * xUnit Test Patterns: Refactoring Test Code (Gerard Meszaros)
  * Pragmatic Unit Testing in C# with NUnit, 2nd Edition (Andrew Hunt)
# Refactoring
  * Refactoring: Improving the Design of Existing Code (Martin Fowler)
  * Refactoring to Patterns (Joshua Kerievsky)
# Secure Development Lifecycle
  * The Security Development Lifecycle (Michael Howard)
  * Writing Secure Code, Second Edition (Michael Howard)

И специализированная литература:
# C#/.NET Framework
  * CLR via C#, Second Edition (Jeffrey Richter)
  * Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Krzysztof Cwalina)

Следующий шаг
Теперь нам нужно научиться это применять, а усилит это практика "парного программирования", написание в стиле TDD. Было бы неплохо, чтобы за вами приглядывал опытный товарищ, но это не должно вас останавливать.

Источник: Starting Junior Programmers on the Right Agile Track Guidance

FxCop 1.36

Качество кода конечно же невозможно без всевозможных тулзов. Сегодня я хотел бы обратиться к уже известной программе FxCop. А причина довольна проста - её реанимация. Буквально недавно Microsoft выпустил вторую бету новой версии FxCop 1.36. Будем надеятся, что скоро будет релиз :)

FxCop is a code analysis tool that checks .NET managed code assemblies for conformance to the Microsoft .NET Framework Design Guidelines. It uses MSIL parsing, and callgraph analysis to inspect assemblies for more than 200 defects in the following areas:

Library design
Globalization
Naming conventions
Performance
Interoperability and portability
Security
Usage

Ссылка: Microsoft FxCop 1.36 Beta 2

Видео "Lean: cовершенствование процессов разработки"

Доступно видео "Lean: cовершенствование процессов разработки"!!! Пока есть только первый семинар из двух, проходивших 26-го декабря. Второе видео будет скорее всего готово на следующей неделе

 

Lean и роль менеджера в Agile. Бесплатный семинар.

12:25 pm - Семинары "Lean и роль менеджера в Agile"

26 Дек	Семинары "Lean и роль менеджера в Agile" Luxoft Ср, 26 Декабря 2007 в 19:00

Мэнеджмент проекта vs JIRA

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

http://confluence.atlassian.com/display/JIRAEXT/Agile+Wall+Report
http://confluence.atlassian.com/display/JIRAEXT/Agile+Velocity+Tracking+plugin
http://confluence.atlassian.com/display/JIRAEXT/JIRA+Charting+Plugin
http://confluence.atlassian.com/display/JIRAEXT/Timecharts
http://confluence.atlassian.com/display/JIRAEXT/Links+Hierarchy+Reports
http://confluence.atlassian.com/display/JIRAEXT/Laughing+Panda+JIRA+Agile+Report+Plugins

И дальше по ссылкам. Очень порадовало заточка ряда плагинов на Agile практики. Так что дерзайте!

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

Personal Sprint

Приведу стэк задач, начнём с наиболее крупной и дальше по убывающей.

1. Vision. Общие знания о проекте, стратегия его развития, фундаментальные принципы декомпозиции и т.п. То что почти не меняется. Стратегические цели. Оценивается бизнес-значимостью.
2. User Stories. На первом месте требования пользователей. Это самые крупные, можно сказать тактические цели в рамках проекта. Оценивается бизнес значимостью и Story Points. Что такое story points? Это сипульки. Условное обозночение трудозатрат, оценивается разработчиками.
3. Tasks. Задачи для разработки. Конкретные задания, которые должен выполнить участник команды. Оценивается в часах. Продолжительность от 1 часа до 1 дня.
4. Personal Sprint (Checklist, TestList). Записи в блокнотике. Каждый разработчик разбивает Task на мелкие шаги. После каждого шага вычёркивает пукнт из List. Для практикующих TDD см. паттерн Test List. Это список тестов, которые нужно написать. Продолжительность от 10-20 минут до одного часа.

Последний пункт может выглядить примерно так. Я хотел сделать "тупой маленький чеклист" для рефакторинга перемещение поля:
1. модифицировать все установки поля (setter)
2. модифицировать всех читателей поля (getter)
3. удалить объявление поля
4. и так далее в таким же простым способом

Можете наконец-то в своём IDE воспользоваться окошком TODO ;)

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

Плюс от таких бумажек следующий - МАТЕРИАЛИЗАЦИЯ. Голова хорошо, но простой список задач проще. Профессиональные медики (см. фильмы зарубежные) ходят с checklist'ом и отмечают галочками выполненные задачи (приём таблеток, процедуры и т.п.). И этому учат их в институте. Так почему такая простая практика отстутствует в арсенале профессионального разработчика? Вы не знаете чем заняться глянули в список и выбрали. Не знаете чем убить минутку до совещания. См. в список.

На закуску пару интересных ссылок не по теме :)
1. Visual Studio Team System 2008 Team Foundation Server Power Tools
http://msdn2.microsoft.com/en-us/tfs2008/bb980963.aspx
2. Год MSDNWiki
http://blogs.msdn.com/sandcastle/archive/2006/09/06/742352.aspx
3. Google.vs.Wiki
http://itblogs.ru/blogs/kav/archive/2007/12/21/24329.aspx

А вы Agile команда?

Ответьте на 4 вопроса Скотта Амблера и вы поймёте Agile-команда вы или нет.
Вопрос 1. Покажите свои Unit-тесты.
Вопрос 2. Познакомьте меня со своим заказчиком
Вопрос 3. Покажите ваш CM (configuration managenet)
Вопрос 4. Покажите вашу самоорганизацию.

Если на все четыре вопроса я увижу в вашей команде ответ, то вы Agile-команда!

Показ мод от Microsoft 2008

ADO.Net Entity Framework beta 3. Решение ORM от Microsoft.

ASP.NET 3.5 Extensions Preview - MVC каркас

Определите национальность

Определите национальность автора кода

//--------
boolean b;

if(b.toString().length() >4){...}
//-------

Dream Team: Первый шаг

Сегодня провели первый старт. Микро-отчёт.

1. Повешана White Board + Status Board
2. Рассмотрены следующие практики:
2.1. Dialy Scrum Meeting
2.2. Атрибутика для DSM: мечь кладенец, банка для добровольных пожертвований.
2.3. Коллективное притяние решение из Базового Протокола.
2.4. Niko-niko календарь.
2.5. User Story в формате "As a user ..." (см. Mike Cohn)
3. Поговорили о целях, целеполагании.

Сложности были в обсуждении п.2.3. Не все решения могут коллективно приниматься. Например, административные. В п.2.1. было сложно договориться во сколько же собираться. Решили договориться на 13 часов. Основной аргумент, чтобы до обеда порешать задачи, которые могут возникнуть после митинга. Сложность в п.2.2. это сама концепция штрафа (банка) была неудобна одному участнику. Согласились действовать по принципу "кто что сможет"; то есть штраф за опоздание на планёрку не строго типизирован: конфетки, деньги и т.п. а гибче "кто что сможет". Niko-niko календарь в основном все поддержали, не поддержавший сказал детские игры. И пришлось признать себя большими детьми :)

Провели ретроспективу на практики и решили заиспользовать в течении следующей недели.
Продолжительность первого шага: 1 неделя.

PS. Таски на жёлтых стикерах признаны для обсуждения (например религиозного). Запланировали повесить возле доски контейнеры для разноцветных стикеров. Возле Nico-nico календаря весит пачка фломастеров.

TeamCity 3.0

Похоже команда Jetbrains решила захватить рынок традиционным способом - БЕСПЛАТНО.

Now available for free, TeamCity 3.0, delivers multiple improvements in different areas and extends support for both Java and .NET software development teams. To name just a few: a new licensing policy, per-project roles and permissions, build statistics charts, .NET code duplicates search, VCS integration enhancements, upgraded performance, and a better user experience.

The key new features of this release include:

• Per-project access rights with project roles – an exclusive feature of the Enterprise edition
• Build statistics charts, with declarative pluggable charts for user-defined metrics
• Pre-tested commit from Visual Studio for Subversion
• StarTeam support
• .NET Duplicates finder for catching similar code fragments of your C# and Visual Basic .NET code
• Java Inspections and Duplicates for Maven2 projects
• Version Control labeling for Subversion, CVS, Perforce, StarTeam, ClearCase
• “Hanging” builds auto-detection and thread dump capturing, for quick feedback on Java and .NET builds’ problems
• Display of build start/finish estimations in the build queue
• Build tags for organizing and quickly filtering builds

To learn more about new features in TeamCity 3.0, please visit
www.jetbrains.com/teamcity/features/newfeatures.html?tc30a.

For additional details about the new licensing scheme for Professional, Enterprise and Open Source licenses, see http://www.jetbrains.com/teamcity/buy/?tc30a .

Existing TeamCity users qualify for a free upgrade to the most feature-rich Enterprise edition. For details, go to http://www.jetbrains.com/teamcity/buy/index.html#upgradeuser?tc30a.

Agile Practices

Сегодня причесал вики сайта http://AgileRussia.ru. Основной упор сделал на разделение всего Agile мировозрения на две вещи: 1) практики и 2) методологии.
Соответственно в практиках будет накапливаться информация о всевозможных Agile-практиках, которые планируется собрать со всего интернета. Кстати, подключайтесь, дел много, заодно узнаем много нового.
Во втором разделе классификация этих же практик с точки зрения авторов методологии.

Сам ресурс доступен по адресу: http://agilerussia.ru/wiki/index.php?title=Practices

PS. В середине недели дам доступ :)

Dream Team: Создание новой Agile-команды

Буквально со следующего понедельника стартует подготовка новой Agile-команды. На страницах своего блога я собираюсь поведать как всё будет происходить. Фактически, команда собрана и уже давно успешно работает. А нам остаётся только прийти на готовенькое и внедрить самое-самое.

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

Итак, жду вас на следующей неделе. Буду сообщать с фронта событий.

Мы делаем новости!

Dependency Injection Application Block

Ребята в Microsoft решили обзавестись своей реализацией Spring.Net. Дали ей название Dependency Injection Application Block. Такое творение ожидается в следующей версии Enterprise Library.

Более подробно читайте об этом слухе - здесь

Функциональный стиль C# 3.0 в помощь качекодуру

Качкодер (сокращённо качёк) - человек, которые пишет качественный код.

В блоге Ивана появилась первая статья о функциональном программировании. Вырежу самые приятные слова, за остальным заходите к Ivan'у :)

Polygon triangle =
  new Polygon {
    new Point { X = 3, Y = 5 },
    new Point { X = -5, Y = 4 },
    new Point { X = -1, Y = -6 }};

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


В чем же цимус от использования неизменяемых объектов, вместо обычных переменных? На самом деле мы получаем целый ворох конфет:
- Отсутствие побочных эффектов. Работа любой функции гарантировано зависит только от входных параметров и результатом ее работы являются только выходные параметры.
- Мы можем совершенно безопасно отдавать свой объект наружу во временное пользование, у нас есть 100% гарантия, что его никто не испортит.
- Отладка упрощается в разы. Все с чем будет работать функция лежит в стеке вызова.
- Повышается эффективность тестирования.
- Колоссально упрощаются алгоритмы синхронизации доступа из разных потоков.
- Появляется возможность автоматически распараллеливать выполнение задач.
- Существенно упрощаются алгоритмы хэширования и выявления эквивалентности.
- Реализация Undo/Redo, причем не только структур данных, но и хода выполнения программы становится тривиальной.
- Появляется возможность заменять произвольные функции не останавливая всей программы. (Реально существуют приложения на Erlang-е, работающие годами без остановки, код которых был заменен целиком)
- ... и много других приятных плюшек.

Джимми Нильссон. Применение DDD и шаблонов проектировани - пример некачественного перевода.

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

"Отличная книга, жалко конечно все это дело опубликовано на туалетной бумаге. За такую бумагу 650 рублей брать, это беспредел. Об этом написал в само издательство никаких ответов. Опечаток тоже очень много, переводили наскоро наверно. Об этом я также упомянул в письме издателю."

"Кроме опечаток есть и просто неправильный перевод профессиональных терминов, что несколько раз меня уже вводило в ступор"

А теперь мой собственный комментарий. Зелёную полосу называют провалившимся тестом. TestFixture — обозвали тестовой конфигурацией на схеме. Mock объект имитацией. А самовольная замена DDD на ППО, а TDD на РПТ — бесчинство и яркое неуважение к читателю.

Пару ярких цитат: "Тест компилируется, но даёт положительный результат (красную полосу)" (стр.464) в оригинале "It compiles, but it turns red.". А от этого плакать хочется: "Теперь тест даёт наконец-то отрицательный результат (зелёную полосу)!" (страница 467 внизу)

Вывод: НЕ ПОКУПАЙТЕ!!! ЧИТАЙТЕ ОРИГИНАЛ!!!

Software Factories (Фабрики разработки программ)

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

1) Джек Гринфилд и Кит Шорт, при участии Стива Кука и Стюарта Кента Фабрики разработки программ. Потоковая сборка типовых приложений, моделирование, структуры и инструменты (Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools)
2) Practical Software Factories in .NET by Gunther Lenz and Christoph Wienands
3) Agile Software Factories by Damon Wilder Carr (Author)



Для начала можно начать с wikipedia: http://en.wikipedia.org/wiki/Software_factory. А затем на хорошо проработанную страничку http://msdn2.microsoft.com/en-us/teamsystem/aa718951.aspx

Аудио-подкасты для программистов

Совсем давно мой хороший знакомы (привет Кирилл!) посоветовал хоороший список аудио-подкастов для разработчиков. Прослушивая их вы убиваете двух зайцев: 1) узнаете самые новые идеи из уст гигантов софтварной индустрии, 2) подкачиваете английский.

Так что подключайтесь к прослушиванию:

* DotNetRocks
* Hanselminutes
* Bits Of Sillicon Hell
* Developer Night in Canada (although it is dormant for a long time)
* Code Sermon
* FLOSS Weekly
* Mondays
* Polymorphic Podcast
* Security Now
* Software Engineering Radio
* This Week in Tech
* Web Dev Radio
* Windows Weekly

(искать в google)

Surprising criticism from parting Microsoft development lead

Jay Bazuzi, once Development Lead for the C# Editor, is leaving Microsoft, and he wrote some surprisingly harsh parting words for his friends before he left; things like “OO isn’t a fad” and that “It’s OK to use someone else’s code”.

Оригинал: ссылка
Источник: ссылка

Выпущена Visual Studio 2008

On Monday, Nov. 19, Microsoft announced that Visual Studio 2008 and the .NET Framework 3.5 were released to manufacturing (RTM). With more than 250 new features,Visual Studio 2008 includes significant enhancements in every edition, including Visual Studio Express and Visual Studio Team System. Developers of all levels – from hobbyists to enterprise development teams – now have a consistent, secure and reliable solution for developing applications for the latest platforms: the Web, Windows Vista, Windows Server 2008, the 2007 Office system, and beyond.

Ссылка на новость
Скачать полную версию (90 дней trial)
Скачать VS2008 Express (900Мб, DVD)
Примеры проектов
.Net Framework 3.5 Full Package

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

1. What's New in the .NET Framework Version 3.5
2. .NET Framework 3.5 Architecture
3. What's New in the .NET Compact Framework Version 3.5
4. What's New in Windows Presentation Foundation Version 3.5
5. What's New in ASP.NET and Web Development
6. What's New in ADO.NET
7. What's New in Architecture Edition
8. What's New in Data
9. What's New in the Visual Studio Debugger

10. What's New in Visual C#
11. What's New in the Visual Basic Language
12. What's New in Visual C++ 2008

Инфекция Agile обнаружена в Сибири!

В начале ноября при поддержке Учебного Центра «Люксофта» в городе Омске состоялись тренинги, посвящённые применению гибких методологий в разработке программного обеспечения, а так же техникам повышения личной эффективности.

Тренинги проводил Agile-евангелист Денис Миллер.

 

 

Цель поездки была распространение эффективных методик разработки программного обеспечения. В течении недели были прочитаны тренинги: шаблоны проектирования, рефакторинг и курсы повышения личной эффективности: управление временем  и использование MindMap. На тренинг по уравлению временем пришло 18 человек, хотя учебный класс не был готов такому повороту событий, но нам удалось поместиться всем вместе и продуктивно провести время. Как говориться в тесноте, но не в обиде. Ребята собрались подкованные поэтому получились не только разобрать теорию, но и обсуждить практические вопросы.

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

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

 

Практика Рефакторинг on-line

Нашёл интересный сайт. Хотите попрактиковаться в рефакторинге. Хотите получить совет. Заходим на сайт http://refactormycode.com.
В основном там Ruby и Java поклонники были замечены. Но есть и колонка для C#.

Implementation Patterns by Kent Beck

Буквально недавно выпущена книга гуру качественного кода и мною примного уважаемого автора Кента Бека под названием "Implementation Patterns". Беглый просмотр оглавления и аннотаций навели меня на мысль, что эта книга компиляция идей мира smaltalk в Java. А раз это так, то этот труд стоит читать! Ведь там идей очень много и очень они качественные.

Ждём завоз этой книги на территорию России. Если кто будет пролетать мимо и увидет в продаже. Просьба купить -- деньги верну :)

Качественный проект

Идея 1. Во время проекта создаётся не только ПРОДУКТ, но так же ДОКУМЕНТАЦИЯ (можно считать, это отдельный проект), создаётся ПРОЦЕСС (многие это уже осознали) и создаётся КОМАНДА (это осознали только адаптивные методологии).

Идея 2. Успех проекта зависит 100% от человеческого фактора. А он в свою очередь складывается из ВЗАИМОДЕЙСТВИЯ, ДОВЕРИЯ, ЭМПАТИИ, ОРГАНИЧЕСКОЙ АРХИТЕКТУРЫ, ДОКУМЕНТАЦИИ, ОБРАТНАЯ СВЯЗЬ и др. (что значат некоторые вещи - не спрашивайте, не знаю). Этим waterfall не занимается.

Согласно Agile, наша цель -- создать лучшй продукт. Причём самым эффективным способом. А как практика последних десятилетий показала, что эффективность зависит от КОМАНДЫ и ЧЕЛОВЕЧЕСКОГО ФАКТОРА. На что и ориентируются множество практик Agile.

Семейный SCRUM (Family Scrum)

Уже второй день проводим вечерний SCRUM в семейном кругу.
Немного необычно. Чувствуется у меня скованность. Но интересно.
Итак наша команда: муж, жена, 2 пацанов по 3.5 года.

Стандарные вопросы Daily Scrum Meeting:
- что было сегодя?
- что будешь делать завтра?
- что тебе мешало быть эффективным? (проблемы)

Я очень много узнал нового, что происходило дома за моё отсутствие. Забавно. Очень здорово, когда узнаю, что один из бандитов постоянно задирался (проблема). И после скрама сразу оптираем со всеми ситуацию. Причем виновник активно подключается по выработке идей, как это можно исправить :)

Дополнительно ревизия дня и планы на завтра малышне позволяет задуматься (все их мысли на лице можно прочитать). И потом они рожают. Немного не в попад -- но получается весело.

Knowledge Transfer with SCRUM

| View | Upload your own

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

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

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