Showing posts with label agile. Show all posts
Showing posts with label agile. Show all posts

Wednesday, November 24, 2010

Взвешенный подход к Agile

ScrumMaster_2

В последний время все чаще попадается на глаза критика Agile и Scrum, а, точнее сказать, agile-евангелистов и подхода подготовки Скрам Мастеров. Сейчас это неплохой бизнес. Надо сказать, когда я впервые столкнулся с тем, как проводится сертификация на Скрам Мастера, у меня у самого волосы встали дыбом. Несколько дней тренинга, простенький экзамен, который может сдать практически кто угодно – и ты Скрам Мастер! Да, потом нужно участвовать в комьюнити, чтобы двигаться дальше, но в целом все это выглядит следующим образом:

- Я уже могу вести Скрам-проекты, учитель?
- Так точно, маленький падаван. Ты же прошел обучение и заплатил деньги сдал экзамен.

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

Также мне всегда было непонятно, почему тот же Scrum часто огульно описывается как панацея от всех бед, хотя совершенно ясно, что он подходит не для ВСЕХ проектов, и не для ВСЕХ команд. Как и waterfall, как и TDD, как и что угодно, серебряной пули же нет. В некоторых случаях Scrum просто менее эффективен, чем другие методологии, а иногда совершенно не подходит.

Появляется все больше и больше критических статей и попыток переосмыслить Agile-подходы и текущую ситуацию. Возможно, все-таки действительно что-то не так в Датском королевстве?

Сначала появилась статья, в которой хорошо описывались основные проблемы и давалась краткая выжимка фактов с предложением “быть честными”: http://www.whattofix.com/blog/archives/2010/09/agile-ruined-my.php (русский перевод здесь: http://experience.openquality.ru/agile-ruined-my-life/)

“Люди думают, что можно взять увечный проект, который уже не жилец, добавить немного Agile и заявить, как это было круто. Да ладно, ребята, никого так провести не удастся. Все точно знают, что это пропаганда. Хуже того, вовлеченные эксперты оказываются последними, кто узнает о тщетности таких действий на публику. На своем опыте они «обучаются» неправильным вещам и «делятся» своим знанием с новыми командами, продолжая дерьмовый цикл.”

“Одна из первых истин, которой учат в Scrum-классах: Scrum – не волшебная пуля. Оставшуюся часть времени вам говорят, что это лучшее изобретение человечества после нарезного хлеба. Все мы встречались и работали с парнями, у которых всегда есть ответ на любой вопрос – нужно только спросить. Решения уже приняты для любой задачи, которая у вас может быть. Такие люди чрезвычайно раздражают. Все равно что говорить со стеной. Плохо, плохо.

“Работает ли Agile для распределенных команд? Смотря по обстоятельствам. Можно ли использовать двухнедельные отметки для оценки проектов? Смотря по обстоятельствам. Работает ли Agile в проектах по разработке встроенного ПО? Смотря по обстоятельствам. Черт! Всё зависит от обстоятельств. Порой как бы сильно я ни пытался быть вежливым, честным и открытым, я становлюсь похожим на тех ребят из Матрицы, когда вы смотрели ее первый раз. Они говорят много, но на самом деле это мало что значит. Звучит напыщенно, но по сути чепуха. Ненавижу давать такие советы. Знаю ребят, которые ненавидят их слушать.”

Были и другие статьи, все перечислять не имеет смысла. Но написать эту заметку меня натолкнул Боб Мартин, написавший статью “What Killed Waterfall Could Kill Agile”, в которой высветил проблему элитарности, присутствовавшей в водопадной разработке и проявляющейся, как он считает, в Scrum. Конечно, Боб выгораживает XP и наезжает на Scrum, но его слова не лишены смысла:

“The elitism engendered by Waterfall was being attacked. Neither Scrum nor XP had any role for an elitist who assumed authority without taking responsibility. In Scrum, the rule of the team is stronger than the rule of an Architect or Designer. Contributions are welcome, but not necessarily followed.”

“I didn’t think thousands of people would be lining up to get their certifications. But I had not considered the lure of elitism. It didn’t occur to me that this special training course, coupled to the term Certified Scrum Master, would become a wedge to break the alignment between authority and responsibility.”

“Indeed, the role of Scrum Master is considered so important, that it requires certification to obtain. If your Scrum team does not have a Certified Scrum Master, then something must be wrong with you.”

“The elitism is back, and it’s growing. More courses with certifications are available, and even more are envisioned. Other training companies are offering their own certifications. After all, the lure of elitism is a great moneymaker. The snowball is rolling down the mountain, and getting bigger with each turn.”

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

Monday, March 22, 2010

Список интересных подкастов: выпуск #4

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

.NET 4.0:

Jason Olson проходит по некоторым новым фичам CLR, C# и BCL. Concurrent GC, side-by-side CLR versions, Memory-Map files, co-variants и contra-variants, Parallel Extensions, немного об обновлениях в языках программирования и новых языках. И да, они наконец-то выкинули CAS и заменили его на более простой механизм. Хотя кто его вообще использовал :)

Небольшой обзор изменений в ASP.NET AJAX 4.0. От UpdatePanel до полностью кастомных AJAX-запросов и JavaScript-контролов. jQuery теперь "часть" ASP.NET AJAX, переработанный AJAX Control Toolkit - тоже, более того, AJAX Control Toolkit теперь работает не только с WebForms и MVC, но даже с PHP или любым другим back-end'ом. ASP.NET AJAX поддерживает dual data-binding на клиенте, который работает по аналогии с дата контекстом EF или L2S, на сервере его поддерживает WCF Data Services, которые раньше назывались ADO.NET Data Services. На закуску немного о ScriptLoader, history API, Microsoft CDN, Microsoft AJAX Minifier, Sea Dragon и Deep Zoom.

Честно говоря, еще сам не слушал этот подкаст, но судя по транскрипту - довольно любопытно. Foreign Keys, POCO и поддержка DDD разработки и модульного тестирования, Lazy/Deferred Loading, поддержка N-Tier сценариев при помощи Self-tracking entities, T4 templates, Code Only (в общем, все то, о чем я уже когда-то писал), немного о WCF Data Services, а также история о том, как Julie помогала Oren Eini (Ayende) создавать EFProf.

Обсуждение возможностей первого функционального языка программирования, включенного в .NET 4.0. Немного о том, что такое функциональные языки вообще, зачем нужен функциональный язык в .NET и какую пользу он может принести обычным разработчикам, привыкшим к императивным языкам вроде C#, VB.NET, Java или С++, некоторый ликбез по терминологии функциональных языков. Много интересного контента и шуток благодаря Теду.

Интервью с програм менеджером DLR team. Конечно же, обсуждение DLR, который релизится с .NET 4.0, и его двух основных языков: IronRuby и IronPython. Разговаривают об архитектуре DLR, истории развития, возможностях, отличиях Iron-версий языков Ruby и Python от своих оригиналов, IronRuby on Rails :)

Другое:

И снова непревзойденная Tess. О чем еще с ней можно поговорить, как не об отладке. Что такое Memory Dump, как его создавать и почему об этом важно знать, что такое Allocated и Committed memory, как пользоваться WinDbg и CDB для отладки "утечек памяти" в .NET и проблем с производительностью, а также некоторые улучшения с отладкой многопоточных приложений в VS2010 и в предыдущих версиях, о которых вы, возможно, не слышали.

Интервью с создателем WebFormsMVP - очень интересного MVP-движка для WebForms. Автор рассказывает, что такое MVC и MVP, зачем использовать паттерн MVP в WebForms приложениях, архитектуре движка, особенностях его использования и том, насколько полно он работает с остальной инфраструктурой ASP.NET. Надо будет обязательно попробовать его в боевом проекте - по идее, должен сберечь кучу времени и сил.

Приятно, что в нашем уголке мира появляются хорошие подкасты :) В гостях у питерской группы ALT.NET подкаста Александр Бындю и Виталий Стахов. Разговор идет о вполне понятных вещах: принципах ООП (SOLID), TDD, практиках XP, полезных инструментах, развитии программиста и различных вариантах построения и развития команд. Прикольно, что Александр Бындю точно так же понимает разницу между Scrum и XP, как и я.

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

Обсуждение Domain-Driven Design и CQRS (Command and Query Responsibility Segregation pattern) с Мишей Чалым и frozen_space. Если про DDD многие хотя бы краем уха слышали, то что такое CQRS для меня для самого тайна :) Где помогает DDD и зачем он нужен, что такое CQRS, его преимущества и недостатки. В общем, самое острие программной инженерии - не пропустите! Подкаст только записали, завтра буду слушать сам.

И напоследок, как всегда, тема попроще :)

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

Приятного прослушивания!

Sunday, February 15, 2009

След Шерлока Холмса в программировании или Немного об agile для программистов

Задумывались ли вы, чем отличаются между собой waterfall и agile подходы к разработке программного обеспечения? Для меня, человека, который раньше работал либо по ad hoc, либо по waterfall, либо по итеративным процессам вроде UP, agile-подходы вроде XP, Scrum и др. (прошу не бить сильно ногами, что буду все причесывать под одну гребенку) раньше казались чем-то сродни ad hoc'а, только с дополнительными правилами, чтобы совершенно не скатиться в анархию. У нас даже шутка ходит о том, на проекте часто бывает не просто agile, а полный agile :) Однако после прочтения книжки Книберга я изменил свое мнение.

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

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

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

Вот собственно из этого всего и родились различные agile-подходы к разработке ПО. А потом появился небезызвестный манифест - и пошло-поехало. Так что же такое agile и чем он отличается от обычной водопадной или итеративной практики разработки? Ну, отличий, конечно, много, но я бы в первую очередь сказать, что это - процесс разработки ПО снизу-вверх, то есть индуктивный процесс. С самого начала мы очень мало знаем о том, что мы вообще строим, иногда даже так же мало, как и заказчик. Но нам по барабану. Мы берем то, что есть, тратим не очень много времени на планирование - и стартуем. Сделали что-нибудь стоящее, показали заказчику, определили следующие задачи - и поехали дальше. И так до тех пор, пока заказчик не получит то, что хотел. При этом необходимо отметить, что гибкие методологии, в отличие от своих "жестких" товарищей, все же имеют свою жесткость - жесткость правил, по которым ведется разработка. Если у вас нет unit-тестов - вы обломаетесь на первых же серьезных рефакторингах системы. Если у вас нет code review или pair programming - вам будет сложно организовать коллективное владение кодом, что можем повлечь серьезные проблемы, если кто-то из ведущих разработчиков вдруг заболеет. Если вы забиваете на product backlog - у вас в скором времени возникнет каша с требованиями (впрочем, каша с требованиями возникает и тогда, когда они есть, но на их обновление точно так же забивают). Если вы не проводите ежедневные митинги - ваши разработчики будут дублировать действия друг друга и изобретать велосипеды сотнями, а код превратится в мусорку. А все потому что работа ведется в условиях самоорганизовывающейся команды (self-management team) и нет никого, кто бы мог сверху спустить план, в котором будет четко сказано, кто, что и когда должен делать.

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

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

Отзыв о книжках: DDD Нильссона и Scrum из окопов Книберга

Последние несколько недель были плодотворными в плане чтения книжек. Дочитал "Применение DDD и шаблонов проектирования: проблемно-ориентированное проектирование приложений с примерами на C# и .NET" Джимми Нильссона и прочитал "Scrum и XP: заметки с передовой" Хенрика Книберга. Спешу поделиться отзывами, так как уже давно ничего толкового не читал.

ddd 

Про первую книгу я уже писал относительно недавно. Рекомендую всем, кто чувствует, что ему стало тесно в рамках стандартных технологий и подходов, а архитектура и дизайн его приложений хромают на обе ноги. Domain Driven Design - это радикально другой подход к разработке ПО, поэтому книжка отлично освежает голову, дает совершенно другую перспективу и точку зрения на привычные вещи. Нильссон дает общее представление о DDD, а также на примерах показывает, как можно разрабатывать реальные приложения с использованием DDD, TDD, и различных паттернов проектирования. Автор начинает с простых вещей, вводит рабочий пример и потихоньку продвигается по пути его реализации, задевая вопросы архитектуры, модели предметной области, инфраструктуры для сохраняемости, архитектурных паттернов, unit-тестов, правил, аспектно-ориентированного программирования, пользовательского интерфейса, а также немного проходится по NHibernate. В общем и целом, после прочтения книжки в голове появляется намного более серьезное понимание всех вышеперечисленных вопросов, и даже если DDD вам не подходит, вы вынесете из книги много новых знаний. Сразу хочу предупредить, что это не Эванс, здесь нет серьезной теоретической базы, лишь практика, практика, и еще раз практика. Ну, и ложка дегтя: русский перевод этой книги просто ужасен. Не понимаю, как можно было перевести кучу названий паттернов (чего стоят только прецеденты использования и неведение сохраняемости), а также стандартных терминов (DDD - ППО, проектирование предметной области, TDD - РПТ, разработка посредством тестирования). Да и ладно бы, но там не только это перевели, поэтому постоянно приходится думать, как эта фраза звучит по-английски и что это за очередной термин такой. По всей видимости, после перевода книжку не проверил эксперт в данной предметной области. Поэтому читайте оригинал :)

scrum

Вторая книжка была переведена сообществом Agile Ukraine, за что ребятам огромное человеческое спасибо! Причем, больше спасибо за то, что они разрекламировали ее, потому что в реальности, как и предыдущая книга, эта читается на английском легко и непринужденно. Книжка переведена просто замечательно, в отличие от перевода того же Нильссона. Сама же книга повествует об опыте Хенрика Книберга в постановке и использовании Scrum'а в нескольких командах. Хенрик последовательно проходится по вопросам планирования спринта, работы с product backlog'ом, ролям команды, ведения burndown-диаграммы, проведения scrum-митингов, демо, ретроспектив, а также, что более важно, объясняет, как работать по Scrum-у в условиях fixed-cost проектов, показывает родство Scrum и XP, и делится опытом постановки процесса QA и работы с несколькими командами. В общем и целом, для человека, который знаком с другими процессами разработки ПО, и который имеет не только положительный, но и отрицательный опыт, эта книга может стать хорошим стимулом попробовать поднять Scrum у себя на проекте. Тем более, если у вас ничего другого нет :) В общем, рекомендую не только PM'ам.