Как организовать организацию процесса разработки команды?

Question

[ksn]

Здравствуйте, уважаемые коллеги!

Выпало на мою нелёгкую судьбу такая участь: руководство коллективом из 3-4 человек (1 дизайнер и 2-3 разработчика ASP.NET MVC) для создания нового SaaS проекта со следующей недели.

Всё бы ничего, но это будет совершенно новый опыт для меня, так как раньше я всегда работал как ASP.NET MVC разработчик под руководством кого-либо. Поэтому, наверное, я смогу называться тимлидом.

Компания у нас небольшая, поэтому мне, как руководителю, придётся позаботиться обо всём: организация процесса разработки, подготовка сервера БД для разработки, настройка SVN, организация баг-трекера, базы знаний (хочу установить TikiWiki CMS Groupware), выбор методологии разработки (хочу задать TDD), контроль процесса разработки и собственно разработка. (По администраторским вопросам, скорее всего, будет помощь, конечно же.)

Продумать и организовать нужно множество вещей. Список, который выше, я уверен, даже не полный. Проект запланирован на полгода.

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

Разъясню все недостающие детали или то, что непонятно.

Большое спасибо!

Answer 1

[egor_nullptr]

Главное помните, что эффективное управление - это создание условий, а не постоянное вмешательство в оперативную деятельность.

Comments

[ksn]

Спасибо за Ваш ответ! А что, по Вашему, создание условий? Я это как-то узко понимаю.

[Сергей Горностаев]

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

[ksn]

@TheDeadOne Хм, ну вот я и написал списочек. Дальше что-то даже не знаю что и нужно. Я в неведении. Может быть Вы сможете чем-то дополнить?

[egor_nullptr]

@ksn советую вам прочитать книгу "Человеческий фактор. Успешные проекты и команды" (в оригинале - "Peopleware") Тома ДеМарко и Тимоти Листера. В ней вы найдёте ответы на многие ваши вопросы.

[ksn]

@egor_nullptr Отлично! То, что надо. Спасибо.

Answer 2

[Руслан Лопатин]

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

1. Чтобы у каждого разработчика было чёткое задание и понимание как его выполнить.
2. Контролировать исполнение, просто читая код, который разработчики выдают.

Если вам что-то не нравится в исполнении - поговорите с исполнителем. Но только о конкретных недоработках. Не нужно всяких теорий типа "это не ООП" и "так в TDD не делается". Есть лишь требования к задаче и степень их выполнения. Всё остальное - от лукавого. Вы работаете с людьми, а не с теориями. Используйте их сильные стороны, а не заставляйте их делать то, что у них явно не получается. Так что если у конкретного разработчика есть, например, индивидуальная непереносимость TDD, то задайтесь вопросом: вам нужен разработчик или TDD?

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

Comments

[ksn]

Спасибо за развёрнутый ответ! Но, как быть, скажем, если у одного не прижилось TDD, из-за этого что, допустить чтобы его код был без тестов? Т.е. значит все будут писать с тестами, а один вот такой вот, будет выдавать код без тестов? Как-то это не вяжется у меня с чётким строением проекта и его целостностью.

[Руслан Лопатин]

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

Но TDD - это написание тестов _перед_ написанием кода. Не всем это подходит, просто в силу особенностей мышления. Это стоит уважать. Но тесты, и адекватное покрытие ими кода, - обязательны.

[ksn]

@lorus Теперь понятно. Спасибо!

Answer 3

[Павел Осадчук]

Имею похожую команду.
развернут Trac + Hg, сервер автосборки jenkins, CI,
подтягиваю команду по TDD.

Я не рекомендую выводить коммерческий проект вашей компании на публичные репозитории, лучше поднимите свой сервер, делов на три-четыре дня

По TDD и внедрению его в команду рекомендую читать и слушать Роя - Roy Osherove
Нет такого случая когда "TDD кому то не подходит", это просто значит что вы как руководитель неправильно к человеку подошли.

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

Если вы новичек в тимлиде, прочитайте классику:
- "Мифический человеко-месяц", Брукс (довольно скучная, но нужная)
- "Человеческий фактор. Успешные проекты и команды" Том Демарко и Тимоти Листер (обязательно к прочтению)

Comments

[ksn]

Спасибо!

Answer 4

[sergealmazov]

Очень рекомендую сервис Trello. Подключаете всю команду и на виртуальной доске нарезаете таски. В каждый момент видите, что и где находится. И кто что делает. Вообще все видят.

В качестве репозитория - удобен BitBucket. Возьмите GIT. Он отлично подходит для Ваших задач. + на Битбакете закрытые репозитории и вас всего 3-4 человека. К тому же бесплатен.

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

Comments

[ksn]

Спасибо и Вам! Насчёт Trello отличная идея, но нет ли чего-нибудь похожего, но для расположения внутри организации? Также и с BitBucket: нужно хостить весь код только у себя, в своих стенах. Правила оформления кода нужны, да. Пожалуй, на основе таких же общих правил, найденных в интернете, составим свои. А может быть даже просто возьмём готовые правила, продуманные другими людьми.

[dpismenny]

ksn: Для того, чтобы хостить код у себя используйте GitLab. По-поводу таск-менеджера, чтобы держать у себя - Redmine. Случайно забрел =)

[sergealmazov]

Денис Письменный: RedMine сложен в настройке и дорог в поддержке. Лучше что-то попроще взять. Или у ребят из JetBrains был отличный трекер - попробуйте его.

[dpismenny]

sergealmazov: Мой выбор - trello+bitbucket+googledocs. Для общения - gmail+skype.

[sergealmazov]

Помнится, была хорошая штука - Google Wave, но уже нет.