Автор: Наталья Тренина В последние пару лет, примерно раз-два в месяц, я получаю сообщения, похожие по своему содержанию. К примеру: Наталья, здравствуйте. Хочу попросить у вас совета, как специалиста в области Agile и Scrum. Я нахожусь в процессе изменения вектора в своей карьере. Давно зрел, и сейчас окончательно решил стать Project Manager. Хочу быть причастным к созданию чего-то полезного. Дальше, как правило, следует беспокоящий вопрос, или просьба посоветовать что-то конкретное. Это очень волнительный момент, сколько бы раз происходило. Влиять на развитие организации морально куда легче, чем давать советы конкретному человеку. К тому же, #яжкоуч - прекрасно понимаю что советы редко бывают верны, и размывают ответственность за принятое решение. Я пришла в гибкую разработку из классического мира проектного управления, куда меня занесло непредсказуемой закономерностью. Вскормленная книгами Барри Боэма и Тома ДеМарко, за годы фриланса, класическая девочка-задрот, постеп

Автор: Наталья Тренина Внедрение любых реорганизационных изменений - будь то гибкие процессы на базе Scrum или Kanban, или освоение технических практик, таких как TDD, парное программирование, автоматизация тестирования в инженерную культуру команды, связано с изменением привычного поведения человека. Мы можем многое говорить о культуре организации, стиле управления, уровне вовлеченности сотрудников, особенностях проекта - всем том, что коучи одним словом называют “контекстом”, когда увиливают от давания советов ;) Но, в конечном счете, способность организации совершенствоваться упирается в способность каждого ее конкретного сотрудника изменяться. И эта способность может быть тренирована как навык! Невозможно дать хороший совет на уровне проекта и команды, не копнув как следует в организационный контекст. Но вполне возможно дать хороший совет на микро-уровне изменений - уровне каждой конкретного члена команды.

Автор: Браян Барр (Brian Barr) Переведено с английского проектом Agile Translations   Существует множество заблуждений о том, что означает Agile. Вот несколько из наиболее распространенных мнений: Agile является методологией разработки. Вообще-то, это не совсем так, но есть группа методов, которые можно отнести к Agile-методологиям (гибким методологиям).  Agile – это то же самое, что и Скрам. Это не одно и то же. Scrum является одним из самых известных и широко используемых. Agile подходов. Однако существуют и другие подходы, которые также считаются Agile. Agile – открытый путь разработки ПО. Это самое глубокое заблуждение. Когда Agile применяется правильно, он становится основой самой дисциплинированной практики разработки программного обеспечения из всех существующих. Итак, что же такое Agile?

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Автор: Наталья Тренина Около полугода назад мне в руки попала книга Чарли Пелерина How NASA builds teams . В книге описывались социальные проблемы крупных технологических проектов, которые обошлись в миллионы долларов космической промышленности США. И, что более ценно - выводы, сделанные Чарли, в форме системы оценки социального контекста проектов NASA 4-D . По ссылке вы можете открыть весьма олдскульный сайт с анкетой, рекомендациями по заполнению и довольно обширными выдержками из книги. Однако, после нескольких экспериментов со знакомыми аджайл-командами, я пришла к выводу, что в мире современного user experience и живого общения, любую мудрую систему можно сделать чуть проще и человечнее :) Итак, спустя несколько месяцев в моей практике появился такой вот ВОРКШОП ПО “СОЦИАЛЬНЫМ ТЕРМОМЕТРАМ” Как его провести? Небольшой мануал ниже.

Автор: Хенрик Книберг (Henrik Kniberg) Перевели с английского: Александр Андронов , Антон Бевзюк и Дмитрий Павлов . ATDD с передовой Разработка через приемочное тестирование для начинающих  Если вы когда-нибудь бывали в такой ситуации: Тогда эта статья для вас — конкретный пример того, как начать разработку через приемочные тесты (Acceptance-test driven development) в действующих проектах с легаси кодом. В ней описан один из способов решения проблемы технического долга . Это пример из реального проекта, со всеми изъянами и недостатками, а не отполированное упражнение из книги. Так что надевайте свои берцы. Я буду использовать Java и JUnit, без всяких модных сторонних библиотек (которыми, как правило, злоупотребляют). Предупреждение: Я не утверждаю, что это единственный Правильный Путь, существует много других “стилей” ATDD. Так же в этой статье не так много чего-то нового и инновационного, здесь просто описаны хорошо себя зарекомендовавшие подходы

Автор: Карлтон Неттлетон (Carlton Nettleton) Переведено с английского проектом Agile Translations . Несколько недель назад я получил сообщение от своего бывшего ученика с печальными новостями – его компания уволила всех Скрам-мастеров и заменила их на “Аджайл Менеджеров Проектов”. Теперь он остался без работы, а Cкрам потерпел серьезную неудачу в их организации. Это было довольно грустно :(

Автор: Илья Павличенко Утекают последние деньки 2013 года, и у меня возникло желание составить список заслуживающих внимания книг по Аджайл/Скрам тематике, вышедших в этом году. 2013ый оказался урожайным на качественную литературу, что меня искренне радует. Ровно 20 (двадцать) лет назад появилась первая Скрам команда в компании Easel, 12 (двенадцать) лет как подписан Аджайл Манифест. За это время появилось большое количество великолепных тренеров, которые смогли переварить десятки проектов, набить кучу шишек и накопить горы опыта. Теперь эти тренеры-практики пишут умные книжки, в которых описывают результаты многолетней работы с Аджайл/Скрам командами. Мне кажется, глупо не воспользоваться их багажом. А стоит это совсем немного. Книги в предложенном списке расположены в произвольном порядке и были прочитаны мною лично. Итак, начнем. Growing Agile: A Coach's Guide to Training Scrum   Автор: Саманта Лэйнг и Карен Гривс. Тематика: книга написана двумя сертифицированны

Автор: Майк Кон (Mike Cohn) Переведено с английского проектом Agile Translations . Стараясь выбрать лучшего Скрам-мастера, некоторые команды выбирают стратегию ротирования (передавания) этой роли между членами команды. Я не сторонник такого подхода, так как не думаю, что постоянная ротация демонстрирует должное уважение к трудностям и значимости этой роли. В моей семье мы по очереди убираем со стола и загружаем посудомоечную машину. Любой из нас может сделать эту работу. Однако, мы не готовим ужин по очереди. Моя жена намного лучше готовит, чем кто-либо в семье. И мы хотим, чтобы наша пища была приготовлена как можно лучше, потому и не чередуем приготовление ужина.

Автор: Джим Хайсмит (Jim Highsmith) Переведено с английского проектом Agile Translations . Когда я общаюсь с представителями компаний из всех уголков мира, становится ясно, что значительное их количество все еще погрязло в болоте продуктивности, эффективности и оптимизации. Их легко вычислить, потому что они часто одержимы измерением велосити (veloctiy) — велосити команды, велосити среди нескольких команд, велосити на уровне организации или даже велосити конкретного разработчика (ой!). Погоня за увеличением велосити убивает гибкость. Это крайность в употреблении неплохого инструмента для неправильных целей: Велосити все чаще используется в качестве метрики продуктивности (а не в качестве способа нормирования нагрузки команды, как задумывалось), что слишком фокусирует внимание на объеме законченных стори поинтов.  Фокусировка на объеме отвлекает внимание от качества удовлетворения потребителей и достаточного инвестирования в механизм поставки (в техническое качество).  П

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Автор: Майк Кон (Mike Cohn) Переведено с английского проектом Agile Translations . Несколько недель назад я обещал написать статью об особых сложностях, связанных с оценкой (эстимацией) нефункциональных требований. Для начала давайте вспомним, что нефункциональные требования – это требования, которые больше связаны с состоянием самой системы, нежели с деталями ее функциональности. Обычно нефункциональные требования касаются производительности, корректности, удобством сопровождения системы (maintainability), функциональной совместимости (interoperability), ее переносимости на другие платформы (portability) и т.д. Кстати, нефункциональные требования также могут быть описаны в виде Пользовательских Историй. Трудность при их эстимации состоит в том, что эти требования имеют двойные издержки. Первый тип издержек – это стоимость первоначального соответствия , а второй – стоимость непрерывного соответствия этим требованиям. Давайте рассмотрим конкретный пример, чтобы на практике разоб

Автор: Майк Кон (Mike Cohn) Переведено с английского проектом Agile Translations . Недавно меня спросили, для какого вида проектов больше всего подходит применение гибкого подхода разработки, и сейчас я хотел бы об этом поговорить. Мне кажется, самыми подходящими для использования гибких методик являются проекты с агрессивными сроками выполнения, высокой степенью сложности и так же высоким уровнем инновации (уникальности). Мы хотим использовать Agile, когда делаем что-то новое, по крайней мере, новое для конкретной команды разработки. Если команда делает то, что она уже делала не один раз, она, вероятно, не нуждается в гибком подходе. На мой взгляд, здесь было бы уместным привести аналогию с промышленным производством. День за днем, собирая один и тот же тип автомобиля, мы довольно быстро учимся всем нюансам сборки этой модели. Здесь нам не нужны гибкие подходы, потому что степень новшества данного процесса является довольно низкой. Однако, инновация сама по себе не означает, что

Автор: Морган Альстром Перевод с английского проектом  Agile Translations . Давайте на секундочку представим, что нам нужны оценки для выполнения нашего проекта. Некоторые из вас скажут, что вы и так их уже применяете. Но, наверное найдутся и те, кто назовет эстимации пустой тратой времени. Независимо от вашего мнения на этот счет, давайте все же допустим, что эстимации имеют место в нашей работе. Обычно мы выполняем эстимацию, чтобы получить некоторую степень прогнозируемости относительно сроков поставки нашего продукта. Вся проблема в том, что самой по себе эстимации для этого, увы, недостаточно. Знание того, что некая задача потребует 6 человеко-недель, на практике не имеет никакой ценности, если вы не уверенны, что эти 6 человеко-недель есть в нашем распоряжении. Для получения более реальной прогнозируемости, нам нужно комбинировать свою эстимацию с неким показателем нагрузочной способности (capacity) команды. На деле есть большая разница, сможет ли команда выделить необходи

Автор: Дэйвид Андерсон (David Anderson) Перевод с английского. Взято с www.software-kanban.de Я осознаю, что большинство Agile-коучей и консультантов довольно часто неправильно понимают, что же это значит – быть Канбан-коучем. Следовательно, они склонны считать, что Канбан – это всего лишь еще одна методика, которую они могут легко внедрить, применяя свои привычные тренерские техники, проверенные на опыте внедрения Agile. Но это предположение является в корне ошибочным! В результате него, некоторые Agile-коучи хотят предлагать Канбан, как один из многих инструментов, наряду с их остальными тренерскими услугами. Тем самым они недооценивают важность посещения специализированных мастер-классов по Канбану для тренеров, менеджеров и консультантов. Особенно интересным является тот факт, что я не замечаю подобного у консультантов по другим областям, таким как CMMI, Six Sigma (6 сигм), Lean (бережливое производство), Теория ограничений, управление рисками и т.д. Они не приходят с пр

Автор: Майк Кон (Mike Cohn)  Перевод с английского. Я сильно интересуюсь оцениванием и планированием и всегда обращаю внимание на новые статьи в блогах и новостях, говорящих о том, что “Оценивание - напрасная трата времени! Не делайте его!”. Меня не удивляет, что аргументы против оценивания и планирования исходят не от бизнесменов, для которых мы разрабатываем продукты или системы. Они понимают важность оценок и планов (и недостатки плохих оценок и планов).

Автор: Майк Кон (Mike Cohn)  Перевод с английского. В одной из мартовских заметок своего блога, я ввел термин, который в то время пробовал ввести в обсуждениях и некоторых классах. Термин был "GASP" и расшифровывался как общепринятая практика Скрам (англ. Generally Accepted Scrum Practice). В чем я сейчас действительно заинтересован и, надеюсь, вы мне в этом сможете помочь, так это создать список всех общепринятых Скрам-практик которые мы знаем. Читать дальше >>>

Автор: Хенрик Книберг (Henrik Kniberg) Перевод с английского проектом  Agile Translations . Разработать продукт непросто. Большинство попыток разработки терпят неудачу, и самой распространенной причиной этого считается создание неправильного продукта. Spotify - шведский низкобюджетный стартап с замечательными показателями выпуска продуктов. Их продукты любимы пользователями и артистами, они распространяются со скоростью вирусов - у них более 20 миллионов активных пользователей, 5 миллионов платных подписчиков, и быстрый рост продолжается. К примеру, чтобы в США начать с нуля и дорасти до 1 миллиона платных подписчиков, им потребовался приблизительно год, а ведь это иностранный рынок, где присутствует множество крепких игроков. Главная идея Spotify – предоставить вам музыку для каждого момента. Это неограниченный доступ к любой музыке мира и возможность быстро ею поделиться. Чем больше музыки «расшарено» и проиграно, тем больше денег поступает артистам. Начавшись c музыкальног

Автор: Майк Кон (Mike Cohn) Перевод с английского Неважно, насколько опытной является Скрам-команда, при этом всегда существует возможность для ее улучшения. Не смотря на то, что хорошая Скрам-команда будет постоянно искать возможности для своего улучшения, она должна выделять короткий период времени в конце каждого спринта для сознательного размышления над тем, как идут их дела, и для поиска способов их улучшения. Все это происходит во время Ретроспективы спринта.

Автор: Алексей Кривицкий Как многим уже известно, мы стартовали инициативу по переводу наиболее востребованных и популярных статей - проект  Agile Translations . Часть этой активности взяли на себя активисты сообщества AgileUkraine, а часть спонсирована SCRUMguides . Переводы, опубликованные в феврале: Планирование релиза: уходим от термина, но не от практики   Майк Кон  Общепринятые практики работы с Беклогом Продукта Майк Кон  Менеджер 2.0: роль менеджера в Скраме Пит Димер Присоединяйтесь к нашей команде переводчиков. Мы используем Канбан и командный подход для выпуска переводов.

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.

Автор: Майк Кон (Mike Cohn)  Перевод с английского. Последнее время я задавался вопросом – не подходит ли Скрам к тому моменту, когда в нем появится еще один митинг – Backlog Grooming Meeting (дословно “встреча по уходу за беклогом”). Потому как подобные встречи проводятся каждый спринт всё большим и большим количеством команд, чтобы убедиться, что беклог будет готов к следующему спринту. Для того, чтобы понять почему Backlog Grooming Meeting всего в нескольких годах от того, чтобы стать общепринятой практикой Скрам, давайте вспомним начало 2000-ых годов. Читать дальше >>>

Автор: Пит Димер (Pete Deemer)  Перевод с английского.  Когда организация начинает использовать Скрам, поначалу часто возникает неудобный момент: кому – то начинает казаться, что роль «менеджера» полностью утрачивается. «Надо бы просто избавиться от них», острит какой-нибудь разработчик, и все менеджеры начинают беспокойно ерзать в своих креслах. Скрам определяет только три роли: Владелец Продукта, Команда и Скрам-мастер, а главная инструкция для всех остальных в организации – «поддерживать их или убраться с дороги». Не слишком ясная формулировка, особенно если ваше начальство ожидает от вас, как старшего менеджера, что все складывается благополучно. Читать дальше >>>

В самом начале февраля пройдет зимний кемп по гибкой разработке. Последние 2 конференции были тематическими и мы продолжаем эту традицию. Что на этот раз в фокусе программы? Do right things. Do things right. Do them fast. Три ключевых постулата гибкой разработки начинаются с ценности. Ясное видение “правильного” продукта является мощным драйвером командной работы, технологической изобретательности и эффективных процессов. Поэтому, в фокусе следующего кемпа - важность понимания большой картины проекта, ценности продукта, особенностей домена, нужд пользователей и сближение “бизнеса” и “разработки” в поиске лучших решений. Три категории докладов: "Drive VALUE", "Drive TECH" и "Drive TEAM" покроют темы продуктовых техник, инженерных практик и командной работы.

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

Автор: Алексей Кривицкий, CST Семь лет назад, когда я запускал свой первый Скрам-проект (Ciklum, проект Encode, 2004 год) мы не знали, что такое груминг. Заказчик созванивался с нами для планирования спринта... и тут начиналось: мы задавали глупые вопросы, заказчик куда-то убегал за ответами, с кем-то советовался и менял приоритеты, мы воевали с картами за стори-поинты, били истории на задачи... Планирование спринта у нас редко занимало меньше 8 часов. Читать дальше Принять участие в обсуждении практик груминга на форуме AgileUkraine.

Три мифа и три совета Мне посчастливилось в этом году работать и общаться в интернациональной среде. Могу вам сказать, что почти везде, где я бываю, некий менеджер, или менеджер проекта отводит меня в сторонку со словами: «Джоанна, можно ли задать вам дурацкий вопрос?». Я всегда отвечаю, что уверена в том, что этот вопрос вовсе не дурацкий. . Этот менеджер, он или она, кивает в ответ, убежденный в том, что такая проблема есть только у него. «Все так быстро меняется. Я просто не знаю, как мне за этим угнаться, как это все контролировать. Как правильно распределить людей по проектам? Мне кажется, что не нужно постоянно переводить их с места на место, но ведь задействовать экспертов в проектах все-таки стоит, не правда ли? Оказывается, некоторые проекты не требуют постоянного участия такого количества сотрудников. Поэтому я не хочу перенасыщать такие проекты персоналом. С другой стороны, недостаток сотрудников тоже нежелателен. Иногда выиграть невозможно». Дорогие менеджеры, интуиция

TDD .NET in Action или Как за 2 дня .NET-разработчику научиться жить без отладчика Какие проблемы мучают разработчиков? Средство, которое решает все эти проблемы Зачем нужен тренинг? Аудитория Тренеры Стоимость Контакты и регистрация Какие проблемы мучают разработчиков? Непонятно с чего начинать реализацию очередной фичи Трудно работать с чужим кодом: никогда не знаешь, что где сломается, если его поменять Страх перед улучшением архитектуры приложения: "не меняй то, что работает" Починка багов: нужно обнаружить поломку затем ее починить нет гарантий, что исправление одних багов не породит другие Долгое ожидание обратной связи: ошибки обнаруживаются на стадии тестирования, и возвращаются к разработчику в то время, когда он занят другими делами. Все эти проблемы понижают эффективность работы. Вместо того, чтобы писать код и наслаждаться этим процессом разработчики тратят свое время на менее приятные вещи, вроде поиска и исправления дефектов. Если добавить к это

Вот и пришло время официально объявить о наборе в летний лагерь AgileBaseCamp в Днепропетровске. Приглашаем всех на конференцию по гибкой разработке 2-го июля в славный город на Днепре! В честь 10-летия подписания AgileManifesto - набора принципов, изменившего целую отрасль программной разработки, компания SCRUMguides , совместно с партнерами проводит серию конференций в Украине. AGILE: Ten years after. Always something NEW! Есть интерес к Agile? - Мы едем к вам! Хотите познакомиться с принципами и практиками Agile Software Development? Поэкспериментировать с инструментами? Нужны практические рекомендации? Хотите поделиться опытом или наоборот - задать вопрос коллегам? К вашим услугам AgileBaseCamp - популярная и постоянная площадка для обмена опытом тех, кто умеет и любит писать софт. В наших котлах уже вскипает программа, но секретными ингредиентами - докладами, мы поделимся чуть позже. Зато уже знаем докладчиков, которые заварят эту кухню: Алексей Кривицкий ,

Автор:  Александр Белецкий. 16 Апреля 2011 года, прошла очередная встреча AgileBaseCamp, на которой мне посчастливилось побывать. Место было выбрано очень удачно, это база Пуща-Озерная, за Киевом, с красивейшими пейзажами и чистым воздухом. Время, также было не случайным - встреча посвящалась 10-летию подписания Agile Manifesto . Все доклады были разделены на 4-ре потока Process, People, Practice, Mix (наверное многие "аджалисты" были возмущенны увидев Process в программе конференции, но я списываю это на тонкий юмор организаторов). Каждый участник мог выбрать поток, который наиболее близок к его интересам. В силу своих интересов, я больше присутвовал на докладах класса Practice & Mix. Открыл конферецию Алексей Кривицкий , довольно интересным экскурсом к началу в историю аджайл на своем примере, а также своим видинием того, что предсавляет из себя аджайл сегодня и чем он может быть завтра. Далее следовали интересные технические доклады, которые я с удовольствием

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

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

Несмотря на все обилие статей, вопрос о том как объяснить Scrum по-прежнему актуален. Особенно, если вам необходимо объяснить Scrum кому-нибудь другому – коллеге, начальнику, заказчику и т.п. Ниже приводиться подборка видео-роликов на тему “что такое Scrum”. Читать дальше...

В Agile сообществах давно обсуждается вопрос оценки уровня “Agile зрелости” команд. Чаще всего вопрос остро встает после того, как команда практикует какую-то Agile методологию шесть и более месяцев. Обычно это звучит как “мы уже научились делать основные практики, например Scrum, и все-таки чего-то не хватает”. Оценка производительности, эффективности и другие “метрические” оценки не имеют смысла, так как каждая команда уникальна в своем роде, и такие метрики будут сильно отличаться от команды к команде. Оценка “заказчик доволен” тоже не всегда адекватна, так как удовлетворенность одного или нескольких человек еще не гарантирует, что ваша команда действительно хорошая и наоборот. :-) Читать дальше...

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...

"Fixed-price" проекты являются обычной практикой в IT или как результат фиксированной стоимости конкурсной предлагаемой цены, или как результат бюджетных давлений внутренних проектов разработки ПО. Я помещаю термин «fixed-price» в кавычки, потому что проекты часто выходят за рамки бюджета, но ради обсуждения давайте проигнорируем эту противную маленькую часть реальности. Организации часто предпочитают fixed-price проекты в попытке уменьшить свой финансовый риск. К сожалению, кажется, что на практике происходит совершенно противоположное. По-видимому, все об этом знают, но почему-то мы не можем выбраться из этой канавы. В этом месяце я обсуждаю вопросы, окружающие fixed-price проекты IT, в надежде мотивировать вас удалиться от этой сомнительной практики. Из Dr Dobb's, автор Скотт Амблер. Читать дальше...

Хороший способ проверить, использует ли ваша команда доску для того, чтобы по настоящему управлять своей работой - это посмотреть на их ежедневный митинг (daily standup). Читать всю статью...

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

Учебный Центр Luxoft приглашает Вас принять участие в конференции Agile Labs 2009 по гибким методологиям разработки ПО, которая состоится 31 марта в Москве. Agile Labs 2009 - первая в России и СНГ масштабная встреча профессионалов , которые применяют практики Agile при разработке ПО. На конференции независимые эксперты поделятся с Вами своим опытом применения Agile-методов, выскажут свои точки зрения на эффективность гибких подходов, поспорят на тему "За" и "Против" Agile. Для кого будет полезна эта конференция? Agile Labs - конференция для профессионалов софтверной индустрии, которые применяют на практике, или только собираются применять гибкие методологии разработки ПО. Конференция полезна всем участникам Agile-команд, от разработчиков до Agile-коучей и менеджеров проектов. Для всех, кому интересны ответы на вопросы "что такое Agile на практике?", "когда и как применять Agilе?" Содержание конференции: Практически все доклады методологические (

Автор: Алексей Кривицкий. Наконец-то, снова встреча в Agile клубе! Когда? 12 марта 19:00 - 22:00 Где? Благодаря компании GlobalLogic , место проведения остаётся неизменно: G-клуб, Киев, ул. Боженко, 86д ссылка на карту На проходной говорите, что вы в клуб, оставляете свои координаты и получаете пропуск. Пройти в клуб - на второй этаж, потом прямо, через дверь, сново прямо во внутренний дворик, вниз по лестнице. Тема встречи Мы собираемся провести ряд мини-рассказов с последующими дискуссиями. Темы обсуждений: "Как мы успешно не делаем оценки проектов" (по следам дискуссии Estimations considered harmful ) Евгений Компаниец "Как анализ корневых причин (root cause analysis) помог провести хорошую ретроспективу" Алексей Кривицкий "Преданность" (commitment) команды проекту и друг другу. Какие в этом минусы и как с этим бороться Артём Сердюк Локальная "оптимизация" костов фирмы в условиях кризиса, и всё что из этого вытекает: учет рабочего времени пр

Автор: Алексей Кривицкий. Седьмая конференция Agile Gathering уже не за горами. Дата : 18 или 25 апреля (весь день) Место : г. Киев (варианты подискиваются) Программа : Как было договорено  помимо докладов мы бы хотели провести мы ряд воркшопов на такие темы как: Практика Test-Driven Development (TDD). Рефакторинг старого кода. Полноценная Scrum симуляция с LEGO.  Клуб Скрам-мастеров Следите за анонсами и не пропустите регистрацию. Не забывайте, конференцию делаете вы . Так что, ждём докладчиков!

Автор: Алексей Кривицкий. Недавно (благодаря коллеге) пришла идея симулировать Scrum на тренингах при помощи конструктора Lego. Идея пошла в ход, и я сейчас могу сказать, что это реально иллюстрирует многие аспекты работы Scrum команд. Читайте полную статью  (на английском)

Как известно Agile без автоматизации регрессионного тестирования невозможен. В марте Николай Алименков проведёт в Харькове и Киеве тренинги по автоматизации тестирования web приложений с Selenium. Детально будут рассмотрены следующие вопросы: Теоретические основы Selenium (Core, RC, Grid) Использование Selenium IDE Практическое написание тестов на тестовом приложении с помощью Core и RC (язык Java) Подходы к написанию функциональных тестов на Selenium Selenium в Agile методологии Применение Selenium для Acceptance Testing Применение Selenium для TDD Детали и регистрация

Учебный Центр Luxoft приглашает принять участие в тренинге: "Инженерные практики Agile" Инструктор: Евтушенко Сергей (Certified Scrum Master) Даты проведения: 18-19.02.09 Длительность: 8 час. Время: 10.00-14.00 Место проведения: г. Киев, ул. Радищева 10/14, БЦ "Ирва", корпус Б, 2-ой этаж Стоимость: 770 грн. В ходе курса описываются инженерные практики, которые делают возможной agile разработку, и их взаимодействие. Рассматриваемые темы: Что такое agile методологии? Что такое XP, Scrum, Feature-Driven Development? Каковы их особенности? Какова роль инженерных практик при использовании agile? Инженерные практики и их взаимодействие Какие инженерные практики используются в agile проектах? Каковы подводные камни при внедрении практик? Детально рассмотрены следующие практики: Модульное тестирование, разработка на основании тестов Приемочное и интеграционное тестирование Техники совместного конструирования (парное программирование, коде ревью, рот

Автор: Алексей Кривицкий. Планирование спринта - это сердце Скрама. Это событие, на котором принимаются решения, определяющие настроение и ход последующих нескольких недель работы. Недобросовестно выполненное спринт планирование может поставить под угрозу успех очередной фазы проекта, породить ряд бессонных ночей заказчика и серию поздних вечеров и офисных выходных у членов команды... В общем много ненужных неприятностей и разочарований. Хорошая новость - есть ряд проверенных практик, которые минимизируют ошибки планирования спринтов. Об этом мы и поговорим... Читать всю статью .

Автор: Алексей Кривицкий 13 и 14 февраля в Киеве пройдёт серия Scrum-тренингов: Базовые концепции Agile и SCRUM Планирование, оценивание и управление проектами по Agile и SCRUM На 6 февраля к каждом классе есть по 5 мест. Будем рады видеть всех желающих.

Автор: Алексей Кривицкий. Сейчас пришло время, когда есть повод пересмотреть свои старые договорённости: компании задумываются в необходимости удержания своих сотрудников, сотрудники подумывают о комфорте работы в своих компаниях, заказчики начинают искать варианты закрытия контрактов со своими старыми подрядчиками, подрядчики начинают сомневаться в выгодности исполняемых заказов... Все что-то переваривают, о чём-то усиленно думают. Сегодня появился повод сослаться на "Кризис" и под этим предлогом сменить условия сотрудничества. Мне хочется назвать это время "временем переосмысления". Что за прекрасное время! Давайте же использовать его потенциал!.. Читать дальше .

Автор: Алексей Кривицкий. После очередного тренинга по теме Автоматизация Приемочного Тестирования , который провёл в Харькове Николай Алименков, мы запустили тематическую группу дискуссий. Два месяца спустя после тренинга - самое интересное время. Некоторые команды сумели внедрить автоматическое тестирование при помощи Selenium. Некоторые используют связку phpUnit и Virtual box... Узнайте больше, расскажите про свой опыт, задайте вопросы коллегам. Перейти к группе дискуссий acceptance-testing

Александр Якима Поговорим о том, как происходит развитие продукта, что компания делает в процессе этого развития. Ключевым словосочетанием в части 2 нашего цикла будет Дорожная Карта . Но речь мы будем вести не о том, как рисовать диаграммы, а о Дорожной Карте, как о метафоре развития продукта. Для менеджера продукта в дорожной карте зашифрован путь к успеху его продукта. Для команды разработчиков в Roadmap'е тоже заключен очень важный смысл. Команда разработчиков, особенно в случае аутсорсинга, очень часто страдает от нехватки видения. Это приводит к весьма плачевным казусам. Основные симптомы: непонимание "языка" заказчика, невозможность каких-либо инноваций со стороны разработчиков или полностью бессмысленные результаты, поверхностное понимание требований (в частности, нефункциональных) - все из-за непонимания контекста - Дорожной Карты . Наоборот, команда, которая стремится к пониманию планов заказчика в развитии продукта, проявляющая инциативу в планировании,