Есть несколько вопросов по тому, как agile выглядит на практике (давайте для определенности возьмем scrum). Пока разбираюсь теоретически, по книжкам, хотелось бы спросить тех, у кого есть практический опыт - как решаются некоторые (может быть кажущиеся) проблемы и противоречия.
1). Что имеется в виду под кроссфункциональностью команды. "By the book" требуется, чтобы каждый работник мог взять и выполнить любую задачу. Но реально непонятно как это. Вот есть в реальной команде, допустим, фронтендер, бэкендер, специалист по базам и админ. Предлагается дать админу джаваскрипт код, а фронту потюнить базу? Так все развалится через неделю. Встречал уточнение, что на самом деле нужно добиваться того, чтобы команда в целом могла выполнить любую задачу по проекту, а специалисты внутри пусть будут узкими. Но это, понятно, накладывает серьезные ограничения на выбор задач из бэклога и на использование статистики.
2). Planning poker. Ситуация - два участника называют (и аргументируют) кардинально разные сроки. В "традиционном" менеджменте это решается так: Синьор Вася говорит "За 6 дней сделаем", джуниор Петя говорит "Хватит и 2 дней". Петя аргументирует, после чего Вася либо прислушивается в нему и корректирует оценку, либо говорит "Я старше[UPD: имеется в виду по должности], делаем как я сказал". На этом обсуждение завершается с некоторым результатом. В planning poker предлагается обсуждать, пока они не договорятся до какой-то совместной оценки. А если они за два часа не договорятся, что делать? Говорить, что задача "непонятная" и не брать на спринт? Тогда получается, что джуниор Петя заблокировал важную фичу. Во всех методиках переговоров есть план на случай, если компромисса не удастся достичь. Какой он в planning poker?
3). Нагрузочное тестирование. Это такой особенный вид тестирования, который может занимать, например, несколько суток и по его итогам может понадобиться значительная переделка архитектуры. При этом, когда разработчики реализовывают конкретные user stories они о роизводительности не думают, а в целом к системе требования по производительности должны предъявляться. Где место нагрузочному тестированию в scrum?
4). Парное программирование. Кто-нибудь вообще видел, чтобы такое применялось регулярно, а не в формате "джун смотрит через плечо синьора"? Если видели - скажите название компании, очень интересно.
5). Кто (какой человек) отвечает за факапы/срывы сроков и тэдэ. Ответ "вся команда" (= никто) вряд ли понравится заказчику из реального мира.
6) Кто принимает решения об увольнении и найме сотрудников?
Понятно, что на каждый из этих вопросов можно ответить "Примите душой Agile Manifesto и найдите ответы в себе", однако, хотелось бы узнать как это решается на практике. Понимаю, что тема несколько холиварная, но хотелось бы избежать ответов типа "Ты нифига не врубаешься в эджайл, иди в дворники" или "Все ответы есть в гугле/такой-то книжке". Вопросы понятно, заданы не ради троллинга, а ради знаний.
1. Ну вы же самите пишете: "Development Teams are cross-functional, with all of the skills as a team necessary to create a Product Increment."
Development Team, as a team и т.д.
Это значит то, что команду нужно грамотно подбирать под проект. Команда должна быть кросс-функциональной, а не каждый в ней. Если вы набрали 5 матерых бэкендщиков, то не нужно их потом винить, что они с фронтендом облажались.
2. Во-первых, если разработчики будут спорить 2 часа, или один другого "унижать", то у вас хватает проблем кроме скрам процессов.
3. Та же ситуация, что и с рефакторингом. Как вы объясните, что часть проекта надо переписать? Т.е. вы все время какое-то гуано ваяли, а теперь осознали? Если уж работаете по скраму, то и product owner должен хорошо в этом разбираться. В разработке всегда хватает задач, которые не дают видимого функционала, которого так хотят видеть на демо, но такие задачи необходимо включать в спринты. + если у вас подразумеваются высокие нагрузки, то необходимо заранее на планировании обсуждать это и вносить эту работу либо в стори, либо создавать новую в бэклоге на будущее.
4. На практике это скорее мозговой штурм. Вы просто садтесь с коллегой и думаете/пишете.
5. По факту отвечает вся команда. Если срыв из-за того, что неправильную эстимацию выставили, так все вместе играли в Planning poker или его альтернативу. Если кто-то пилил задачу весь спринт, а потом сказал перед демо, что не успел, то виноват он и скрам мастер, который не проследил , возможно, повесил слишком большой таск. Если заказчик попросил слишком большую задачу в спринт, а ему никто на это не возразил - ссзб, снова виноваты.
6. Проджет/деливери менеджер.
1. Команда должна быть кросс-функциональной, а не каждый в ней.
То есть все-таки в команде есть фронтендер, бэкендер, админ, дэйта сайентист, деплой инженер и т.д. ... по необходимости проекта. Тогда более-менее логично, что таска на фронтенд прилетит скорее фронтендеру, верно? А с кем он тогда играет в planning poker? Со всеми непричастными?
2. Во-первых, если разработчики будут спорить 2 часа, или один другого "унижать", то у вас хватает проблем кроме скрам процессов.
Ну, во-первых непонятно, откуда вы взяли "унижать". Во-вторых при "традиционном" менеджменте проблемы нет. Собственно в посте написано, как это решается. Судя по тому, что в скраме эту проблему с разной степенью элегантностью пытаются проигнорировать, решения нет, верно?
5. По факту отвечает вся команда.
Вы такое когда-нибудь видели?
Ситуация: профакаплен некий майлстоун (снова) - сорваны планы поставки, качество плохое. Заказчик хочет пообщаться с ответственным. Ответственная - вся команда. На сакраментальный вопрос "Почему? Кто виноват?" даются ответы:
Вася: Потому что Петя затупил и сорвал таску. Виноваты Петя и скрам-мастер
Петя: Таска неожиданно оказалась слишком большой, неправильно оценились, виноваты все
Леша: Виноваты тестировщики со стороны заказчика - это не баги, а фичи
Маша: Я не знаю, кто виноват, а здесь первую неделю
Ермолай: Мне пофиг, кто виноват, я увольняюсь, мне осталось работать четыре дня
Как вы думаете, какова будет реакция заказчика?
6. Проджет/деливери менеджер.
В скраме есть проджект менеджер и деливери менеджер? А какие у них функции?
Тогда более-менее логично, что таска на фронтенд прилетит скорее фронтендеру, верно? А с кем он тогда играет в planning poker?
верно. для небольших команд, где каждый занимается своей областью, планинг покер не работает. Как правило, оценка скорее нужна для того, чтобы заказчик, допустим, в лице продакт оунера, мог планировать какие-либо действия. Допустим, очередность выпуска фич, или же включения оных в релиз. Когда, например, фронтендер всего один, то его задача дать свою оценку, и обосновать ее.
Ну, во-первых непонятно, откуда вы взяли "унижать". Во-вторых при "традиционном" менеджменте проблемы нет. Собственно в посте написано, как это решается. Судя по тому, что в скраме эту проблему с разной степенью элегантностью пытаются проигнорировать, решения нет, верно?
ну, у вас был написан пример с "Я старше, делаем как я сказал". Если бы я в своей команде услышал от кого-то нечто подобное, потом бы состоялся не самый приятный диалог с таким разработчиком.
Суть оценки через планнинг покер - не упустить часть работы. Я никогда не сталкивался на практике, что кто-то оценивает задачу в 3, а другой в 13. Обычно разбежка в пределе одного шага. И в любом случае, несопадение мнений лишь призывает к обсуждению. Если никак не удается сойтись на одной цифре, обычно берут более высокую.
Заказчик хочет пообщаться с ответственным.
ни в коем случае. если приведенный вами диалог произойдет в присутствии заказчика, велик шанс, что пойдут гулять все вместе с Ермолаем.
давайте так. в скраме есть понятие velocity. это отношение выполненных задач к запланированным. velocity > 70% - это хорошо. Если Петя зафакапил одну таску из 5-6 запланированных - это в принципе, обычная ситуация, и тут либо нужно общаться с заказчиком о том, что нужно снижать кол-во запланированных сторипоинтов на спринт, потому что бла-бла-бла(много времени на митинги/планирование/etc), либо, если он этого не понимает, искусственно завышать оценку задачи, закладывая в нее риски. В свободное время всегда можно дописать тестов или отрефакторить что-либо.
Если же таска оказалась реально слишком большой, то виноваты все, и в частности Петя со скрам-мастером. Не потратили время на планирование, не разбили на мелкие подзадачи. Скрам мастер бакланил весь спринт и не видел, что у Пети проблемы? или Петя ссал всем в уши, что все хорошо, а на деле нет? Нужно разбираться, для этого есть ретроспектива.
Леша - баклан. У стори есть Acceptance Criteria, которых придерживаются и qa, и разработчики. Поэтому, либо кто-то невнимательно их читал, либо виноваты те, кто эту стори писали(как правило, продакт оунер), а потом виноваты те, кто оценивал стори без внятных критериев.
В скраме есть проджект менеджер и деливери менеджер? А какие у них функции?
в скраме таких ролей нет. в проджект менеджменте есть. если у вас проект не уровня "онлайн магазин за 2 месяца", а что-то серьезное, или аутсорс, прости господи, то без таких людей не обойтись. кто-то же должен контролировать весть проект/продукт, людей, оборудование, риски, релизы и т.д. мы же sales отдел тоже в скрам не включаем, а они есть :)
catwatcher скрам возможен только в сплоченной команде. Если все друг на друга тянут и откровенно работать просто не хотят, нужно менять культуру общения. В команде все должны быть "скованы одной цепью" (в хорошем смысле) все работают на результат, нет индивидуумов, есть команда. В хорошо настроенной команде на ретро ребята сами будут рассказывать, что у них было не так, потому что никто не будет фокусировать внимания на их личности, а только на самой проблеме.
Вы смешали в одну кучу бизнес и разработку программного обеспечения. Отсюда и непонимание.
1. "фронтендер, бэкендер, специалист по базам и админ" Админ точно только косвенно входит в разработку продукта. "специалист по базам" - очень узкая специализация, нужен ли такой для проекта, сможете ли его в полном обьеме загрузить работой на срок проекта? Поэтому Agile и предлагает использовать другой тип работников, более широкого профиля. Хотя при Agile возможно чтобы равномерно были загружены и фронтендер и бэкендер.
2. Ваш пример это скорее психологическая проблема в комманде. Синьор - с заниженной самооценкой, компенсирующий ее на подчиненных. Agile - подразумевает, как вы написали "чтобы каждый работник мог взять и выполнить любую задачу", значит в команде не будет ни Синьор, ни Джуниор.
3. В требованиях к User Story и нужно писать требования по нагрузке и архитектура должна строиться от этой нагрузки.
4. Опять же подразумевается работа программистов одного уровня.
5. Владельца бизнеса никто не отменял. Agile подразумевает "Ретроспектив" и на будущие спринты должны быть учтены срывы текущего, но если команда срывает постоянно, значит нужно смотреть извне команды, что за проблемы внутри. А перед заказчиком отвечает владелец бизнеса и никак иначе.
6. Владельца бизнеса
1. Админ точно только косвенно входит в разработку продукта. "специалист по базам" - очень узкая специализация, нужен ли такой для проекта, сможете ли его в полном обьеме загрузить работой на срок проекта?
Ну, для некоторых проектов нужен специалист по БД. Для некоторых проектов нужен такой специалист после достижения некоторого ( заранее неизвестного ) масштаба. Такие проекты просто нельзя делать по скраму? Или нужно где-то искать универсального солдата со знанием ангуляра и настройки оракла?
2. Ваш пример это скорее психологическая проблема в комманде. Синьор - с заниженной самооценкой, компенсирующий ее на подчиненных.
Нееет, он подразумевает, что есть человек, который берет на себя ответственность за решение, если есть разные мнения. Как это решается в planning poker?
3. В требованиях к User Story и нужно писать требования по нагрузке и архитектура должна строиться от этой нагрузки.
Юзер стори - "Регистрация должна проходить за 1 секунду". Разработчик демонстрирует у себя на машине как регистрация проходит за полсекунды. Считаем, что все нормально с производительностью?
4. Опять же подразумевается работа программистов одного уровня.
Так вы сами такое видели? А вы работаете в парах? Почему нет?
5-6. Владельца бизнеса
То есть Иван Ильич лично с Гавайских островов решает уволить ли лентяя Васю? Отдельный вопрос - а если владелец бизнеса, скажем, государство или 25 инвестиционных фондов.
1. У админа свой обьем задач, который относится и к бизнесу (поддержка офиса) и к проекту (бекапы, настройка базы). Никто по agile не запрещает привлекать сторонних исполнителей под конкретную задачу. Привлекли, он оценил архитектуру, дал рекомендации, а дальше сами.
2. Фраза "Я старше," не указывает на ответственность. )) Тут важна не ответственность, а соблюдение правил. Если джуниор правильно обосновал почему он так решил, то при повторной оценке (бросание карт), синьер просто должен учесть обоснования и указать время с их учетом, так же он должен обьяснить джуниору почему он считает иначе, и тот тоже сделает свои выводы.
3. Вы указали очень узкие требования, они могут быть шире. "1. Регистрация за секунду, при одновременном подключении 1 тыс. пользователей." и т.п.
4. Это постоянно случается и при ватерфоле, и при других подходах. "У меня тут проблема, не знаю как лучше вот такую задачку решить, подойти, помоги...". А вот надобности в постоянном extreme programming я не встречал.
5. Вымышленные крайности. )) Государство не может вести бизнес, так как это неодушевленная сущность. У бизнеса всегда есть ответственное лицо - управляющий. Даже у бизнесов, которыми владеет государство. Вот он и ответственный. Если клиент заключает договор на разработку, он же не указывает в договоре, что вся ответственность по данному договору лежит на Джуниоре Пете, а указывает фирму, и подписывает этот договор уполномеченное лицо (управляющий или доверенные им люди)
1. Никто по agile не запрещает привлекать сторонних исполнителей под конкретную задачу.
То есть вот когда про скрам пишут "Development Teams are cross-functional, with all of the skills as a team necessary to create a Product Increment." ( https://en.wikipedia.org/wiki/Scrum_(software_deve... ) - это скорее невыполнимо, так? При "традиционном" менеджменте, если 5 раз в неделю нужен разработчик БД, его скорее возьмут в штат. В эджайл это типа запрещено, так?
2. Фраза "Я старше," не указывает на ответственность.
Окей, я проапдейтил)
синьер просто должен учесть обоснования
Синьор обозначил, что не согласен. Джуниор не согласен с его аргументами. Прошло два часа обсуждения - наши действия? Идея "рано или поздно они договорятся" мне кажется идеалистичной, скорее "Рано или поздно они задолбаются и разойдутся злыми"
5. У бизнеса всегда есть ответственное лицо - управляющий.
Ну, да. Вот, например, Сбербанк ( отвлекаясь от споров, хороший там эджайл или плохой ). Им владеет Центробанк России. Предположим, договор важный, его подписывала непосредственно Набиуллина ( или Греф или кто там ... ). Лично Эльвира Сахипзадовна увольняет программистов?
catwatcher: 1. Повторюсь. Если вы можете загрузить работой разработчика БД на весь срок проекта, то берите. Agile не накладывает таких ограничений. Но если он сможет делать и другие задачи, то еще лучше.
2. "Прошло два часа обсуждения - наши действия" - Вы у верены, что у вас Синьор + Джиниор, а не 2 Джуниора? Но возвращаясь к вопросу. Конфликт/недопонимание между сотрудниками это бизнес проблема, а не Agile. Тут решение за владельцем бизнеса.
5. Экономическое образование вам помогло бы понять. А попростому, есть делегирование полномочий. Высший руководитель делегирует часть своих полномичий другим сотрудникам, для примера "Директор по кадрам" получает права на увольнение программистов. Команда решила, что Петя лишний и попросила Директора по кадрам уволить его.
catwatcher:
1. Что мешает разработчику БД заниматься чем-то другим в свободное время? Если он загружен все 5 дней своими задачами, значит задачи и команда идеально сбалансированы, что бывает редко.
2. Синьор не согласен и аргументирует это. Джун слушает. На то он и джун.
5. Типичная иерархия крупной компании включает гораздо более одного управляющего. В моей организации крупные договора подписывает ген.дир, отвечают за исполнение в зависимости от области его замы или руководители подразделений. В крупных договорах достаточно бюрократии, что бы они там не один раз оставили свой росчерк. Мелкие могут заключать они же без автографа ген дира, они же полностью и несут ответственность. Если будет срыв крупного договора, ответит в первую очередь непосредственно ген.дир и по нисходящей до последнего виноватого. Виноватый не смог выполнить свои обязанности, а все кто выше не уследили, то есть тоже не смогли выполнить свои обязанности.
Предвидя вопрос, если все работали на убой и качественно, но все равно договор сорвался, то виноваты те, кто его заключил, ибо перед тем как подписывать что-то, должны были оценить все факторы.
catwatcher:
1. А чем он может помочь команде? Тем и будет заниматься
2. Если два равнозначных члена команды спорят до упора, то или придут к консенсусу или один из них набьет морду другому) Второй вариант мне не встречался)
>Скрам
Нет, не скрам, но это типичная структура крупной компании, о которой вы тут упомянули. И независимо от скрамности, перед заказчиками отвечают именно управленцы. В этом их работа и заключается. Но стоит отличать внутреннюю и внешнюю ответственность - заказчикам плевать, что Петя не успел к дедлайну, плевать, что причиной послужил тот спор. Им важен результат. А scrum это методика организации рабочего процесса, которая возможно поможет достичь лучшего результата.
Если два равнозначных члена команды спорят до упора, то или придут к консенсусу или один из них набьет морду другому) Второй вариант мне не встречался)
Мне тоже второй вариант кажется крайне маловероятным, а вероятность первого - далеко не 100 процентов. Если два человека зарубаются без лимита, то скорее всего победит тот, кто выносливее, кто говорит громче и увереннее или является более статусным де-факто. Идея будто бы N умных человек могут договориться по вопросам сроков произвольной задачи в немодерируемом споре она, ну, утопическая. Посмотрите на почти любой спор на хабре - часто там приходят к единому мнению?
Нет, не скрам, но это типичная структура крупной компании
Да, это понятно, но в "традиционном" менеджменте есть руководитель проекта, который несет ответственность за проект и имеет полномочия ( финансовые, кадровые и организационные ). По скраму тут проскакивала идея, якобы все за все отвечает владелец бизнеса, про структуру был разговор в этом контексте.
catwatcher: Спор возникает только в том случае, когда личностные убеждения одного человека противоречат личностным убеждениям другого. Приводя здравые аргументы всегда можно расширить опыт оппонента и убрать убеждения. Но стишок "Как то утром очень рано повстречались два барана..." конечно не на пустом месте родился.
4). Парное программирование. Кто-нибудь вообще видел
Я участвовал, нас было трое таких "экстремальных" и мы периодически садились по двое за один комп и разруливали какие-то сложные задачи. Не все время, конечно, но пару раз в неделю по 2-3 часа в день бывало. И это очень заметно ускоряло некоторые процессы, особенно в таких местах, где нужно было вносить изменения затрагивающие очень большие куски проекта.
Типа "вот этот кусок ORM очень медленный и жрет память, я думаю надо его выбросить, вон ту таблицу разделить, а вот здесь сделать денормализацию, а вон тот кусок вообще выбросить, но это заденет кроссдоменный логин который ты сейчас пилишь, так что давай вместе".
Тут стоит отметить, что сам проект был тем еще цирком - мы за несколько месяцев сильно переписали код, который до того разрабатывался года полтора, при этом к каждой пятнице нужен был "показательный" билд, который мало того чтоб просто работал, но еще и какие-то новые фичи имел. На других проектах не пригождалось потому что архитектура была стабильной и заранее продуманной или не так просто было найти напарника с которым процесс ускорялся бы а не замедлялся.
На практике agile выглядит так: после планирования разрабы вежливо выпроваживают бизнес за дверь и начинают писать код. Он им нужен исключительно чтобы бизнес не подкидывал новые гениальные сверхсрочные хотелки, а так-то любой девелопер за исключением совсем уж новичков может организовать себя.
Бизнес думает, что agile ему нужен для контроля, но на самом деле он нужен для -понимания, что нельзя получить все сразу и уже вчера- расстановки приоритетов, котов пасти все равно невозможно.
Бизнес всегда находится в приоритете, так как от него все зависит. Если заказчик решил, что эта хотелка ему важнее, создается новая задача, устанавливается ей приоритет и стоимость ее выполнения.
Главное чтобы были оплачены уже выполненные задачи с учетом стоимости потраченного на них времени, и поэтому тут важен правильный учет выполненых задач и договор учитывающий такие изменения.
Петр: Тут зависимость в обе стороны, дело само собой не сделается. Так что если команда разработки сказала, что добавить новую фичу, которая принесёт еще некоторое количество денег бизнесу, пока нельзя, то бизнесу приходится смириться.
Владимир Олохтонов: "пока нельзя" должно иметь обоснованное время, на которое будет отложен функционал, так как если клиент откажется от проекта, то команде продолжать разрабатывать смысла уже не будет. ))
Agile, очень похож на коммунизм. Имхо, обе идеи крайне утопичны, не учитывают эволюционную психологию, этологию и кучу других аспектов. Управление разработкой ПО включает в себя дикое количество переменных, которые не реально учесть. А заказчики зачастую не понимают во что ввязываются. Будем наблюдатьс куда же это все приведет.
Как говорят умные люди, agile - узаконенный беспорядок. Примерно так оно и выглядит к сожалению (в наших реалиях, ибо все его неправильно и бездумно делают), с опытом и годами вменяемые люди это прекрасно понимают. Agile, это когда "Хуяк-хуяк, и в продакшн", нормальные методологии они другие:)
JSmitty: Чувак, дело не в задаче, дело в проекте. Каждая конкретная задача не стоит ничего, важен проект. И вот agile для получения результата не гарантирует вообще ничего. Это удобно, но это просто модное слово, которое описывает, что абсолютная гибкость это хорошо. Но вот нет, важно быть гибким и готовым к изменениям. но еще более важен рабочий результат. То как ведутся проекты по любому agile у нас - фигня какая-то слабы безвольных людей, которые просто безвольно и безумно следуют желаниям окружаюищих - так дела не делаются.
JSmitty: По сути - agile отменяет нормальное планирование, ибо либо ты гибок, либо планируешь. совмещать это тяжко на больших проектах. вот был у тебя проект на 8 месяцев трех разработчиков и через три недели после начала все несколько меняется. а потом опять, а потом опять, и расходы ты свои посчитал и то что надо еще сделать в голове видишь, но вот уже не гарантируешь ничего, не то что резальтат будет через 6 месяцев, а уж тем более что оно работать будет.
Да заказчик знает что сроки сдвигаются, но вот он не знает что он получит и что это что-то будет работать, а значит он не знает ничего что нужно.
ТЗ и agile??? Они вместе хорошо живут, но вот agile не нужен ТЗ, это из другого мира.
Плывучий план - не план а болото, да и не план важное, а результат.
" Устоявшаяся команда с известной производительностью нормально оценивается в сроках, и вполне предсказуема с т.зр. менеджмента" - это вообще не про agile, извините, разговор закончен:)
1) На практике это означает a) Людей в команду желательно подбирать более универсальных, владеющих разными технологиями и без амбиций типа "яжпрограммист, я не буду тестить". b) Если выбирать не приходится и вам достались узкие специалисты и при этом команда постоянная, то занимайтесь ее развитием, расширяя их компетенции. Это долго, но стоит того. с) Если специалисты узкие и даны на короткое время, тогда обходитесь без кроссфункциональности. Это не догма, как и все остальное в скраме.
2) В planing poker не могут участвовать 2 человека. Участвует вся команда. Кроме того на практике джуниор обычно не спорит с сеньором, а прислушивается к нему. По времени планирование спринта - ограничено. (мах 8 часов для больших и сложных спринтов) Скрам-мастер должен следить за тем, чтобы обсуждение шло конструктивно и не буксовало. Если кто-то уперся рогом в землю, не может убедить других и не слушает их аргументы - это не командное поведение. А команда - это основа agile. С ним нужно проводить воспитательную работу. Если это регулярно - возникает вопрос, действительно ли его место в этой команде.
3) Все необходимые виды тестирования должны проходить в рамках спринта. Желательно использовать Continuous Integration и тесты, включая нагрузочные гонять регулярно. Разработчики, реализуя user stories должны думать о производительности, как и о многом другом. Разумеется, требования к производительности должны быть им озвучены.
4) Это не скрам, а одна из практик экстремального программирования. Применял в компании SiberLogic. В случаях, когда было критически важно, несмотря на затраты, быстро и качественно запилить задачу за часы.
5) Коммуникацию с заказчиком в скраме обычно осуществляет продакт. Он же и отвечает перед ним. Команда отвечает перед продактом. На практике в некоторых компаниях перед заказчиком отвечает ПМ, который находится снаружи скрам-команды.
6) За найм и увольнение отвечают те же люди, что и без скрама. Это может быть директор или HR. Иногда этим занимаются ПМы. Однако, скрам-команда может "вытолкнуть" человека, если он в нее не вписывается. Если разговоры по душам не помогают, то человека перемещают в другую команду или в другую компанию :)
По книжкам скрам не внедряется. Если будут еще вопросы, пишите в личку.
Посмотрите на то, как строены современные таск трекеры, например WEEEK. В структуре и функциях как раз заложена agile - методология управления проектами. Вот так и выглядит)
Простой
