Agile *

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

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

Недавно дошли руки до превращения записи моего доклада на AgileKitchen в полноценный слайдкаст.

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

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

Столько слов придумали, все и не запомнишь — Канбан, Скрам, ЭксПи…
Есть ощущение что создается наука из ничего так-же как бухгалтерия в нашем государстве.
А ведь смысл и идея не нова, лежит в основе мироздания, матушки природы и любого производства.

Вот мои простые тезисы по этому поводу:
1. Делай только то что надо сейчас
2. Делай только то что принесет максимальный эффект
3. Если задача сложная разбивай на простые
4. Используй самый простой подход решающий задачу
5. Работай одновременно только над одной задачей
6. Переключайся только когда задача полностью готова
7. Делай работу над ошибками

В идеале готова — в нужном качестве у заказчика и он ей доволен.

Спасибо за внимание!

PS: Если статья понравилась, поднимите карму.
Потому как те кому не понравилась понимаете что сделали…

Прочитал пост "Проблемы при внедрении Agile" хабрапользователя adnotum, захотелось предложить несколько решений описанных проблем. Поскольку решения достаточно универсальные, решил оформить их в виде отдельного поста.
Большинство описанных проблем появляется, потому что Scrum является гибким фреймворком, а не полноценной методологией. Это является его недостатком и преимуществом одновременно. «Ванильный» или «кошерный» Scrum описан кратко в официальном авторитетном руководстве от Сазерленда и Шваббера. «Кошерный» Scrum — это когда ты все делаешь по правилам, а получается не очень вкусно, да и сам процесс не доставляет удовольствия. Такой сферический Scrum будет работать только идеальном вакууме, но его можно и нужно адаптировать, чем собственно этот фреймворк и хорош.

Как и многие сейчас, мы решили попробовать внедрить agile для развития одного из наших решений. Точнее, поскольку в мире разработки ПО нет «черного» и «белого», мы решили «не внедрить agile», а перейти от использования менее гибких подходов к использованию более гибких.

В данном топике я хотел бы описать проблемы, с которыми мы столкнулись, а также привести соображения, как некоторых из этих проблем можно было бы избежать. Написание топика продиктовано желанием способствовать переводу дискуссии про agile из плоскости «как наконец заставить этих старомодных менеджеров перейти к прогрессивным методологиям» в плоскость «как работать по agile наиболее эффективно».

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



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

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

На недавней конференции я вдоволь наслушалась разговоров трёх менеджеров о самоорганизующихся командах.

«Вы не можете просто так взять и дать волю людям, и предоставить команде всё решать самой. Они же всё испортят! Да, и к тому же, все эти Scrum-мастера, тренеры и самоорганизующиеся команды похоже могут оставить меня без работы», — говорил один из них с обречённостью в голосе.

«Ограничения по времени классная штука», — говорил другой. «Засуньте их всех в комнату, поддайте жару и они начнут творить», — утверждал он.

«О, так это означает, что я могу перетасовывать людей между проектами и они сами просто объединятся в команду и самоорганизуются. Я могу иметь подвижные Scrum команды по первому требованию!» — восклицал третий.

Время развеять некоторые заблуждения.

Последнее время я слышу множество разговоров о разработке, основанной на тестировании (TDD), о разработке, основанной на функционировании (BDD), об экстремальном программировании (XP), о SCRUM-е, о собраниях стоя и ещё Бог знает о каком количестве методик для создания ПО, но все эти методики не имеют смысла, если ПО, которое мы создаём не соответствует требованиям пользователей. Давайте я попробую это объяснить по-другому. Идеальная реализация неправильно составленной спецификации бесполезна. Так же, как и полезность прекрасно написанной библиотеки стремится к нулю, если у неё нет документации. Что-то определённо не так, если ваше приложение не решает поставленную проблему или, если никто не знает как им воспользоваться.

Здорово. И как же нам решить эту проблему? Проще, чем вы думаете, и достаточно важно, чтобы выделить ответ в отдельный параграф.

Первым делом создайте Readme файл.

Пользуясь юбилеем — как раз в августе, 10 лет назад был опубликован^[1] The Agile Manifesto еще раз предлагаю сейчас, в летнее затишье, загрузить на будущее в себя немного Agile (когда пойдут дедлайны, будет уже не до этого).

А именно, посмотреть-почитать материалы докладов с прошедшей в Москве конференции AgileDays-2011. Далее, будет небольшое пояснение, почему эти материалы интересны, смотрибельны и читабельны, а также аннотированная тематическая классификация докладов, с ссылками на материалы — видеозаписи, слайды, рецензии и т.п.

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

Тролль (бояр. смутьян) — индивид, занимающийся троллингом. Изначально так называлось само провокационное сообщение или действие. Целью тролля является производство лулзов для себя и посетителей, раскусивших его, за счёт менее догадливых посетителей, тратящих время, силы и кровь из задницы на срач с ним.

Цитата взята с Луркмора, советую ее кстати дочитать. Почему я заговорил о троллях? А все потому, что в последнее время очень часто сталкиваюсь с троллями от IT. Хорошо это или плохо и что с этим делать обсудим ниже.

Оценка задач

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

Что будет если собрать кучу народа, дать им лего, мандарины, стикеры, фломастеры? Бардак? Может быть. Но если замесить все это на agile, то может получиться очень интересно. Именно так и вышло на прошедшем AgileCamp в Самаре. Подробности под катом.

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

— Давайте не лезь в этот модуль. Код недокументирован, все начнет глючить и сыпаться, особенно биллинг.
— До нас работала команда дураков, они учились программировать на этом проекте. Если сюда лезть, в команде упадет мотивация…
— Как это работает… Это надо в код смотреть. Люди, писавшие, уже ушли, документации нет. Месяц минимум.
— Мы залили данные, и все стало тормозить. Надо спринт посвятить исследованию причин. (и так несколько спринтов подряд)

Вы понимаете, что происходит что-то странное, что проект «заболел», что можно было наверно этого избежать, если знать заранее…

Постараемся понять, кому «бить морду» сейчас и кого отмутузить профилактически когда к нам придет следующий проект — чтобы избежать подобного коллапса.

Давайте подумаем, кому нужны гуманные методологии разработки? Команда, ответственность, храбрость, доверие…

Инвестор

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

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

Менеджер проекта

Ему нужно, чтобы проект:

а) Был довольно точно описан, согласован с Заказчиком и требования не менялись. Тогда его несложно оценить, распланировать этапы работ и водопадно выполнить.

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

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

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

Бум интереса к этой методологии прошел, однако до сих пор многие молодые команды легко очаровываются теоретической магией scrum, обещанием щелкать новые требования, как орешки, и не морочиться по ТЗ, бросаются внедрять на своем производстве и тут же натыкаются на трудности. Scrum вообще родился как методология разработки ПО, если вдруг кто забыл, и для успешного использования в web-разработке требует некоторой настройки. Это отдельный вопрос, в этой заметке я хотел бы затронуть другую тему и предостеречь от очевидных, в общем-то, ошибок, связанных с формированием требований к проекту. В любом описании методологии по запросу в Google говорится про важность роли scrum master'a и изложении требований к проекту в виде историй, но никто не говорит о том, откуда берутся требования, и нужно ли вообще их реализовывать. Без понимания этого момента сделать что-то путное вряд ли получится, и методология тут ни при чем.

Тема новой встречи сообщества AgilePiter — «Инженерные практики в Agile».

Мы будем рассматривать особенности внедрения и практического использования continuous integration, парного программирования, код ревью и прочих техник, а также попробуем вместе найти ответы на ваши вопросы.
Встреча будет проходить в формате модерируемой дискуссии, без докладов. Модерируют дискуссию Михаил Карпов (Яндекс) и Роман Юферев (VIAcode).

Участие бесплатное; количество мест ограничено.
Для участия в мероприятии необходимо подтвердить своё участие:
Регистрация на встречу

Встреча состоится в следующий вторник, 14 июня, с 19:00 до 21:30 в офисе компании «Яндекс».

Место проведения: Санкт-Петербург, Свердловская набережная, 44, бизнес-центр «Бенуа» (4 этаж).
От метро «Площадь Ленина» каждые 15 минут ходят бесплатные автобусы с надписями «Бенуа» под ветровым стеклом.
Где найти остановку: http://company.yandex.ru/contacts/spb/

На проходной говорите, что вы на семинар по Agile и поднимаетесь на четвертый этаж.
При необходимости — звоните: +7 (911) 769-00-21, Михаил.

Прошедшие встречи AgilePiter:
http://habrahabr.ru/search/?q=agilepiter

Начало прозаичное. А именно — как я работаю. Приходит хозяин фирмы, рассказывает мне задачу, я ее сам дроблю и делаю. Потом у меня в команде появился еще один человек и дробить задачи я стал уже на нас двоих. Если у меня, что-то не получалось или был какой-то затык, я обращался к разработчику на другой технологии. Он мне помогал и был своего рода моим начальником по технической части. Например: когда я захотел написать новый проект на Zend, а не на Codeigniter'e (на котором у нас все проекты), он мне дал две недели: если не успею, тогда на Codeigniter'e быстренько за два дня, чтобы сделал. Единственный минус, который я видел в своей работе, так это полное отсутствие тестирования с моей стороны и тестера как такового вообще.

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

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

Поехали.

Гибкие и «жесткие»

Есть гибкие методологии разработки (Agile), такие как Scrum, простые и постигаемые за пару дней. А есть «жесткие», увесистые, требующие многомесячного погружения, такие как RUP.

Гибкие методологии убеждают нас «поверить», что из-за того, что требования постоянно меняются, можно к черту отказаться от многолетнего опыта разработки программного обеспечения, впитанного классическими методологиями, тем же «водопадом», все решительно упростить и броситься в объятья «коммунистической» свободы, честности и равенства.

А чего бояться-то? Сумасшедшие бородатые специалисты говорят о процессах, артефактах, матрицах зависимости (Requirements Traceability Matrix) — а мы в рубахе, босиком, раз и… запрограммируем любой интернет-проект за 3 спринта! Ура, товарищи, к победе.

Так вот, «упрощение», предлагаемое гибкими методологиями, очень условное и коварное. «Расслабились» с одной стороны, придется хорошенько поднатужиться с другой.

В прошлый раз мы обсуждали работу с заказчиком и управление требованиями.
Тема новой встречи — «Проведение совещаний в Scrum».

Мы будем рассматривать особенности проведения ретроспективы, планирования, stand-up и демо, а также попробуем вместе найти ответы на ваши вопросы.
Модерирует дискуссию консультант ScrumTrek — Алексей Корсун.

Участие бесплатное; количество мест ограничено.
Для участия в мероприятии необходимо подтвердить своё участие:
Регистрация на встречу

Встреча состоится при поддержке ЗАО «Ланит-Терком» во вторник, 22го февраля, с 19.00 до 21:30.
Место проведения: 14 линия В.О., дом 29. Здание математико-механического факультета СПбГУ.
На проходной говорите, что вы на семинар по Agile.

С уважением,
Михаил Карпов, менеджер проектов, Яндекс
Алексей Корсун, представитель ScrumTrek в Петербурге
Татьяна Васильева, руководитель проекта, Ланит-Терком