?

Log in

Украинское Agile-сообщество's Journal
 
[Most Recent Entries] [Calendar View] [Friends]

Below are the 13 most recent journal entries recorded in Украинское Agile-сообщество's LiveJournal:

Saturday, March 13th, 2010
1:33 pm
[main_framer]
Looking for a job. java team lead / system architect
Hi!

At the moment I am looking for a job of java team lead / system architect.
CV
http://www.chantingwolf.narod.ru/cv8en.doc
LinkedIN profile
http://www.linkedin.com/in/mykbova

-Mykola
Thursday, December 3rd, 2009
1:15 pm
[vfursov]
Доклад на Первом международном Форуме студентов и аспирантов по управлению проектами в Москве
Сегодня делал Доклад на Первом международном Форуме студентов и аспирантов по управлению проектами в Москве.
Приехать на форум не удалось, потому презентовал свой доклад в форме вэбинара.
Тема доклада: SCRUM - наиболее удачный путь организации сложных проектов.
Кому интересно, вот здесь можно ознакомиться с полным скриптом сегодняшнего доклада.

Current Mood: accomplished
Friday, October 2nd, 2009
1:49 pm
[gi_ant]
Эволюция Продукта. Мысли вынесенные с Agileee.
Вернулся недавно с Agileee
У в компании нас принято после любой конференции делиться с сотрудниками полученной информацией посредством презентации.
Может кого то эта презентация натолкнёт на полезные мысли :)


mindmapCollapse )
Monday, April 27th, 2009
1:55 pm
[t_gra]
Behavior Driven Development (BDD) - мой доклад с Agile Gathering 7

Выступил на Agile Gathering 7 с докладом про Behavior Driven Development. Вот презентация:

Запись опубликована AgileProductivity. Пожалуйста, оставляйте комментарии там.

Tuesday, February 10th, 2009
12:36 am
[t_gra]
Живой труп, или ригидный Agile

avva написал пост о своём восприятии Agile:

Agile, на мой взгляд - почти целиком вредная гиль. Даже в тех случаях, когда в рамках агиля говорят что-то разумное (а это случается, потому что агиль невероятно расплывчат и слабо-определен, будучи в основном феноменом маркетинга, и его можно повернуть в разные стороны), это все равно часто компрометируется съедающим мозг баззвордизмом и приводит к ердуне.

Мой ответ:

Кажется, вам встречались в основном “не тру” аджайлисты.

Очень часто различные полезные течения опошлялись последователями N-ого поколения, копирующими лишь внешние признаки, ритуалы, и превращающие полезные паттерны в ригидные правила.

Так, например, раннее христианство отличается от того, что сформировалось в 5-7 веке, когда сформировался канон.

В то время как одним из ключевых принципов Agile на мой взгляд является необходимость модификации и постоянной подстройки процесса под конкретный проект/команду/сложившуюся ситуацию. (inspect and adapt)

Вы правильно заметили, что Agile определён достаточно расплывчато. Это так, потому что фактически каждая команда имеет свой собственный процесс - и он мутирует с течением времени.

Называют эту сущность отдельным словом с тем, чтобы отделить от традиционных/ригидных методологий - водопадной модели, итерационной (с маленькими водопадами в каждой итерации), с одной стороны, и от недисциплинированной, хаотической разработки, с другой.

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

Маркетинговая привлекательность баззвордов, конечно, играют отрицательную роль. Знакомый работал в одной аутсорсинговой конторе и заказчики требовали Agile. В результате был имплементирован некий дубовый процесс, заключающийся главным образом в том, что не было предварительного проектирования. А других практик, которые делают это возможным, внедрено не было. Команды как целостности не было. И главное, не было предусмотрено адаптации процесса (да и некому было это делать и брать за это ответственность - команды же нет, есть отдельные индивидуумы). В результате у знакомого, естественно, сложилось отрицательное мнение об Agile.

У Agile есть две стороны - инженерные практики и практики командной работы/управления. Вы в этом посте затронули только инженерные практики (которые, как я понял, вы любите, если без фанатизма). Интересно, как вы относитесь к неинженерным практикам (Iteration Planning Meeting, Daily Scrum Meeting, Retrospective и т.д.)?

Запись опубликована AgileProductivity. Пожалуйста, оставляйте комментарии там.

Friday, October 31st, 2008
1:52 am
[t_gra]
Sunday, October 12th, 2008
5:58 pm
[t_gra]
Agile Gathering 6
Съездил в Киев на конференцию Agile Gathering 6. Надеюсь, через пару дней на сайте появятся презентации докладов.
Sunday, October 5th, 2008
12:57 am
[t_gra]
Главарь банды - шесть качеств хорошего скрам-мастера (Майк Кон)

Недавно я понял, что мне необходимо делегировать другим людям полномочия скрам-мастера в своих командах. А самому сосредоточиться на работе Product Owner’а (прокси-продукт-овнера, на самом деле) и коачинге новоиспечённых скрам-мастеров в командах.

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

С целью дать командам информацию о критериях выбора хорошего скрам-мастера, я нашёл и перевёл статью Майка Кона “Главарь банды. Шесть качеств хорошего скрам-мастера.” (Mike Cohn, Six Attibutes of a Good ScrumMaster). Заодно перевёл и комментарии к этой статье, оставленные на сайте ScrumAlliance, которые, на мой взгляд, прекрасно дополняют статью.

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

Представляю его вам:

Leader of the Band

Six Attributes of a Good ScrumMaster

by Mike Cohn | 05 Feb 2007

Главарь банды

Шесть качеств хорошего скрам-мастера

Майк Кон, 5 февраля 2007

перевод – Алексей Тигарев <tigra AT nlp.od.ua>, 11.06.2008

http://nlp.od.ua/

In my last column I asserted that in an ideal world a team would select its own ScrumMaster, but that it isn’t always practical. I promised that my next column would discuss what to look for in a potential ScrumMaster, whether the selection is being made by the team itself or by someone outside the team. In this week’s column, I present six attributes that your next ScrumMaster should demonstrate.

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

Читать запись полностью »

12:54 am
[t_gra]
Традиционные роли и роли в Agile
Недавно ко мне обратился владелец одной компании по поводу работы. Мы пообщались, и он попросил меня ответить на несколько вопросов. На английском.

Вопросы он задал довольно интересные, и ко мне пришло вдохновение. Не в силах остановиться до трёх ночи, я писал сочинение :)

Я решил опубликовать его в виде серии постов.

Итак, первый вопрос, в ответе на который я раскрываю смысл должностей Product Manager, Project Manager и Team Lead, и альтернативную систему координат, принятую в Agile, точнее в Scrum - Team, Product Owner, Scrum Master. А также моё личное отношение к этим ролям.

1. Вы пишете о том, что хотите занимать позицию Project Manager или Team Leader. Какими задачами на Ваш взгляд должен заниматься человек находящийся на этой позиции и как Вы их видите?

I am interested in Product Manager or Project Manager positions actually, as I'm writing in my CV.

Responsibilities of mentioned positions traditionally may include:
(Читать дальше)
12:48 am
[t_gra]
"Гибкая продуктивность" - первая глава готова
Я закончил первую главу моей книги с рабочим названием "Гибкая продуктивность: утройте продуктивность команды программистов, используя гибкие методологии". Скачать можно здесь (нужно знать пароль, он будет у подписчиков, покупателей системы и финалистов онлайн-тренинга). Эту и некоторые из последующих глав книги получат все подписчики рассылки.

Подпишитесь сейчас, чтобы получить ссылку на скачивание файла.

SmartResponder.ru
Ваш e-mail: *
Ваше имя: *
Вот содержание первой главы:
  • Глава 1. Текущее состояние. Традиционные проблемы команд разработчиков.
    • Несоответствие разработанного продукта требованиям и ожиданиям заказчика
    • Типы контрактов при разработке программного обеспечения
    • Проблемы с контрактами Fixed Price
      • Fixed Price без документирования требований
      • Fixed Price с частичным документированием требований
      • Fixed Price с максимально детально документированными требованиями
        • Делаем всё правильно
        • «Водопад» стоит дорого
        • Требования всё равно меняются
        • «Водопад» запросов об изменениях (change requests)
        • Патовая ситуация
      • Изменение требований во время разработки
    • Проблемы с контрактами Time & Materials
      • Гибкость для заказчика
      • Комфорт для исполнителя
      • Злостная оптимизация
      • Неэффективность Time & Materials для заказчика
      • Убытки исполнителя от дополнительных ограничений контракта
      • Проблемы с изменением требований остаются
      • Как продают контракты Time & Materials
    • Трудно хорошо договориться с заказчиком
    • Трудности с закрытием контракта
    • Качество кода
    • Низкое качество продукта
    • Низкая мотивация
  • 12:45 am
    [t_gra]
    Agile TV - "гибкое телевидение"
    Я создал "телеканал" по гибким методологиям разработки - Agile TV! Смотреть можно по этой ссылке: http://nlp.od.ua/agile-tv/ Пока что я включил в "программу телепередач" такие ролики:
    • Agile Testing
    • Agile & Waterfall: A Tale of Two Teams
    • Bay XP Meeting Part 2: Agile Estimation, Mike Cohn
    • Being Agile is our favourite thing
    • Agile Retrospectives: Making Good Teams Great!
    • Get Agile: Agile vs Waterfall
    • Why does Agile Software Development Pay?
    • Agile Development Teams: Scope and Scate - with Mike Cohn
    • Agile Software Development
    • Agile User Experience
    • High Moon Studios - An Agile Game Developer
    • I am agile
    • The Road From The Project Manager to Agile Coach (1 of 2)
    • Agile Development with Scrum: What they don't tell you
    • Agile Software Development Training in Kitchener (I)
    • An agile alternative to ponderous usability test
    • Rajesh Learning Agile Methodology
    • User-centered design and agile development at NCR
    • Tesco - Software for Agile Business
    • Communitech Agile Session (II)
    • Agile Tracking
    • Welcome to Agile Enterprise Arcitecture
    • Scrum et. al
    В дальнейшем появятся новые "передачи", а также живые трансляции. Пароль для доступа к странице с "телевизором" выслан всем подписчикам рассылки. Также он будет выслан всем новым подписчикам автоматически. Подпишитесь сейчас, чтобы получить доступ к "телевизору".
    SmartResponder.ru
    Ваш e-mail: *
    Ваше имя: *
    12:41 am
    [t_gra]
    FAQ по ретроспективам (Naresh Jain) - билингва-перевод

    Представляю вашему вниманию билингва-перевод статьи Naresh Jain “Retrospectives: FAQs”:

    Retrospectives: FAQs

    http://blogs.agilefaqs.com/2006/06/25/retrospectives-faqs/

    Naresh Jain

    Часто задаваемые вопросы по ретроспективам

    Naresh Jain

    перевод – Алексей Тигарев, http://nlp.od.ua/

    What is a retrospective?

    Что такое ретроспектива?

    Retrospective (from Latin retrospectare, “look back”) generally means to take a look back at events that already have taken place.

    Провести ретроспективу (от латинского retrospectare, “смотреть назад”) означает посмотреть назад, на уже произошедшие события.

    In the software world, a retrospective is a meeting held with a project team at the end of a project or process to discuss what was successful about the project, what could be improved, and how to incorporate the successes and improvements in future projects.

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

    In the agile software world, a retrospective is a meeting held by the project team at the end of every iteration/sprint to discuss what we learnt as a team, what we can improve as a team and plan the future iteration/sprint based on this learning.

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

    Читать запись полностью »

    12:38 am
    [t_gra]
    Primavera работает по Agile

    Думаю, многие знают фирму Primavera как фирму-производителя очень мощного и очень дорогого программного обеспечения для управления проектами.

    Эти инструменты вызывают прочную ассоциацию с Waterfall - водопадной моделью разработки ПО и управлением в стиле command and control. Диаграммы Ганта, назначение ресурсов из пула на работы, чётко определённые взаимосвязи между работами, артефакты, передаваемые из работы в работу….

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

    Теперь внимание - вопрос!

    Каким образом разработано программное обеспечение для управления проектами Primavera? То, которое позволяет строить диаграммы Ганта и распределять ресурсы, определять критический путь и т.д.? Напрашивается ответ, что эксперты по традиционному управлению проектами и своим проектом управляли традиционно, по Waterfall’у.

    До четвёртой версии - да. Так и работали. Но версия 5.0 их флагманского продукта разработана с использованием Scrum. Думаю, что и текущая 6-я.

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

    Пришла пора понять, что в стиле Command & Control и по водопадной модели (либо по “итерационной” модели, где каждая итерация представлена маленьким водопадиком) управлять проектами разработки ПО нельзя.

    А программное обеспечение Primaver’ы пригодится. Не только в области разработки ПО нужно управлять проектами. Да и работая по Agile, иногда можно воспользоваться традиционным проджект-менеджерским ПО. Например, я несколько раз пользовался таким ПО для иллюстративных целей, чтобы показать, как примерно могут в реальности происходить работы в течение итерации.

    Запись опубликована AgileProductivity. Пожалуйста, оставляйте комментарии там.

    AgileProductivity: Утройте продуктивность команды программистов, используя гибкие методологии   About LiveJournal.com