Если к вашему проекту подключаются новые люди, а тем более начинающие разработчики, то вам обязательно нужно провести новичков чрез терни к звездам.
Начинаем
Первым делом нужно дать сводные понятия о таких вещах как
# Agile Software Development
# Scrum
# Domain Driven Design
# Test Driven Development
# Object Oriented Design
# Enterprise Design Patterns
# Secure Development Lifecycle
# Дальше конкретные технологии (ASP.NET/BizTalk/SharePoint/WCF/WPF/etc)
Важные понятия
Чтобы стать сильным Agile объектно-ориентированным разработчиком вам обязательно нужно будет ряд простых понятий:
Separation of Concerns
Liskov Substitution Principle
Law of Demeter
Single Responsibility Principle
Open/Close Principle
Interface Segregation Principle
Dependency Inversion Principle
Закупаем литературу
Чтение статей и участие на форумах не сделает из вас сильного разработчика. Нужно обратиться к фундаментальным работам.
# Agile/Development Principles
* Code Complete: A Practical Handbook of Software Construction (Steve McConnell)
* Agile Software Development, Principles, Patterns, and Practices (Robert C. Martin)
* Agile Principles, Patterns, and Practices in C# (Robert C. Martin)
* Agile Software Development with SCRUM (Ken Schwaber)
* User Stories Applied: For Agile Software Development (Mike Cohn)
* Practices of an Agile Developer: Working in the Real World (Andrew Hunt)
# General Development
* Release It!: Design and Deploy Production-Ready Software (Michael Nygard)
* Ship it! A Practical Guide to Successful Software Projects (Jared Richardson)
* The Pragmatic Programmer: From Journeyman to Master (Andrew Hunt)
# Design Patterns
* Head First Object-Oriented Analysis and Design (Brett McLaughlin)
* Patterns of Enterprise Application Architecture (Martin Fowler)
* Design Patterns: Elements of Reusable Object-Oriented Software (GoF)
* Head First Design Patterns (Elisabeth Freeman)
# Domain Driven Design
* Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans)
* Applying Domain-Driven Design and Patterns: With Examples in C# and .NET (Jimmy Nilsson)
# Test Driven Development
* Test Driven Development: By Example (Kent Beck)
* xUnit Test Patterns: Refactoring Test Code (Gerard Meszaros)
* Pragmatic Unit Testing in C# with NUnit, 2nd Edition (Andrew Hunt)
# Refactoring
* Refactoring: Improving the Design of Existing Code (Martin Fowler)
* Refactoring to Patterns (Joshua Kerievsky)
# Secure Development Lifecycle
* The Security Development Lifecycle (Michael Howard)
* Writing Secure Code, Second Edition (Michael Howard)
И специализированная литература:
# C#/.NET Framework
* CLR via C#, Second Edition (Jeffrey Richter)
* Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Krzysztof Cwalina)
Следующий шаг
Теперь нам нужно научиться это применять, а усилит это практика "парного программирования", написание в стиле TDD. Было бы неплохо, чтобы за вами приглядывал опытный товарищ, но это не должно вас останавливать.
Источник: Starting Junior Programmers on the Right Agile Track Guidance
пятница, 25 января 2008 г.
Инструкция превращения Junior Developer'a в Agile-профи
Подписаться на:
Комментарии к сообщению (Atom)
Привет!
ОтветитьУдалитьВот зачем такой список писать - показать сколько ты книг прочитал или есть другая скрытая цель?
Что бы из перейти к гибким методологиям надо осознать их и почувствовать необходимость в них и больше НИЧЕГО. Лучше если это озарение придет к некоторым членам команды и остальные за ними потянуться (идеальный вариант). Если эти технологии никому не нужны и без них все прекрасно работает то какой в них смысл?
Все остальное можно варьировать - на то они и гибкие.
Спасибо!
Список - это краткий курс молодого бойца. Кстати, я бы рад похвастаться, таким количеством прочитанных книг... Но это суета :)
ОтветитьУдалитьОтвет простой.
1. Это уровень Shu. Без него дальше никуда. см. Shu-ha-ri подход. Читать нужно, нужно учить, нужно выполнять последовательно, это говорит первый уровень.
2. Осознать и почувствовать - это из области фантастики. Гибкие - сложные взаимодействия, сложные решения, сложные подходы. Их не нужно чувствовать, их нужно знать. Всё очень прагматично. Это лишь бизнес :)
3. Гибкие - это не варьирование. Гибкие это отношение к требованиям. Так что Agile это очень жесткая методология сдачи проектов в короткие сроки с отличным качеством. Этому нужно учиться у гуру. Книги это подарок мировых гуру нам... будущим гуру :)
В общем сорвём вуаль кокетства с Agile :)
Привет!
ОтветитьУдалитьПервый раз слышу такое определение гибких методологий. Я то думал что требования тут не при чем... Т.е. получается если я работаю надо гос проектом - то никакие гибкие методологии мне уже не подходят...вот ужас то.
Вот нашел на гибком сайте:
# Адаптивный процесс. В Agile не существует заранее определенного процесса, который бы описывал методы работы в проекте и диктовал команде как добиваться поставленных целей. Вместо этого команда должна сама определить тот процесс, который позволяет ей добиваться высоких результатов.
Нельзя прийти в команду и сказать - люди вы лохи, Agile это круто и я вам сейчас тут его построю и вас заодно. Это абсолютно неверный подход и ни к чему хорошему он не ведет. Надо осознать какие проблемы в работе и как их решить (все равно в какой методологии).
Например авторы тех книг, в своих личных блогах не выступают столь радикально. Например, если рассмотреть дизайн приложения. Пусть мы используем в своем гибком подходе XP практики - это же не означает что мы вообще должны отказаться от предварительного проектирования и сразу приступать к реализации некоторого модуля как это обозначено там (делаем только то что нужно сейчас). Поэтапный рефакторинг для достижения требуемой цели построения системы может оказаться неподъемной задачей. Или, например, возьмем другую практику - модульное тестирование. Написал модуль, написал для него кучу тестом, посмотрел что бы было полное покрытие, а на следующей итерации этот модуль переделали, и опять перелопатить кучу тестов догоняя до 100% покрытия.
Где тут оптимальный путь? Я думаю он где-то посередине и в этом и заключается гибкость методологий и практик, а тупо следовать букве закона, совершенно не понимая и не чувствуя зачем - может быть столь же опасно как и не знание этого самого закона.
Спасибо!
Всё верно.
ОтветитьУдалитьОсновная идея в том, что мы из бооольшого вотерфола (так как всех заколебало в конце разработки разочаровываться) превратили маленькие - вотерфольчики. Убрали икрементное добавление на итерационное.
А дальше всё поехало. Оказалось маленькие вотерфольчики совсем не вотерфольчики классические. Нужно оптимальней, быстрей, поменьше лишнего. Начали урезать докумы до инструмента моделирования, а не протоколирования. Начали смотреть на человеческий фактор. В общем всё то о чем ты говорил.
Но первый посыл - это изменяемость требований.
По поводу оптимального пути. Тесты выкидываются - без сожаления. Тесты - инстумент моделирования, понимания проблематики. Тесты не должны быть обузой. Как добавляются, так и выкидываются :)
В общем см. паттерны TDD.
А так классные замечания - в точку.
Кстати, проблема 100% переписывания кода тестов - это нормальная вестчь. И это не проблема. Это знак того что предметная область и решение было немного неполно. Это лечиться стандартными решениями: митинги, вовлечение заказчика, коллективное владение, демы, ретровспективы, сессии моделирования, в общем игра в коммуникацию и изобретения.
ОтветитьУдалитьОбъект воздействия этих практик: ЧЕЛОВЕК.
Цель воздействия: превратить каждого разработчика в консультанта предметной области.
Цель превращения: адекватность решений... человек интуитивно строить модели как можно ближе к реальности... и соотвесно код меньше переписывается.
А по первости (начало проекта) это стандартная вещь - когда куча вещей нестабильны и это требует постоянной переделки (кстати не понятно, при TDD драйве изолированность очень повышенная, и переделки носят локальный характер).
В общем больше коммуникации -- и работы будет меньше. А форсирование этой коммуникации должно быть постоянным и жестоким, но приятным :) Agile - это работа, серъёзная, может быть иногда через силу. Но главное смочь встать на рельсы, а дальше само должно попереть...
Ну раз у нас тут такая дискуссия пошла то вот еще мои мысли по поводу требований, для размышления.
ОтветитьУдалитьПриходит Заказчик к Программисту и говорит: "А что ты и правда можешь любой сайт написать?"
П - Конечно, я так же применяю гибкие методологии что позволит нам сильно ускорить проект и сделать именно то что вам нужно.
З - Круто. Давай тогда напишем мне вводилку для реестра заказчиков. Сколько мне надо на это времени и денег.
П - Ну задача не сложная, да и наработки у меня есть. Думаю за неделю справлюсь так что с вас 500 баксов.
З - Круто. Пойду к своему боссу, расскажу ему о поем крутой задумке, выбью деньги и потом можно начинать работать.
Ну вот, теперь деньги выделены, сроки обговорены, работа началась, но в середине пути (на третий день), когда список тестовых контрагентов перевалил за 2 страницы до заказчика наконец дошло что по ним бы неплохо сделать поиск - ведь их будет все больше и больше в дальнейшем.
Какие тут могут быть дальнейшие действия:
1. З не хочет попадать на бабки и потребует с П что бы он доделал эту функциональность в установленный срок, так как перед шефом краснеть
2. П в свою очередь не захочет наверное почти в два раза усложнять задачу, но вряд ли он сможет отвертеться, так как исходные требования вряд ли были зафиксированы и подписаны обоими сторонами.
3. Они могут доделать так как есть и вместе попросить шефа дать еще денег на еще одну неделю и простить их таких балбесов. Однако шеф, наверное, будет сильно удивлен, так как ему сначала сказали что гибкие методологии позволяют менять требования а потом выяснилось что не все так просто. И самое главное что он не сможет получить эту вводилку контрагентов к установленному сроку.
Так что в этом случает Программист будет супер счастлив и доволен когда исходные требования меняться не будут - во всех остальных случаях он попадает.
Я все понимаю что задача достаточно простая, но такая ситуация абсолютно реальная и проблему в целом тут видно очень хорошо.
Спасибо!
Спасибо!
Интересная задача.
ОтветитьУдалитьНо причём тут Agile? ;)
Постановка задачи была не по-Agile. А решение требуется по Agile.
Если кто-то хочет работать по Agile, а не прикрываться Agile. Он должен знать что это такое. В приведённом примере судя по описанию ни заказчик, ни разработчик не зрали, что такое Agile. Поэтому ответ простой - тут ничего не поможет :)
К тому же нарушена тонна принципов и практик Agile в приведённом примере. Поэтому повторю свой ответ - в морг :)
Приглашаю послушать тренинги по Agile ребят с AgileRussia. Например, у Асхата - и будет всё понятно. Или понятно где искать ответ на твою ситуацию :)
Кратким курсом молодого бойца вы называете 24 книги, некоторые из которых содержат более тысячи страниц и требуют очень вдумчивого чтения?
ОтветитьУдалитьСпасибо, такой Agile нам не нужен.
Блин, хотел ведь весь список написать... Похоже зря не написал, может быть заинтересовал бы :)
ОтветитьУдалитьзаходи на http://agileguru.ru - может такой понравится :)