Внедрение протокола управления проектами и тестирования программного обеспечения с нуля

Question

Я работаю в небольшой компании (2-4 разработчики программного обеспечения), где программное обеспечение является «только» частью основного продукта (специализированных измерительных приборов). До сих пор программное обеспечение было построено от начала до конца без какого-либо формального процесса, но поскольку мы неуклонно растут как в количестве продуктов, так и в людях, очевидно, что нам необходимо принять . (проектирование, строительство, тестирование, поддержание), чтобы не взорваться в беспорядке

Проблема в том, что ни у кого из нас нет опыта реального мира в таких процессах. В статьях Википедии software development methodology и software development process перечислены многие практики, и я знаю о современных словах (гибких, экстремальных и т. Д.), Но мы по-прежнему не понимаем, как и с чего начать все это.

Что мы должны сделать, чтобы начать, учитывая, что в настоящее время у нас нет нет формального процесса, и цель будет иметь свет процесса, который помогает нам держать все под контролем, не замедляя нас вниз? Есть некоторые из них:

• Essential де-факто литература, которую мы должны читать в первую очередь?
• Основные инструменты? (У нас есть SCM, но стоит ли нам использовать что-то вроде FogBugz?)
• Практические рекомендации «сделайте это и это»?

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

Answer 1

Очень рекомендуемое чтение включает в себя: Agile Manifesto и Pragmatic Programmer. Впоследствии вы, вероятно, захотите ознакомиться с разработкой программного обеспечения Scrum или Test-Driven Development. По крайней мере вы должны иметь:

• хранилище Источник управления
• Ошибка системы слежения
• Стандартный набор инструментов для связи (Вики имеет тенденцию быть популярным для документации, эти дней) ,
• IDE
• Тестирование рамки

Многое будет зависеть от навыков вашей команды и домена приложения, к которому вы хотите войти. Познакомьтесь с некоторыми методологиями, затем практика их. Проведите 15-минутные постоянные встречи в начале дня. Разрабатывайте код постепенно с помощью записи неудачного теста, пропустите его, повторите мышление. Etc и т. Д.

Answer 2

Подписывание жестко чьего-либо взгляда на процесс разработки не будет работать для всех. Основываясь на реальных знаниях

1. Получите основы процесса разработки справа - см. The Joel Test.
2. Отслеживание все. Используйте систему, такую ​​как JIRA, FogBugz или так далее, чтобы отслеживать все проблемы, функции и ошибки, которые когда-либо сообщались. Отслеживайте, сколько времени вы тратите на каждую задачу; информация, которую вы подготовили, будет вам лучше.
3. Triage - Работа с заинтересованными сторонами, чтобы убедиться, что вы делаете на самом деле важно, а не только то, что вы думаю, важен. По моему опыту, разработчики и клиенты часто имеют разные взгляды!

Answer 3

Я огромный поклонник недавней Lean литературы предшественниками движения, Мэри и Том Poppendieck:

• Lean Toolkit
• Implementing Lean Software Development: From Concept to Cash
• Leading Lean Software Development

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

Answer 4

Я бы предложил попробовать Scrum для начала. Как легкая структура управления проектами, она должна соответствовать вашим небольшим потребностям команды.
Чтобы сделать это менее болезненным, я бы также предложил временно нанять кого-то знакомого с схваткой (возможно, сертифицированным мастером схватки), через 3-4 месяца вы должны быть в состоянии поддерживать его самостоятельно. Действительно, инвестиции в несколько месяцев опытного члена команды должны окупиться. И я не имею в виду аналитика, консультант или что бы вы ни называли человеком, который приходит, анализирует, делает презентацию, берет деньги и уходит, пока вы остаетесь с проблемой. Я имею в виду члена команды, который будет работать с вами, но также будет предлагать вам схватку через ежедневную практику .
Вы могли бы просто просто прочитать некоторые книги или отправить одного или двух членов команды на тренировку, но я думаю, что иметь возможность включить Scrum в вашу повседневную работу и начать изучение на примерах является лучшим.

Хорошее описание подробное описание (основано на ежедневной работе) было бы Scrum and XP from the Trenches (alternative source).