×Закрыть

Марина Мельник, Exigen Services — о Scrum, Distributed Scrum и Agile

Беседа с Мариной Мельник, руководителем Agile Center of Excellence компании Exigen Services о базовых особенностях применения гибкой методологии Distributed Scrum.

— Марина, для тех, кто не совсем в теме, расскажите немного об истории Agile и о Scrum-подходе.

— Agile Manifesto, «Манифест гибкой методологии разработки ПО» был выпущен в феврале 2001 года в штате Юта, США. Причиной его появления стало желание разработчиков найти альтернативу «тяжелым» практикам разработки программного обеспечения, обремененным тоннами документации. Именно таким был «метод водопада», принятый стандартом разработки в те годы.

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

В своей работе мы используем Scrum и XP — две основные методики гибкого подхода к разработке. Экстремальное программирование уделяет больше внимание инженерной стороне развития продукта, это системный подход. Методика XP сконцентрирована на процессе производства, а Scrum фокусируется на управлении и выпуске.

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

— А что такое классический Scrum?

— При классическом Scrum команда включает в себя от 5 до 7 человек, которые обычно находятся в одном помещении. Это называется сollocated team. Этот главный принцип озвучил Кен Швабер еще в 2001 году — команда должна базироваться в одном месте. Такие проекты, как правило, рассчитаны на небольшие узкоспециализированные приложения и длятся от двух до пяти месяцев. Поставки продукта заказчику проводятся каждые 2-3 недели.

— В чем же отличие распределенного Scrum от классического?

— Его основное отличие от классического как раз в том, что команда, вернее, команды расположены в разных центрах разработки, или даже в разных странах. Но при этом основные Agile-принципы соблюдаются.

— Зачем все так усложнять?

— При разработке сложных, крупномасштабных систем, работа над проектом может длиться до года и более, а количество разработчиков доходит до сотни. В этом случае невозможно быстро и без лишних затрат собрать collocated team, которая бы удовлетворяла всем необходимым требованиям. Нанимать новых людей в одном офисе с большой скоростью не позволяет рынок. Распределенный Scrum — прагматичный подход, позволяющий балансировать использование существующих и наем новых талантов.

— Некоторые компании стремятся к росту центров разработки, вы, судя по всему, мыслите по-другому...

— Непродуманно активный наем персонала приводит к росту так называемого «бенча», увеличению расходов на его содержание и, как следствие, малоприятным шагам по его сокращению. Мы за эффективное распределение ресурсов, бережливое производство, что в конечном итоге экономит и ресурсы заказчиков.

Мы, безусловно, набираем новых людей, но делаем это тщательно, предварительно взвесив все варианты распределения имеющихся специалистов.

— Какие еще преимущества получает компания-разработчик от использования распределенного Scrum?

— Использование такого подхода позволяет разработчикам объять почти необъятное. Располагая распределенными ресурсами и гибко комбинируя их для работы в проектах, компания может повысить уровень сложности выполняемых проектов за гибкого привлечения экспертов из разных центров разработки. Также увеличиваются шансы доступа к глобальному пулу проектов. Значительно уменьшаются риски, связанные с персоналом. В случае необходимости вы всегда можете привлечь аналогичного специалиста из другой команды или центра разработки. При грамотном управлении ресурсами значительно сокращается размер бенча, а, значит, растет прибыль компании.

— Плюсы для разработчиков очевидны. А что компания-заказчик выиграет от использования распределенного Scrum при разработке решения?

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

— Какие проблемы вы могли бы назвать в организации проекта, который будет работать по методологии распределенного Scrum?

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

Короче, много. Но мы боремся, и для того, чтобы аккумулировать наилучшие наработки и иметь возможность их успешного переиспользования, мы организовали Центр профессиональной экспертизы Agile (Agile Center of Excellence).
Также учитывая постоянно возрастающие требования проектов к квалификации персонала, одной из основных задач является постоянное обучение сотрудников.

— Как именно развиваете?

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

Внешняя программа называется Exigen Agile Practices — это академическая программа обучения, целью которой является развитие у студентов и молодых специалистов знаний и навыков, необходимых IT-бизнесу в современных условиях. В ходе такого обучения можно за короткое время приобрести практические навыки по использованию Scrum.

Есть и другие программы, но они уже не относятся к распределенному Scrum.

LinkedIn

Лучшие комментарии пропустить

кадры решают все, а не методологии

Привет!
Я так понимаю, что основная жалоба по поводу статьи — отсутствие практического примера, который можно было бы с пользой применить у себя.
Попробую один такой пример привести. Это презентация, которую лучше, конечно, слышать в моем исполнении, т.к. всю инфо на слайды не поместишь, но все же...
www.slideshare.net/...nce-report-scrum-12571662

«Течет вода Кубань-реки куда велят большевики скрамовики.» ©
«Мир! Труд! Эджайл!»
«Ударим зелеными стикерами по бездорожью, разгельдяйству и бюрократизму!»

Весь текст в лозунгах, такое впечатление, что это стенограмма съезда партии :) и стоит только выкрикнуть в офисе слово «Скрам» и проект сам напишеться и сам сдасться. А по-сему вопросы: «Где цифры, сравнения с тяжелыми методиками»?

Какие еще преимущества получает компания-разработчик от использования распределенного Scrum?

Преимущества перед чем: обычным scrum или «тяжелыми» методиками?

Это интервью или прес-релиз? Попытался это прочесть и понял, что читать нечего. При этом у меня сохранилась четкая уверенности, что профессионалы могут и про Скрам и про Канбан и про ХР и прочие Agile методологии рассказать интересно на основе своего опыта. А говорить шаблонами и фразами вычитанными в умных книгах и услышанными на Agile-конфах это просто капец. Если у вас настолько скучная работа, что и рассказать нечего, а и скрам вы чтите как Библию, то звыняйте. Фтопку такие «интервью».

127 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Статья скукота, девочка красивая. Выложи фото в купальнике.

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

x___x

Привет!
Я так понимаю, что основная жалоба по поводу статьи — отсутствие практического примера, который можно было бы с пользой применить у себя.
Попробую один такой пример привести. Это презентация, которую лучше, конечно, слышать в моем исполнении, т.к. всю инфо на слайды не поместишь, но все же...
www.slideshare.net/...nce-report-scrum-12571662

Excellent!
Are there any measurements to evaluate success?

Про TFS особенно повеселило ;-)

Навіть програмою з найнезручнішим інтерфейсом можна себе змусити використовувати і навіть до цього звикнути. Інше питання навіщо?
Якщо на вокористання продукту А я затрачатиму 30 хв. в день, продукту Б — 1,5 годин, то наявне неефективне використання мого робочого часу. Якщо ж ще до всього продукт не є моїм основним інструментом, несе утилітарну функцію і замість помагати, лише сповілюнює мій прогрес, то чи є сенс за такий продукт ще й платити?

которую лучше, конечно, слышать в моем исполнении

Наверное лучше таки было бы прослушать. Ибо со слайдов складывается впечатление:
— 12 страниц воды
— на 13 слайде видно что в комманде был просто бардак (ни тестов и задач)

— на слайде 24 — полный фейл: «18 часовой рабочий день», при нормальном планирование должно быть 8. Или я шото не так понимаю?

Ваша презентація з розряду «Як я провела літо». Візьмемо SCRUM, до того був RUP, до того ще щось і буде нам щастя, проекти виконуватимуться самі, клієнти валитимуть табуном. На жаль — це в більшості випадків профанація і банально не працює без суттєвого допилювання напильником на чуть складніших проектах.
Є нормальні люди які це розуміють, аналізують, намагаються поділитися досвідом як тут:
habrahabr.ru/post/139194
habrahabr.ru/post/143116 і є розуміння що розробка ПЗ — це складний процес і що в тому ж виробництві якось процесами керуватися навчилися за останні 100 років. А в нас чомусь носяться з прапорцями ми робимо щоденні мітінги, ретроспективи, continuous integration, unit tests, code review — і все. Насправді це ази. Ну припустимо є в нас всі ці пратики і що далі, нам гарантовано успіх?
Що і як робити коли коли ми не встигаємо? Коли суттєво недооцінили технічні ризики? Коли хоч ти трісни, але доводиться розбивати функціонал між різними командами і зявляються залежністі і починається розбір між SCRUM-майстрами хто і що кому не доробив. Оте з SCRUM про мультифункціональні команди, хочу я побачити iPad-розробника, який сяде за мене COM-компоненти на C# писати. Чи побачите ви як SCRUM-майстер коли почнуться зрізатися кути? Ось є реліз 1, є реліз 2, є реліз 3, до релізу 1 довелося викинути купу функціоналу який «не несе безнес цінності». В результаті маємо «технічний борг», який не дає взагалі вийти на реліз 3 з прийнятною продуктивністю. Зате в SCRUM-майстрів красивий графік.

Реальність на жаль значно складніша, ніж намальована срібна куля: Agile чи Lean чи ....

без плашки «реклама» дешево.

Надо бы кого-то на кресте распять за Эджайл, глядишь и Евангелия эти убедительней будут.

Снова болтовня, где факты? Кто-то хоть когда-то исследовал реальный эффект таких методологий?

Друзья, спокойнее. Если вы потратите 10 минут на интенсивное гугление — окажется, что таких исследований немало, и эффект есть.

Правда? Давайте посмотрим на них. И я говорю не о том, когда сначала делали так, потом добавили стандартных вещей под маркой аджаил и получили улучшения. Continuous integration, код ревью и юнит тесты это не аджаил.

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

От того кто задаёт вопрос, вопрос не меняется.

Continuous integration, код ревью и юнит тесты это не аджаил.

Oh really? www.extremeprogramming.org/rules.html

Или XP — это не Agile? :)

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

Все вышеперечисленные техники — маркеры: например, если у вас есть CI — ваш процесс, скорее всего, более соответствует Agile-манифесту, чем без него (конкретно в пункте «responding to change»). То же самое относится к код ревью, парному программированию и т.д.

кадры решают все, а не методологии

Ну хоть один все понял, салют!!!

Причем кадры не только со стороны исполнителя но и со стороны заказчика.

Млин.... этот пост должен был быть оставлен пользователем Joseph Stalin =(

Ну так вот же — кадры решили использовать такую методологию.

ШО, Опять? Сколько можно уже мусолить этот Agile ;-)

Заметил, что в почту предложения об очередном Agile тренинге стали приходить гораздо чаще, чем предложения о «enlarge your penis» :D

Аgile/scrum мастера также хотят заработать себе хороший летний отпуск. ;-)

Enlarge your agile for free без смс, мокрые писечки.

Странно, но статья не оставила впечатления, что распределенный Agile приносит пользу.

Первой проблемой стоит разница часовых поясов. Меня терзают смутные сомненья, что это самая большая проблема.

Вторая проблема — амбиции отдельных членов команды. Ага, это только при распределенном управлении у тебя появляются такие проблемы :)

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

....

Расскажите нам, пожалуйста, о реальном опыте. А то получается, что если для меня часовые пояса не проблема и мы прошли стадию Шторма (привет мистеру Такману), то у меня идеальный скрам. Да все индусы работают по нему сместив график на +6 часов :)

на мой взгляд главная проблема -Амбиции людей и разница в том, что принято называть «компетенцией».
Просто когда ты в одном офисе, ты с людьми общаешься лично, а это не только по скайпу. Тут и эмоции и «невербальное» общение. Это в 90% упрощает общение.
Лечиться на моей практике — постановкой «правильных» целей и приоритетов. Может еще помочь бюрократия и прочее подобное -те же скрам борды. Тут уже статью можно писать отдельную.

Вторая проблема — разница в опыте и знаниях. Решается как раз обменом опытом, мостами и тренингами.

Дима, да я не против, что это проблема.
В распределенных командах фаза «шторма» (именно в этой фазе самые серьезные амбиции накладываются на амбиции и возможности других) происходит сложнее. Да, и вероятно, в этом виноваты именно эмоции и невербалика.
Только Agile к этому не имеет никакого отношения :) проблемы, которые описаны в статье — проблемы ЛЮБЫХ распределенных команд.

Сергей согласен. Но дело в том, что заказчик на 90% хочет Agile. Разрабы на 70% хотят Agile — кто-то реально понимает зачем, кто-то может просто потому что «модно». Например, некоторый продуктовые кампании переходят на agile, но общаясь с руководством прекрасно видишь, что он тут не к месту, а для галочки.

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

Замовник на 100% хоче результат, адекватний вкладеним коштам. Зараз іде активна популяризація таблетки під назвою Agile/Scrum. Але сама по собі методологія не розв’язує багатьох проблем, багато практик доводиться залучати з-поза меж, окреслених авторами Agile методів (що і недивно, адже вони фокусувались на найбільш важливих, найкритичніших моментах виробництва програмного забезпечення). Понад те, в даному прес-релізі немає навіть того, що безпосередньо вказано в Scrum Guides / Agile Guides, із чого особисто я роблю висновок, що у керівника центру компетенцій немає не лише компетенцій (тобто уміння застосовувати свої знання на практиці), а й теоретичних знань матеріалу. Так, ефективні комунікації — це одна з ключових запорук успіху. Але не єдина. І навіть не визначальна. Можна ефективно спілкуватись в командах, між командами, із замовником, а постачати заздалегідь неприйнятний для замовника продукт. І, як показує практика, це — проблема значної частини Agile і не-Agile команд. Що і недивно — той факт, що у вас є лопата, і ви вмієте нею гарно вимахувати, зовсім не гарантує, що ви зробите нею гарну роботу, яка повністю відповідатиме очікуванням замовника...

Sergii,
Ваши выводы по меньшей мере странные. Разве здесь было собеседование на знание

Scrum Guides / Agile Guides

? Или для того чтобы доказать вам цену своих слов нужно указывать — я сдал теорию и у меня N лет практики?

Я не оцінюю людей виключно за знанням теорії. Але, коли їм немає чого продемонструвати в якості своїх практичних досягнень, залишається оцінювати теорію.Це по-перше. А по-друге, «N років практики» і «Q успішно завершених проектів» — це абсолютно різні речі. «Робив» ≠ «Зробив». І замовник радше довірить свої гроші тому, хто вже досягав успіху. Теоретично, Ваша компанія, як, до речі, і моя, мали б хвалитись досягнутими результатами. На практиці — хваляться кількістю підготовлених людей, команд та умінням цитувати всесвітньо відомих гуру...

согласен в последнем, но не могу не обратить внимание на то, что не вместо

хваляться кількістю підготовлених людей, команд та умінням цитувати всесвітньо відомих гуру

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

“Робив” ≠"Зробив"

но тут есть тонкий момент в данной полемике — где вы собираетесь работать N лет если у вас нет успеха? кому вы нужны? Не вижу смыла разводить на этом месте полемику.

Гай-гай :-)
Я стільки знаю людей і компаній, що роками женуть халтурку, і нічого... Світ задосить великий, аби роками забезпечувати роботою не один мільйон жителів південно-східної Азії, а вони напевно не такі вигадливі, як жителі центрально-східної Європи :-)

Сожалею о вашем печальном опыте. или он вас радует? тогда сожалею вдвойне.

Ціную іронію. Але, коли Ви не помітили — досвід не мій...

тем более — на каком основании вам о нем говорить?

Відповідь: «В якості людини, яка витягувала провалені іншими проекти» Вас влаштує?

вполне. На самом деле я согласен с вами насчет того, что кампании могут годами гнать фигню. Но говорить не о своем опыте — зачем? В целом не вижу предмета дискусии.

Но говорить не о своем опыте — зачем

Как??? То есть, чтобы узнать, что цианистый калий смертелен, вы его сами попробуете?

править проект -это пробовать цианистый калий ?)) не настолько алегорично ) И вообще можно дать его кому-то другому и сказать, что на 99% другой умер от яда))

И вообще можно дать его кому-то другому и сказать, что на 99% другой умер от яда))

А откуда вы это знаете, вы ж не признаете чужой опыт? Ваши же слова:

Но говорить не о своем опыте — зачем?

То есть опыт берем только свой... А вдруг вы не умрете от калия?

Раз виправляв, отже це вже не зовсім «не мій» досвід...

почему бы вам тогда им не поделиться? тут dou — напишите статью, расскажите что за проблема, как вы ее решили, считаете ли вы после всего своего опыта, что это было верное решение и какие альтернативы?

«Чукча не писатель, чукча читатель» ©

и критик, говоря по правде.

Это интервью или прес-релиз? Попытался это прочесть и понял, что читать нечего. При этом у меня сохранилась четкая уверенности, что профессионалы могут и про Скрам и про Канбан и про ХР и прочие Agile методологии рассказать интересно на основе своего опыта. А говорить шаблонами и фразами вычитанными в умных книгах и услышанными на Agile-конфах это просто капец. Если у вас настолько скучная работа, что и рассказать нечего, а и скрам вы чтите как Библию, то звыняйте. Фтопку такие «интервью».

Я б позначив цей матеріал не як «інтерв’ю», а як «публікується на правах реклами». Бо іншої рубрики для матеріалу, підготовленого і опублікованого маркетинг-менеджером компанії Exigen Services, не повинно бути...

Я б позначив цей матеріал...

Ну, сделайте собственный сайт — и помечайте, как хотите.

Ога, сначала добейся.

Ни в коем случае. Всего лишь показал легкий способ реализовать желания комментатора. =)

Ну, якщо репутація людей, які не гребують «джинсою», вас влаштовує — немає питань...

За последние несколько недель это уже не первое серьезное обвинение от вас в адрес редакции. Мне кажется, вам стоило бы потрудиться доказать свои слова или принести извинения.

Сподіваюсь, попередні «серйозні звинувачення» були підкріплені достатньою аргументацією? Коли ні, я окремо продублюю аргументи, що стосувались попередніх прецедентів.
Що ж до цього. Я не вважаю незаангажованою публікацією (а саме незаангажованим і має бути інтерв’ю) матеріал, підготовлений Світланою Постаноговою, що обіймає посаду Marketing Manager в Exigen Services, за мотивами бесіди з Мариною Мельник, керівником Agile Center of Excellence тієї ж таки компанії Exigen Services. Якби інтерв’ю брав Делегер, Турунов, Марченко, Іщенко, врешті-решт Куйдич, у мене б не було жодних зауважень. Понад те, я не сумніваюсь, що відповідне інтерв’ю було б проведене і оформлене на більш професійному рівні — всі попередні публікації вищеозначених осіб дають підстави так стверджувати. Мені прикро, але факт залишається фактом — матеріал слабенький, заангажований і лише підриває авторитет ДОУ.

ПС До речі, тут вже давали посилання на сайт Exigen Services саме з цим «інтерв’ю» (www.exigenservices.ru/...es/03-04-12-480 ), але несподівано публікація магічним чином зникла з сайту. Може хтось має скриншот?..

Звиняте, дядьку, сами мы не местные, но этот текст действительно выглядит, как джинса.

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

Непонятно, кто кого интервьюирует. И, опять же, непонятно, почему интервьюирует.

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

Непонятно, почему бы просто не начать с того, что «кем-то где-то был организован Центр профессиональной экспертизы Agile (Agile Center of Excellence), и наш корреспондент впервые в жизни идет примерять эту экспертизу на самом себе.

И забавно выглядит это упрощенное «для тех, кто не в теме»: аджайл — альтернатива водопаду...

И непонятно, почему вы аватарку сменили — вас теперь не узнать :)

«Течет вода Кубань-реки куда велят большевики скрамовики.» ©
«Мир! Труд! Эджайл!»
«Ударим зелеными стикерами по бездорожью, разгельдяйству и бюрократизму!»

Весь текст в лозунгах, такое впечатление, что это стенограмма съезда партии :) и стоит только выкрикнуть в офисе слово «Скрам» и проект сам напишеться и сам сдасться. А по-сему вопросы: «Где цифры, сравнения с тяжелыми методиками»?

Какие еще преимущества получает компания-разработчик от использования распределенного Scrum?

Преимущества перед чем: обычным scrum или «тяжелыми» методиками?

Если не врут на сайте — им таки есть, с чем сравнивать:

Компания Exigen Services одной из первых нашла применение Agile-методологиям в условиях географически распределённых команд. Компания сертифицирована по CMMI пятого уровня и ISO 9001:2000 по показателям эффективности, зрелости и стабильности.
На протяжении 17 лет мы успешно сотрудничаем с клиентами...

www.exigenservices.ru/about

Я ниразу не сомневаюсь в стабильности и состоятельности компании, и ее сертификатах

Если не врут на сайте
но, тем не менее, мы тут комментируем интервью, а не достижения компании.

До речі, магічним чином публікація щезла з сайту компанії :-)

Овва, і як же це я одразу не помітив. На сайті Ексиджену інтерв’ю було опубліковано 3.04.12 (тобто два тижні тому!).
Я колись чув, що на ДОУ публікуються виключно ексклюзивні матеріали. Тобто, такі, що раніше ніде не публікувались. Поправте мене, коли я помиляюсь.

Ну, справедливости ради — материал заметно переработан, так что, думаю, требования ДОУ соблюдены.

Сподіваюсь, переробляли матеріал не ДОУшники :-)

Правильно, все в купу — Agile, CMMI, ISO, а замовник нехай вибирає те, що його цікавить :-)

замовник нехай вибирає те, що його цікавить :-)

Сделанная работа?

просто к некоторым заказчикам нужен «свой» подход и набор сертификов и тп) Главное же результат.

Абсолютно передбачувано Вам відповів Dima Lebedinsky, Techlead в Exigen Services:

просто к некоторым заказчикам нужен «свой» подход и набор сертификов и тп)
А те, що в одному абзаці навіть для «певних замовників» ніхто не пише:
Компанія Exigen Services однією з перших знайшла застосування Agile-методологій в умовах географічно розподілених команд. Компанія сертифікована за CMMI п’ятого рівня та ISO 9001:2000 за показниками ефективності, зрілості та стабільності.
www.exigenservices.com.ua/about
то це так, дрібнички...

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

такая практика есть и она работает

Так все могут сказать про свою «практику».

А какой конретно вопрос? моя практика в таких проектах — 3 проекта за 2 года. в каждом от 2-х команд на 5-7 человек. практика как-бы есть )

А какой конретно вопрос? моя практика в таких проектах — 3 проекта за 2 года. в каждом от 2-х команд на 5-7 человек. практика как-бы есть )

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

Со своей стороны потролю: а мы вот «cowboy coding» практикуем. Это супер-методология, благодаря ее использованию, мы увеличили скорость работы в 1.76 раза, повысили довольство команды ;)

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

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

Позвольте и мне ответный — а как вы мерили и по сравнению с чем? такая точна цифра у вас )) Кстати, а кто в вашей методологии выступает в роли «индейцев»?

Кстати, а кто в вашей методологии выступает в роли «индейцев»?

Про Cowboy coding это не шутка, если че: en.wikipedia.org/...i/Cowboy_coding

Разницу в работах в похожих проектах и командах, я лично заметил. Как вы видите я все еще работаю в этой кампании и намерен и далее :)

Не, не катит. Для чистоты эксперимента одна и та же команда должна сделать проект по одной методологии, потом вернуться во времени, и опять сделать его по другой, тогда можно сравнивать ... =) В других случаях остается только «считать попугаев» =) ... Именно потому, что этот эксперимент неосуществим, я упростил вариант сравнения до (1 команда — разные, но похожие, проекты), я думаю, что это справедливо. Сравнивать как разные команды делают разные проекты разными методологиями — некорректно.

Позвольте и мне ответный — а как вы мерили и по сравнению с чем? такая точна цифра у вас )) Кстати, а кто в вашей методологии выступает в роли «индейцев»?

Я ни с чем не сравнивал, то бишь играю по вашим правилам: вы мне не предоставили материал для сравнения просто сказав, что «agile офигенен», не сказав по сравнению с чем, и я вам в ответ со своим уставом говорю, что cowboy coding-таки тащит! А вы мне, чувствую, не верите ;)

Про индейцев — это моя шутка. Насчет cowboy — не знаком, не знаю, не могу судить :) Не люблю знаете ли говорить о вещах, в которых не разбираюсь.
По себе могу сказать, что agile как таковой может упростить жизнь и экологию внутри команды. Для меня и моих людей он работает ) Тут я вам не навязываю свое мнение — как в комментарии выше уже писал — scrum и agile — это инструменты, которые в правильных руках будут приложены в правильное место. На моей практике agile и distributed scrum показали себя с хорошей стороны, в опыте работы с очень требовательным и не последовательным заказчиком. И в данном случае следование немногим жестким правилам scrum дало возможность сделать не один успешный проект. И главное во время.

К слову говорить о плюсах и минусах той или иной методологии имеет смысл если мы смотрим с одной и той же колокольни (заказчик, команда и тп)

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

А можно по пунктам, типа такое-то правило (практика) дало такую-то выгоду, которой не было при применении не-Аджайл.

ну из того что помню и могу рассказать
1. фиксация scoup — помогало от звонка заказчика в среду утром последней недели спринта с «а давайте вот тут вот так сделаем?»
фиксация скоупа спринта — давала время на подумать перед тем как ломиться делать
— как заказчику — что он хочет,
— требования — как это влезает в уже существующие требования и на что повлияет.
— команда — как и главное какой команде это делать.
2. burndown, taskboard, scum of scrums — где и каком состоянии команды. сколько задач и в какой области может это команда взять на себя. Риски.
3. daily scrum meetings — как дела в твой личной команде. что за проблемы — требования, «кривые руки», помощь и как их решить — при этом не в последний день спринта.
4. scrum of scrums — локальная команда работает и не завязает в обсуждениях всего и вся. Скрам в 15 минут с комадной и 15 минут со всем лидами и тп.
5. в тоже время вы работаете в локальной скрам команде и как следствиие — важен каждый человек в команде.
6. общая ретроспектива и планирование — позволяет как обсудить и общие проблемы между всеми командами так и понять общие и личные цели каждой из команд.

ну где-то так. :) спрашивайте. Но отвечу уже завта.

Можливо, Ви не повірите, але це все реально працює і в не-Аджайл оточенні. І це все може не давати результат в Аджайл оточенні (знаю не один такий проект)...

С чего вдруг мне вам не верить? я не родился в agile и успешно работал и до этого. Но ведь и сам agile, как и манифест что вы корректно указали, не родился на пустом месте.
Сергей, я уже ранее указывал на лично свою точку зрения — правильная таблетка в правильном месте.

и да может — но мне лично приятнее работать в команде, в которой есть цель и инициатива.

Ну так Аджайл і ціледосягання — речі, що лежать в різних площинах...

что cowboy coding-таки тащит! А вы мне, чувствую, не верите ;)

Всегда думал что Cowboy coding — это «антипаттерн» (да вроде и в вики так пишут). Или я что-то пропускаю?

Я считаю, что это скорее описание методологии эффективного прототипирования и быстрого набивания шышек :)

Я вообще-то немного времени а аутсорсе был занят, но мне кажется, что в этом случае такое (cowboy coding) не рекомендуется.

Но! в случае разработки собственного продукта можно взять такие замечательные вещи этого полушуточного подхода:
1) инициатива исходит разработчика (эксперимент поощряется)
2) разработчик сам выбирает архитектуру компонентов разрабатываемой системы (но, естественно, не всей системы, а то если ковбоев много будет, то они бизонов не загонят и мустанги подохнут ;), а такжe используемые фреймворки, и .т.д..

— другие плюсики в вики описаны, но они для специфического класса проектов (типа студенческих, pet-projects, и т.д.).

Всегда думал что Cowboy coding — это «антипаттерн» (да вроде и в вики так пишут)

В вики пишут, что это последователи эджайла эдиного называют cowboy-coding антипаттерном.

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

Ага, значит имеем в результате 3 проекта с мифической сложностью поэтому однозначно можна сделать вывод что Agile рулит. ;-)
Может дело в сложности проекта (X) которая соответствовала количеству людей (Y) и опыту людей (Z) на проекте чтобы в итоге сделать проект c неким минимальным качеством (Q) которое устроило бы заказчика в некоторые сроки по времени (T) ?

Как Agile в вашем случае повлияло на переменные X, Y, Z, Q, T чтобы в итоге достичь успеха?

Вот она сила формализации, а я своими дифирамбами так и не добился ответа на этот вопрос! (может, вам повезет)

Ростислав,
вы хотите услышать что agile уменьшит вам количество необходимых толковых людей в команде? так причем здесь agile — это никак не зависит от методологии?
С чем может помочь скрам и работа в команде, так это в достижении более быстрого разделения знаний в команде. но тут тоже зависит от людей в этой команде)

На мой взгляд — оснавная цель scrum и agile — успеть туда-куда еще сам не знает заказчик — к тому времени когда ему это нужно. а все остальное — процесс. SoS в этом помогает. но не лечит )

оснавная цель scrum и agile — успеть туда-куда еще сам не знает заказчик — к тому времени когда ему это нужно

Можна поподробнее? Куда нужно успеть? Чего не знает заказчик? И о том что ему нужно но он об этом еще не знает? ;-)

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

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

не поверите, но иногда так и бывает. например заказчик цитата — «хочу вот такой вот сайт, но чтобы было не совсем как у них. Как точно я пока не скажу. вы пока вот так сделайте, а потом посмотрим». И такое было) Я думаю работа с таким клиентом не специфична только для agile.

ха-ха))))) ваш вопрос ко мне почему agile рулит? не ко мне))
Почему он мне подходит для моих проектов — причины указаны.
Вы определитесь — вы хотите добиться от меня лично коментария «agile фигня — а ваша „я сам знаю че делаю“ лучше» ? нет. для моих проектов scrum показал свою эффективность и помог решить часть ошибок.
Попробуйте сами — у вас же есть и

X, Y, Z, Q, T

может вас agile поможет )))

у меня слаживаеться впечатление что вы поставили на agile весь ярлык «вундервафли» и яростно пытаетесь доказать всем, что agile никакая не «вундервафля» ))

Вот ...

Почему он мне подходит для моих проектов — причины указаны.

для моих проектов scrum показал свою эффективность и помог решить часть ошибок.

Из всего вышесказанного никак не выходит, что

agile не делает что-то лучше, чем другая методология (так как вы ни с чем не сравнивали, он помог решить часть ошибок

Зато выходит, что:

agile позволил вам сдать проект, даже не один! замечательно!. Но! из этого не следует, что любая другая методология (тот же водопад, или RUP или MSF, или любая другая заумная аббревиатура) не обеспечила бы такой же, может худший, а может и лучший результат.

у меня слаживаеться впечатление что вы поставили на agile весь ярлык «вундервафли» и яростно пытаетесь доказать всем, что agile никакая не «вундервафля» ))

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

Ростислав,
нужно понимать контекст.

на мой личный взгляд плюсы Scrum of Scrums — это возможность быстро и комфортно организовать работы больших команд ( 14+ человек) без реального головняка. Да еще если учесть что вам все это нужно сделать на сейчас и через 2-3 недели получить что-то. В тоже время вам может в вашей команда и не нужны верстальщики на все время работы над проектом. может это 2 недели из 52? и реально только 2 недели та — жена заказчика зашла на сайт с ие 6 — и ей не понравилось, а до этого никому этот осел и не был нужен. Ради этого держать весь штат верстальшиков на бенче? или лихорадочно кричать о найме людей? это пример.

RUP кстати тоже считают agile ) это так к слову. Вам подходит RUP для ваших задач используйте. Хотите узнать альтернативы — спросите. Например у Марины)

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

С другой стороны, есть облегченный вариант RUP — OpenUP, который, таки да, соответствует приципам Agile Manifesto.

итеративно-инкрементальную разработку, которая является необходимым, но отнюдь не достаточным условием Agile.

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

Если считать манифестом только 4 строчки — то да, не является. Однако, в основополагающих принципах манифеста упоминается «Deliver working software frequently...» и далее по тексту, что ИМХО может быть обеспечено с помощью IID, или ее дальнейшим развитием — потоковой моделью.

Без заголовка, вводной/выводной части, и имен — там таки 4 строчки agilemanifesto.org.

Но даже если полезть в «12 принципов» — там тоже нет ни слова про итерации.

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

Можно, конечно, поспорить насчет

Deliver working software frequently, from a
couple of weeks to a couple of months, with a

preference to the shorter timescale.

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

Наверное, точнее будет сказать, что других способов соответствовать этому самому принципу пока не придумали :) Вернее, придумали Lean, но это, по сути, IID «в пределе»

Класичний RUP відповідає всім принципам Agile Manifesto, чому присвячено багато досліджень, які нескладно нагуглити всього лишень за двома словами «RUP» та «Agile». Щоправда, ненабагато менше досліджень присвячено тому, що RUP ≠ Agile.
Особисто мене ідеологічні війни цікавлять мало, оскільки в реальному житті нерідко найкращим виявляється поєднання в одному проекті практик із різних фреймворків. І навпаки, намагання використовувати «чисті» моделі, м’яко кажучи, не завжди призводять до успіху...

Особисто мене ідеологічні війни цікавлять мало

С другой стороны, они полезны тем, что разрушают стереотипы и предубеждения.

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

Он таки очень бюрократический. Припоминаю презентацию Книберга со сравнением — www.crisp.se/...s/henrikkniberg

на восьмом слайде, в коробочках — предписываемые практики

Фокус в том, что RUP — это конструктор процессов. При всем моем уважении к Книбергу, то, что изображено у него на слайде — это не более, чем полный перечень «деталей» этого конструктора. А собрать из него можно как и бюрократического монстра, так и очень даже гибкий процесс, что и доказал Robert ’Uncle Bob’ Martin, описав минимальную реализацию RUP под названием dX (перевернутая аббревиатура «XP»)

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

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

Ну так к RUP основная претензия — очень сложно не выстрелить себе в ногу. Т.е., нужно иметь сертификацию PMI (вместе с соответствующим обучением), знать и уметь применять PMBOK, тогда, конечно, из RUP сделаешь все, что пожелаешь.

Вон, на плюсах тоже можно много чего интересного писать, почему же тогда вокруг всем JEE нужна?

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

Только вот для Agile соответствующей сертификации пока не придумали. CSM — не вариант, при двухдневном курсе ни о каком глубоком понимании того, как устроен Agile, речь не идет. Правда, вроде бы PMI порывались сделать какой-то вариант сертификации по Agile направлению, но не в курсе, есть ли какие-то результаты.

Дело в том, что с RUP недостаточно понимать «лежащие в основе философию и принципы». Нужно еще хорошо знать сам фреймворк, в то время, как Scrum/XP дают возможность быстро стартовать и закончить проект за то время, пока будет изучаться талмуд по RUP.

А в остальном согласен — без понимания принципов разработки ПО любой подход выродится в карго-культ, а потом в т.н. «обратный карго-культ», когда ПМ начинает понимать, что деревянные наушники и стэндапы с досками не призывают транспортники с тушенкой, и считает настоящих авиадиспетчеров такими же шарлатанами, которые просто усерднее молятся. Увы, понимание того, что серебряной пули не бывает, приходит с опытом, а на рынке «23-летних сеньоров» и «25-летних програм менеджеров» его просто слишком мало.

I really believe that any framework doesn’t work without real seniors in a team.
But in case of Agile we have to form a team of seniors while in case of RUP we need to have some seniors in a team...

Ну так к RUP основная претензия — очень сложно не выстрелить себе в ногу. Т.е., нужно иметь сертификацию PMI (вместе с соответствующим обучением), знать и уметь применять PMBOK, тогда, конечно, из RUP сделаешь все, что пожелаешь.
Sorry, but this is a bullshit...
RUP ≠ PMI certification (PMP / PgMP), which impossible without strong knowledge of PMBOK...

PS you know, SK would be very upset if he read such statement :-)

Как Agile может показать свою эффективность в таком простом случае когда набранная команда банально может не потянуть проект повышенной сложности? ;-)

А кто просил сверх сложный случай? или с чего вы решили что не может? И судя по вашим словам команда должна лихорадочно работать по овертаймам что бы успеть?

Все что вам похоже нужно это что-то доказать. Что ?

Много акцента на методологиях и сертификатах которые в общем случае ничего не решают.

смотря для кого.

В общем случае для всех это видно из X, Y, Z, Q, T и моего примера выше.

видно что — пример? мифические цифры x-z? Кокретный пример, где эти методологии не работают? или что? Вы ничего не показали и не доказали.
Или то,что я не привел вам решение ваших проблем? и не сказал, что это дасть вам 100500 счастья? Так вам это может и не дать — это уже от вас зависит.

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

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

Господа президенты, это Рабинович, разъединяю...)))

Ну дык раз от вас не добиться никакой технической информации, буду данный пост считать постом исключительно в целях рекламы =(

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

Мне кажется, что товарищ «тень» хотел того же, так что дискуссия зашла в тупик, а ветки про «enlargement» где-где, а на ДОУ развивать не очень хочется.

Руслан, но вы же тоже поймите меня — я же не менеджер проектов и тем более отвечаю тут по своей личной инициативе. Есть желание получить подробную статью — хорошо так и скажите. Попробуем организовать. Будет возможность ответить ответим. Ставьте вопрос — по типу — в проекте 2 команды, при этом один лид "сам-себя-назвал"- архитектор, а другая команда — в шоке — как решить? на такое можно что-то отвечать.

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

Переименуйте меня обратно ;)

Я уже понял все, что вы хотели донести. Мне был интересен сравнительный эксперимент хотя бы 2-х методологий (и судя по коментам, не только), к сожалению, я его не увидел, поэтому сделал вывод про рекламность поста

Руслан, но вы же тоже поймите меня — я же не менеджер проектов и тем более отвечаю тут по своей личной инициативе.

в чем вам лично ни капельки не упрекаю, извините, если сложилось такое мнение.

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

Сравнительным анализом методологий в цифрах занимался Скотт Эмблер, вот результаты его исследования за 2010 год:

2010 IT Project Success Rates

Методология это как формат протокола общения. Вы договорились с заказчиком что будете вести с ним дела соблюдая требования такой то методологии. НО в общем случае выбранная методология не влияет на успех проекта в конечном итоге. Также методология не может не работать если вы и заказчик вовремя выполняете все ее требования.

CMMI 5 здається отримали аж 2005-го року. От чомусть BAE Systems і 2009-го і 2011-го сертифікувались: sas.sei.cmu.edu/pars/pars.aspx
Здається мені що цінність цього папірця так само як

ISO 9001:2000
дуже низька. Маю дуже великий сумнів що вже в 2005-му був Agile, тоді дай боже щоб був RUP. Отже процеси і підходи змінилися, як швидше за все й люди, а все ще махаємо папірцями які не кажуть нічого.

Подписаться на комментарии