Написание программного обеспечения часто является коллективным усилием. Чтобы сделать команду эффективной, нужны усилия.

В этой статье мы рассмотрим, что делает команду эффективной.

Нет битых окон

Вся команда должна сосредоточиться на качестве. Если что-то сломалось, каждый должен активно исправлять проблемы.

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

Вся команда должна сосредоточиться на качестве.

Вареные лягушки

По аналогии с вареной лягушкой лягушка медленно кипит в кастрюле, а вода внутри медленно нагревается.

Спустя долгое время вода в кастрюле станет такой горячей, что лягушка сварилась.

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

Все предполагают, что все остальные решают эти проблемы, пока все не изменилось.

Мы должны активно следить за изменениями в окружающей среде.

Кроме того, мы не должны позволять сползать рамки, если мы когда-либо хотим завершить проект.

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

Мы должны искать вещи, которых нет в исходном требовании, и думать, сможем ли мы вообще это сделать.

Тогда мы должны их убрать, если нет.

Общаться

Общение всегда важно. Без этого мы столкнемся друг с другом.

Команде также необходимо четко общаться с людьми за пределами команды.

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

Они создают легко читаемую и понятную документацию.

Они говорят в один голос и даже могут иметь чувство юмора.

Нам нужно создать бренд, чтобы нас воспринимали вне команды. Может придумать логотип или название, чтобы наша команда запомнилась.

Не повторяйся

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

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

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

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

Ортогональность

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

Ошибочно думать, что все они могут работать, не разговаривая друг с другом.

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

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

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

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

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

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

Это связано с тем, что изменение не повлияет на другие команды из-за ортогональности.

Мы можем уменьшить количество взаимодействий между отдельными работниками, m сократить время до доставки, повысить качество и уменьшить количество дефектов.

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

Это хорошо работает с ответственными разработчиками и сильным менеджментом проектов. Затем миру проектов нужен один технический и один административный руководитель.

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

Заключение

Мы можем создавать команды эффектов, устраняя дублирование усилий и эффективно общаться внутри и за пределами команды.

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

Следовательно, они могут быть построены без особой связи друг с другом.