Словарь современного разработчика софта (не на коленке), ПМ-а, ТЛ и т.д.

Аджайл: Agile.

Скрам: Scrum
Методология разработки програмного обеспечения завязанная на частых итерациях и постоянный контакт с заказчиком.


ну разве что task, bug, CRUD, use case, usage scenario.

scrum
Scrum, Product Owner, Product Backlog, Scrum Master, Sprint Backlog, Daily Standup, Planning poker, Retrospective, Burn Down Chart, User Story, Epic, Spike, Team Velocity, Story Points, Continuos Delivery, Incremental development, Stakeholders, Agile, Lean, и немного из XP: TDD, Pair Programming
Еще Scrum Board

scrum,
KanBan

В скраме процесс очень прост. Есть продакт овнер, скрам мастер и команда. овнер решает, какие фичи нам нужнее и готовит список фич, команда планирует спринты - короткие промежутки времени. В идеале, один спринт - одна фича. Т.о. фичи нужно подгонять под размер спринта. Скрам мастер решает все проблемы команды, не касающиеся собственно кода. Т.е. всякие там условия работы, терки с овнером и внутри команды.
Удобство для овнера (заказчика) можно сразу видеть как все идет и отказаться от проекта, если что. Удобство для разрабов - если производительности команды выдерживается и делается то, что просил таки продактовнер, то это не разрабов дело, что продукт говно.
Это позволяет годами разводить лохов, при условии, что разрабы не дураки.

Канбан лишь визуализирует и накладывает ограничения на количество задач в работе

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



есть такое выражение: есть люди, которые практикуют скрам, и уде нет))

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


Доп литература:
http://tim.com.ua/
http://slashdot.org/
http://techcrunch.com
книга по менеджменту: читни пм бок