К основному контенту

ЧаВо (или просто F.A.Q.)

Q: Что такое "agile"? Это методология подобная другим, к примеру, RUP (Rational Unified)?
A: Agile - это не методология в полном понимании этого значения, это скорее набор принципов и ценностей, которые создают проектную среду, благоприятную для общения и кооперации ради решения общих проектных задач. Это достигается техниками, которые фокусируют команду и заказчиков на тесном сотрудничестве, акцентируют внимание на важности обмена информацией, повышают уровень креативности. Agile - это больше философия, чем методология. В agile не существует четких методов и предписанных шагов, которым можно было бы безболезненно следовать. Вместо этого agile дает набор хороших идей и здравых советов, основанных на опыте, которые вы можете начать использовать в своих проектах и адаптировать под свои конкретные нужды.

Q: Что значит быть "agile"? Как я узнаю, что я или мой проект следует agile-принципам?
A: Формально говоря, быть agile означает уважать ценности agile манифеста.
В повседневной-профессиональной жизни быть agile означает - быть достаточно гибким, приветствуя изменения требований в проекте на поздней фазе; быть креативным, общительным и позитивно настроенным; уважать людей, с которыми работаешь, и ценить их больше чем формальности и бумаги; поощрать и сопутствовать распространению информации в проектной среде; быть сфокусированным на конечном результате труда - программном продукте, принимая все другие артефакты как сопутствующие.
Быть agile - значить ценить профессионализм, оставаясь гибким в отношениях с людьми.

Q: Что это за штука такая "Scrum"?
A: Scrum - это один из agile подходов в ведении проектов, который стал довольно популярным за последние годы благодаря своему успеху. За эти годы тысячи проектов преуспели благодаря его применению. Сберегая все ценности и концепции agile подходов, Scrum предлагает четкую и простую структуру проекта (framework), которая дает заказчику и команде котроль над такими важными рисками как изменчивость и сложность, которые присутствуют по всех проектах. Scrum предлагает принять простые но мощные правила, к примеру, - как организовать взаимодействие между двумя сторонами проекта - заказчиками и командой, как создать позитивную и креативную среду в проекте, как научиться принимать изменения со стороны заказчиков без увеличения рисков проекта, и проч. В итоге вы получаете отличную сработанную команду, полностью контролирующую ход проекта.
--------------------------

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

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

Все о Скрам от Майка Кона

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

Скрамбан - собираем лучшее

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

Планирование релиза: уходим от термина, но не от практики

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

Диаграммы Ганта и Agile проекты. Так уж они несовместимы?

Автор: Алексей Кривицкий. "Планы бесполезны, планирование необходимо". Ейзенхауэр Диаграммы Ганта – это традиционный механизм визуального планирования, который получил свою популярность благодаря артефакту традиционных проектов, который назывался Work Breakdown Structure (WBS), и продуктам Microsoft Project и Microsoft Project Server, которые позволяли конструировать и хранить WBS. Пропоненты Agile принципов много внимания уделяют визуализации и открытости планирования. Так почему же так часто в контексте Agile мы слышим критику в адрес диаграмм Ганта? Давайте разберёмся. Пару слов о терминологии. В данной статье " традиционными подходами " к управлению проектами (или просто традиционными проектами) называются те подходы или проекты, которые противопоставляются Agile проектам. Я не использовал термин «водопадных проектов», так как во-первых на практике настоящих водопадных проектов не так много, а во-вторых по мимо водопадных и Agile проектов есть ещё мн