1. Первый Кит
    1. Коммуникации
      1. любую проблему можно объяснить ненадлежащим уровнем качества коммуникаций
      2. даже при устройстве на другую работу о причине увольнения можно сказать: "недостаток коммуникаций для должного развития и выполнения задач"
        1. вас все поймут
        2. сами часто сталкиваются
  2. Второй кит
    1. Трансформация
      1. все просадки по срокам, неверные оценки, низкое качество решений можно объяснить идущей трансформацией команды/процессов/архитектуры/подхода
  3. Третий Кит
    1. Мотивация
      1. низкая/высокая/ее отсуствие- тема для бесконечных важных совещаний
        1. первым делом нужно повысить мотивацию команды
      2. объяснение для низкой производительности, плохое качество принимаемых решений
        1. Scrum master from Dark Side
          1. https://www.xmind.net/m/rDbdrv/
  4. Принципы
    1. при аргументации не использовать факты и данные
    2. не искать источник позникновения проблемы, искать виновных
    3. постоянные деструктивные конфликты с переходом на личности
    4. "я так вижу", "я лучше знаю"
    5. обязательное втягивание в процессы/совещания всех незаинтересованных лиц
    6. только инновации каждый день
  5. Отрицаем
    1. 1. Никогда не пренебрегать качеством.
      1. Все понимают, что из-за дыр в безопасности или из-за того, что приложение не выдержит нагрузку, наш проект не будет нужен никому.
    2. 2. Интересы пользователя превыше всего.
      1. Не важно как я считаю правильным, главное, чтобы пользователь смог быстро решить свою задачу с помощью нашего продукта.
    3. 3. Коллективная ответственность за качество продукта.
      1. Мы не ищем виноватых, получая релизные баги, мы анализируем, почему это получилось, ищем корневую причину, корректируем работу.
    4. 4. Не прокрастинировать!
      1. Стараемся не откладывать ничего на потом. Например, настройку боевого сервера нельзя отложить на последнюю итерацию перед бетта- тестированием.
    5. 5. Взаимопомощь и взаимообучение!
      1. Все помогают друг другу насколько это возможно, применяем сессии парной разработки с различным набором участников.
    6. 6. Мы команда!
      1. У нас одна цель и мы к ней идем! Минус в том, что каждый эту цель может понимать по своему или вообще не понимать.
    7. 7. Мы стоим Храм, не храм их костылей.
      1. Понимание всего продукта целиком, а не его отдельных частей, минус в том, что при не знании всего дродукта, новый код ,может поломать что-то имеющееся, а потом это еще и протестировать забудут.
    8. 6. Честность!
      1. Мы должны точно знать что у нас сейчас, в каком состоянии продукт, что мы успеваем, а что нет. Минус: очень сложно быть честными даже с самим собой.
    9. 7. Придерживаемся Scrum.
      1. Скрам не работает с жесткими сроками, поэтому мы его корректируем.
    10. 8. Будь Agile! Будь DevOps.
      1. Мы быстро меняемся в текущем контексте, используем новые технологии, опираясь на базовые принципа гибкой методологии.
    11. 9. Не стоит держаться за прошлое.
      1. Мы накапливаем опыт, аккумулируем знания. Но если целесообразнее переписать модуль с нуля, или создать новые прототипы, мы не расстраиваемся, а воспринимаем это как опыт.
    12. 10. Постоянное улучшение.
      1. Как процесса так и работающего продукта. Работающий продукт- одна из основных характеристик команды.
    13. 11. Обратная связь.
      1. От всех заинтересованных лиц, для корректировки процесса и продукта. Учимся слушать и слышать.
    14. 12. Критическое мышление.
      1. Все ошибаются, поэтому важно мыслить критически, а не настаивать на чем-то необоснованно.
    15. 13. Мотивация.
      1. Скрам подразумевает, что команда- это высококвалифицированная кроссфункциональная команда профессионалов. Мы стремимся к этому. Минус- в нашем контексте практически не достижимая цель.
    16. 14. Говоря, оперируй данными.
      1. Минус- часто сложно объективные данные получить
    17. 15. Следуй принципам Lean и Кайдзен.
      1. Мы стараемся бороться с потерями, простоями и перепроизводством, для того, чтобы обеспечить плавный поток поставки ценностей нашим пользователям.
    18. 16. Простота и фокусировка.
      1. Искусство минимилизации излишней работы с целью расстановки приоритетов.
    19. 17. Мы — самоорганизающаяся команда.
      1. Скрам нам говорит, что самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Действительно так, проверили на практике.
    20. 18. Постоянное обучение.
      1. Всех членов команды, в том числе и «не профильным» дисциплинам.
    21. 19. Оптимальный баланс между коммуникациями и действиями.
      1. Иногда легче показать, как это работает, чем долго объяснять. Коммуникации очень важны внутри команды. Но часто, не зафиксированная информация забывается.
    22. 20. Оптимальное наличие документации.
      1. Чтобы она не была избыточна, но была достаточной для принятие решений всеми заинтересованными лицами. Это конечно плюс, а минус в том- что никто не хочет ее писать.
  6. Команда, работающая над проектом- это своя экосистема. Как она будет реагировать на внешние воздействия зависит от ряда факторов: зрелости команды, процессов и т.д. Зачастую, внешние слухи заставляют полностью менять поведение команды, и это может привести к непредсказуемым результатам.