Принятие программного управления проектами и протокол тестирования с нуля

Question

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

Проблема в том, что никто из нас не имеет большого реального опыта в таких процессах. В методологии разработки программного обеспечения Wikipedia и процесс разработки программного обеспечения записей перечислены многие практики, и я знаю о современных модных словах (гибких, экстремальных и т. Д.), Но мы все еще потеряны о том, как и с чего все это начать.

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

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

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

Answer 1

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

• Хранилище исходного кода
• Система отслеживания ошибок
• Стандартный набор инструментов для общения (вики, как правило, популярны для документации, эти дней)
• IDE
• Структура тестирования

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

Answer 2

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

Хорошее описание, подробное описание (на основе ежедневной работы) будет Scrum и XP из окопов ( альтернативный источник ).

Answer 3

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

• Lean Toolkit
• Внедрение разработки программного обеспечения Lean: от концепции к деньгам
• Ведущая разработка программного обеспечения Lean

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

Answer 4

Жесткая подписка на чужое мнение о процессе разработки не будет работать для всех. Начните с настоящих основ

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