Есть ли 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. Беседа с Ильёй Сербисом :)