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

Часто задаваемые вопросы по ретроспективам, 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.В мире гибких методологий разработки, ретроспектива — собрание, которое проводит проектная команда в конце каждой итерации/спринта, чтобы обсудить, чему мы научились, как команда и строить планы на следующие итерации/спринты, основываясь на извлечённых уроках.

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

ПОПУЛЯРНОЕ

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

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


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

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

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


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

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

Календарь тренингов по Agile

Наши партнёры по тренингам: