Да, Зак и Джерри допустили ошибки.
Джерри надо было для начала разузнать, почему же команда потеряла мотивацию - много тасок, идиотский легаси код, плохо поставленные процессы, неинтересные таски... В зависимости от этого можно уже решать, что делать. Тимбилдинг подошел бы только для некоторых вариантов из перечисленных, ведь тимбилдинг - разовая вещь - отдохнули и забыли. Для других вещей можно выделять бонусы (з легаси какой-нибудь, например). И в любом случае Джерри надо было больше стоять на своем (хотя и не совсем понятно, как закончился этот разговор)
Если говорить о Заке и предложении добавить еще один митинг... Митингов должно быть ровно столько, чтобы они помогали работе, но не мешали. Да, это важный артефакт, но не стоит делать из этого пунктик. Тем более, без предварительного разбирательства (упомянутого выше) такой митинг скорее усугубит ситуацию в команде, чем улучшит. Присутствие других команд и (тем более) заказчика в ситуации, когда команда чувствует себя уныло, также ухудшит ситуацию.
Основная проблема в команде - неправильное использование ролей и титулов. Из этого выплывают много вещей.
- У нас же вроде как agile (судя по первому заданию). Пока на митинге действительно не решили, что это надо делать, пока не собрали требования, не оценили их, пока создали backlog, пока не заэстимейтили таски, пока не выделили спринт и пока не сказали, кто чем будет заниматься... работа не пойдет. Исправление: очевидно, надо бы делать все по порядку.
- Зак - директор компании. Если уж честно, он вообще не должен лезть в проекты и их функционал. Видно, что в компании Заку поклоняются, хотя его и не любят. Вывод - в компании плохо знают свое место. Каждый должен заниматься своим делом.
- Не надо садить Junior'а переделывать архитектуру (по себе знаю). Опять таки, каждый должен заниматься своим делом. Он не знает множества вещей. И, хотя и будет стараться сделать все как надо, все равно может что-нибудь забыть. +просто нельзя допускать человека, только что прочитавшего книгу по паттернам, к проектированию архитектуры. Паттерны тогда будут везде и всюду. И бессмысленно. Исправление: если уже перепиливаете архитектуру - займитесь этим с самого начала. Нужен весьма опытный архитектор, нужны качественно подготоваленные требования и т.д.
График 1: видно, что кто-то эпически вкалывал - количество тасок, которые надо выполнить, и которые были выполнены, идут даже не пропорционально. Таких людей явно хвалить надо.
График 2: Кто-то явно недорабатывал. Такой график в любом случае выглядит плохо. Явно видно, что процессы в команде поставлены плохо, т.к. в течении спринта количество тасок достаточно сильно вырастает (в случае, если таски все таки делались, все еще хуже - на одну сделанную таску добавляли минимум одну новую). Судя также по количеству тасок, эта команда сильно перерабатывала в конце месяца.
Причина конфликта: (глубинная) плохо поставленные процессы.
Прямо сейчас(по второму графику плохо понятно, когда это - сейчас) надо мириться - пойти поговорить, извиниться.
2.1 The HTML Parser shall produce an HTML markup error report which allows quick resolution of errors when used by HTML novices. (5 Points)
Данное требование является размытым.
- Не понятно, что такое HTML novices. Я бы скорее разбил на два требования: "Создать флаг, который позволяет выводить репорт про ошибку (--verbose)" и "Для пользователей новичков (например, с соответствующим стажем или статусом) включать флаг --verbose по умолчанию.
- Не понятно, что должно быть markup error report. Необходимо детализировать, либо дать ссылки на документ, в котором должна описываться форма репорта.
2.2 The XML Editor shall switch between displaying and hiding nonprinting characters instantaneously.
- Не заданы non-printable characters. Возмозно, стоит перечислить.
- Вообще требование плохо сформулировано. Не указан способ переключения. Не указано, зачем это делать, не указано, кто это будет делать.
- Не ясно, что означает мгновенно. Если это намек на то, как должно происходить переключение (например, через хоткей), то это плохой намек. И вообще, намеков не должно быть в таких вещах - должна быть четкая характеристика, что надо сделать.
2.4 User-ids are removed from the system by the system administrator when appropriate (5 Points)
- Необходимо задать значение слова appropriate. Это может быть expired критерий или какие-то другие бизнес правила.
- Необходимо определить процесс удаления. Можно просто положить в корзину, можно удалить насовсем.
- Необходимо определить, что нужно делать с данными, которые связаны с этими user-id. Могут быть случаи, когда какие-то сущности используют сущности с этими id, может быть случаи, когда этот id - часть больших записей (таблица с 100500 полями). Не ясно, удаление user_id влечет за собой удаление всех данных, или означает только зачистку одного поля.
- from the system Наверное, имеется ввиду БД? Я бы как-то поточнее описывал.
Сreate Class Diagram for the functionality Address book (10 Points)
