Merge pull request #25 from uran1980/master

Russian translation

russian/README.md

@@ -0,0 +1,42 @@
+# Agile Lite: Agile без перегрева
+
+"Agile разработка программного обеспечения" это отличная идея, которая переусложненна умными дядьками из мира таймменеджемента и консалтинга в сфере разработки ПО. Представленный в данной статье подход `Agile Lite` призван упростить ситуацию. Вам не нужны книги или семинары чтобы понять что такое `Agile Lite`. Вам достаточно иметь текстовый файл с несколькими параграфами описывающими этот подход. Это и есть этот текстовый файл.
+
+`Agile Lite` очень прост. Он может быть применен к любому проекту с людьми работающими над ним в команде, и если эта работа может быть разбита на мелкие части, которые в дальнейшем мы будем называть задачами (Issues). Как и другие Agile методологии `Agile Lite` использует короткие циклы разработки именуемые `Спринты` (Sprints). Что уникально в данном подходе, дак это то, что `Agile Lite` учитывает тенденцию команды к выгоранию при усиленной и продолжительной работе над проектом и призвана уменьшить, или даже исключить данный фактор, путем разбиения цикла разработки на **3-х недельный период спринта и 1-но недельный период разгрузки** (**3 weeks on/1 week off**).
+
+
+Базовое использование методологии состоит в следующем:
+
+* Первая неделя каждого цикла тратится на работу проджект-менеджеров и владельцев проекта на выработку задач на предстоящий `спринт`. В независимости от того, что на это выделена неделя, ежедневные сессии планирования не должны занимать более 2 часов в день, а вообще в идеале достаточно 45 минут в день. Эта неделя разгруки для команды разработчиков и в течении нее они могут просто отдыхать и разгружать свои мозги, занимаясь различной интересной для себя работой, например своими хобби-проектами, самообучением или чем-то другим, в общем, по максимуму расслабляться в эту неделю.
+
+* Далее начинается период 3-х недельного цикла спринта. В этот период разработчики работают над Задачами (Issues), которые были определены в первой неделе на сессиях планирования. Т.к. команда может быть удаленной и распределенной по часовым зонам, то живые митинги проводятся не часто и в основном вся коммуникация происходит через систему трекинга задач (issue tracking system), т.к. это более быстрый способ общения нежели по e-mail. Системой трекинга в данном случае может выступать Trello, не используйте для этого эксель таблицы гуглдокс, они для этого не годятся. Ежедневные стендапы не приветствуются; текущее состояние хода работы можно смотреть в системе трекинга тасков по мере обновления статусов задач разработчиками.
+
+* Как только начался период спринта, новые задачи не могут быть добавлены в текущий спринт, но могут удаляться из него. Тем самым мы уменьшаем переключение между контектами у разработчиков и не нарушаем их текущий настрой (не отвлекаем их от решения текущего потока задач), что есть хорошо.
+
+* Задачи, которые не были завершены в период спринта, пересматриваются на следующий спринт, в последующей неделе планирования, где по ним принимается решение продолжать ли ее выполнение в следующем спринте, или положит обратно в баклог (Backlog), или переназначить на другого разработчика.
+
+* Задачи, которые предстоит выполнить могут располагаться либо в беклоге (планируемые на будущее), либо в текущем спринте.
+
+* Как вы уже наверное поняли неделя планирования после спринта предназначена для разгрузки мозгов разработчиков и подготовки их к следующему периоду спринта. Здесь нет гонок на выживание. Разработчики не должны работать сверхурочно и в выходные дни. Все это призвано исключить выгарание команды. А исключение выгорания и стрессов полезно для всех.
+
+Вот и все. Данный подход не предписывает какие-то конкретные инструкции по разработке программного обеспечения, и это хорошо.
+
+Работа по поддержке проекта выполняется на ежедневной основе, т.к. всегда могут случаться какие-то сбои или форсмажеры и разработчики должны быть готовы их устарнить. Если такое происходит, то текущие задачи откладываются и решается возникшая проблема, после чего разработчик продолжает выполнять свои задачи.
+
+`Agile Lite` лучше обычного Agile и более подходящий способ разработки программного обеспечения. Он дает возможность разработчикам иметь более высокую производительность, а владельцам проекта иметь стабильную и эффективную комманду для развития своего продукта и получения прибыли.
+
+
+Чтобы узнать больше о `Agile Lite`, рекомендую вам прочитать также эти небольшие статьи:
+
+* [Agile Lite для разработчиков](agile_lite_for_developers.md)
+* [Agile Lite для менеджеров](agile_lite_for_managers.md)
+* [Часто Задаваемые Вопросы (FAQ)](faq.md)
+
+
+---
+
+Original Source: [Agile Lite: Agile without all the burnout](https://github.com/davebs/AgileLite)
+
+---
+If you would like to see more workplaces implement a system such as this, please star this repo on github and share on social media to increase visibility.  
+Dave Sullivan 2019 dave.brian.sullivan@gmail.com

russian/agile_lite_for_developers.md

@@ -0,0 +1,44 @@
+# Agile Lite для разработчиков
+
+Если вы уже достаточно давно работаете разработчиком в сфере IT, то вы, наверняка, хоть бы раз испытывали состояние выгорания. У такого эмоционального состояния найдется множество причин, но все они могут быть описаны как результат напряженной работы под большим стрессом достаточно продолжительное время.
+
+Все начинается вместе с проектом. Вначале проект имеет подробное описание требований и сроки дедлайна. По ходу его активной разработки требования постоянно изменяются, а сроки окончания остается на месте. И вот наступает дедлайн, в который вы, естественно, не укладываетесь. Взглянув на начало проекта вы осознаете, что требования к проекту теперь совершенно отличается от тех, что были изначально. 
+Конечно, вы считаете себя виноватым в том, что не уложились в эти сроки, и вы все чаще начинаете работать сверхурочно, чтобы что-то доделать или исправить. И вот к концу очередной напряженной рабочей недели, неважно как усердно вы ее отработали, менеджер проекта вами по-прежнему не доволен, т.к. проект постоянно не укладвается в установленные сроки разработки.
+
+Отдыхая после работы или находясь в отпуске вы постоянно считаете, что вы бездельник и моглибы потратить свое свободное время на доработку проекта. 
+Со временем вы все больше начинаете считать, что весь проект и поддержка команды лежит только на вас.
+В офисе к вам так часто обращаются с разными просьбами, что ваше вынужденное отсутсвие на рабочем месте воспринимается как прогул, почти все сотрудники знают когда вы уходите и приходите и вы не можете незаметно отлучиться даже на 5 минут. 
+И всегда когда кто-то у вас спрашивает как дела, вы постоянно повторяете одно и тоже: "Я занят! Я очень занят!".
+
+И наконец наступает момент когда вы говорите самому себе: "Да пошло оно все...". 
+Возможно, вы меняете свою работу и устраиваетесь в другую IT компанию, но там все тоже самое повторяется снова и снова.
+Возможно, вы все-таки остаетесь, но теперь становитесь пофигистом, при любом обращении к вам хамите и посылаете людей подальше и в конце-концов вас увольняют за неподобавющее поведение или оскарбление кого-то из менеджеров.
+Возможно вы решаете просто кардинально сменить область своей деятельности и уйти из сферы IT разводить кроликов или продавать фрукты.
+
+> Вобщем, как в той поговорке: если хочешь убить свое увлечение или хобби - сделай его своей работой.
+
+У меня есть решение. Это гибкая форма [Agile разработки](https://ru.wikipedia.org/wiki/Гибкая_методология_разработки), которая пожет вам избежать выгорания. Я называю ее `Agile Lite` (Agile без перегрева).
+
+Ее оснонвые правила следующие: 
+* Каждый цикл разработки включает 3 недели спринта и 1 неделю разгрузки, в которую выполняется планирование спринта на следующий период. Мантра: **3 недели спринт / 1 неделя разгрузки**.
+* Сприн включает в себя решение задач (`Issues`), и разработчики их решают, и регистрируют их выполнение в специальной системе трекинга.
+* Как только начался 3-х недельний сприн, в этот период никакие новые задачи не могут быть добавлены в данный спринт, только удалены/закрыты. Это исключает частые переключения разработчиков между контектсами задач и это хорошо.
+* Задачей (`Issue`) является любой блок работы, который занимает от 4 до 8 часов рабочего времени разработчика и который прописан в виде описанной задачи (таска) в систему трекинга.
+* Любые задачи в текущем спринте, которые не были завершены по окончанию очердного периода спринта, пересматриваются в течении периода недельной разгрузки и планирования, и переносятся в следующий 3-х недельний спринт.
+* Мы отказваемся от такого понятия как переработки. У нас нет гонок на выживание. Разработчики на постоянной основе получают новые порции задач и получают необходимое время на их выполнение, а также время на разгрузку своих мозгов. Менеджерские затраты на управление при этом минимальны.
+
+Это и есть описание методологии разработки по `Agile Lite`. Естественно вы можете подкорректировать эти описания под свои нужды. Но есть один отличительный признак Agil Lite, который я хотел бы отметить - это то, что мы явно говорим: "Эй, команды работающие по методологии agile тоже могут выгорать также как и команды работающие по другим методологиям, возможно нам надо добавить еще некоторых правил, чтобы уменьшить вероятность выгорания нашего движка, которым явялется наша команда".
+
+Давайте прекратим перегревать наши движки! У нас итак много работы, которую мы должны сделать. По сути бездонная яма работы. Но жизнь коротка, чтобы тратить ее всю на работу, стресс и выгорание.
+
+----
+
+If you would like to see more workplaces implement a system such as this, please star this repo on github and share on social media to increase visibility.
+Dave Sullivan 2019 dave.brian.sullivan@gmail.com
+
+----
+
+Источник: [Agile_Lite_for_Developers](https://github.com/davebs/AgileLite/blob/master/agile_lite_for_developers.md)
+
+![01](01.jpg)
+