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


Q: What is 'agile'? Is it a new methodology like RUP?
A: Agile is not really a methodology but a set of principles and values which create a base for cooperative and collaborative project environment. This is done by means of techniques that focus on keeping clients and the team together, fostering information exchange and creativity. It is more a philosophy rather than a methodology. There are no straightforward methods or steps which you could have simply followed. Instead there are good ideas and essence from experience that you can adopt and develop further into solutions that work in your very specific case.

Q: What is to be agile? How can I know if I am or my project is agile
A: Formally speaking to be agile means to respect the values of the agile manifesto.
In your daily/professional life being agile means to be flexible enough to embrace changes later in the project; to be creative, communicable and positive in such an extend so that any software tools could ever replace this; respect people you are working with, value people over papers, foster information sharing; being focused on the end product of your work, not the intermediate results.

Q: What on earth is 'Scrum'?
A: Scrum is one of the agile approaches that became quite popular over the last decade. Being about agile it shares the same ideas but yet provides a framework that helps you manage uncertainty and complexity of your project, gives you guidelines to organize cooperation between the business side (the client) and your technical side (the team), creates positive environment for growing excellent jelled teams.

Q: How can I choose an agile approach?
A: All agile approaches are quite similar as they share the same principles and values. What they differ in are some accents, details and specifics. So in some case one agile approach might be more appropriate than the other. In theory it doesn't really matter which one you choose to start with because being agile means learn-and-adapt fast, so sooner or later (depending how agile you and your team are) you will develop 'your agile approach'. In practice though I'd recommend to become familiar with at least several agile approaches like Scrum, eXtreme Programming - XP, Evo, Crystal, Adaptive SD... that you can comprehend and choose the one that more likely to work in your very specific case.

Q: What is the difference between Scrum and XP (eXtreme Programming)?
A: It depends on what you understand under XP. Most people unfortunately are familiar only with the engineering aspects of XP: test-driven development, refactoring, pair programming, continuous integration, simple designs (YAGNI principle). But XP doesn't end and is not limited to these aspects. Indeed, it is an integrated process that covers all aspects on software development: from requirements management to testing, from release to sprint planning to task estimations. All of the practices support each other and make the whole thing work. More on the XP practices you can find for example here: Ron Jeffries' blog.
To sum up: XP is an independent agile process that can be applied in all areas of the project.

Now about Scrum. In contrast to XP with its strong accent on engineering practices, Scrum is a simple framework rather a process which provides guidelines but leaves the choice of concrete practices such as requirements management, engineering techniques up to the team.

Does it mean a project can follow Scrum guidelines on planning and use engineering practices from XP - definitely yes. It is even recommended because of the benefits that XP engineering practices are proven to bring.

Don't forget that Scrum is about common sense which means that if XP (or other) approaches seem to be logical for you - you should probably bring them into your Scrum process.

to be continued...

Q: What is the difference between a Project Manager and this 'ScrumMaster'?

Q: Is there anyone practicing Scrum in Ukraine? Russia?

Q: Can I pass Scrum certifications (CSM and other) in Ukraine?

Q: Is Scrum a silver bullet?
A: http://en.wikipedia.org/wiki/No_Silver_Bullet

Q: Is there any evidence of successful projects doing Scrum?

Q: Is there any way to convince my clients to try Scrum?

Q: What this 'velocity' is about? Do I need it?

Q: My company is in progress on CMMI model L3(4,5). Why should we bother about things like Scrum?


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

Автор: Richard Lawrence
Переведено с английского проектом Agile Translations

Хорошие Пользовательские Истории следуют INVEST модели, предложенной Биллом Вейком (Bill Wake). Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

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

Автор: Илья Павличенко.

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

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

Ретроспектива спринта - эффективный формат

Автор: Майк Кон (Mike Cohn)
Перевод с английского

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

Какие проекты лучше всего подходят для применения Agile

Автор: Майк Кон (Mike Cohn)
Переведено с английского проектом Agile Translations.

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

На мой взгляд, здесь было бы уместным привести аналогию с промышленным производством. День за днем, собирая один и тот же тип автомобиля, мы довольно быстро учимся всем нюансам сборки этой модели. Здесь нам не нужны гибкие подходы, потому что степень новшества данного процесса является довольно низкой. Однако, инновация сама по себе не означает, что мы дол…

Об agile по-русски: User Stories, часть 1

«Разработка ПО - это игра изобретательности и кооперации»
Элистер Коуберн (1)
О чем эта статья? Это одна из статей серии «Про agile по-русски» (см. сноску внизу про значение термина «agile»), идея которых поделиться опытом использования agile принципов (2) в разработке программного обеспечения. Основная суть этих подходов – кооперация между всеми членами проекта и адаптивность процесса разработки к неизбежным изменениям. Также важным аспектом Agile является принятие человеческого фактора в проекте как неотъемлемой части и более того – как наиважнейшей причиной прогресса. Agile акцентирует важность поддержания человеческих отношений и учета человеческих особенностей для успеха проекта.Эта статья рассказывает о применении «userstories» («пользовательских историй») - одной из практик agile. Далее для краткости я буду называть их просто «историями». Для кого эта статья? Эта статья для профессионалов по разработке программного обеспечения: менеджеров продуктов, менеджеров верхнего и среднег…