«псевдо-аджайл» только поначалу выглядит круто

Содержание:

Плюсы и минусы Agile

Постигая Agile, важно знать как о положительных, так и об отрицательных сторонах этой методологии. Начнем с плюсов

В первую очередь стоит отметить, что Agile-управление очень гибкое. Если, например, традиционная методология указывает на конкретные этапы работы, то Эджайл легко подстраивается под потребителя конечного продукта и требования заказчика.

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

Кроме того, Agile быстро запускается, легко реагирует на изменения, позволяет команде разработчиков и клиентов поддерживать постоянную связь в реальном времени. Преимущества очевидны, но давайте поговорим и о минусах.

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

Второй недостаток заключается в необходимости адаптировать под изменяющиеся условия проекта проектную документацию. При отсутствии надлежащего информирования команды об изменениях или дополнительных функциях документы с функциональными требованиями или архитектурой могут оказаться неактуальными на текущий момент времени.

Третьим существенным минусом Аджайл можно назвать необходимость в частых встречах

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

Сюда же можно отнести такие вещи как необходимость в постоянном присутствии клиента, невозможность выстраивать долгосрочные планы и потребность в мотивированных и высококвалифицированных специалистах. Кстати, последнее в огромной степени касается и внедрения Agile-управления в деятельность организации. И, постигая Agile, с темой ее внедрения тоже нужно познакомиться.

Роль техдира в Agile — игра в Тетрис

Вы обсудили с Заказчиком и договорились выпустить в ближайшем релизе важные для продукта фичи, которые так давно и с нетерпением ждут Пользователи. Вы на крыльях несетесь на PlanningPoker, начинается оценка и бац…
— Давайте не лезь в этот модуль. Код недокументирован, все начнет глючить и сыпаться, особенно биллинг.
— До нас работала команда дураков, они учились программировать на этом проекте. Если сюда лезть, в команде упадет мотивация…
— Как это работает… Это надо в код смотреть. Люди, писавшие, уже ушли, документации нет. Месяц минимум.
— Мы залили данные, и все стало тормозить. Надо спринт посвятить исследованию причин. (и так несколько спринтов подряд)
Вы понимаете, что происходит что-то странное, что проект «заболел», что можно было наверно этого избежать, если знать заранее…
Постараемся понять, кому «бить морду» сейчас и кого отмутузить профилактически когда к нам придет следующий проект — чтобы избежать подобного коллапса.

Внедрение Agile

Примеров внедрения Эджайл в работу компаний есть достаточно много. И практически все они говорят, что оно требует целого комплекса важных мероприятий.

Для начала выбирается конкретный метод, что зависит от условий проекта. Затем определяются задачи и цели, основной дедлайн и сроки спринтов, численность команды и другие составляющие работы над проектом

Важно подобрать метод, отвечающий максимальному количеству требований

Как мы и сказали, для внедрения Agile необходима команда профессионалов. Все ее члены должны знать базовые идеи и принципы методологии и уметь их применять. Если в компании нет таких людей, сотрудников нужно обучить. Руководство компании, решившей перейти к использованию Аджайл, также должно четко понимать, готова ли организация к изменениям, можно ли применять систему к своим проектам и т.д. Чаще всего, чтобы ответить на эти вопросы, приходится обращаться к специалистам по Agile.

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

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

Agile в ИТ-компаниях. Как увидеть лес за деревьями

В этой статье хотелось немного поговорить о том, как используется Agile в ИТ-компаниях. И начнем сразу с главного: для большинства таких компаний Agile в виде Scrum, Kanban, Lean или XP – это не просто эфемерная атмосфера всеобщей гибкости, а вполне себе конкретный производственный процесс по созданию и поставке ПО.

Если задача чисто продуктовая, то команды, которые продукт создают, как правило, не до конца знают, что нужно рынку. Обычно у них есть некое видение и набор гипотез, посредством которых и проверяется видение. И здесь Scrum подходит лучше всего, так как проверка гипотез требует постоянной связи с конечными пользователями и постоянных улучшений на базе полученной обратной связи.

Продуктовый подход с использованием Scrum может использоваться и в сервисных ИТ-компаниях, когда они делают продукт для заказчика или вместе с ним по вышеописанной логике. Только такие продуктовые истории для сервисных компаний — это проект и внутренние метрики у них отличаются от метрик продуктовых компаний.

Гибкий рой: как спроектировать разделяемую работу для команд разработки ПО

Из песочницы

Успешные аджайл-команды склонны ограничивать незавершённую работу (НЗП, незавершённое производство). Предпочитают ли они Скрам, Канбан-метод, или какую-либо другую аджайл-методологию, эти команды особенно выделяют над всем остальным быструю разработку полезной функциональности.

Они больше беспокоятся о пустой работе (подолгу незавершаемые истории), нежели о незанятых руках (есть ли свободная минута у людей, не связанная с их запланированной работой). Соответственно, они идентифицируют высоко-приоритетные истории и «роятся» вокруг них, так, чтобы вся команда, или многие из них, фокусировались на одной и той же истории до самого её завершения. Вместо того, чтобы поделить беклог на несколько отдельных частей, которую каждый член команды сможет брать в частном порядке, высокопроизводительные аджайл-команды предпочитают работать в семейном стиле — они делают всё возможное, чтобы завершить наиболее важные элементы беклога.

Преимущества ограничения НЗП хорошо известны, включая большую сфокусированность, более быстрое выполнение, низкое время цикла и меньшее количество потерь. Эти преимущества делают практику «роения» широко признанной. Тем не менее, хотя многие авторы отмечают необходимость организовывать работу таким образом, чтобы она позволяла «роиться», трудно найти конкретные указания о том, как это сделать. Первый шаг — это понимание того, как организовать работу таким образом, чтобы она была разделяемой между членами команды. К счастью, есть целый ряд конкретных подходов, которые вы можете использовать, чтобы сделать работу более разделяемой.

Культурные факторы успеха трансформации

1. Наиболее очевидным фактором успеха для организации является понимание природы Agile. Agile – это не Scrum, Kanban или SAFe. Agile – это набор ценностей, культура сотрудничества, адаптивности, вовлеченности и принятия (и использования) неопределенности. Часто это буквально тектонический сдвиг в том, как организация привыкла работать.

2. Для культурных изменений необходимы вовлеченность и приверженность (commitment) всей организации. Я действительно имею в виду всю организацию, включая как вертикальную иерархию (от исполнителей до высшего руководства), так и горизонтальное распределение различных служб (от ИТ до финансистов и HR).

3. Если достигнута вовлеченность всей организации, компания может начать трансформацию обслуживающих процессов (прим. ред. — кадры, финансы, административно-хозяйственное обеспечение и прочие). Гибкость этих процессов определяет разницу между локальной гибкостью в рамках одного подразделения и гибкостью всей организации в целом (Business Agility).

4. Культурная трансформация также означает понимание цели Agile. Речь идет не о том, чтобы делать больше с меньшими затратами или работать быстрее. Организации должны быть в состоянии признать, принять и использовать неопределенность как конкурентное преимущество для себя и своих клиентов.

5. Организации должны выйти из зоны комфорта, а не просто начать применять те гибкие практики, которые легче всего встраиваются в их текущие процессы.

6. Организации, способные быстро ошибаться (fail fast) и тут же на этом учиться, как правило, проводят более успешные и устойчивые изменения.

7. Основа основ – организации, которые приводят свои КПЭ (KPI) в соответствие с ценностями и принципами Agile (прим. ред — к примеру, система бонусирования не должна порождать конфликты внутри команды), сразу же настраивают себя на успех.

8. Наконец, организациям необходимо выбрать правильные причины для начала трансформации. Там, где много дисфункций в командах, команды перегружены и демотивированы, стремление к переходу на Agile не вызовет большого воодушевления. Agile не заработает сам по себе. В этом случае организации необходимо сосредоточиться на решении этих проблем, не пытаясь воспринимать Agile как панацею.

Пример внедрения Agile

Рассмотрим простой пример, который я привожу на своем корпоративном тренинге по Agile, когда рассматриваем с руководителями вопрос формирования Agile команд:

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

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

Логично предположить, что Agile внедряют довольно крупные и известные консалтинговые компании, но это вовсе не означает, что они обладают опытом внедрения данной методологии.

Прямой зависимости между Agile и прибылью компании нет, пока нет, но скоро будет!

Agile методологию интересно применять для небольших команд, для того чтобы найти какую-либо интересную идею или интересное решение, которое даст вашей компании «эффект прорыва» с минимальными затратами, именно для этого Agile и предназначен.

Хочешь заработать миллион?

Recovery Mode

Всем известна фраза Рона Хаббарда «…хочешь заработать миллион — создай свою религию», которую он выдал в 1950 году. Тогда он создал ещё одну деструктивную секту, можно это было в 60-х в США — которая до сих пор пытается утвердиться в мире, как религия.

Хотя, сорри, друзья.

Во-первых, это было сказано, а точнее написано в 1938 году.

В-вторых, это сделал неподражаемый Джордж Оруэлл, который так мастерски написал антиутопию «1984», что только сейчас до его благодарных читателей в Великобритании и США стало доходить, что писал он о них. Да и вообще Джордж был знатным шутником, учитывая, где он работал и что он знал о широких народных массах.

В-третьих, впервые это фраза появилась в его письме в виде строчки “there might be a lot of cash in starting a religion”: я бы перевёл, «как можно можно поднять славно деньжат, если застартапить религию».

Долгое время этой простым и немудрённым рецептом пользовались только сайентологи. Но потом к ним подтянулись башковитые ребята из IT — c IQ у них всех было всё OK, а деньги и уважение лишними не бывают.

Будем считать это исключительно моей личной субъективной гипотезой, но именно так появились Agile, а затем Scrum. Давным-давно в XIV веке Уильям Оккам сформулировал одну чудесную фразу в одной из книг: «Non sunt entia multiplicanda praeter necessitatem». Вот и удивляюсь, как жила разработка до появления Scrum. Наверное, её просто не было. На самом деле «клиентоориентированность» — это финальный этап чудесной эпохи потребления, которая как раз заканчивается — вертись вокруг клиента, как Солнце вокруг плоской Земли, и всё будет путём.

Agile и антикризисное управление

Говорить об успешном внедрение методологии Agile в российских компаниях очень опрометчиво, прошло еще очень мало времени, чтобы оценивать результат и наслаждаться успехом.

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

Вы должны помнить: что вы и только вы, как руководитель несете ответственность за внедрение каких-либо новых подходов и методов своей компании, но с другой стороны:

  • вам нужны новые подходы и новые методы,
  • вам нужно четкое понимание прибыли,
  • четкое понимание новых рынков, на которое нацелена ваша компания.

Так что как инструмент антикризисного управления Agile вполне подойдет для многих российских компаний.

Agile — это не конечное состояние, а образ мышления и жизни

Этот пункт о том, что применение Agile в целом — путь, а не цель. Нельзя «внедрить» Agile и расслабиться. Если вы выбираете этот путь, у вас всегда будет что-то ещё, что можно сделать лучше, какой-то ещё вызов, которому надо ответить, какая-то ещё проблема, которую надо решить, ещё одна высота, которую надо покорить… Это движение бесконечно, потому что нет идеального процесса или продукта, развитие и конкуренция не останавливаются никогда, как никогда не прекращается борьба за выживание в природе.

И если всё удалось: люди в компании понимают и разделяют ценности и принципы Agile, работают согласно им, — тогда менеджменту не придётся «тащить» на себе любые изменения или «пинать» работников, чтобы они начали что-то делать по-другому. Предприятие станет единым организмом, управление которым будет отнимать меньше сил и приносить больше удовольствия.
А там, где больше удовольствия от работы, и результат выше. Это касается не только специалистов, но и менеджмента, причём в ещё большей степени.

На этом наше обзорное знакомство с принципами Agile заканчивается. Какие цели ставятся перед Agile в России и каких реальных результатов достигают компании, переходящие на гибкие методологии, можно узнать, познакомившись с отчётом ежегодного исследования ScrumTrek об использовании Agile в России.

Какие могут быть проблемы

Ай, какой классный Agile, да? Увы, хотя его и можно применять в любой компании (даже если ты — прости, Господи — банк), подходит он далеко не всем. Да ещё и его внедрение может быть крайней болезненным.

Я вижу три проблемы (хотя, вполне может статься, что их больше), из-за которых нельзя советовать переходить на Agile всем подряд:

Но если твоя команда работает над кучей проектов, хорошо знает своё дело и топит за идеальный результат, возможно, Agile — это ваше.

Agile-методология позволяет то, что не позволяет каскадная модель — создавать качественные продукты без подробнейшего плана на все этапы. Всё благодаря итеративности, обратной связи клиентов и сотрудников и самоорганизации команды.

Главное, помни, что Agile – это методология и философия. Чтобы применять всё это для управления проектами, нужно собрать свою методику или выбрать одну из существующих — о них я расскажу в следующих статьях.

Разновидность методологий гибкой разработки

Agile Modeling (AM)

Agile Modeling — набор ценностей, принципов и практик для моделирования программного обеспечения.

AM используют как составляющую полноценной методики разработки ПО — например, экстремального программирования или Rapid Application Development.

Принципы Agile Modeling таковы:

  • эффективное взаимодействие между проектными стейкхолдерами
  • стремление разработать наиболее простое из возможных решений, которое подойдет всем требованиям
  • постоянное получение обратной связи
  • смелость принимать и отвечать за решения
  • понимание, что вы не знаете абсолютно всё.

Agile Unified Process (AUP)

AUP — упрощённая версия другой методологии разработки ПО — Rational Unified Process (RUP). С 2012 года её заменили на Disciplined Agile Delivery (DAD), но кое-где AUP еще встречается.

Автор методики, Скотт Амблер, выделил следующие ключевые позиции Agile Unified Process:

  • Ваша команда знает, что делает;
  • Простота превыше всего.
  • Соответствие принципам гибкой методологии разработки.
  • Сфокусированность на ценных для проекта активностях.
  • Независимость в выборе инструментов.
  • Индивидуальная настройка AUP под нужды конкретного проекта.

Agile Data Method (ADM)

ADM — набор итеративных методик гибкой разработки программного обеспечения, которые делают упор на формирование требования и решений по проекту через сотрудничество отдельных команд. Как и AUP, это не самоценная методика.

Суть Agile Data Method определяется шестью положениями:

  1. Данные — основа создания любого приложения.
  2. Проблемы с проектом — их можно обнаружить только при чётком понимании цели и концепции проекта.
  3. Рабочие группы — помимо непосредственной команды разработчиков есть enterprise groups, которые поддерживают другие рабочие группы.
  4. Уникальность — нет идеальной методики, под каждый проект нужно комбинировать инструменты с разных методологий.
  5. Работа в команде — совместная работа гораздо эффективнее, чем поодиночке.
  6. «Сладкое пятно» — поиск оптимального решения проблемы («сладкого пятна»), избегая крайностей.

Essential Unified Process (EssUP)

Разработка шведского учёного Ивара Якобсона, созданная для улучшения Rational Unified Process.

EssUP оперирует понятием практики, в которые входят:

  • сценарий использования — описание поведения системы.
  • итерационная разработка — создание рабочих кусков кода короткими циклами в несколько недель.
  • командные практики — направленные на сплочение команды и повышение её эффективности.
  • процессуальные практики — например, «Думай глобально, начинай с малого» или «Вовлекайте стейкхолдеров в бизнес-процессы».

Все практики в том или ином виде встречаются в методологиях RUP, CMMI и гибкой методике разработки.

Getting Real (GR)

Эффективная для стартапов и начинающих команд методология, которая предлагает по максимуму использовать особенности небольших проектов и компаний: мобильность, гибкость, поиск новых решений, отсутствие жёсткой запутанной иерархии и т.д. Джейсон Фрид и Давид Ханссон, основатели компании 37signals (теперь — Basecamp), определили Getting Real как систему для решения реальных задач: максимально простую, понятную и функциональную.

  • возможностей
  • опций и настроек
  • структуры компании
  • встреч
  • обещаний.

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

OpenUP (OUP)

Практики реализуются на основе четырех принципов:

  1. согласование интересов и достижение общего видения во время совместной работы
  2. непрерывное совершенствование через постоянную обратную связь
  3. фокусирование на архитектуре приложения на ранних стадиях для минимизации рисков
  4. максимизация ценности для конечного потребителя.

Основные принципы Agile

Четыре ценности и 12 принципов Agile сформулированы в уже упомянутом Манифесте. При этом ценности были сформулированы в первую очередь, а принципы авторы расписали позднее. Именно ценности являются основой Agile, а их непонимание — источником мифов об Agile.

Ценность 1. Люди и взаимодействие важнее процессов и инструментов

Авторы манифеста сталкивались с тем, что корпоративные методологии и оргструктура часто не соответствовали потребностям организации. С тех пор мало что поменялось — установленные процедуры в крупных корпорациях препятствуют созданию новых продуктов, организационные колодцы мешают эффективной работе проектных команд. 

Авторы утверждают: люди и их взаимодействие должны определять набор процессов и выбирать инструменты . Потребности взаимодействия команд первичны, процессы и инструменты должны им помогать, а не мешать.

Это не значит, что в Agile творится хаос и анархия. Гибкие фреймворки дают высокую степень адаптации, при этом требуют жесткого соблюдения. Команды должны иметь возможность подстраивать под себя процессы, но обязаны им следовать.

Ценность 2. Работающий продукт важнее исчерпывающей документации

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

Большая часть этой документации не несет также и ценности клиенту! Сначала создайте продукт, а потом документируйте его.

Ценность 3. Сотрудничество с заказчиком важнее согласования условий контракта

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

Ценность 4. Готовность к изменениям важнее следования первоначальному плану

Из этой формулировки следует миф о том, что в Agile нет планирования. Это неверно. Гибкие подходы создавались для условий неопределенности и частых изменений. Предварительное планирование, то есть подход, когда мы сначала долго планируем проект, распределяем ресурсы и задачи, не работает.

Конечно, оно несет определенную пользу, но приоритет отдается планированию оперативному. Как правило, горизонт детального планирования задач составляет 2-4 недели. Если все вокруг меняется часто — ваши планы тоже должны.

Мы не будем разбирать все 12 принципов — этого хватит на несколько статей. Я рекомендую прочесть эту часть манифеста самостоятельно. 

Есть еще одна базовая вещь, которую важно знать для понимания Agile — итеративно-инкрементальный подход. Итеративно-инкрементальный подход

Итеративно-инкрементальный подход

Итеративно-инкрементальный подход лежит в основе гибких подходов. Его суть в том, чтобы не разрабатывать весь продукт целиком и поставлять результат разом в конце проекта, как в классических проектах, а действовать постепенно, маленькими партиями.

Итеративный и итеративно-инкрементальный подходы. Автор иллюстрации Jeff Patton

Разрабатывая продукт небольшими итерациями, мы получаем возможность не только раньше поставить ценность клиенту. Что гораздо важнее, мы получаем обратную связь от заказчиков. Ценно ли то, что мы делаем? Туда ли мы идем? Поставленная цель еще актуальна? Ответить на эти вопросы можно, только предоставив пользователю что-то, что он может использовать, потрогать. 

Чтобы добиться этого, мы декомпозируем наш продукт на более-менее независимые ценные элементы. В Scrum список таких элементов называется «бэклог», однако по сути это приоритизированный лист пожеланий относительно функциональности нашего продукта.

Закон Парето гласит, что 20% усилий дают 80% результата. Иногда даже этих 80% нашего бэклога бывает достаточно для нас или нашего заказчика.

Конфликты при внедрении Agile

Сама идеология Agile подразумевает под собой готовность персонала к изменениям и при этом сами изменения ставятся выше чем какие-либо согласования или какие-либо изначально выбранные планы или стратегия. На этом давайте остановимся и определим внутри себя следующую конфликтную ситуацию — это согласование.

Как мы с вами понимаем согласование необходимо для того чтобы внедрить что-либо или скорректировать что-либо в текущих бизнес-процессах компании.

Если мы игнорируем согласование как факт, то нарушаем бизнес-процессы компании, а следовательно это может привести к довольно серьезным последствиям.

Поэтому не стоит слепо верить советам внедрять концепцию Agile «как есть», так как нарушение процессов согласования приведет к тому, что многие бизнес-процессы в вашей компании просто-напросто могут развалиться и вы столкнетесь с множеством конфликтных ситуаций.

Agile сложнее, чем 4 ценности

Во-первых, помимо ценностей, в Agile-манифесте есть также 12 принципов, которые уточняют и дополняют ценности.

Во-вторых, в статье «Что такое Agile-подход и зачем он нужен бизнесу» вы найдете подробное изложение 6 признаков работы по Agile, которые намного более конкретны, чем ценности и даже принципы. Приведу их здесь кратко:

Потребности клиента понятны всем

Важно, что при Agile-подходе на нуждах клиента фокусируется не только бизнес и менеджер продукта, но и вся команда. То есть, каждый из разработчиков понимает: кто клиенты, что им нужно и какие их проблемы решает новый продукт

Это помогает находить более адекватные решения.

Процессы и оргструктуры максимально упрощены. Правила и процессы, по которым работают Agile-команды, должны быть простыми, чтобы люди смогли сфокусироваться на клиентах и на создаваемом продукте.

Работа короткими циклами (итерациями). Продолжительность цикла — порядка недели или месяца, за это время разработчики выдают какой-либо полезный для клиента результат.

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

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

Внутренняя мотивация вместо «кнута и пряника». Agile-методы помогают настроить процессы таким образом, что сотрудники становятся более свободны и счастливы на работе, видят востребованность своего труда клиентами, ценят доверие и предоставленные им возможности для саморазвития. Люди с такой внутренней мотивацией эффективнее справляются с работой, особенно если это сложная творческая работа.

Эти 6 признаков характерны для многих гибких подходов, если они правильно применяются. Рассмотрим теперь чуть подробнее, что это за гибкие подходы.

Agile: ускорение процесса?

Как утверждают сторонники методологии Agile, они, напротив, придерживаются точки зрения, что объем, содержание и проектирование нельзя заморозить до начала разработки. Следовательно, в Agile применяется гибкий рабочий подход, который может принять изменения намного позже в цикле разработки. Вместо того чтобы пытаться разработать «один идеальный проект», Agile следует принципу: выпустить полезные функции, достаточно хорошие для того, чтобы клиенты могли их использовать, а затем продолжать улучшать их на основе их частой обратной связи. Идея заключается в том, чтобы как можно скорее предоставить работоспособное программное обеспечение и получить обратную связь для дальнейшего итеративного развития. Этот способ работы также устраняет необходимость в замораживании требований и предварительном проектировании.

Таким образом, в мире Agile можно отказаться от последовательной работы по этапам разработки программного обеспечения. Команда может работать как самоорганизующаяся группа, которая может итеративно проектирует, разрабатывает, тестирует и выпускает работоспособные функции. Временем управляют с помощью концепции спринтов (широко используемая версия Agile, известная как Scrum) продолжительностью в 15/30 дней. Каждый спринт используется для поставки новой небольшой партии готовых функций ПО. Хотя текущий спринт заморожен, последующие могут быть изменены на основе обратной связи с клиентами.

Что такое быть тимлидом

Интро

К сожалению, большая часть работы тимлида скрыта от команды. И в зависимости от многочисленных факторов, таких как размер команды, выстроенные процессы, наличие других ролей, занимающихся работой с командой — она еще и невероятно размыта. Список твоих обязанностей в разных компаниях будет отличаться. Где-то это просто формальная должность человека, который просто перетаскивает задачи из одного статуса в другой в свободное время от написания кода, в другой — это полноценная роль, где придется отложить в сторону свою любимую IDE и заняться кучей других обязанностей. Кстати, очень часто эту роль совмещают с еще одной ролью, техлида, и далеко не всегда это плохо.

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

Если ты никогда раньше этим не занимался, тебе предстоит свой долгий и тернистый путь с огромным количеством разбросанных граблей, на которые тебе придется наткнуться и без поддержки команды, увы, этот путь преодолеть будет невозможно.

Диаграмма Ганта vs Канбан доска

Перевод

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector